Der Vortrag behandelt die automatisierte Bereitstellung und Konfiguration von Docker-Hosts und -Containern unter Verwendung von Infrastruktur als Code (IaC) mit Tools wie Terraform und Ansible. Es wird gezeigt, wie diese Technologie sowohl auf physischer Hardware als auch in der Cloud angewendet werden kann, um einheitliche Entwicklungs- und Produktionsumgebungen zu schaffen. Ziel ist eine vollständige Automatisierung der Infrastrukturverwaltung und eine einfache Handhabung durch Versionierung im Git-Repository.

1. #BaselOne17
Infrastructure as
Code

2. Provisionierung von Dockerhosts
und -Containern mitTerraform,
Ansible und LXD auf Blech und Cloud
Infrastructure as Code

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

4. https://github.com/Remigius2011
https://stackoverflow.com/users/3639856/remigius-stalder
https://twitter.com/remigiusstalder
www.descom-consulting.ch
Remigius Stalder
passionate developer
descom consulting ltd. (since 1991)

5. Motivation
Tools
Plan
Demo
?
Outline

6. Motivation

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

9. Beispielarchitektur
app cluster
reverse
proxy
static
resources
web service
authc
app db
authc db
client

10. Tools

11. tools
ansible
lxd
terraform
docker
setup
containers

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)

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

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.)

20. Plan

21. swarm cluster (project A)
Cloud Setup
. . .docker host (VM instance)
container container container
container container
. . .
docker host (VM instance)
container container container
container container
. . .
swarm cluster (project B)
. . .docker host (VM instance)
container container container
container container
. . .
docker host (VM instance)
container container container
container container
. . .

22. bare metal (lxd host)
Lokales Setup (lxd)
. . .
docker host (VM instance)
container container container
container container
. . .
docker host (VM instance)
container container container
container container
. . .
bare metal (lxd host)
. . .
docker host (VM instance)
container container container
container container
. . .
docker host (VM instance)
container container container
container container
. . .
swarm
cluster
project A
swarm
cluster
project B

23. Setup Steps
Step 1: Management Host
openssh + private key, tools: git, terraform, ansible
=> Ansible
Step 2: LXD Host
openssh + public key, lxd, images
=> Ansible
Step 3: Provisioning (LXD Guest / CloudVM)
openssh + public key, fixed IP
=>Terraform
Step 4: Docker Hosts
docker, swarm
=> Ansible
Step 5: Docker Containers
à votre goût…
=> Ansible

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

26. Demo

27. Demo
=> shell

28. Conclusions

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

31. Getting Started
https://github.com/Remigius2011/iac

32. Questions

33. Danke für’s Zuhören…
resources:
slides https://www.slideshare.net/remigius-stalder/iac-baselone17
code https://github.com/Remigius2011/iac
links https://github.com/Remigius2011/iac/blob/master/doc/resources.md
Bildnachweis:
Motivation: https://unsplash.com/photos/oMpAz-DN-9I
Tools: https://www.pexels.com/photo/industry-metal-technology-manufacturing-47729/
Plan: https://www.pexels.com/photo/architect-architecture-artist-blur-268362/
Demo: https://pixabay.com/de/blitz-teslaspule-experiment-113310/
Conclusions: https://www.pexels.com/photo/view-ape-thinking-primate-33535/
Questions: https://pixabay.com/de/frage-fragezeichen-umfrage-problem-2736480/
Code: screenshots aus https://github.com/Remigius2011/iac (intellij)