http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5

1. Richard Attermeyer
OPITZ CONSULTING Deutschland GmbH
Vagrant, Puppet, Docker für
Entwickler und Architekten

2. Ihr Sprecher
Richard Attermeyer
richard.attermeyer@opitz-consulting.com
twitter/attermr
github/rattermeyer
blog.devopsarchitect.de / www.thecattlecrew.com

3. Agenda

4. High-Level Überblick

5. High-Level Überblick
Entwicklung + Continuous
Delivery

6. High-Level Überblick
Entwicklung + Continuous
Delivery
VMs, Config Mgmt, Container

7. Los geht‘s

8. DevOps
Kultur- und Prozesswandel
Wir haben noch nicht alle Antworten
Umfasst unterschiedliche Gruppen
Name ist neu
Mehr Firmen beschäftigen sich damit

9. Continuous Delivery
Sammlung von Techniken, Prozessen und
Werkzeugen, die den Softwarelieferprozess
verbessern

10. Bildquelle / URL
Aber womit anfangen?

11. Dauer bis Arbeitsumgebung steht

12. Dauer bis Arbeitsumgebung steht
Dauer bis Änderung in
Arbeitsumgebung verteilt

13. Dauer bis Arbeitsumgebung steht
Dauer bis Änderung in
Arbeitsumgebung verteilt
Versionierung von
Arbeitsumgebungen

14. Dauer bis Arbeitsumgebung steht
Dauer bis Änderung in
Arbeitsumgebung verteilt
Versionierung von
Arbeitsumgebungen
„Works on my machine“

15. Virtuelle Maschinen

16. Lösungsmöglichkeit
Golden Image

17. Aber:

18. Golden Image: Probleme
 Groß
 Verteilung dauert
 Einfaches Customizing schwierig
 Viele verschiedene Konfigurationen
 Jede kleine Änderung erzeugt direkt große Datenmenge
und komplette Re-Installation
 Keine Zusammenarbeit
 Versionierung schwierig

19. Und jetzt?

20. Lösungsmöglichkeit
Development environments
made easy.

21. Entwickler-Workflow
> git clone https://gh.com/rattermeyer/jenkins-in-a-box.git*
> cd jenkins-in-a-box
> vagrant up
* git clone https://github.com/rattermeyer/jenkins-in-a-box.git

22. Vagrant: Vagrantfile
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "phusion/ubuntu-14.04-amd64"
config.vm.provider "virtualbox" do |vb|
vb.customize ["modifyvm", :id, "--memory", "1024"]
vb.customize ["modifyvm", :id, "--cpus", "1"]
end
config.vm.provision "puppet" do |puppet|
puppet.manifests_path = "puppet/manifests"
puppet.manifest_file = "site.pp"
puppet.module_path = "puppet/modules"
puppet.options = "--verbose --debug"
end
config.vm.network "private_network", ip: "192.168.33.10"
end

23. Base Box
 Vorgefertigtes Vagrant VM image, ready-to-run
 Eigene Erstellung möglich
 Base Box ist Basis für weiteres Provisioning

24. Provisioning
Projekt:
Ubuntu Base
Provisioning
Spezifische
VM
Projekt:
Ubuntu
Base
Provisioning
Tomcat
JDK
IDE
Entwicklungs-umgebung

25. Provisionierung
Hohe
Flexibilität
Lange Dauer
Provisioning
Geringe
Flexibilität
Kurze
Provisionierungs-dauer

26. Zusammenfassung
 Viele vorgefertigte Images
siehe Vagrant Cloud und Vagrantbox.es .
 Vagrantfiles.
Aufsetzen der Box bei Initialisierung
 Maschinen-Schnappschüsse als Vagrant Box file
(Verteilung und Austausch)
 Feinabstimmung der VM Parameter
RAM, CPU, APIC...
 Integration mit CM Werkzeugen
Puppet, Chef, Ansible, Salt

27. Puppet / Config Management

28. Wie kann Puppet helfen?
 Transparenz
 Systemdefinition an zentraler Stelle
 Systemdefinition ist klar strukturiert und verständlich
 Reporting über Änderungen
 Automatisierung
 Systemaufbau „auf Knopfdruck“
 Nicht nur initial, sondern über den ganzen Lifecycle
 Reproduzierbarkeit
 Systemaufbau ist durch Definitionsdatei zuverlässig reproduzierbar
 Konfigurationsänderungen sind sichtbar und bei Bedarf revidierbar
 Änderungen sind versionierbar

29. Arbeitsablauf mit Puppet
Grundidee:
„Beschreibe das Zielsystem, Puppet kümmert sich um den Weg dahin“
Resource
Definition
Reporting apply --noop
apply

30. Deklarativ
Infrastructure-as-Code

31. Deklaration einer Ressource
Wichtigste Ressourcetypen
 File
 Package
 Service
 Außerdem: exec, user, group,
notice
file { "/var/tmp/foo":
ensure => present,
owner => "ec2-user",
group => "ec2-user",
}

32. Klassen
 Zur Gruppierung
zusammenhängender
Ressourcen
 Klassen können auch
parametriert werden
 Aber: Jede Klasse wird pro
Knoten nur einmal instanziiert!
class ntp {
package { "ntp":
ensure => present,
}
service { "ntp":
ensure => running,
require => Package["ntp"],
}
}

33. Module
 Einheitliche Struktur und Kapsel
für ein Feature
 Module in Puppets Modulepath
können direkt eingebunden
werden
 Über puppet modules können
Module von PuppetForge
geladen werden
<name>
manifests/
init.pp
…
files/
tests/
templates
lib/

34. Infrastructure-as-Code
package { 'curl':
}
class { '::java' :
}
include profiles::jenkinsmaster
include ssh::client
class profiles::jenkinsmaster (
$lts = true
) {
class { 'jenkins':
lts => $lts,
install_java => false,
}
include jenkins::master
create_resources('jenkins::plugin',
hiera_hash('jenkinsmaster::plugins'))
}

35. Deklarativ
Versionskontrolle
Teilen von Modulen

36. Zurück zu Vagrant

37. Use Cases?

38. Entwicklungsumgebung

39. Entwicklungsumgebung
< 5 Maschinen

40. Entwicklungsumgebung
< 5 Maschinen
„Resourcenhungrig“

41. Mehr unabhängige VMs?
Build Once Run Anywhere?

42. Bildquelle / URL
Build Ship Run

43. BSD Jails / Solaris Zones
Linux Containers
Docker Container / Images

44. App A App B
Gast BS Gast BS
Hypervisor
Host BS
App A App B
Docker Engine
Hypervisor
Host BS
Virtuelle
Maschinen
Container

45. docker run –it ubuntu bash

46. Dockerfile
FROM rattermeyer/ubuntu-jdk:1.0
maintainer richard.attermeyer@gmail.com
ENV PROJECT_VERSION 0.0.1-SNAPSHOT
ENV PROJECT_NAME todo-list-backend
RUN mkdir /opt/${PROJECT_NAME}
ADD ${PROJECT_NAME}-${PROJECT_VERSION}.jar /opt/${PROJECT_NAME}/
EXPOSE 8080
ENTRYPOINT java -jar /opt/${PROJECT_NAME}/${PROJECT_NAME}-
${PROJECT_VERSION}.jar

47. Zusammenfassung
 Leichtgewichtig
Docker Images sind viel leichtgewichtiger als volle VMs. Start
dauert Sekunden anstatt wenige Minuten. Zu verteilende
Images i.d.R. kleiner (nur Delta, neuer FS Layer)
 Versionskontrolle der Images
Daher einfacheres Handling von Builds. Und damit auch
geeigneter für eine Continuous Delivery Pipeline
 Lots of images (again)

48. Use Cases, Kosten und Nutzen

49. CD Build Agent / Slave
Jenkins / GO CD
Source Code
Puppet / Java /
Schemaverwaltung
Entwicklung
Vagrant
Continuous Delivery
Pipeline
Jenkins / GO CD
Test
Docker / Vagrant
Produktion
Docker / VM
Puppet

50. Docker
Use Case Aufwand / Nutzen
 Leichtgewichtige VMs
 Statisch, homogene
Umgebungen
 Isolation von mehreren
Slaves im CD Prozess
 Gut für Microservices
Verteile nicht das war / ear
sondern den ganzen
Container
 Spring Boot, DropWizard, self
contained deployment
 Flache Lernkurve
 Recht schnell guter Nutzen
für Continuous Delivery
 Betrieb noch mit Aufwand
verbunden

51. Vagrant
Use Case Aufwand / Nutzen
 Entwicklerumgebung
(Entwicklung in the Box inkl.
IDE)
 Testgrid (auch für CD) für
verschiedene
Betriebssysteme
 Ubuntu, RedHat, Windows
 CM Tool für einheitliches
Provisioning über
unterschiedliche OS
 Homogene Umgebung
 Einfach, Shell / Ansible Provisioning
 Flache Lernkurve
 Schnell guter Nutzen
 Test Grid / Unterschiedliche
Umgebungen
 Schwer. Erfordert CM Know-how
 Hoher Aufwand Planung
 Wenige (Inhouse-)Projekte haben
diese Anforderungen

52. Puppet
Use Case Aufwand / Nutzen
 Management status-behafteter
Umgebungen
 Abstraktion von Resourcen /
Distributionen
 Nutzung in bestehenden
Prozessen
 Hohe Lernkurve
 Strategische Entscheidung
 Schwierig: Unterschiedliche
Umgebungen (Debian vs. RedHat)
 Gute Module finden / selber entwickeln
aufwändig
 Einfacher: Homogene Umgebung
 Aber warum dann nicht ansible?
 Nützlich: In Kombination etwa mit
Docker
 Konfiguration des Hosts mit Puppet
 Guests: Docker Container

53. Bildquelle / URL
Ausblick

54. Entwicklungsumgebungen
 Vagrant
 Fig: Für Docker Umgebungen
 Vortex: nodejs basiert
Ecosystem
 Vagrant Plugins
 Vagrant Cloud
 Vagrant Jenkins Plugin
Config Management
 Puppet
 Chef
 Ansible, Saltstack
Ecosystem
 Puppet Forge
 Chef Recipes
 Ansible Galaxy
 …
Containerization
 Docker
 Linux Container
 OpenVZ
Ecosystem
 CoreOS
 Maestro-ng, fig,
 Consul, SkyDns, SkyDock, Serf
 Kubernetes

55. Viele neue Projekte

56. Viele neue Projekte
Wenig Erfahrungen im
Enterprise Umfeld

57. Viele neue Projekte
Wenig Erfahrungen im
Enterprise Umfeld
Heute Hip, morgen out

58. DevOps und CD wichtig

59. DevOps und CD wichtig
Einzelne Aspekte gut
verstanden

60. DevOps und CD wichtig
Einzelne Aspekte gut
verstanden
Nichts tun: Keine Option

61. Es gibt viel zu tun:
Packen wir‘s an

62. Bildquelle / URL
Fragen?

63. Demo?

64. Demo
 Vagrant startet docker host
 Docker: Sonar, Nexus, Git-Server, Jenkins-Master, Jenkins-
Slave
 Jenkins-Master: Provisioniert mit Puppet

65. Kontakt
Richard Attermeyer
Senior Solution Architect
OPITZ CONSULTING GmbH
Kirchstr. 6 | 51647 Gummersbach
Phone: +49 173 727 9004
Mail: richard.attermeyer@opitz-consulting.com
Twitter: @attermr
Blog: blog.devopsarchitect.de
youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting

66. Fotoreferenzen
„Computer Problems“ by CollegeDegrees360 is licensed under CC BY 2.0
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported
License.
“Crossroads” by Carsten Tokmit is licensed under CC BY-SA 2.0
“Gucker” by H.P. Brinkmann is licensed under CC BY 2.0