Vagrant, Puppet, Docker für Entwickler und Architekten

3.380 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Vagrant, Puppet, Docker für Entwickler und Architekten

  1. 1. Richard Attermeyer OPITZ CONSULTING Deutschland GmbH Vagrant, Puppet, Docker für Entwickler und Architekten
  2. 2. Ihr Sprecher Richard Attermeyer richard.attermeyer@opitz-consulting.com twitter/attermr github/rattermeyer blog.devopsarchitect.de / www.thecattlecrew.com
  3. 3. Agenda
  4. 4. High-Level Überblick
  5. 5. High-Level Überblick Entwicklung + Continuous Delivery
  6. 6. High-Level Überblick Entwicklung + Continuous Delivery VMs, Config Mgmt, Container
  7. 7. Los geht‘s
  8. 8. DevOps Kultur- und Prozesswandel Wir haben noch nicht alle Antworten Umfasst unterschiedliche Gruppen Name ist neu Mehr Firmen beschäftigen sich damit
  9. 9. Continuous Delivery Sammlung von Techniken, Prozessen und Werkzeugen, die den Softwarelieferprozess verbessern
  10. 10. Bildquelle / URL Aber womit anfangen?
  11. 11. Dauer bis Arbeitsumgebung steht
  12. 12. Dauer bis Arbeitsumgebung steht Dauer bis Änderung in Arbeitsumgebung verteilt
  13. 13. Dauer bis Arbeitsumgebung steht Dauer bis Änderung in Arbeitsumgebung verteilt Versionierung von Arbeitsumgebungen
  14. 14. Dauer bis Arbeitsumgebung steht Dauer bis Änderung in Arbeitsumgebung verteilt Versionierung von Arbeitsumgebungen „Works on my machine“
  15. 15. Virtuelle Maschinen
  16. 16. Lösungsmöglichkeit Golden Image
  17. 17. Aber:
  18. 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. 19. Und jetzt?
  20. 20. Lösungsmöglichkeit Development environments made easy.
  21. 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. 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. 23. Base Box  Vorgefertigtes Vagrant VM image, ready-to-run  Eigene Erstellung möglich  Base Box ist Basis für weiteres Provisioning
  24. 24. Provisioning Projekt: Ubuntu Base Provisioning Spezifische VM Projekt: Ubuntu Base Provisioning Tomcat JDK IDE Entwicklungs-umgebung
  25. 25. Provisionierung Hohe Flexibilität Lange Dauer Provisioning Geringe Flexibilität Kurze Provisionierungs-dauer
  26. 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. 27. Puppet / Config Management
  28. 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. 29. Arbeitsablauf mit Puppet Grundidee: „Beschreibe das Zielsystem, Puppet kümmert sich um den Weg dahin“ Resource Definition Reporting apply --noop apply
  30. 30. Deklarativ Infrastructure-as-Code
  31. 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. 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. 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. 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. 35. Deklarativ Versionskontrolle Teilen von Modulen
  36. 36. Zurück zu Vagrant
  37. 37. Use Cases?
  38. 38. Entwicklungsumgebung
  39. 39. Entwicklungsumgebung < 5 Maschinen
  40. 40. Entwicklungsumgebung < 5 Maschinen „Resourcenhungrig“
  41. 41. Mehr unabhängige VMs? Build Once Run Anywhere?
  42. 42. Bildquelle / URL Build Ship Run
  43. 43. BSD Jails / Solaris Zones Linux Containers Docker Container / Images
  44. 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. 45. docker run –it ubuntu bash
  46. 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. 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. 48. Use Cases, Kosten und Nutzen
  49. 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. 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. 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. 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. 53. Bildquelle / URL Ausblick
  54. 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. 55. Viele neue Projekte
  56. 56. Viele neue Projekte Wenig Erfahrungen im Enterprise Umfeld
  57. 57. Viele neue Projekte Wenig Erfahrungen im Enterprise Umfeld Heute Hip, morgen out
  58. 58. DevOps und CD wichtig
  59. 59. DevOps und CD wichtig Einzelne Aspekte gut verstanden
  60. 60. DevOps und CD wichtig Einzelne Aspekte gut verstanden Nichts tun: Keine Option
  61. 61. Es gibt viel zu tun: Packen wir‘s an
  62. 62. Bildquelle / URL Fragen?
  63. 63. Demo?
  64. 64. Demo  Vagrant startet docker host  Docker: Sonar, Nexus, Git-Server, Jenkins-Master, Jenkins- Slave  Jenkins-Master: Provisioniert mit Puppet
  65. 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. 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

×