Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Infrastructure as Code mit Helm und Helmfile

Infrastructure as Code mit Helm und Helmfile

Das Tool-Ökosystem um Kubernetes wächst und wächst, dennoch ist es nach wie vor eine Herausforderung, reproduzierbare und gleichzeitig flexible Rollouts für Infrastrukturkomponenten und Anwendungen für verschiedene Stages zu automatisieren. In diesem Talk zeigt uns Tammo van Lessen einen Toolstack mit Helm 3 und Helmfile, mit dem er die Anforderungen aus Kundenprojekten durch Templating auf verschiedenen Ebenen erfüllen konnte.

Video: https://www.youtube.com/watch?v=Z8nJUycpPts

Tammo van Lessen

November 11, 2020
Tweet

More Decks by Tammo van Lessen

Other Decks in Programming

Transcript

  1. 1 1 . 1 1 . 2 0 2 0

    I N N O Q T E C H N O L O G Y L U N C H Infrastructure as Code mit Helm & Helmfile Tammo van Lessen Principal Consultant
  2. Kubernetes in 11 Sekunden Kubernetes Cluster Master Nodes Worker Nodes

    Pod Pod Pod Pod Pod kube-proxy kubelet API server etcd scheduler ccm cm kubectl
  3. Was ist Helm? • Paketmanager für Kubernetes • De-facto Standard

    (je nach dem wen man fragt) • Vitales Ökosystem im Artifact Hub (artifacthub.io) • Template-basiertes Rendering von K8s-Manifests • Versteckt K8s-Details, values.yaml ist die Schnittstelle • Bildet logische Klammer um zusammengehörige Manifeste • Versionierte Pakete (semver) • Wohl gealtert
  4. Helm-Terminologie • Chart • Repository • Template • Config •

    Release • Dependencies / Umbrella Chart • (Tiller) Chart Repository Kubernetes Cluster Release Release values.yaml
  5. Wo Helm nervt… • Helm Repositories müssen in separatem Schritt

    bekannt gemacht werden • Kein Templating bzw. Wiederverwendung innerhalb der Values möglich • Umgang mit Umgebungsvariablen mühsam • Unklar, was eigentlich auf dem Cluster verändert wird • Semver Version Ranges nur in Umbrella-Charts • Es gibt nicht für alles Helm Charts – oder die Qualität der Charts ist fragwürdig • Ausweg: Shell-Skripte mit helm, kubectl, jq, yq, gettext envsubst
  6. Was ist Helmfile? • Wrapper für Helm – führt Helm

    für euch aus • https://github.com/roboll/helmfile – 2,5k ⭐ – -factor? • Alles in einer Datei – aber aufteilbar • Mehr Kontrolle über die Abhängigkeiten • Mehrstufiges Templating • DRY • Konzept von Umgebungen • Integration von helm-diff und helm-secrets • Werte aus externen Quellen oder Skripten beziehen
  7. CLI

  8. Environments • Konstrukt, um umgebungsspezifische Werte zu definieren • Inline

    oder aus Dateien • Name steht in .Environment.Name, Werte unter .Values für Templating zur Verfügung
  9. Mehrstufiges Templating • Go templates mit Sprig und Erweiterungen •

    Helmfile Environments sind die Wertquellen • Platzhalter in Helmfile selbst und Dateireferenzen die auf .gotmpl enden werden evaluiert
  10. Eine Helmfile ist YAML, also kann man YAML auch nutzen.

    Don‘t repeat yourself https://github.com/roboll/helmfile/blob/master/docs/writing-helmfile.md#release-template--conventional-directory-structure
  11. • Helmfile integriert helm- secrets (zendesk), welches SOPS (Mozilla) verwendet.

    • Kann YAML-Dateien mittels AWS KMS, GCP KMS, Azure Key Vault and PGP ver- und entschlüsseln. • So können Secrets auch im Git-Repository hinterlegt werden. helm-secrets
  12. Externe Values • Weitere Möglichkeiten externe Werte und Secrets einzubinden:

    • Aufruf von Skripten via exec • Remote value.yaml files via Git-URL • variantdev/vals – Einbindung über URI-Referenzen • Vault, AWS (S3, SSM, Secrets Manager), GCP Secrets Manager, SOPS, Terraform State, File • mysql-password: refs+vault://secret/data/mycomponent#/mysqlpw
  13. Ich hab doch nur ein wenig YAML… • incubator/raw ist

    ein Helm Chart, das Manifests als Values entgegen nimmt.
  14. Anforderungen • Ziel: 3 „fast gleiche Umgebungen“: dev, preprod, prod

    • 2 AKS-Cluster (1x für dev+preprod, 1x für prod) • 3 Gruppen von Rollouts: • Cluster-Infrastruktur (je Cluster; nginx-ingress, cert-manager, external-dns, …) • Umgebungsinfrastuktur (je Umgebung; Kafka, InfluxDB, …) • Anwendungen/SCS (je Umgebung) • Es sollen definierte Versionsstände durch die Umgebungen propagiert werden. • Bugfixes sollen automatisch auf prod ausgerollt werden.
  15. Lösung • Automatisierung mit Gitlab CI, Provisionierung von AKS per

    Terraform • Cloud-Infrastruktur + Umgebungsinfrastruktur • Helmfile mit 2 Environments (devcluster + prodcluster) • Helmfile mit 3 Environments (dev, preprod, prod) • Umgebungen definieren Chart-Versionen für unabhängige Updates • raw-Charts in for-loops um Config und Secrets für die Anwendungen zu verteilen • Anwendungen • Automatische Bugfix-Rollouts durch Semver Range (~1.2.0) • DRY durch Release Template (für Kafka- und DB-Verbindungen)
  16. Anforderungen • Grundlage ähnlich zu Szenario 1. • Plus: Die

    Anwendung soll isoliert verschiedenen Kunden zur Verfügung gestellt werden. • Provisionierung soll möglichst automatisch über eine zentrale Konfigurationsdatei erfolgen
  17. Fazit Extrem flexibel dank Templating Ein Tool für alles Einfaches

    Secrets Management Werte aus verschiedenen Quellen beziehen
  18. Danke! Fragen? Tammo van Lessen [email protected] +49 171 2774 106

    @taval Krischerstr. 100 40789 Monheim am Rhein Germany +49 2173 3366-0 Ohlauer Str. 43 10999 Berlin Germany +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany +49 2173 3366-0 Kreuzstr. 16 80331 München Germany +49 2173 3366-0 Hermannstrasse 13 20095 Hamburg Germany +49 2173 3366-0 Gewerbestr. 11 CH-6330 Cham Switzerland +41 41 743 0116 innoQ Deutschland GmbH innoQ Schweiz GmbH www.innoq.com