Pattern strutturali e dove trovarli: analizziamo il sidecar container, cos’è e come funziona.

Definizione

Un Sidecar container estende e migliora le funzionalità di un container preesistente, senza modificarlo.

Questo modello è uno di quelli fondamentali nel dominio dei container perché permette ai container single-purpose di cooperare strettamente tra loro.

Il pattern Sidecar descrive questo tipo di collaborazione in cui un container migliora la funzionalità di un altro container.

In pratica…

Un esempio tipico usato per dimostrare questo pattern è quello di un server HTTP e di un sistema per la sincronizzazione con Git.

Il container del server HTTP si concentra solo sull’attività di servire i file dell’applicazione web tramite un server e non sa come e da dove provengono i file. Allo stesso modo, il container Git ha come unico obiettivo quello di sincronizzare i dati da un server al filesystem locale, senza preoccuparsi di come questi verranno utiizzati.

Questo esempio mostra come il sincronizzatore di Git migliora il comportamento del server HTTP con i contenuti da esporre mantenendoli sincronizzati:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
  labels:
    project: k8spatterns
    pattern: Sidecar
spec:
  containers:
    - name: app
      image: centos/httpd
      ports:
        - containerPort: 80
      volumeMounts:
        - mountPath: /var/www/html
          name: source
    - name: poll
      image: bitnami/git
      env:
        - name: SOURCE_REPO
          value: https://github.com/mdn/beginner-html-site-scripted
      command: [ "sh", "-c" ]
      args:
        - |
          git clone $(SOURCE_REPO) .
          while true; do
            sleep 60
            git pull
          done          
      workingDir: /var/lib/data
      volumeMounts:
        - mountPath: /var/lib/data
          name: source
  volumes:
    - emptyDir: {}
      name: source

Potremmo anche dire che entrambi i container collaborano e sono ugualmente importanti, ma in un modello Sidecar, c’è sempre un container definito come principale e un container di supporto (o ausiliario) che migliora il comportamento del server HTTP.

In genere, il container principale è il primo nella definizione dello YAML del Pod e rappresenta il container predefinito.

Questo semplice schema, illustrato in figura, rappresenta la collaborazione dei container in fase di esecuzione, e allo stesso tempo consente la separazione delle responsabilità per entrambi i container, che potrebbero essere di proprietà di team diversi, che utilizzano linguaggi di programmazione diversi, con cicli di rilascio diversi, e via dicendo.

Inoltre, questo pattern promuove inoltre la sostituibilità e il riutilizzo dei container, in quanto il server HTTP e il sincronizzatore Git possono essere riutilizzati in altre applicazioni e configurazioni diverse.

Risorse utili

• Docker - per cominciare bene con Docker e Kubernetes
• Kubernetes - Guida per gestire e orchestrare i container