•  untoreh-luce

Sui contenitori

Utilizzo dei contenitori, cosa e perché

Cosa sono i contenitori?

[Containers] è un nome dato ad ambienti ristretti, reso possibile da una raccolta di sottosistemi all'interno di Linux come [cgroups ] e [namespaces ]. Sebbene la pagina wiki usi la parola virtualizzazione penso che la parola isolamento è più appropriato, poiché virtualizzazione significa che c'è uno strato di traduzione nel mezzo, mentre ciò che fanno i cgroup e gli spazi dei nomi è separare e contestualizzare i processi.

I cgroup vengono utilizzati per definire le politiche di allocazione delle risorse, di solitoRAM eCPU , mentre gli spazi dei nomi controllano i contesti come i punti di montaggio, la rete e gli utenti. [Apparmor] fornisce invece un modo per limitare le capacità per gli ambienti contenitori nel loro insieme, mentre apparmor senza contenitori è, come scritto in wikipedia, basato su programmi.

Strumenti come flatpak e firejail utilizzare contenitori, per limitare la superficie di accesso delle applicazioni utente. I contenitori [Windows] implementano sistemi equivalenti e offrono anche supporto per i contenitori Linux tramite [WSL].

Ma perché?

Troppo?

Quando ho iniziato a costruire pino , ho sperimentato un po' con la spedizione delle mie immagini di container, distribuite dalle versioni di github. La sceneggiatura principale (trees ) i comandi erano

Usage: trees APP [FLAGS]...
'APP'               Install apps through ostree deltas checkouts.
    -b, --base      base image (alp,trub...)
    -n, --name      same as APP (etcd,hhvm...)
    -f, --force     clear before install
    -d, --delete    clear checkout and prune ostree repo
ck, check           make sure the apps repo is mounted
co, checkout        builds the trees of links for the specified APP
    -t 	            optional path where to build the tree

Era simile a flatpak, poiché stavo inviando un delta statico ostree basato sull'immagine principale del pino e [controllando] il nuovo rootfs basato sull'app, quindi lanciando un'istanza di contenitore su di esso. OpenVZ ha avuto molti problemi prima della v7 per l'esecuzione di container (dal momento che sai...stavi eseguendo un nidificato container su un container [VPS], e il kernel era un fork div2.6 (!))...era un enorme perdita di tempo.

Quando?

Il mio tentativo è stato quello di ottenere un runtime minimo del contenitore senza richiederedocker o un software più robusto, poiché docker è probabilmente il più leggero e sciame portuale , essendo integrato condivide molte funzionalità e fornisce le caratteristiche più utili per l'orchestrazione, il che lo rende il più snello sui requisiti del sistema host rispetto a k8s o nomade.

Nonostante i contenitori siano una funzionalità che potresti desiderare la maggior parte delle volte, l'orchestrazione non lo è. penso liberamente mirato le campagne pubblicitarie attirano il non inteso target di riferimento per tale software, facendo credere che possa essere utile a loro , senza sottolineare la premessa che tu veramente bisogno di ridimensionare molto (!) per giustificare il costo della complessità di tali configurazioni. Il numero di attrezzatura di convenienzacostruito intorno a k8s per aiutare il processo di bootstrap di un cluster k8s dovrebbe essere una prova sufficiente...

Conclusioni

Gli strumenti di orchestrazione finiscono per affollare il posto per soluzioni per gestire macchine multi host quando gli utenti non riescono a distinguere tra server per animali domestici e per bestiame. In molte occasioni, software come ansible, pyinfra o anche cssh o culo è tutto ciò di cui si ha bisogno.

Tag degli articoli: