[rlug] flame de vineri ( ubuntu)

[Mihai Badici]

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).
>