Sincer, s-ar putea sa-ti bati cuie multe in cap la inceput pana cand vei
incepe sa intelegi cum functioneaza, dar overall o sa ai numai de
castigat, mai ales cand ai categorii de servere / servicii cu
configuratii comune (sau parametrizate). Insa daca ai fiecare server cu
motul lui, atunci s-ar putea sa te incurce mai mult decat sa te ajute
(sau eventual sa il aplici doar la chestiile comune), insa cand ai macar
3 "de alea", 3 "de alelalte" samd, folosind un "configuration manager"
te ajuta mult si sa eviti pe cat posibil acele "subtle differences" (sau
nu neaparat subtile, ca faci pe 2 din 3 modificari la cine stie ce
config si dupa aia te intrebi de ce merge cu virgule).
Dupa cum vad eu ca merge IT-ul, scripturile de instalare a serverelor nu
prea mai sunt la moda, ci se merge pe definirea "starii" dorite a
sistemului / serviciilor, intr-un format descriptiv (de obicei yaml).
Cum se face la "low level" nu te intereseaza, si da, aici pe alocuri
ansible poate sa devina lent (unii ar zice "ca porcul"), insa ai
garantia ca dupa ce ai rulat task-urile respective (daca le si scrii
bine) pachetele si configuratiile sunt asa cum trebuie sa fie,
serviciile au fost restartate la nevoie samd. Nu zic ca m-am lovit de
buguri idioate (care nici macar nu sunt catalogate ca buguri, ci "asa
functioneaza"), dar trecem peste. Si cat timp nu rulezi efectiv ceva nu
ai nicio amprenta de idle, ca nu exista serviciu sa ruleze pe clienti.
Si nu stiu ce-l deranja pe Petru ca e push, pentru ca pana la urma tu
decizi cand vrei modificarile, nu cand "vrea muschiul serverului" (de
asta am injurat puppet-ul la inceput, pe urma au bagat si partea de
meckanize). Singurul scenariu la care ma gandesc ca ai nevoie de pull e
atunci cand vrei sa automatizezi total instalarea unui server fizic (si
sa incluzi un script de post-install), altfel se reduce la 1) push
creare / instalare / clonare de vm / lxc container 2) rulare config
management, ambele in principiu posibile ca task-uri in ansible. Si
toate astea cu absolut nimic instalat in plus pe "client", decat un
acces ssh si python-ul, care oricum e instalat by default din ce stiu eu
cam pe orice distributie de linux (si pe alocuri vreo 2-3 pachete de
python instalate automat de catre ansible la momentul necesar).
Oricum, ce merge acum, aproape garantat ca peste 5-10 va trebui sa-ti
bagi surubelnita pana la capat, dar macar vei avea un punct de plecare
cu "inventarul". Pana atunci poti avea la nevoie un server nou
functional in maxim minute / zeci de minute (bine, nu vorbim aici de
mega importuri de date, ca atunci se impute treaba). Ca de fapt asta e
toata smecheria cu "configuration managementul": sa ai chestii comune
aplicabile la mai multe servere, altfel ... mai rau te complici si mai
rau pierzi timpul.
Si ca sfat: inainte de rularea pe server fizic poate n-ar fi rau sa
testezi pe o masina virtuala (o data, de doua, de zece ori pana iese
perfect). E mai simplu de refacut, mai ales daca hypervizorul suporta si
ceva snapshot-uri.
Alex
On 28-Jun-20 3:51 PM, Adrian Popa wrote:
> Planul meu era sa ma ajut de ansible pentru taskuri relativ repetitive post
> OS-upgrade. De exemplu, instaleaza cacti versiunea X, sau upgradeaza cacti
> versiunea Y. Am suficient de multe servere vechi in ograda cat sa merite
> investitia de efort. Chiar daca fiecare server e facut de capul lui, e o
> oportunitate buna sa le mai unific configurile.
>
> Ce-i drept, post install nu cred ca orice modificare o sa se faca via
> ansible (obiceiuri vechi), ci tot cu shell, dar ma gandesc ca daca fac
> backup de config/chestii modificate si fac restore la upgrade cu ansible,
> ar putea sa mearga si pe termen mai lung, chiar daca nu e 100% clean/the
> ansible way.
>
> Oricum e mai bine decat sa fac server cu server si sa nu ramana nimic
> documentat post upgrade, ca peste 5-10 ani sa o iau de la capat...
>
> Daca trimit trafic din productie in server si nu merge, asta e - castig
> experienta si vad ce am uitat, se imbunatatesc scripturile, workflow-ul,
> etc. Toata lumea castiga (mai putin end userul).
> :)
>
>
> On Sat, Jun 27, 2020 at 1:55 PM Andrei POPESCU <andreimpope...@gmail.com>
> wrote:
>
>> On Vi, 26 iun 20, 14:51:09, Adrian Popa wrote:
>>> P.S. De la Centos 7 la 8 există upgrade path, sau e aceeaşi problemă?
>> Oare
>>> pe Ubuntu de ce se poate şi pe CentOS nu? Sau intrăm în holy flame war?
>>> Mersi!
>> Ubuntu probabil moștenește (mai mult sau mai puțin) actualizarea "in
>> place" de la Debian.
>>
>> În Debian orice pachet *trebuie* să suporte actualizare "in place" de la
>> versiunea "stable" precedentă ("oldstable")[1][2].
>>
>> Excepții se admit doar în cazuri speciale[3], care ar trebui să fie
>> documentate în Notele de lansare (Release Notes) și/sau NEWS.Debian
>> (afișat automat dacă pachetul 'apt-listchanges' este instalat).
>>
>> Versiunile pachetelor din Ubuntu (LTS) posibil/probabil să nu corespundă
>> 1:1 cu cele din Debian "oldstable"/"stable". În caz de diferențe depinde
>> de Ubuntu să testeze și, dacă este cazul, să modifice pachetele ca să
>> funcționeze actualizarea "in place".
>>
>> [1] nu găsesc acum exact unde este scris în Debian Policy
>> [2] pentru versiuni mai vechi de "oldstable" nu se oferă garanții și în
>> general nu se testează, deși este posibil să funcționeze
>> [3] exemplu: aplicația s-a modificat prea mult și nu oferă posibilitatea
>> de actualizare automată
>>
>> Spor,
>> Andrei
>> --
>> If you can't explain it simply, you don't understand it well enough.
>> (Albert Einstein)
>> _______________________________________________
>> RLUG mailing list
>> RLUG@lists.lug.ro
>> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
>>
> _______________________________________________
> RLUG mailing list
> RLUG@lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
