3 strategie per implementazioni di produzione automatizzate con Docker

Docker è uno strumento di sviluppo popolare in quanto semplifica l'avvio di istanze isolate dell'applicazione con una configurazione riproducibile. Può essere utilizzato anche in produzione, dove garantisce che le distribuzioni live siano identiche al tuo ambiente di sviluppo.

Portare un container in produzione non è sempre così semplice come eseguire docker run sul tuo computer locale. Non è una buona idea inviare manualmente le immagini a un registro, connettersi a un host Docker remoto e avviare i contenitori. Questo si basa sull'intervento umano, quindi è dispendioso in termini di tempo e soggetto a errori.

In questa guida, esamineremo tre diverse strategie che puoi utilizzare per automatizzare facilmente le distribuzioni Docker e mantenere una configurazione coerente. Questi approcci possono essere sottoposti a script come parte di una pipeline CI per avviare nuovi contenitori ogni volta che il codice cambia. Dovrai creare le tue immagini Docker e inviarle a un registro come prima fase dello script, quindi utilizzare una delle tecniche seguenti per estrarre l'immagine e avviare i contenitori nel tuo ambiente di produzione.

1. Docker Componi su SSH

Docker Compose ti consente di avviare più contenitori con un unico comando. Inoltre, Compose è configurato tramite un file YAML che ti aiuta a modificare le versioni e garantisce distribuzioni riproducibili.

Potresti aver già utilizzato Compose come strumento di sviluppo locale. Devi creare un docker-compose.yml file nella tua directory di lavoro, quindi aggiungi uno o più services che definiscono i contenitori da cui partire:

version: 3
services:
  app:
    image: example.com/app:latest
    ports:
      - 80:80
  database:
    image: mysql:8.0
    expose:
      - 3306

Una volta ottenuto un file Compose, usa il docker-compose up -d comando per avviare i tuoi contenitori. Se modifichi il file, ripeti il ​​comando per applicare le modifiche. Compose aggiornerà o sostituirà i contenitori per ottenere il nuovo stato dichiarato.

Aggiunta del --pull flag indica a Compose di provare a estrarre le immagini aggiornate prima di avviare i contenitori. Puoi anche usare --force-recreate per forzare la creazione di nuovi contenitori, anche se la loro configurazione sottostante non è cambiata.

Come si collega tutto questo alle implementazioni di produzione? Significa che puoi utilizzare Compose come parte della tua pipeline CI per avviare facilmente contenitori che soddisfano lo stato dichiarato nel tuo docker-compose.yml file. Esecuzione di docker-compose up -d --pull in ogni pipeline ti verrà fornito un set di contenitori in cui ciascuno esegue l'ultima versione della propria immagine.

Esistono diversi modi per implementare questo metodo. Il percorso più semplice e sicuro consiste nell'installare Docker e Compose sull'host di produzione, quindi connettersi ad esso tramite SSH. Dovresti utilizzare le impostazioni del tuo provider CI per archiviare le credenziali SSH come variabili accessibili alla tua pipeline. Dovresti quindi configurare il client SSH nella tua pipeline, copiare il docker-compose.yml file sul tuo host remoto ed esegui il  docker-compose up comando.

Ecco uno script di esempio:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo $SSH_PRIVATE_KEY | ssh-add -
echo $SSH_HOST_KEY > ~/.ssh/known_hosts
scp docker-compose.yml:[email protected]:/home/ci-user/docker-compose.yml
ssh -t [email protected] docker-compose up -d

In alternativa, puoi utilizzare i contesti Docker per eseguire il binario Compose in locale, all'interno dell'ambiente della pipeline. Ciò richiederebbe di esporre il socket Docker sul tuo host remoto; poiché questo può rappresentare un rischio per la sicurezza, l'approccio è generalmente meno favorevole in situazioni in cui potrebbe essere utilizzato anche SSH.

Seguendo questo metodo dovresti installare Docker e Compose sull'host che esegue le tue pipeline. All'interno dello script della pipeline, devi registrare e selezionare un contesto Docker che punta al tuo host di produzione remoto. I dettagli della connessione dovrebbero essere forniti come variabili impostate nel pannello delle impostazioni del provider della CI. Con il contesto selezionato, eseguiresti docker-compose up -d nell'ambiente della tua pipeline ma vedi il comando eseguito sul server remoto.

2. Utilizzo di una piattaforma come servizio (PaaS)

L'adozione di un'offerta Platform-as-a-Service (PaaS) è ​​un altro approccio all'esecuzione dei container Docker in produzione. Puoi ospitare autonomamente il tuo con soluzioni come Dokku o scegliere un'offerta ospitata come Amazon ECS, DigitalOcean App Platform o Heroku.

Un PaaS astrae la complessità della creazione di immagini, del mantenimento di configurazioni dettagliate e del provisioning dei propri host Docker. Puoi utilizzare Git per inviare direttamente il tuo repository alla piattaforma o eseguire un comando CLI per caricare le modifiche. Il PaaS gestisce la creazione di container dalle risorse di origine, dai Dockerfile o da un file di configurazione specifico della piattaforma.

Le soluzioni PaaS sono un ottimo modo per collegarsi rapidamente online con una minima interazione pratica con Docker. Sono facili da integrare nella pipeline CI e la maggior parte dei principali provider offre script di esempio per iniziare. Tuttavia, è possibile superare una PaaS, il che potrebbe significare che dovrai ripensare la tua infrastruttura in futuro.

I passaggi per automatizzare la distribuzione sulla piattaforma scelta variano in base al provider. Se stai usando Dokku o un PaaS simile con integrazione Git, il tuo script CI potrebbe essere semplice come due righe:

git remote add dokku [email protected]:app-name
git push dokku master

Lo script aggiunge il tuo server Dokku come telecomando Git e spinge verso l'alto il contenuto del repository. Dokku creerà automaticamente un'immagine dal tuo Dockerfile e avvia le istanze del contenitore. Dovresti aggiungere la chiave pubblica SSH del tuo server CI a Dokku affinché funzioni; in caso contrario, il tuo script CI non sarebbe in grado di autenticarsi sulla piattaforma.

3. Orchestrazione con Kubernetes/Docker Swarm

L'uso di un orchestratore come Kubernetes o Docker Swarm è probabilmente il modo più comune per eseguire istanze di container live. Questi strumenti sono progettati appositamente per distribuire e ridimensionare i container negli ambienti di produzione.

Gli orchestratori rimuovono le complessità della gestione dell'infrastruttura, consentendoti di concentrarti sulla tua applicazione e sui suoi componenti. Analogamente a Docker Compose, adottano un approccio dichiarativo alla configurazione dello stato in cui si definisce come dovrebbe essere lo stato finale. L'agente di orchestrazione determina la sequenza corretta di azioni per raggiungere tale stato.

Kubernetes è l'orchestratore più popolare. Un modo per interagire con i cluster Kubernetes è con Kubectl, lo strumento di gestione CLI ufficiale. Kubectl ti consente di applicare file manifest in formato YAML che definiscono le risorse contenitore da creare nel tuo cluster.

Ecco un semplice manifest che crea una singola istanza del contenitore:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo
          image: example.com/image:latest

Puoi utilizzare Kubectl per applicare questo manifest a un cluster:

kubectl apply -f manifest.yaml

Le successive modifiche al file vengono applicate ripetendo il comando. Kubernetes intraprende automaticamente le azioni necessarie per raggiungere il nuovo stato dichiarato.

Ciò rende Kubernetes un'ottima opzione per le distribuzioni di produzione automatizzate. Puoi usare kubectl apply all'interno delle tue pipeline per prendere i manifest nel tuo repository e applicare lo stato dichiarato al tuo cluster. La creazione di un nuovo tag immagine per ogni commit vedrebbe Kubernetes estrarre quell'immagine e avviare nuovi contenitori per la distribuzione.

Per configurarlo, dovresti fornire il contenuto di un file di configurazione Kubeconfig come variabile della pipeline. Ciò fornisce a Kubectl le credenziali da utilizzare per la connessione al cluster. Il binario Kubectl locale funzionerebbe quindi sul tuo cluster remoto.

Docker Swarm è un'altra opzione di orchestrazione integrata con Docker. Puoi impostare uno stack Swarm usando lo stesso docker-compose.yml file come descritto in precedenza. È quindi possibile utilizzare approcci di distribuzione simili, collegandosi all'host Swarm tramite SSH o utilizzando un contesto Docker per modificare la destinazione dei binari Docker locali.

Gli orchestrator sono molto più complessi rispetto all'utilizzo di Compose semplice o di un PaaS gestito. Nel caso di Kubernetes, devi imparare nuove astrazioni, terminologia e formati di file di configurazione prima di poter distribuire i tuoi contenitori. Tuttavia, i cluster offrono anche funzionalità aggiuntive che semplificano la manutenzione delle applicazioni a lungo termine. Puoi facilmente ridimensionare le repliche su più host, creare ridondanza e aggregare log e metriche.

L'orchestrazione è quindi l'opzione migliore per i sistemi più grandi che eseguono più container. Ciò non significa che l'attenzione del settore che stanno ricevendo gli strumenti dovrebbe indurti a utilizzare Kubernetes per ogni distribuzione. Compose o un PaaS sarà più facile da configurare, ragionare e mantenere per casi d'uso più piccoli in cui sei meno preoccupato per la scalabilità e il blocco del fornitore.

Riepilogo

Abbiamo esaminato tre diversi modi di eseguire i container come carichi di lavoro di produzione. I dettagli di implementazione variano a seconda della strategia scelta, della toolchain di supporto e dell'ambiente CI, quindi abbiamo omesso una descrizione precisa di come impostare l'automazione come parte del flusso di lavoro. Tuttavia, tutti e tre possono essere facilmente integrati in una pipeline CI che viene eseguita ogni volta che unisci o esegui il push del codice.

L'orchestrazione mediante uno strumento come Kubernetes è diventata rapidamente il metodo preferito per implementazioni scalabili di sistemi che eseguono più container. Sebbene possa semplificare notevolmente il funzionamento dei servizi per cui è progettato, offre anche una curva di apprendimento significativa e un sovraccarico di manutenzione, quindi non dovresti saltare senza considerare le alternative.

I sistemi più piccoli formati da pochi componenti possono ottenere risultati migliori dall'utilizzo di Compose per avviare contenitori con una configurazione riproducibile su un host Docker esistente. Ciò offre alcuni dei vantaggi di Kubernetes, come la configurazione dichiarativa, senza la complessità aggiuntiva. Puoi "facilitare" l'orchestrazione in un secondo momento aggiungendo il supporto Docker Swarm al tuo file Compose esistente, consentendoti di avviare più repliche distribuite di contenitori.

Infine, le opzioni Platform-as-a-Service accelerano la distribuzione delle applicazioni senza farti pensare a dettagli granulari del contenitore. Questi servizi offrono la prospettiva di un'automazione completa dell'infrastruttura a partire da una configurazione minima. Possono essere restrittivi a lungo termine, quindi pensa a come la tua soluzione crescerà nel tempo prima di impegnarti.

Quando si distribuiscono contenitori in produzione, è necessario considerare anche l'hosting di immagini e l'iniezione di configurazione. È possibile utilizzare un servizio di registro pubblico per rendere disponibili le immagini nell'ambiente di produzione. In alternativa, puoi eseguire il tuo registro privato e fornire le credenziali come parte della tua pipeline CI. I valori di configurazione sono generalmente forniti come variabili di ambiente che puoi definire nella schermata delle impostazioni del tuo provider CI.