De anul trecut am trecut incet, incet spre DevOps. Mai bag si pe security, da mai rar in ultima vreme.

Doar Ops n-am mai facut de ceva vreme si evident, ca m-am mai ramolit un pic pe partea asta. Iar cu Dev-ul din DevOps  o lalai in Python, ca e bun pentru a programa chestii de sistem.

Pentru un client nou, am avut de facut un server de deployment pentru niste servere fizice astfel incat sa bagi serverul poaspat scos din cutie in priza, sa-l conectezi la retea si 15min mai tarziu sa-l ai instalat. Bine, depinde de viteza mirror-ului asta, ca prin unele tari merge intrnetul de zici ca’l aduc cu galeata.

Ca si distro am folosit Ubuntu 16.04 LTS pentru ca $reasons.

Partea usoara e sa instalezi un server de TFTP si un server de DHCP care sa aloce IP-uri si sa spuna la clienti cum se cheama fisierul pentru BOOTP.

Ca si server de deployment am folosit tot un Ubuntu 16.04, sa fie instalarea intre prieteni sa mearga bine si fara probleme :))

Si pentru ca multe servere, evident ceva care sa faca orchestrare si management. Si ca ziceam mai sus ca o lalai cu Python, SaltStack a fost raspunsul.

Asa ca, cum se face sa deployezi multe servere fizice in vremea lui AWS, GCP si Azure:

1. Se instaleaza atftpd, se modifica  /etc/default/atftpd si se schimba USE_INETD din true in false. Dupa care systemctl enable atftpd si systemctl start atftpd.
2. Se downloadeaza un ISO de Ubuntu Server 16.04 si se monteaza cu loop pe sistem.
3. Se copiaza de unde s-a montat ISO continutul directorului netboot in /srv/tftp.
4. Dupa nevoie se editeaza /srv/tftp/boot-screens/menu.cfg astfel incat sa bata cu realitatea la fata locului. Cateva note la exemplul meu:
   1. installerul e retardat si daca serverul de DNS raspunde cu AAAA RRs, o sa vrea sa se conecteze pe IPv6 la mirror, chiar daca nu are ruta default pe IPv6.
   2. A.B.C.D se inlocuieste cu adresa IP a serverului de TFTP
   3. eno3 e cum stiu eu ca se cheama interfata de retea pe care o foloseste masina ce va fi instalata pentru DHCP, pentru ca in cazul meu aveam mai multe interfete si se blocheaza installer-ul si te pune sa alegi una (chiar si cu optiunea auto tot la fel face).
5. Se creeza /srv/tftp/preseed/ubuntu-16.04-preseed.cfg unde se va scrie configuratia pentru installer. La fel, cateva note la exemplul meu:
   1. Installer-ul va crea un setup de tip RAID10 din primele patru discuri de pe sistem. Recipe-ul de RAID l-am bunghit cu #mumu help, ca nu prea e documentat cum se face. E un pic de magie in toata treaba aia.
   2. Peste va configura LVM si / va fi un LV de 30GB pe VG-ul nou creat.
   3. In cazul in care masina va avea mai multe interfete de retea, trebuie specificat ce intefata sa foloseasca in mod automat. Altfel va sta ca boul asteptand sa selectezi pe care sa o folosesti.
   4. $magic_postinstall_setup_script poate fi orice script (bash, python, perl etc.) care face chestii pe sistem inainte de reboot dupa instalare. Scriptul asta de obicei se pune pe un server web, se downloadeaza si se executa. O sa revin mai tarziu cu ce si cum.
6. Se instaleaza isc-dhcp-server si se modifica /etc/dhcp/dhcpd.conf sa dea adrese dintr-un pool la clienti si se adauga urmatoarea optiune in definitia de subnet:

7. filename "pxelinux.0";

   systemctl enable isc-dhcp-server si systemctl start isc-dhcp-server.

8. Se buteaza o masina fizica si se asteapta pana termina de instalat. Daca da oroare sa ceva, trebuie fixata in fisierul de preseed, reboot si de la cap cu instalarea pana merge. Nu exista checker pentru fisierul de preseed. Pe mine m-a enervat maxim treaba asta ca instalarea se facea pe niste Dell R430 si pana buteaza alea mori incet.

Ziceam mai sus ca inainte de reboot, pot da comenzi in sistemul nou instalat sa-l configurez cumva inainte sa porneasca prima oara.

d-i preseed/late_command string \
 in-target wget -P /tmp/ -t 0 -c http://A.B.C.D/myscript.sh; \
 in-target chmod +x /tmp/myscript.sh; \
 in-target /tmp/myscript.sh; \
 in-target wget -P /tmp/ https://repo.saltstack.com/apt/ubuntu/16.04/amd64/latest/SALTSTACK-GPG-KEY.pub; \
 in-target apt-key add /tmp/SALTSTACK-GPG-KEY.pub; \
 /bin/echo "dev.raid.speed_limit_max = 1000000" >> /target/etc/sysctl.conf; \
 /bin/echo "deb http://repo.saltstack.com/apt/ubuntu/16.04/amd64/latest xenial main" > /target/etc/apt/sources.list.d/saltstack.list; \
 in-target apt-get update; \
 in-target apt-get install -y salt-minion

Se pot da comenzi succesive in late_command. Ce trebuie stiut:

1. Cuvantul in-target ii zice installer-ului sa faca chroot() in noul sistem si sa execute comanda de acolo.
2. Comenzile date fara in-target se ruleaza de pe mediul de instalare (din installer cum s-ar zice).
3. Se foloseste combinatia normala + in-target ca unele comenzi nu merg in chroot, ca de exemplu echo $stuff merge doar din installer, in chroot nu merge. Poate imi scapa mi ceva, dar sa stau sa debughez asta dura prea mult.

Ziceam ca pentru orchestrare si configurare am mers pe SaltStack. Eu pentru ca are minioni, colegul de proiect ca i s-a luat de Puppet. Bine, nici eu nu m-am omorat dupa Puppet ca e scris in Ruby.

Cine a facut SaltStack asta a fost inteligent si minionii daca n-au nici o configuratie, o sa incerce sa se lege la salt.domain.name. Si asta inseamna ca tot ce trebuie sa am este un salt-master instalat si configurat acolo un pic, configurat DNS-ul atfel incat salt.domain.com sa bata la un serverul pe care ruleaza salt-master si, dupa ce fiecare masina fizica se rebuteaza, minionul se va conecta automat la salt-master. Magie adevarata.

salt-key –accept-all este raspunsul la intrebarea cum confirm ca minionii inregistrati sunt ai mei :)