[rlug] flame de vineri ( ubuntu)

Tue Mar 26 10:16:32 EET 2024

Nu a fost niciodată ceva „canonic” să faci dist-upgrade la o nouă 
versiune majoră Debian într-un container Docker.  Asta îi o năstrușnicie 
în sine și probabil explică cum ai căzut în eroarea de a crede că aveai 
nevoie de systemd într-un container Debian cu nginx.

Iar pericolul monoculturii systemd cred că a cam trecut…  Și în Debian 
există suport pentru alte init-uri: https://wiki.debian.org/Init.  Mai 
nou văd că merge implicit GNOME cu GDM fără systemd, interesant…

Referință obligatorie: https://xkcd.com/386/.

On 3/25/24 20:28, Mihai Badici via RLUG wrote:
> Da, uite, acum la rece să încerc să pun problema altfel. Eu am un 
> oarecare interes pentru sistemele embeded, chestie care nu e deloc 
> depășită ci chiar devine din ce în ce mai la modă. Referințele la 
> slackware le fac mai mult ca să epatez burghezii; el a evoluat fix 
> invers: încercând să fie cât mai clean a devenit irelevant pentru 
> sistemele normale.
> 
> Docker e oarecum în aceeași găleată, chiar dacă e "embeded" software, nu 
> hardware.
> 
> De asta sunt un pic debusolat de ușurința cu care se renunță (de tot) la 
> un init minimal pentru unul maximal. Că evident că în multe scenarii 
> systemd are avantaje și până la urmă dacă se poate de ce nu.
> 
> Asta înseamnă că la un moment dat o distribuție care se vrea universală 
> nu prea mai e ce trebuie pentru o întreagă categorie de device-uri (ca 
> să mă autoconving că nu vorbeam chiar prostii am verificat în 
> changelog-ul systemd și chiar există un patch prin 2014 referitor la 
> "tratarea docker ca un tip special de container").
> 
> Eu am preferat să îmi derivez niște imagini din whezzy și voiam să le 
> "upgradez" la jessie dar a fost un interval în care nu exista docker 
> bazat pe jessie. Acum văd că dezvoltatorii au devenit mai flexibili, 
> pentru că nginx din bookworm nu pare că mai depinde, cel puțin nu 
> direct, de systemd. Dar deduc că și tu folosești alpine, eu am ajuns la 
> el pentru că atunci nu aveam alternativă și în general fără momentul ăla 
> de talibăneală probabil că nici nu s-ar fi auzit de el...
> 
> Te asigur că tot ce am făcut era complet "canonic" și că am studiat 
> destul de mult docker la momentul respectiv. Doar că am optat pentru 
> niște pachete pe care le știam stable, nu pentru nginx/latest .
> 
> Mă gândesc că vreo zece ani tot o să mai fim cât de cât relevanți, măcar 
> să mai reparăm din trăznăile pe care le fac ăștia micii din prea mult 
> entuziasm... doar că hai să zicem că aria mea de interes e un pic 
> diferită. Mă gândeam că anumite lucruri ar fi putut coexista într-o lume 
> "mai bună și mai dreaptă", cum zicea un dictator din tinerețea mea. KISS 
> e încă valid și va mai fi probabil și în următorul mileniu, chiar dacă 
> evident, în afară de a ține lucrurile simple trebuie să avem în vedere 
> să ne rezolve și problemele, ceea ce, suntem cu toții de acord, ar putea 
> să fie mai complicat decât ne dorim.
> 
> Ce să zic, pe următoarea vineri când mă mai enervez :)
> 
> On 3/23/24 09:24, Dumitru Moldovan via RLUG wrote:
>> Mihai,
>>
>> Ca de la un „linuxist bătrân” la altul, ca să citez un clasic al 
>> acestei liste de discuții…  Petru a încercat în mod repetat, cu o 
>> răbdare pe care io personal nu o mai am, să te ajute să înțelegi unde 
>> greșești.  Cu cât se dezvoltă discuția însă, cu atât ne dezvălui mai 
>> multe niveluri unde se întâmplă aceste greșeli.
>>
>> Acuma mno, toți avem un ego care ne orbește și ne împiedică să ne 
>> vedem propriile limitări.  Dar, vorba aia, până la urmă ce vrem să 
>> ajungem la vârsta a treia?  Niște moșnegi oțetiți de propriile 
>> frustrări, pe care nici măcar nu le prea înțelegem?  Sau, precum un 
>> vin de calitate, ceva încă recomandabil?
>>
>> Dacă duci dorul vechii configurări de rețea din Slackware, îți 
>> recomand OpenBSD, care a dus această simplificare până la concluzia ei 
>> logică, o soluție elegantă ce unifică inclusiv configurările de rețea 
>> fără fir. Însă de vrem să supraviețuim dpdv comercial în actualul 
>> context, trebuie să înțelegem care-i treaba cu Docker, de exemplu. 
>> Abia apoi ne putem avânta în lamentări mai la obiect privind „the old 
>> ways”…
>>
>> On 3/23/24 07:28, Mihai Badici via RLUG wrote:
>>> Neața :)
>>>
>>> Da, cumva ne apropiem, după cum ziceam vorbim de un proiect de prin 
>>> 2014-16 deci nu îmi mai amintesc nici eu bine.
>>>
>>> Tu folosești nginx:latest care la rândul lui e și el derivat din ceva 
>>> ( nu de către tine, de către alții, dar e) . Dacă te uiți la ce am 
>>> dat eu, imaginile mele erau derivate dintr-o imagine de wheezy.
>>>
>>> Acum poate oi fi greșit eu la acel moment, fiecare imagine era cu 
>>> From: debian/wheezy și apt-install  aplicația mea. Aș fi putut 
>>> probabil să le iau direct cu from: nginx:latest și să ignor că unul 
>>> din containere ar putea fi bazat pe debian și altul pe alpine; eu așa 
>>> m-am gândit, că e mai bine ca toate imaginile să aibă aceeași bază și 
>>> pentru că debian foloseam atunci, să fie debian.
>>>
>>> Cum docker e bazat pe layere succesive m-am gândit că așa e cel mai 
>>> economic și mai ușor de întreținut.
>>>
>>> Sigur că tu dacă o iei din nginx:latest pasezi problema la altul, 
>>> ceea ce e bine pentru tine dar nu schimbă lucrurile. Și nginx:latest 
>>> e probabil derivat tot din bookworm:latest, doar că nu de tine, și 
>>> după from probabil tot apt-get install nginx are (eu am refuzat moda 
>>> de a compila aplicația în Dockerfile, deși venind dinsprte slackware 
>>> s-ar zice că e contraintuitiv :) )
>>>
>>> Mă rog, nu are importanță, era doar o problemă de demult pe care am 
>>> adus-o în discuție ca să ilustrez o tendință.
>>>
>>> Aparent, proiectele de it sunt doar de două feluri: alea 
>>> subfinanțate, unde se improvizează ca să meargă, și alea 
>>> suprafinanțate, în care oamenii trebuie să își justifice salariul și 
>>> adaugă layere succesive de complexitate la problemele simple. Cale de 
>>> mijloc nu mai e :)
>>>
>>>
>>> On 3/23/24 00:23, Petru Rațiu via RLUG wrote:
>>>> On Sat, Mar 23, 2024 at 12:09 AM Mihai Badici via RLUG 
>>>> <rlug at lists.lug.ro>
>>>> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>> Vezi, aici m-ai pierdut. Pentru ca daca vrei nginx, folosesti 
>>>> nginx:latest
>>>> sau whatever. Care poate avea intern debian sau nu (default are, dar nu
>>>> prea conteaza), dar nu depinde in nici un fel de systemd (daca imi 
>>>> arati
>>>> unde scrie systemd la
>>>> https://github.com/nginxinc/docker-nginx/blob/1f227619c1f1baa0bed8bed844ea614437ff14fb/mainline/debian/Dockerfile
>>>> . il mananc).
>>>>
>>>> Faptul ca o tot dai cu pachetele din Debian si dependinta lor de 
>>>> systemd
>>>> imi spune ca ai incercat sa pui full distro in container, si 
>>>> sigur-sigur
>>>> faci ceva foarte in raspar daca ajungi sa faci de-astea.
>>>>
>>>> Aia cu "imaginea aia incercam sa o tin upgradata" e semn ca faceai 
>>>> ceva gen
>>>> golden image de VM, si efectiv la containere nu vrei sa faci asta 
>>>> decat in
>>>> anumite situatii foarte particulare. Daca vrei sa ai containere
>>>> maintainable, vrei sa tii un layer cat mai subtire de customizare pe
>>>> imagini facute de upstream (preferabil chiar de catre maintainerii
>>>> softurilor respective) si sa faci periodic rebuild cu acelasi 
>>>> scripturi ale
>>>> tale bazate pe latest security updates.
>>>>
>>>> Si ma rog, treaba ta, faci ce vrei, dar nu veni sa bombani ca ale 
>>>> naibii
>>>> iphoanele astea noi, bati doua cuie cu ele si trebuie schimbate.
>>>>
>>>
>>> _______________________________________________
>>> RLUG mailing list
>>> RLUG at lists.lug.ro
>>> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
>>
>>
>> _______________________________________________
>> RLUG mailing list
>> RLUG at lists.lug.ro
>> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
> 
> _______________________________________________
> RLUG mailing list
> RLUG at lists.lug.ro
> http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro