Merci pentru încercarea de a mă trage de mânecă.
Singurul motiv pentru care am continuat discuția a fost pentru că deja
apăream prea lame că rulam apt-get update pe containere. Nu , n-am făcut
asta. :)
Restul au fost niște decizii care atunci mi s-au părut bune, nici acum
nu consider că erau greșite doar că evident puteam să iau altele mai
bune, ca în orice situație în care privești în 2024 lucruri pe care
le-ai făcut în 2014-2016 .
Poate o să mai revin asupra discuției deși nu cred.
Greșeala mea e că am adus în discuție niște exemple prea concrete într-o
discuție care trebuia să fie destul de abstractă. Docker era un exemplu
destul de evident în care aveam nevoie de un init simplu și nu îl mai
aveam la dispoziție. Nu vreau să fie "ca înainte" , mai ales că am prins
vremurile de dinainte și sigur nu era mai bine :)
Mie mi s-a părut bun ca exemplu dar nu mă așteptam ca discuția să ajungă
la "de ce ai făcut așa și nu altminteri" pentru că nu despre asta era
vorba.
Sunt interesat de ubuntu pentru că e important ca o distribuție să aibă
un suport comercial în spate ( de la un nivel încolo o firmă vrea să
știe la cine să sune când are probleme) , modelul economic mi se pare
viabil și în afară de RedHat nu mai e altcineva disponibil, dar de
fiecare dată când am încercat să mă apropii de distribuția asta am găsit
tot felul de "amănunte" care nu mi-au plăcut
și care în cotinuare cred că sunt datorate unor dezvoltatori cu prea
multă "personalitate". Cam asta era discuția din punctul meu de vedere.
Ce a ieșit... hai să zicem că a ieșit "ca pe vremuri", asta am căutat
asta am primit :)
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@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@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
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
