Provisionierung von Dockerhosts und -Containern mit Terraform, Ansible und LXD auf Blech und Cloud
Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden. Dieser Vortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der (oder des) Engineers vorhanden sind.
Es wird gezeigt, wie das Verfahren sowohl auf Blech (d.h. auf lokalen physischen Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse Übereinstimmung zwischen Test-/Integrations- und Produktionsinfrastruktur erreicht wird.
Die vorgestellten Werkzeuge sind terraform und ansible für Provisionierung und Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
3. Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch
automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden.
DieserVortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll
maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der
(oder des) Engineers vorhanden sind.
Es wird gezeigt, wie dasVerfahren sowohl auf Blech (d.h. auf lokalen physischen
Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse
Übereinstimmung zwischenTest-/Integrations- und Produktionsinfrastruktur erreicht
wird.
Die vorgestelltenWerkzeuge sind terraform und ansible für Provisionierung und
Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und
Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle
TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
Abstract
7. Was ist IaC?
Definition der Infrastruktur:
Ressourcen (Maschinen, Netzwerk etc.)
Konfiguration (OS, Software, User etc.)
Kein GUI, nur Code!
alles geht in ein (git-) repo
automatisierte Bereitstellung von lauffähigen
Systemen on premise / in cloud
Ziel: 100% Automatisierung, alles ephemer
d.h. wegwerfbar
8. Was möchten und können wir damit erreichen?
Automatisierung: Provisionierung und Konfiguration
einheitliche Umgebungen (dev/int/prod – local/cloud)
alles versioniert in einem repository
“single source of truth”
einfache Updates (z.B. neue OSVersion)
inkrementelleÄnderungen
Reproduzierbarkeit
schnellereVerfügbarkeit
=> geringeres Risiko
geringere Kosten
12. Terraform
Open-Source Projekt: Hashicorp
implementiert in: go
Provisionierung von (virtuellen) Resourcen
VMs, Netzwerke etc.
Plugins
Cloud Providers (AWS, Azure, DigitalOcean…),
Lokale Infrastruktur (LXD, OpenStack,VMware vSphere…)
DSL
Alternativen
CloudFormation (AWS), docker-machine (docker), InfraKit (moby)
13.
14. Ansible
Open-Source Projekt: Red Hat
implementiert in: python
Konfigurationsmanagement
Konfiguration von bereitgestellten Ressourcen, wie:
Softwareinstallation, Anpassung von Konfigurationsdateien,
Einrichtung der Users etc.
Strukturierung
Inventar und Rollen
Playbooks: Definition der Konfiguration (yaml)
Roles: einzelne Aspekte der Infrastruktur (Modularisierung)
Variablen: Parametrisierung (auch verschlüsselt – z.B. für Passwörter)
Plugin Module: für die meisten Aufgaben vorhanden
Alternativen
Chef, Saltstack, Puppet
15.
16. Provisionierung / Konfiguration:Terraform vs. Ansible
Beide sind:
code-driven
agentenlos (über ssh / Ansible mit python)
Terraform Ansible
Provisionierung von (VM-) Instanzen Konfiguration (VM + Blech)
Initialisierung Verfeinerung
Immutable Mutable
proprietäre DSL (HCL) yaml
(HashiCorp) (Red Hat)
17. lxd
Open-Source Projekt: Canonical - linuxcontainers
implementiert in: go
Systemcontainer – leichtgewichtigeVMs
Hosts: div. Linux, u.a. alpine, fedora, ubuntu + snap package
Images: div. Linux, u.a. alpine, centos, debian, fedora, ubuntu
eigene Images als export oder .tar.gz
resource constraints, nesting, live migration (checkpoint/restore)
backing store: ext4, ZFS, Btrfs, LVM
security: apparmor, seccomp
lxd host routet IP traffic zu den containers (by default)
Caveat
upstream docker läuft (derzeit) nur in privilegierten Containern!
d.h. root im container = root auf host
18. Docker
Open-Source Projekt: Docker Inc.
implementiert in: go
Applikationscontainer – App/Service + Umgebung
Hosts: Linux (viele Distributionen), Mac,Win
Images: viele vorgefertigte auf https://hub.docker.com/
einfache und reproduzierbare Erstellung eigener Images (Dockerfile)
Sandbox Umgebung, ingress port mapping, transiente / persistente Daten,
environment
Clustering
swarm: task dispatching, load-balancing, fail-over, restart policies,
skalierung, rolling upgrades/rollbacks
=> ideal für microservices
CLI + REST-API
java clients: com.spotify:docker-client, com.github.docker-java:docker-java
19. Containers: Docker vs. LXD
Gleicher Ursprung: Linux Containers
namespaces (“Virtualisierung” der Systemressourcen)
cgroups (Policies für Ressourcenverwendung)
Client-Server Architektur
beide haben: CLI + REST API
LXD Docker
ganzes (Linux-) OS Einzelner Prozess (mit Umgebung)
vollst. Images (tgz) Images in Layers (Delta)
eigene Images unüblich eigene Images einfach (Dockerfile)
leichtgewichtige VM Virtualisierung einer Applikation
(Canonical) (Docker Inc.)
24. Szenarios / Umgebungen
Umgebung Step 1
(mgt)
Step 2
(lxd host)
Step 3
(provisioning)
Step 4
(docker)
Step 5
(containers)
bare x x x
lxd x x x x x
cloud x x x x
bare: docker direkt auf OS/Blech (keine Provisionierung)
lxd: docker in lxd container
cloud: docker in cloud vm
25. Kontrollmöglichkeiten
mgt host
lxd host
(bare metal)
docker host
(lxd guest)
docker host
(cloud VM)
docker
containers
lokal
cloud
die Pfeile symbolisieren die Kontrollmöglichkeiten via ssh / ansible (vom mgt host) resp. CLI (lxc / docker)
ssh / lxc
ssh
ssh
ssh / lxc docker
docker
29. Conclusions
Terraform/Ansible: DSLs (zu?) einfach
einfach zu lernen
manchmal work-arounds für mangelnden Sprachaustruck nötig
Terraform: im Nu ein Cluster am Laufen!
…und ebenso schnell wieder weggezaubert
Provisionierung undVorbereitung für Ansible, dann weiter mit Ansible
Ansible: für fast alles ein Plugin vorhanden
wenn Plugin fehlt oder unpassend: einfach shell-Modul verwenden
lxd: Experimentierlabor
Viele hosts mit wenig Hardware schnell erstellt, eigene IaaS ohne grossen Aufwand
für Produktion als docker host m.E. (noch) nicht geeignet (privileges)
Docker: Infrastruktur als Commodity – Apps verpackt
Apps laufen in jeder Umgebung (praktisch) gleich: dev/test/prod – local/cloud
Handling extrem vereinfacht – drastischeVerringerung des Aufwands
30. Best Practices
Security first!
mgmt host sichern, ssh keys, UFW auf lxd hosts etc.
100% Automation – no compromise
Dockerfile / ansible / terraform / shell => alles ins (git) repo!
Manchmal ist etwas Hartnäckigkeit nötig, um wirklich alles zu automatisieren…
Netzwerk planen: IP Adressen der lxd hosts und containers – think big!
Z.B. innerhalb 10.0.0.0/8: je ein ClassC Netz pro lxd host (+ ipv6 wenn nötig)
lxd host routet ingress traffic zu containers -> static routes definieren
(mit ansible oder in router/firewall)
Docker Container Inheritance: aufzeichnen (DAG)
Optimierung der notwendigen Layers durch Minimierung der Parents
Verwendung von minimalen Basis-Images, wie z.B. Alpine
Ansible: gute Struktur
Was brauchen wir?Welche Roles? -> Roles zuerst als Skelett (Task Namen / Kommentare)
dann Playbooks, Inventar (hosts/groups),Variablen, Secrets
Ansible:Tasks möglichst idempotent
mehrfache Ausführung eines playbooks sollte dasselbe Ergebnis erzielen
Terraform: Status nach Destroy prüfen
in seltenen Fällen wird nicht alles destroyed…
Secrets
Passwörter, Keys etc. geheim halten: ansible vault, secrets in docker swarm,
terraform: via command line aus ansible vault