On 5/3/24 15:24, 380° wrote:
[...]
Il 02/05/24 6:33 PM, Giuseppe Attardi ha scritto:
[...]
Kamal, da una breve scorsa alla documentazione, è qualcosa tipo
Ansible [...] Hanson spiega che Kubernetes è complesso e richiede
competenze (appunto come sospettavo), perché è “dichiarativo”.
Iniziamo con un paio di concetti:
1. kubernetes è un sistema di gestione dei cluster, piuttosto complesso
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKubernetes&e=566de099&h=2b97a3f5&f=y&p=n
; di sistemi di gestione
cluster è piena la storia dell'IT [1], kubernetes non sarà
l'ultimo... e nemmeno il penultimo.
La storia dell'IT è piena di tante cose. Alcune di queste hanno preso
piede, altre no. Tutte noi della lista Nexa tendenzialmente siamo per
l'Open Source. Qualcuno addirittura per il Software Libero.
Per usare le tue parole, esistono tanti kernel, Linux non sarà l'ultimo
e nemmeno il penultimo. Eppure non so vedere all'orizzonte il prossimo.
Il mondo è andato verso questa direzione, con buona pace di sistemi
probabilmente migliori come FreeBSD e al netto di tutte le distro-war
che possiamo fare (e che fanno sempre piacere ;-) ).
Idem con patate per Kubernetes.
Essere utilizzati di più, come sai, significa avere maggiore supporto
dalla comunità, poter risolvere più facilmente i problemi, avere più
documentazione, maggior affidabilità e stabilità, maggiore
interoperabilità e integrazione...
La caratteristica di kubernetes,
che lo rende così /complicato/, è che *ingloba* un sacco di altri
servizi che in altri sistemi di gestione dei cluster sono lasciati ad
altri software che i sistemisti devono scegliere, installare e
configurare indipendentemente.
Sono moderatamente d'accordo. Anche se più banalmente, secondo me, la
difficoltà sta nella configurazione dettagliata di una molteplicità di
risorse IT. Il vantaggio è l'uniformità di queste configurazioni,
l'opportunità di versionamento delle stesse e la centralizzazione della
loro gestione.
[...]
Kubernetes è complesso... perché chi l'ha pensato aveva in mente di
gestire il workload di Google, su scala worldwide. A quella scala, la
complessità di kubernetes... è insignificante rispetto
all'infrastruttura che dovra' gestire.
I sistemi di "cluster management for world sized cloud infrastructure"
sono figli dell'/ideologia/ "pets vs cattle" [2]
Non so se si tratti di un'ideologia. Direi più un portato industriale.
Si potrebbe forse dire che l'industria è un'ideologia.
Rimanendo, però, con i piedi per terra, servono sia i pets che i cattle.
Così come serve sia l'artigianato che l'industria.
A me piacerebbe avere una casa piena di oggetti di artigianato,
purtroppo non posso permettermelo. Mi limito ad alcune cose, sul resto
cedo. Penso che valga in generale.
Come se i due insiemi descritti sopra fossero davvero _disgiunti_: sarà
mica una cosa seria? (e infatti kubernetes usa il termine "Pet Sets"
che l'autore dell'articolo sopra contesta... non proprio "rocket
science" diciamo :-D )
Non ho mai sentito dire da nessuno che Kubernetes è rocket science. Al
massimo si sente dire che è una "ficata" oppure una "rottura di scatole".
:-)
L'ideologia "pets vs cattle" è stata osannata come il "nuovo (cattle)
che avanza sul vecchio (pets)", nonostante sia _evidente_ sia è frutto
di mistificazione su come funzionavano i sistemi "high availability
clusters" già mooolto tempo prima che il _meme_ fosse inventato.
Il tutto è anche frutto della confusione assordante tra "scale-out" vs
"scale-up", che tra l'altro sono problemi che si incontrano
_regolarmente_ nel ciclo di vita di una infrastruttura IT, che essendo
"fatta di bit" è da decenni che è "nomade".
Tutto ciò ha portato alla /reificazione/ del concetto che i container
sono _ephemeral_ by nature... tranne che i dati
(https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKubernetes%23Storage&e=566de099&h=c59b9bc2&f=y&p=n
) e le configurazioni
(https://urlsand.esvalabs.com/?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FKubernetes%23etcd&e=566de099&h=6b0726e4&f=y&p=n
) che servono non lo sono
affatto:
Non lo so se sia questo che abbia portato alla reificazione dei
container. I namespace sono nel kernel di Linux dal 2002 e i cgroups dal
2006. Kubernetes è nato nel 2014. La storia dei container inizia negli
anni '80 con chroot e per 3 decenni sono state proposte numerose
variazioni sul tema, fino a quella che ha preso piede. Che non è
necessariamente la migliore, così come Linux non è il miglior kernel in
circolazione.
Il fatto che siano effimeri è fondamentale. Tenere separata la
computazione dai dati e dalle configurazioni è una buona prassi. Tutto è
più pulito e portabile. Gestire questa separazione è sempre stato un
problema. Mi pare che Kubernetes ultimamente abbia fatto passi da
gigante verso una gestione convincente: snapshot e volume cloning,
secrets encryption tramite API e poi i Container Storage Interface che
hanno standardizzato il modo in cui i container interagiscono con i
sistemi di storage esterni. Stiamo parlando di un sistema con migliaia
di contributori, centinaia di migliaia di commit e una vitalità che dopo
10 anni non accenna a diminuire (all'ultimo KubeCon a Parigi eravamo
10.000 persone!).
[...]
Il discorso cambia a scale piu' piccole (Ateneo, ASL, Regione...). A
queste scale, la complessita' di K8S si sente, forte. E' la stessa scala
di Hey/Heinemeier e per questo Heinemeier ha premuto "reset": a lui,
semplicemente, non serviva. Meglio: era sufficiente qualcosa di *MOLTO*
piu' semplice.
E' un folle? E' un ignorante? Oppure è semplicemente un "realista"?
É un sistemista che ha ben presente lo "use case" di kubernetes e ha
chiaramente capito che a lui proprio non serve. Dopotutto deve /solo/
erogare 4/5 applicazioni web con backend per i dati, mica fare AWS.
Ma infatti, benissimo così. Basta che funzioni. Non è necessario passare
a Kubernetes e tanto meno al cloud, se non serve.
Allo stesso tempo se a qualcuno serve, il prodotto è lì a disposizione,
con una licenza Open Source (Apache License 2.0) compatibile con la GPLv3.
...poi essendo un bravissimo sviluppatore si diverte anche a reinventare
la ruota (Kamal) perché gli piace fare "il sarto", ma vabbè, ognuno ha
il suo ego :-)
Ottimo. Adoro i sarti!
:-)
[...]
Appunto, dichiarativo vs procedurale.
La differenza sta lì, da una parte fai tutto tu a mano, devi tenere
traccia di tutyo e ogni modifica costa quanto ricominciare daccapo.
Questa "una parte" sarebbe Ansible? Ma Ansible è dichiarativo!
...ormai "tutto è dichiarativo" :-)... "Infrastrutcture as Code".
Ansible è dichiarativo, ma stateless, ossia non mantiene lo stato (come
invece fa OpenTofu, ad esempio). Lo stato è ricostruibile
implicitamente, ma al prezzo di usare sinapsi umane. Come hai ben
descritto nel seguito, l'idempotenza è limitata ai moduli, non al loro
assemblamento in una logica di processo, che potrebbe facilmente far
incappare in un deadlock. Ci sono le buone prassi per evitarlo e poi c'è
l'esperienza che ti aiuta a debuggare le situazioni più ostiche.
[...]
--8<---------------cut here---------------start------------->8---
Reliable. When carefully written, an Ansible playbook can be idempotent,
to prevent unexpected side effects on the managed systems. It is
possible to write playbooks that are not idempotent.
--8<---------------cut here---------------end--------------->8---
Esatto.
[...]
--8<---------------cut here---------------end--------------->8---
La cosa è (ovviamente) risolvibile, come ha dimostrato Damiano, ma c'è
stato bisongo di un processo di _riconciliazione_ tra la dichiarazione e
lo stato, cosa che in un sistema idempotente sarebbe... impensabile
[...]
E' così. Del resto è stata una scelta quella di tenerlo il più possibile
leggero, con una curva di apprendimento piatta, e un'apertura a
qualsiasi situazione. E di conseguenza a qualsiasi casino...
[...]
[...]
Insomma: non c'e' una ricetta magica per tutto.
Sì invece:
«Purely Functional System Configuration Management»
by Eelco Dolstra and Armijn Hemel, 2007-05-07
--8<---------------cut here---------------start------------->8---
System configuration management is difficult because systems evolve in
an undisciplined way: packages are upgraded, configuration files are
edited, and so on. The management of existing operating systems is
strongly imperative in nature, since software packages and configuration
data (e.g., /bin and /etc in Unix) can be seen as imperative data
structures: they are updated in-place by system administration
actions. In this paper we present an alternative approach to system
configuration management: a purely functional method, analogous to
languages like Haskell. In this approach, the static parts of a
configuration — software packages, configuration files, control scripts
— are built from pure functions, i.e., the results depend solely on the
specified inputs of the function and are immutable. As a result,
realising a system configuration becomes deterministic and
reproducible. Upgrading to a new configuration is mostly atomic and
doesn’t overwrite anything of the old configuration, thus enabling
rollbacks. We have implemented the purely functional model in a small
but realistic Linuxbased operating system distribution called NixOS.
--8<---------------cut here---------------end--------------->8---
(https://urlsand.esvalabs.com/?u=https%3A%2F%2Fedolstra.github.io%2Fpubs%2Fhotos-final.pdf&e=566de099&h=c7fe91cd&f=y&p=n
)
Oggi quei concetti sono implementati in NixOS e Guix System; per i
manifest di packages e servizi il primo usa un _mix_ di Nix - un DSL
funzionale sviluppato ad-hoc - e bash, il secondo usa Guile, un dialetto
di Scheme.
[...]
Ecco su questo vorrei espandere un po'. Sono soluzioni di nicchia,
sicuramente interessanti ed eleganti, ma pochissimo utilizzate e quindi
l'ecosistema a supporto è limitato.
[...kubernetes...]
Se cambiano i requisiti, basta cambiare le specifiche e il sistema si
riadatta ad esse in modo totalmente automatico.
Su questo elemento *DISSENTO* fortemente. In *TEORIA* funziona cosi'.
Nella pratica, dipende assolutamente dall'applicazione che deve
girarci.
Confermo: la statefulness dei sistemi purtroppo a volte è _embedded_
nelle applicazioni che sono progettate proprio male [3]
Certo. Su questo non si può fare molto di più che odiare i programmatori.
:-P
[...]
Tu e AWS volete "vendere" la vostra piattaforma. Heinemeier preferisce
gestirla per i fatti suoi (perché pensa di sapere quello che fa).
A me piace piu' il suo approccio...
Non è solo una questione di gusti, è che a parità di competenze
l'approccio on-premises costa almeno un ordine di grandezza meno.
Ma dipende, in realtà, non generalizzerei. Bisogna farsi bene i conti.
Dovrebbe essere questo il mestiere del Product Owner.
In ogni caso, la questione dei costi mi interessa fino ad un certo
punto. Quanto meno valuterei anche i benefici, che sono soggettivi, come
il caso di Heinemeier dimostra.
La questione quindi si "riduce" a: per farselo "da soli" occorre avere
adeguate competenze, se lo facciamo "in cloud" non abbiamo bisogno di
quelle competenze e quindi _risparmiamo_...
Non è detto che sia così.
L'idea portante dell'IT automation è quella della standardizzazione. Che
ci sta, secondo me. Con tutte le riserve di qualsiasi approccio
industriale alla tecnologia, ma anche con tutto l'incoraggiamento
all'inclusività. Intendo dire che grazie alla standardizzazione in
meccanica, anche un pasticcione come me può fare bricolage in casa. Poi
per le cose serie (e per i casini inenarrabili che combino) ci sono i
professionisti.
[...]
Sono, io, "cloud"?
Stai gestendo a mano, con l’ausilio di tool, una infrastruttura
fornita da altri.
Il cloud GARR è basato su OpenStack e Kubernetes, entrambi orchestrati
in modo dichiarativo da Canonical Juju.
La scelta di una soluzione dichiarativa era quella che consentiva di
gestire una piattaforma così sofisticata con solo 5 persone, anziché
50.
Il fine ultimo di tutti questi bei ragionamenti è questo e soltanto
questo: decimare le persone necessarie a far funzionare una
infrastruttura come quelle di GARR o altre organizzazioni pubbliche o
private?
Tra l'altro i 5 rimasti devono limitarsi a fare 4 click su un "admin
panel".
Beh no. Direi che il fine ultimo sarebbe lavorare tutte, lavorare meno.
Figuriamoci se io ho qualcosa contro l'automazione, il mio alter ego ci
lavora per l'automazione, ma non può sempre e _solo_ limitarsi tutto a
_risparmiare_ sugli stipendi.
Infine, sarà anche che alla fine rimangono in 5 su 50 a gestire una
intrastruttura basata su kubernetes... ma prima o poi le cose cominciano
a non funzionare più con 4 click e allora... parte il _cinema_.
[...]
Giustissimo. Non c'è nulla di magico. E occorre conoscere
approfonditamente le soluzioni per evitare casini mondiali.
E' anche vero che con la standardizzazione, magari un po' di "bricolage"
riusciamo ad ottenerlo anche dai meno tecnici. Il che ci potrebbe
consentire di creare comunità più inclusive e orizzontali, non comunità
dove pochi smanettoni fanno cose incomprensibili alle più.
La chiave è l'automazione. Non la modalita' con la quale viene
implementata.
Non vorrei dire ma per _sviluppare_ le librerie necessarie a rendere
_accessibile_ l'automazione nel "Infrastructure as Code" è necessario
tanto lavoro competente... ma a quello non ci pensa nessuno?
Le "librerie" di Terraform, Ansible, Puppet, NixOS, Guix crescono sugli
alberi?
[...]
Al momento a finaziarle sono aziende multinazionali turbo-capitaliste
(tranne NixOS e Guix, ovviamente). Del resto anche per il Kernel Linux è
così.
Qui c'è un recente articolo da leggiucchiare sulla scarsa resilienza di
progetti trainati dal capitale (e sulle contromisure da prendere):
https://www.jeffgeerling.com/blog/2024/corporate-open-source-dead
D.
(null)
