Docker Images für unterschiedliche Plattformen bauen

Seit ich denken kann beherrschten x86 Architekturen meine IT Welt. Dank Smartphones, dem RaspberriPi, der Graviton Plattform von Amazon oder aktuellen Apple Geräten ändert sich das ein wenig. Als User können von diesem Wettbewerb nur profitieren. Für Programmierer und Admins wird die Welt ein wenig komplexer sobald wir Binaries bauen. Ich kann auf meinem lokalen Host x86_64 GNU/Linux mit nicht ohne erweitertes Tooling gegen eine andere Zielplattform wie linux/arm64 kompilieren und auch keine kompatiblen Images bauen.

Docker bietet dafür ein Cli Plugin namens BuildX vor mit dem Container in spezifischen Umgebungen gebaut werden können.

Der Prozess lässt sich wunderbar in eine Github Action einbauen die Images pusht und baut:

name: Build

on:
  push:
    branches: main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout code
        uses: actions/checkout@v2
      - name: install buildx
        id: buildx
        uses: crazy-max/ghaction-docker-buildx@v1
        with:
          version: latest
      - name: login to docker hub
        run: echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin
      - name: build the image
        run: |
          docker buildx build --push \
            --tag ${{ secrets.DOCKER_REPO_NAME }}:latest \
            --platform linux/amd64,linux/arm64 .

Die paar Zeilen Yaml müssen im Repository unter ./.github/actions abgelegt werden und schon fällt nach jedem Push auf den Main Branch ein neues Image heraus welches support für die Plattformen linux/amd64 und linux/arm64 hat. Das hat den schönen Nebeneffekt, daß sich z.b. Kubernetes automatisch das passende Image zieht und man braucht keine Anpassungen in Code oder Konfiguration zu machen wenn man Docker Images in unterschiedlichen Umgebungen laufen lässt.

Ausbafähig ist an der Stelle die Verwendung von Docker Secrets. Eventuell gibt es auch eine BuildX Action.

Helm Charts verwenden

Es gibt viele Wege Anwendungen und Konfigurationen in einen Kubernetes Cluster zu bringen.

Der Weg ueber Helm3 gefaellt mir besonders fuer third Party Software. Man fuegt das entsprechende Repository zu Helm hinzu, passt die Variablen ueber eine Konfigurationsdatei oder Parameter an und installiert das Chart. Der Uninstall Befehl hinterlaesst den Cluster meist besenrein.

Falls Dir das Thema Kubernetes fremd ist kannst Du innerhalb von ca 5. Minuten einen MicroK9s Cluster mit diesem Tutorial installieren und meine Schritte durchgehen. Es wird ein Monitoring Stack mit Grafana und den Backends Loki + Prometheus sowie einigen Dashboards installiert und konfiguriert. Hier die Dokumentation von den Grafanalabs.

Repo hinzufuegen

# Bitte das Kommando microk8s.helm3 statt helm3 verwenden falls Du microk8s nutzt.
helm3 repo add grafana https://grafana.github.io/helm-charts
helm3 repo update

Grafana, Loki, Prometheus, Fluent.d und den Alertmanager installieren

Um eine Anwendung zu testen starte ich gerne auf der Kommandozeile und Default Parametern in den Namespace

# Namespace anlegen microk8s.kubectl statt kubectel verwenden falls Du microk8s nutzt.
kubectl create  namespace monitoring

helm upgrade --install loki grafana/loki-stack \
  --set fluent-bit.enabled=true,promtail.enabled=false,grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

Nach ein paar Minuten sollten alle Pods hochgefahren sein und die Anwendung verfuegbar und man kann sich ein nacktes Grafana anschauen

# Passwort besorgen 

kubectl get secret --namespace monitoring loki-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

# Port forwarden 
kubectl port-forward --namespace monitoring service/loki-grafana 3000:80


Jetzt solltest Du dich auf http://localhost:3000/ mit username: admin und dem Passwort aus der Commandline anmelden koennen.

Anwendung loeschen

microk8s.helm3 uninstall loki  -n monitoring

Anwendungskonfiguration als Yaml File

Cli Parametern sind pratkisch um mal etwas auszuprobieren aber bei komplexeren Einstellungen wird es schnell unuebersichtlich und eine Textdatei die man Versionieren kann ist ungemein praktischer. In ~ 50 Zeilen Yaml kann man die gleichen Einstellungen deployen mit ein paar Extras wie:

  • Plugins installieren
  • Admin Passwort setzen (bitte nur auf localhost so laufen lassen)
  • Vorgefertigte oder selbst erstellte Dashboards installieren

values.yaml

fluent-bit:
  enabled: true
promtail:
  enabled: false
grafana:
  enabled: true
  persistence:
    enabled: false 
  adminPassword: 1q2w3e4r
  plugins:
  - grafana-piechart-panel
  dashboardProviders:
    dashboardproviders.yaml:
      apiVersion: 1
      providers:
        - name: default
          orgId: 1
          folder:
          type: file
          disableDeletion: true
          editable: false
          options:
            path: /var/lib/grafana/dashboards/default
  dashboards:
    default:
      Logging:
        gnetId: 12611
        revison: 1
        datasource: Loki
      K8health:    
        gnetId: 315
        revison: 1
        datasource: Prometheus
      ApiServer:  
        gnetId: 12006
        revison: 1
        datasource: Prometheus
prometheus:
  enabled: true
  server:
    persistentVolume:
      enabled: false
  alertmanager:
    persistentVolume:
      enabled: false

Nun den Stack erneut installieren

microk8s.helm3 upgrade --install --namespace=monitoring loki grafana/loki-stack  -f values.yaml

Analog zu den Dashboards koennen alle moeglichen und unmoeglichen Settings der Anwendung, Versionen bis zu persistant Volumes konfiguiert werden. Mir gefaellt besonders, dass wesentlich weniger Yaml produziert werden muss als z.B. bei Kustomize und man sehr schnell von „ich bastel ein wenig rum“ in den Zustand „ich habe eine wiederverwendbare Komponente die ich leicht modifizieren kann“ iterieren kann. Im naechsten Schritt kann man dann z.B. mit ArgoCD wunderbar continuous Delivery betreiben.