Recensione: Red Hat fa Docker nel modo più difficile

Il progetto Atomic di Red Hat è un modo ostinato di eseguire container Linux. Il sistema operativo Atomic Host viene fornito con Docker (contenitori), Flannel (rete), OSTree (gestione host), Etcd (archivio valore-chiave distribuito) e Kubernetes (orchestrazione) già installati. 

Kubernetes è uno dei due sistemi di orchestrazione dei container più diffusi, l'altro è Docker Swarm. Potresti chiamarlo "piena forza", ma con ciò derivano complessità e costi amministrativi aggiuntivi.

Kubernetes coordina la creazione di "pod" su più host Atomic. I pod sono gruppi di contenitori Docker che separano logicamente i servizi in un'applicazione. I contenitori in un pod condividono un indirizzo IP e comunicano su localhost.

Flannel fornisce una rete overlay per gli host Atomic, consentendo a ogni pod nel cluster di comunicare con qualsiasi altro pod o servizio all'interno del cluster. Questa rete overlay viene utilizzata solo per la rete di container. Un servizio proxy Kubernetes fornisce l'accesso allo spazio IP dell'host.

Etcd viene utilizzato per memorizzare le configurazioni sia per Kubernetes che per Flannel su tutti gli host nel cluster.

I cluster di contenitori atomici fanno determinati presupposti a causa di Kubernetes. Gli amministratori non hanno davvero scelta con Atomic: utilizzare Kubernetes o trovare un altro sistema operativo contenitore. 

Se sei irritato dalla "progettazione per convenzione" e desideri maggiore libertà e flessibilità in un host contenitore, potresti prendere in considerazione RancherOS o VMware Photon. Se il tuo obiettivo finale è eseguire molti container su molti host, Atomic Host, Kubernetes e amici potrebbero essere proprio ciò di cui hai bisogno.  

Amministrazione del sistema Atomic Host

Atomic Host utilizza la propria versione del dockercomando atomic, sebbene il dockercomando reale  sia disponibile in / bin / docker. La sua posizione in / bin suggerisce alcune delle modifiche apportate a RHEL / CentOS / Fedora per rendere il sistema operativo Atomic appositamente progettato per i contenitori. Normalmente solo i binari di sistema importanti risiedono in / bin.

Gestisci Atomic Host tramite due sottosistemi. RPM-OSTree gestisce la distribuzione e gli aggiornamenti del sistema host, mentre Docker gestisce il provisioning dei container per l'esecuzione di servizi e applicazioni. Entrambi questi sottosistemi sono gestiti dal atomiccomando situato in / usr / bin /.

RPM-OSTree rende il filesystem Atomic immutabile; cioè, il filesystem è di sola lettura eccetto / var e / etc. La directory / var / lib / docker è dove sono archiviati tutti i file e le immagini relativi a Docker, mentre / etc ha tutti i file di configurazione. Come vedremo in seguito, ciò rende più semplici e sicuri upgrade e downgrade dell'host, un requisito essenziale quando si gestiscono potenzialmente migliaia di host container in un cluster.

Il atomiccomando è concepito per essere un singolo punto di ingresso al sottosistema del contenitore, un comando ombrello per tutto ciò che riguarda il contenitore, comprese le operazioni dell'host. Il atomiccomando assomiglia molto al dockercomando, ma risolve un problema fondamentale condiviso da tutti i sistemi operativi host del contenitore: avviare un servizio a livello di sistema in un contenitore al momento dell'avvio, in modo affidabile e trasparente, utilizzando i file di unità Systemd.

In Atomic, questo viene fatto con quello che viene chiamato un contenitore super privilegiato, che ha la capacità di vedere e manipolare l'host stesso. Quindi, sebbene atomicsembri un comando Docker standard, sta colmando le lacune tra Docker e RPM-OSTree (configurazione di script di installazione, impostazione di servizi, assegnazione di privilegi appropriati e simili) per consentire la distribuzione affidabile di un'applicazione basata su container .

In atomic parole povere, il  comando ti consente di manipolare l'infrastruttura host sottostante (cgroups, namespace, SELinux, ecc.) Per eseguire le tue applicazioni. Ad esempio, supponiamo di aver creato un'applicazione contenitore Network Time Protocol (ntpd) che richiede la funzionalità SYS_TIME per modificare l'ora di sistema dell'host. Puoi configurarlo aggiungendo metadati all'immagine del contenitore utilizzando il comando:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

Quindi, quando esegui container ( atomic run ntpd), il sistema leggerà quei metadati e configurerà la capacità SYS_TIME e altre risorse per il contenitore. 

Installazione e configurazione di Atomic Host

L'installazione è stata una lotta, soprattutto perché ho trovato la documentazione disorganizzata e confusa. I documenti presuppongono un alto livello di conoscenza dell'ecosistema Red Hat che non tutti i lettori avranno. Dopo alcune false partenze, sono finalmente riuscito a installare da una ISO bare metal. Il supporto per l'installazione della macchina virtuale con qualcosa di diverso da virt-manager è doloroso. Atomic Host non è assolutamente compatibile con Windows o Mac in questo senso.

Per chiunque abbia familiarità con un'installazione di CentOS, la procedura bare metal sarà semplice. Le uniche differenze evidenti sono nel layout del disco, con spazio riservato automaticamente per Docker e container, insieme alla pletora di mount per SELinux, cgroups, ecc. Che accompagnano l'installazione del sistema operativo del container.

L'utilizzo di Kubernetes per gestire i container in un cluster è notevolmente più complicato rispetto all'esecuzione di Docker su un singolo host, ma con una maggiore complessità si ottiene maggiore affidabilità e capacità. Con Kubernetes ottieni anche la comodità di sapere che il sistema è stato testato in battaglia in ambienti di produzione su larga scala (presso Google).

Non esiste un modo semplice per configurare un master Kubernetes. La documentazione è distribuita su vari siti Web del progetto e molte volte i documenti puntano ad altri siti per i dettagli, quindi preparati a dedicare molto tempo alla lettura, alla ricerca di documenti e alla sperimentazione. La somma totale dello sforzo comporta la modifica di una dozzina di file distribuiti in poche directory / etc. Ovviamente il trucco sta nel sapere quali sono queste modifiche. Kubernetes non è fatto per la sperimentazione casuale con i contenitori. Questa è roba di produzione pesante.

Dopo aver configurato il master con Kubernetes, certificati, servizi e una rete di overlay Flannel, quindi installato Flannel (flanneld), Kubernetes (kubelet) ed Etcd su ogni nodo, ho finalmente avuto un cluster di contenitori a cinque nodi in esecuzione. Sfortunatamente questo ha consumato un bel po 'di memoria e non sono riuscito a trovare un modo per testare utilizzando un singolo nodo, come ho fatto durante i test di RancherOS e VMware Photon.

A questo punto, Kubernetes può essere utilizzato per avviare e gestire i pod, quei gruppi di contenitori che incapsulano servizi e applicazioni.

Archiviazione e rete di Atomic Host

Come la maggior parte dei sistemi operativi host container, Atomic Host adotta un approccio minimalista, con spazio su disco appena sufficiente per eseguire l'host. Ciò non lascia molto ai numerosi contenitori Docker in cui verrà eseguito un tipico cluster, quindi sarà necessario collegare l'archiviazione esterna all'host per questo.

In Docker, le immagini ei file correlati sono generalmente archiviati in / var / lib / docker, e sulla maggior parte dei sistemi operativi standard dovresti semplicemente montare un dispositivo in quel punto nel filesystem per aggiungere spazio di archiviazione. Tuttavia, Atomic utilizza volumi LVM (Linux Volume Manager) diretti tramite il back-end Device Mapper per archiviare immagini e metadati Docker: / dev / atomicos / docker-data e / dev / atomicos / docker-meta. Ciò significa che dovrai imparare qualcosa su LVM e sui volumi per aggiungere spazio a un host Atomic.

Il punto di partenza per la gestione dell'archiviazione in Atomic è lo script di installazione, / etc / sysconfig / docker-storage-setup. Atomic Host dispone di un pool di archiviazione per l'archiviazione Docker (e host), quindi il trucco qui è aggiungere un nuovo dispositivo a questo pool. Lo farai aggiungendo all'elenco dei dispositivi nel file, in questo modo:

DEVS="/dev/vdb /dev/vdc"

Quindi esegui lo script di supporto, / usr / bin / docker-storage-setup. Se tutto va bene, i tuoi dischi sono stati aggiunti al pool e il tuo host Atomic ha spazio per Docker. Suppongo che LVM sarà gestito in produzione con strumenti di amministrazione esistenti, o con script come Ansible / Salt / Chef / Puppet, quindi probabilmente apparirà più standard agli amministratori che lavorano in ambienti datacenter di grandi dimensioni.

Project Atomic utilizza Flannel per fornire una rete di overlay di container tramite Etcd. Puoi configurarlo inserendo un file di configurazione JSON nell'archivio valori-chiave Etcd, utilizzando strumenti come Curl. Per configurare una sottorete per i contenitori, potremmo creare un file JSON simile a questo:

   "Rete": "172.16.0.0/12",

   "SubnetLen": 24,

   "Backend": {

      "Tipo": "vxlan"

   }

}

E per inserirlo nel master Etcd, lo inseriamo nella chiave di configurazione di rete:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Sebbene un po 'ingombrante, è gestibile. Mi piacerebbe vedere un wrapper per questi comandi di configurazione che lo rendono più intuitiva per l'amministratore Unix, forse qualcosa di simile atomic ifconfig…, atomic route…e così via

C'è un'altra differenza che vale la pena sottolineare: i concetti Kubernetes di pod e servizi. Un pod è un gruppo di contenitori che sono relativamente strettamente accoppiati. Tutti i contenitori in un pod condividono lo stesso host e lo stesso indirizzo IP e vivono o muoiono tutti insieme. Specifica quante istanze di un pod vuoi eseguire e Kubernetes esegue l'ordine. Se un'istanza si interrompe o non riesce, Kubernetes ne avvia un'altra in modo che corrisponda allo stato desiderato.

Un servizio Kubernetes è un'astrazione che definisce un insieme logico di pod e una policy per accedervi. Ciò fornisce a un (micro) servizio un nome e un indirizzo unico e stabile per tutto il ciclo di vita del pod. C'è molto di più in questo, ma dovrebbe aiutarti a capire perché hai bisogno di un componente separato per gestire la rete. In Atomic Host, quel componente è Flannel.

Aggiornamenti e downgrade di Atomic Host

Atomic Host utilizza un gestore di pacchetti chiamato RPM-OSTree, che combina le funzionalità dei tradizionali RPM e OSTree. RPM-OSTree ci dà la capacità di scorrere in modo affidabile avanti e indietro, poiché il processo è "atomico" (nel senso del termine database). RPM-OSTree fornisce transazioni affidabili per gli aggiornamenti, il che significa che è improbabile che rompa il sistema operativo. Come i comandi per i container, gli upgrade e i rollback degli host sono atomicgestiti dal sistema di gestione:

atomic host upgrade

atomic host rollback

Nota che non ho testato un rollback, perché non avevo nulla su cui eseguire il rollback.

Red Hat Atomic Host è più adatto alle organizzazioni con un forte investimento nelle competenze e nell'infrastruttura di Red Hat. Le aziende che iniziano da una prospettiva diversa potrebbero voler considerare altre opzioni. L'inclusione di Kubernetes e la storia di Red Hat in ambienti di produzione di grandi dimensioni significano che Atomic Host sarà quasi un "drop-in" per l'esecuzione di carichi di lavoro containerizzati nelle aziende. Ma non vedo gli sviluppatori che lo scelgono come piattaforma Docker preferita.