On Tue, Mar 26, 2024 at 11:53 AM Mihai Badici via RLUG <rlug@lists.lug.ro> wrote:
> On 2024-03-26 11:26, Alex 'CAVE' Cernat via RLUG wrote: > > On 26-Mar-24 11:21, Petru Rațiu via RLUG wrote: > >> Daca tratezi containerele ca pe golden images de VM care au si pe > >> dracu si > >> pe ta-su in ele, o sa ai un numar de probleme la care raspunsul mai > >> normal > >> la cap e "de ce nu folosesti pana la urma vm-uri". > > > > ca ai mai putin overhead si pornesc mai repede, cu posibilele riscuri > > de securitate la pachet (ca ai acelasi kernel) - asta ca si comparatie > > intre LXC si VMs > > > > Alex > > > > ps: nu-s avocatul LXC (nici nu folosesc), mai curand al VMs, deci nu > > sariti :-P > Păi în final tot acolo ajungi. Eu am construit imagini din imaginea de > bază, deci în sistem ai imaginea de bază plus diferențele ( cum era la > mine, una era wheezy+php, alta wheezy+nginx. Cele două imagini ar > cuprinde imaginea de bază -cum zice Petre, golden image - ca la > Microsoft+ diferența care e pachetul util plus ceva customizări. Acum că > rememorez am și o explicație, la un moment dat ajunsesem folosind > imagini de php de la docker la un balamuc total în ceea ce priveșțe > modulele de php; eu aveam deja un script cu care le instalam pe mașina > fizică și în felul ăsta, punând scriptul în docker file-ul de php > obțineam o configurație identică cu cea a serverului fizic în privința > modulelor. Inițial scopul deploymentului a fost să realizez un mediu de > test pentru dezvoltare, înainte de a pune aplicatia pe serverul fizic, > care, ați ghicit, era tot wheezy. Așa se explică și insistența mea de a > folosi imagini de jessie, ca după ce făceam upgrade pe cele fizice la > jessie să am un mediu compatibil. > Ulterior urma să folosesc sistemul și în mediul de producție și dacă > stau bine să mă gândesc chiar încă există unul în producție, dar > varianta ulterioară, cu alpine. Tipul respectiv însă a avut probleme > fără legătură cu IT-ul și proiectul a rămas așa... > PS: am avut și virtuale cu golden image pe hyperv. După câțiva ani de > update-uri diferențele au devenit mai mari decât imaginea așa că le-am > comis sau nu mai știu cum se numește la MS și am trecut la imagini > normale ca să economisesc spațiu... > > Cred ca capcana in care se cade usor aici e impacarea a "vreau ca mediul de dev sa fie identic cu productia" si "vreau ca devii sa-si poata face management singuri la mediul lor asa ca trebuie sa fie cat mai simplu". Daca le iei pe ambele ca atare, inseamna ca ajungi ca mediul de productie sa fie designed de devi, pe criteriile lor, si in majoritatea cazurilor nu vrei asta :) Proiectul la care lucrez de vreo 5 ani si unde am inceput sa dau serios cu nasul de de-astea a inceput cu aceeasi abordare: un container facut de mai stiu eu cine ca de pe tutorialele de youtube si tiktok, cu purcel si catel in el, unde mergea totul ca root ca sa n-aiba probleme de permisiuni, care avea php, nginx, node, supervisord si inca cativa pokemoni. Dupa ce am pierdut niste zeci de ore citind diverse dockerfiles de la oameni mai seriosi, am facut o abordare hibrida, cu multiple stage, ceva gen: FROM: php-fpm:<versiune> AS base < compilat diverse module, configurat php, pus scripturi custom> CMD php-fpm -f FROM base AS local < instalat nginx, supervisord, node, balarii> CMD supervisord Scripturile de build fac docker build -t base --tag <production tag> ; respectiv docker build -t local --tag <local tag> Devii isi trag tagul local, si au acolo tot cele trebuie (node imi trebuie pentru ca au un webpack care face minuni cu js-uri si css-uri, pe productie nu ruleaza decat la build). Pe producite plec cu tagul de base, pun in el codul (masat cu composer si webpack pe alte containere dedicate) si la runtime nu stie decat de fpm, nginxul e in alt container, etc, etc. In timp si pe local am mai facut split la chestii (gen nginx dedicat pentru ca am inceput sa avem mai multe servicii care depindeau de url si care aveau nevoie de ssl, etc), dar pot lucra local cu o chestie care seamana doar vag cu productia, dar macar au acelasi versiuni, cai pe disc, etc. Daca in schimb lasi ca deciziile de "sa fie usor pt dev" se informeze setupul de prod, ajungi la probleme de-astea de care devilor nu prea le pasa, gen cum facem upgrade-uri, cum strangem loguri, cum stim cine ce-a modificat, etc. -- P. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
