Tu o ții pe a ta și ai tras niște concluzii greșite.
Eu builduiam o imagine locală - de exemplu porneam de la un build de
nginx , îi aplicam ceva scripturi de customizare și obțineam o imagine
locală, să zicem nginx-mihai.
Pe aia încercam să o țin upgradată și toate containerele le derivam din
ea. Până aici cred că ești de acord. În felul ăsta nici nu descărcam
decât o dată, nu că ar mai conta.
Într-adevăr nu îți trebuie systemd în container. Dar pe debian toate
serviciile, inclusiv nginx depindeau de systemd. Deci dacă vrei să
instalezi un jessie sau mai nou oricum trebuie să instalezi și systemd.
Acum ce e drept că în principiu poți să îl instalezi dar să nu îl
pornești, că tu oricum nu rulezi decât acel exec. Nu mai știu care era
problema atunci, poate o fi fost un blocaj al meu, n-are rost să
despicăm firul în patru.
Asta cu rulat php, mysql în același container nu știu de unde ai scos-o.
docker e un container- un serviciu, am containere de toate versiunile de
php, de node, de redis și tot ce mai trebuia. Doar că la trecerea de la
wheezy la jessie am avut acest blocaj, nu mai țin minte, hai să zicem
că a fost blocajul meu mental ca să o închidem.
Cert e că au fost diverse discuții pe tema asta la acel moment și tot
atunci alpine a devenit popular, tocmai pentru că era mai "primitiv".
Practic un container docker nu are nevoie de un init prea complex,
trebuie doar să seteze ip-ul și să pornească un script ( mă rog, ar mai
fi câteva dar simplificat vorbind). Ori, noi avem unul foarte complex .
Uite, acum mă uit pe computerul meu, acum nginx nu mai depinde de
systemd ( apache : Pre-Depends: init-system-helpers (>= 1.54~)
) deci asta a fost soluția în final . Ok, m-am lămurit, vorbim de epoci
diferite. Atunci am încercat în fel și chip să scap de el, se pare că
s-a rezolvat ulterior.
Uite aici câte containere aveam, de unde ai scos-o că rulam mai multe
servicii pe unul? Păi așa puneam cpanel :)
ls docker-project/
create-django-stack create-php-once docker-dovecot docker-node
docker-php56-40-fpm docker-php7.4-fpm docker-puppeteer
docker-slapd lemp.yml oracle-mysql templates
create-lemp create-redmine docker-dynamo
docker-node-alpine docker-php7.2-fpm docker-php7-fpm
docker-python2 lemp-54.yml newdb.sql README.txt
create-node django.yml docker-nginx-naxsi
docker-php54-fpm docker-php7.3-fpm docker-php7-libkolab
docker-redis lemp-56.yml node.yml sites
În fine, discuția chiar că a divagat, dar ce să fac, ai tras niște
concluzii care nu mă avantajează și trebuie să te contrazic- măcar
pentru că sunt false :)
Ceea ce voiam să spun e că în zilele noastre sunt situații în care ai
nevoie de scripturi cât mai simple, docker de pildă, iar distribuțiile
merg spre soluții din ce în ce mai complicate.
CentOS de pildă (presupun că e la fel și la RedHat) are totuși un sistem
destul de spartan; alpine e de-a dreptul primitiv; debian am impresia că
încearcă să împace și capra și varza, dar cumva ubuntu (și nu e prima
dată când îmi dă impresia asta) mi se pare că s-a dus undeva de unde nu
mai poți să faci lucrurile simple și nu văd nici un folos. Dacă tu vezi
un folos... please, dar mâine, că sunt moș și mă culc :)
On 3/22/24 22:48, Petru Rațiu via RLUG wrote:
Upgrade-ul se face facand rebuild de la un tag mai nou (si probabil vrei
unul batut in cuie ca sa nu se schimbe la fiecare build decat daca tii
neaparat).
Also, nu-ti trebuie systemd in container decat daca ai explicit nevoie de
systemd (pentru naiba stie ce voodoo). Ca sa rulezi nginx (sau apache sau
whatever), setezi ca entrypoint binarul de nginx cu ce parametri vrei, si
ruleaza doar el in "chrootul" ala. Mai flexibil de atat, se practica sa ai
ca entrypoint un script care face alte chestii la runtime (poate hookuri
sau ceva) si la sfarsit face exec nginx. Vrei exec la final de entrypoint
ca sa mufeze corect stdout/stderr si semnalele cu docker sau ce alt runtime
folosesti. Sau mai bine de atat, folosesti direct din upstream imaginea de
nginx sau apache sau mariadb care expune fix ce are nevoie (si eventual o
forkuiesti tu local daca vrei un modul in plus sau ceva).
Daca din ceva masochism vrei sa ai mai multe procese in acelasi container,
se mai practica sa rulezi ca top-level process altceva gandit pentru asta
(am vazut ca tini e foarte popular, in medii mai phpiste am vazut ca se
practica supervisord), dar trebuie tinut cont de cum se trateaza semnalele
si cum obtii logurile (probabil prin fisiere puse intr-un volum extern).
Aproape niciodata nu vrei sa intri in el sa dai apt upgrade, decat poate
pentru teste.
Patternul cu "facem un container cu apache si php si mysql in el" e gresit
(unless vrei un mediu de development fara prea multe zorzoane), normal e sa
ai un container cu apache, unul cu php, unul cu mysql, sa le poti intretine
separat. Altfel mai bine faci un vm si-l tratezi batraneste.
Tot ecosistemul cu containere pleaca de la conceptul de immutable
infrastructure, pornesti imagini "pe curat" de fiecare data si stii ca
orice modificari pe ele tin pana la urmatorul restart. Vrei update-uri
explicite, faci altele. Asta ajuta sa nu-ti bati capul daca a plecat pe
acelasi server sau are acelasi ip samd samd. Discutabil daca se justifica
cand de fapt ai un server, dar daca inoti impotriva curentului nu-i de
mirare ca esti tras periodic la fund.
Also, hate-ul cu alpine nu se refera la busybox (appleturile alea din
busybox sunt relativ usor de invatat ce limitari au si la o adica poti pune
binarele care iti trebuie), ci la faptul ca libc-ul folosit nu e glibc sau
eglibc, ci musl, o implementare mult mai light. Care merge suficient de
bine pana dai cu capul de chestii lipsa (sau de binare "pentru linux" care
au fost linkate cu glibc).
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
