Salut In primul rand cum se zice la noi "la mulțean!", deci o sa ma limitez azi la a face mega polemici :-P
Asimov vs. Herbert, coca coca vs. pepsi, push vs. pull ... subiecte mai mult sau mai putin filosofice de discutat la un pahar de vorba ... Polemica intre push si pull e mare si pe internet, dar am gasit un "landmark" care, vorba poetului, "face sens": pentru chestiile statice si cvasi-statice push, pentru chestii dinamice si mega-dinamice pull. Sau eventual direct best of both worlds, dupa gusturi. La push (cel putin pentru ansible) ai sarit totusi peste o chestie mega-importanta, si anume idempotenta. Daca ai dat definitie de push/pull, sa dau si eu una: idempotenta => rezultatul final ar trebui sa fie acelasi fie ca rulezi o data, de doua, de zece ori sau de mii de ori aceeasi chestie. Singura chestie ar fi sa nu o rulezi de 2 ori in paralel in acelasi moment, ca in unele cazuri s-ar putea sa dea cu virgula (in conditiile in care se fac si modificari la momentul respectiv). La fel, nu conteaza ca e un server, ca sunt 10, 100, 1000 sau chiar mai multe, nu te apuci tu sa intri pe fiecare, ci face CM_push-ul pentru tine, cel mai probabil in paralel. Desigur, de la un punct in colo (mii / zeci de mii de masini) un sistem pull posibil poate scala mai bine pentru ca workloadul se imparte per interval (nu se executa job-urile in acelasi timp), doar ca incepi sa pierzi controlul in ceea ce priveste CAND se intampla lucrurile, ceea ce s-ar putea conteze, s-ar putea sa nu. In plus la un sistem pull se vor consuma resurse inutil de fiecare data cand verifica configuratiile locale, chiar daca TU stii prea bine ca nu s-a facut nicio modificare (in schimb e o metoda in plus de detectie ca cineva de-al casei sau nu neaparat si-a bagat nasul pe unde nu trebuia - ma rog, nu o metoda pe care sa te si bazezi ca intrusion detection). Iar aia cu "am facut eu asta, tu faci aia", cat timp exista un uber-scenariu (sau mai multe) nu-si are sensul, in acel uber-scenariu ai definit tot ce misca (binenteles, totul definit granular, ca sa poti rula pe bucati). Pentru ca exista idempotenta, ajunge sa rulezi bucata de care ai nevoie (poate sa fie acel uber-playbook, sau doar unul sau mai multe bucati / roluri, sau doar un simplu task, si asta pe un singur server, un grup de servere sau ce vrei, libertatea fiind deplina). Cum iti organizezi bucataria, iarasi, depinde de bucatari. In fine, o discutie de genul push/pull nu cred ca se poate termina vreodata, ambele variante au plusuri si minusuri si din fericire e loc pentru ambele pe lume. Insa pentru cultura mea generala as fi curios cum vezi tu urmatorul scenariu pe varianta "pull" (ca pe push ar fi doar o insiruire de task-uri cu niste parametri): - update sa zicem de kernel la un "cluster" de 12 (sau 24, sau 100, cate vrei) sa zicem in spatele unor LB, cu reboot inclus, astfel incat sa nu fie mai mult de 1 (2, 5, 10, 20 ...) server(e) down la un moment dat (ca altfel s-au dus naibii performantele clusterului) si in worst case de 1, 2, 3, x erori sa se opreasca toata procedura (aici puristii cu containere ar zice clar - ma rog, NU la update de kernel, ca nu e cazul: deploy new containers and dispose old ones, ca asa e treaba in 2020) sau daca iti place mai mult ideea cu un cluster de măria cu 3, 5, 7, 9, x servere be my guest ... ideea e ca doar un numar limitat de servere pot fi afectate la un moment dat, iar procedura sa se poata opri automat atunci cand erorile trec de un anumit prag Alex On 28-Jun-20 5:06 PM, Petru Rațiu wrote: > On Sun, Jun 28, 2020 at 4:33 PM Alex 'CAVE' Cernat <c...@cernat.ro> wrote: > >> 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). > > Asta e tot clenciul: nu vreau sa fac eu lucrurile _acum_, vreau sa descriu > la un moment dat cum sa fie si ele sa se aplice continuu pe servere as > needed. Push inseamna ca lucrurile le triggerezi tu pe server ad-hoc, care > server trebuie sa fie available si intr-o stare care sa poata prelua > schimbarile alea. Pull inseamna ca nu ma leg eu la server, daca maine fac > altul va face fix acelasi lucru, fara sa trebuiasca sa-mi aduc aminte sa-i > zic eu ce e de facut. Also, cand ai cateva zeci-sute-mii de servere, vrei > sa-si faca ele in paralel treburile, nu sa te duci pe fiecare (plus ca e > mereu unul care e down for maintenance si trebuie sa-l tii minte si sa > revii cand e cazul etc). Also cand lucrezi in stil push incepi sa ai > probleme de coordonare cand sunteti mai multi "ai facut tu aia, o fac eu, > etc". Nu zic ca nu se poate dar scula nu te incurajeaza sa evoluezi in > directia asta, e pe abordarea "un baiat cu 5 servere". Cand sunteti 5 si > sunt cateva sute iti dai seama ca trebuie schimbata abordarea, nu mai merge > cu "sa fac aceleasi lucruri dar mai mult / mai repede". > > Pe scurt, vreau sa fiu inginer de sistem care descrie cum sa fie sistemul, > nu meserias de sistem care il ia mereu la ciocan si cheie franceza. Fiecare > abordare are nivelul de scara unde e mai eficienta, dar e diferenta intre > ele e mai profunda decat de cat de shiny si yaml-istice sunt sculele. > > Again, nu tineam musai sa intru in discutia asta, voiam doar sa punctez ca > asta cu minunile automatizarii nu inseamna doar sa ai ciocan nichelat. Si > in nici un caz nu e atat de simplu ca "citesti 2 howto-uri". > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
