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). -- P. On Fri, Mar 22, 2024 at 10:26 PM Mihai Badici via RLUG <rlug@lists.lug.ro> wrote: > Alpine e cu bizibox ca să facă economie de spațiu. De acord că e o > prostie dar și-a făcut treaba. > > Acum că am căutat pentru că m-ai provocat, systemd pare că a fost > introdus în jessie deci pe atunci am avut de-a face cu situația asta, > pentru că wheezy era deja oldstable și nu voiam să mai lucrez cu el > > Nu aș fi schimbat nici distribuția că preferam să lucrez cu ceva ce > știam. Și evident ca nu intram pe containere să dau update, asta a fost > presupunerea ta, ca să mărești flame-ul , eu am zis doar că nu le puteam > upgrada :) > > Ăsta primul e de la început, 2016 - cel din 2022 e cu alpine, dar n-am > prea mai lucrat la el, da fost doar o actualizare... > > drwxr-xr-x 10 mihai mihai 4.0K Oct 13 2016 docker-local > -rw-r--r-- 1 mihai mihai 27K Jun 15 2018 docker-php5-fpm.zip > drwxr-xr-x 22 mihai mihai 4.0K Dec 7 2022 docker-project > > > cat docker-mariadb/Dockerfile > FROM debian:wheezy > > > On 3/22/24 22:08, Petru Rațiu via RLUG wrote: > > Serious, io rulez nginx (si altele) in productie in containere de ani de > > zile si nu m-am lovit de problema asta cu systemd. I guess ca se poate > daca > > tii neaparat, dar n-a fost nevoie. Ah si tin up-to-date (cat de cat) > > imaginile. Desigur, in moduri total diferite de "intru pe toate vm-urile > si > > dau apt upgrade", dar asta e. > > > > Also, fuck alpine with a chainsaw. Primul an m-am tot dat cu capul de > > probleme mizerabile doar pentru ca desteptii initiali vrusesera ei sa fie > > cool si au plecat de la alpine. O avea si el rostul lui, dar am dat de > > atatea ori cu capul de limitarile libc-ului ala "special" ca am zis ca > trec > > totul pe debian si aia e. > > > _______________________________________________ > 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
