In che modo i contesti Docker ti consentono di lavorare con più host

I contesti nella CLI di Docker forniscono un meccanismo semplificato per interagire con più endpoint Docker. Puoi impostare contesti per ciascuno dei tuoi host e passare da uno all’altro al volo.

Quando un contesto è attivo, Docker indirizzerà tutti i tuoi comandi a quell’host. Se utilizzi principalmente un’installazione Docker locale ma a volte devi avviare contenitori in produzione, i contesti Docker sono un’opzione disponibile.

Qualsiasi endpoint Docker valido può essere trasformato in un contesto. Puoi collegare le normali installazioni di Docker Engine, i cluster Docker Swarm e i cluster Kubernetes nel cloud. Ciascun contesto memorizzato contiene tutte le informazioni di connessione per l’host di riferimento.

Creare un contesto

I contesti sono gestiti con il docker context comando. Crei nuovi contesti usando docker context create. È necessario fornire un nome per il contesto e la relativa configurazione dell’endpoint.

Ecco come creare un contesto che si connette a un socket Docker esposto su TCP su un host remoto:

docker context create remote-host --docker host=tcp:///my-remote-host:2735

I contesti usano Docker Swarm come orchestratore di contenitori predefinito. Puoi impostarlo esplicitamente usando un flag:

docker context create remote-host 
    --default-stack-orchestrator=swarm 
    --docker host=tcp:///my-remote-host:2735

Per creare una connessione a Kubernetes, cambia il tipo di orchestratore. Devi anche aggiungere il --kubernetes flag e specifica il percorso di un file di configurazione Kubernetes:

docker context create kubernetes-host 
    --default-stack-orchestrator=kubernetes 
    --kubernetes config-file=/home/username/.kube/config 
    --docker host=unix:///var/run/docker.sock

Selezione dei contesti

Il contesto attivo viene cambiato usando docker context use. Passa il nome del contesto che vuoi attivare.

docker context use remote-host

Tutti i successivi comandi CLI verranno eseguiti utilizzando l’endpoint fornito dal nuovo contesto. Il contesto attivo persisterà automaticamente fino a quando non lo cambierai. Per passare a un contesto diverso, eseguire docker context use ancora. Puoi tornare al contesto predefinito con il tuo socket Docker locale passando default come nome del contesto.

Puoi sempre sovrascrivere il contesto selezionato aggiungendo il --context flag a qualsiasi comando Docker:

docker run ubuntu:latest --context remote-host

Il DOCKER_CONTEXT la variabile d’ambiente funziona anche come alternativa al --context bandiera. Entrambi i meccanismi facilitano un passaggio temporaneo a un contesto diverso senza farti correre e tornare indietro a docker context use comando.

Usando il DOCKER_HOST La variabile d’ambiente sovrascriverà anche il contesto attivo. Questa variabile obbliga Docker a utilizzare un particolare endpoint del demone invece di quello fornito dal contesto.

Puoi ispezionare il contesto attivo eseguendo docker context ls. Questo comando elenca tutti i contesti disponibili nella configurazione della CLI. Il contesto attivo è evidenziato con un asterisco. Per eliminare un contesto, esegui docker context rm, fornendo il nome del contesto. Non è possibile eliminare il default contesto.

Sincronizzazione dei contesti tra le macchine

I file di contesto sono archiviati nella directory di configurazione della Docker CLI. Questo è di solito $HOME/.docker su Linux. Troverai i tuoi contesti nel contexts sottodirectory. Ogni contesto ottiene la propria cartella denominata con un hash univoco. All’interno troverai un meta.json file che descrive il contesto. Solo i contesti creati hanno file archiviati su disco. Il default context eredita le impostazioni dalla configurazione del demone Docker.

Se desideri sincronizzare la configurazione del contesto, puoi eseguire il backup di contexts cartella per spostarla su un’altra macchina. Puoi utilizzare un trasferimento Rsync o un repository Git per semplificare gli aggiornamenti regolari. Anche il collegamento simbolico della cartella a una condivisione di rete potrebbe essere un’opzione a seconda delle esigenze.

Docker ti consente anche di esportare e importare contesti tramite la CLI:

docker context export my-context

Questo creerà un my-context.dockercontext file nella tua directory di lavoro. Il file include il meta.json contenuti e alcune informazioni extra, come il nome del contesto. Trasferisci questo file su un’altra macchina ed esegui docker context import my-context.dockercontext per caricare la configurazione del contesto.

In alternativa, puoi esportare un file di configurazione Kubernetes autonomo per i contesti Kubernetes:

docker context export kubernetes-context --kubeconfig

Questo produrrà un normale file “kubeconfig” compatibile con gli strumenti dell’ecosistema Kubernetes come kubectl. La capacità di acquisire un file kubeconfig da un contesto Docker migliora l’interoperabilità della toolchain. Nulla all’interno del file sarà specifico per la Docker CLI.

Se hai bisogno di modificare un contesto, usa il docker context update comando. Questo accetta gli stessi flag di docker context create. Se stai effettuando aggiornamenti collettivi, puoi modificare il meta.json file per manipolare direttamente i tuoi contesti. Puoi ispezionare un contesto meta.json file dalla CLI con docker context inspect my-context.

Conclusione

I contesti Docker sono utili quando è necessario distribuire contenitori in più ambienti indipendenti. Puoi impostare contesti per il tuo socket Docker locale, un server di staging del team condiviso e il tuo server Kubernetes di produzione.

Docker ha il supporto integrato per il Microsoft Azure e Amazon ECS container cloud, che possono essere aggiunti anche come contesti. Non c’è limite al numero di contesti che puoi creare, quindi hai una buona versatilità mentre ti muovi tra i tuoi host.

Probabilmente il più grande problema funzionale con i contesti è la possibilità di eseguire accidentalmente un comando nel contesto sbagliato. Se hai dimenticato che sei nel tuo production contesto, in esecuzione docker rm database-container potrebbe avere conseguenze devastanti. In caso di dubbio, corri docker context ls prima di controllare ciò che hai selezionato.