Virtualisation and automation - how to program your data center

Über uns Mathias Münch Jörg Meltzer Schichten der Automatisierung Virtualisierung und Automatisierung - wie man sich ein Rechenzentrum programmiert HW Hypervisor Virtuelle Maschine Betriebssystem Anwendungskonfiguration Blade, SAN, Switch Betriebssystem der Virtualisierungsplatform
z.B. VMware ESXi, Xen erstellen, zerstören, virtuelle Hardware konfigurieren Installserver: Kickstart, PXE Boot
Dienste: DNS, DHCP,LDAP, VCS Konfigurationsmanagement-
Tools: Puppet/Chef/CFEngine Virtualisierung mit VMware Sphere vSphere Automatisierung leichtgewichtiger Wrapper um vCenter Soap Api
Schnelle Entwicklung
Beispielskripte nutzen vm{create,destroy,info,control}.pl
gute Online API Dokumentation
API bietet auch synchrone Operationen
VMware Community Skripte
schlecht
Codequalität Beispielskripte
POD Dokumentation in Modulen fehlt
keine VMware Shell analog zur PowerShell CLI vSphere Perl-SDK Konfigurationsmanagement
mit CFEngine3 CFEngine Policies
"Makefile" für Systemkonfiguration
konvergente Konfiguration
Policyhub ist dummer Fileserver
autonome Client Agenten
deklarative Sprache
beschreibt, was gemacht werden soll, nicht wie
Modularisierung mit Bundles und Bodys Betriebssystem Installation
mit Cobbler zentraler Installationsserver
Open Source
automatisiert OS Installation
RHEL, SuSE, Debian
vereinfacht Handhabung von
PXE Boot, TFTP Server, DHCP, DNS, ...
Flexible Kickstarts mit Snippets und Templating
Web Interface
Orchestrierung
Distribution, Profil, System, YUM Repos
Python, XML-RPC Schnittstelle Beispiel - Reporting #!/usr/bin/perl
use strict;
use warnings;

# Step 1: Import the vSphere SDK for Perl Modules.
use VMware::VIRuntime;

# Step 2: (Optional) Define Script-Specific Command-Line Options.
my %opts = (
entity => {
type => "=s",
help => "ManagedEntity type: VirtualMachine, etc",
required => 1,
},
);

Opts::add_options(%opts);
Opts::parse();
Opts::validate();
# Step 3: Connect to the Server.
Util::connect();

# Step 4: Obtain View Objects of Server-Side Managed Objects.
# Obtain all inventory objects of the specified type

my $entity_type = Opts::get_option('entity');
my $entity_views = Vim::find_entity_views(
view_type => $entity_type);

# Step 5: Process Views and Report Results.
# Process the findings and output to the console
foreach my $entity_view (@$entity_views) {
my $entity_name = $entity_view->name;
Util::trace(0, "Found $entity_type: $entity_name\n");
}

# Step 6: Close the Server Connection.
# Disconnect from the server
Util::disconnect(); Staging und Yum Repositories Cobbler Features Beispiel # import mounted dvd
cobbler import --path=/mnt --name=CentOS-6 --kickstart=/var/lib/cobbler/kickstarts/default.ks
cobbler distro report --name CentOS-6

cobbler profile add --name latest --comment "profile for development hosts"
cobbler repo add --name latest --mirror /var/www/yum/latest --comment "yum repo for development" ...

cobbler profile add --name int --comment "profile for integration hosts"
cobbler repo add --name int --mirror /var/www/yum/int --comment "yum repo for integration"
cobbler system add --name int1 --profile int --interface eth0 --mac ... --ip ...


cobbler profile add --name prod --comment "profile for prod1 hosts"
cobbler repo add --name prod --mirror /var/www/yum/prod --comment "yum repo for prod"
cobbler system add --name prod1 --profile prod

# dhcp, tftp... synchronisieren
cobbler sync CI fordert Versionierung
Konfiguration und Source Code
keine Binaries
Zusammenstellung der Yum Repositories muss versioniert werden
Zentrale RPM Halde
Stage Yum Repos mit Symlinks
Linkliste mit RPM Pfaden versionieren (trunk)
Symlinks wiederherstellen (andere Stages) Infrastructure
as a Service Infrastructure as Code VMware vSphere 4.1
VMware vSphere SDK for Perl vmcreate.pl --vmname "testVM" --mac0 00:50:56:7e:45:1b --tpl L cobbler system add
--name=<x10110.domain.de>
--profile=<RHEL6>
--mac=<00:50:56:7e:45:1b>
--ip=<172.22.113.50>
--hostname=<x10110.domain.de> bundle agent resolver
{
files:
"/etc/resolv.conf"
copy_from => remote( "${global.cfmaster}","$(global.filestore)/resolver/resolv.conf","false"),
classes => if_ok("resolv_conf_ok"),
perms => mog("644", "root", "root");

reports:
resolv_conf_ok::
"Name resolution configured correctly.";
} PXE Boot, DHCP
Netzwerkinstallation Service + Stage Datei
Konfiguration "Infrastructure as code". I love the phrase. Where devops is a word that is sadly open to so much (mis)interpretation, "Infrastructure as code" is pretty clear. Treat your infrastructure as code. Programmable. Testable. Deployable. (John E. Vincent) DevOps does not preclude the use of other frameworks or methodologies, such as ITIL (Gartner, Inc., 2011)
there is nothing mutually exclusive about Devops and the enterprise process. (John Wills, 2010) Tags Versionskontrolle Trunk Stages Übergang zum
Konfigurationsmanagement Vorsicht Featuritis, nur das Nötigste in Kickstart installieren
System mit Service und Stage Information impfen
Letzter Task der OS Installation ist der initiale Lauf des Konfigurationsmanagement Tools In der Stage
Konfigurationsmanagement Policies
Anwendungskonfiguration Templates
Yum/Apt Repository Paket Zusammenstellung Außerhalb der Stage Datenbank
Yum / Apt Repository Inhalte
Anwendungskonfiguration Parameter
Konfigurationsmanagement Datenbank Ops machen Code von Devs lernen
Agile Methoden
Continuous Delivery
Automatisierte Tests Devs machen Infrastruktur von Ops lernen
Packaging
Konfigurationsmanagement
Monitoring http://nikhewitt.blogspot.de/ http://www.geograph.ie/photo/790351 ein zufälliges Wolkenfoto bunde agent shadow { # wie Subroutine

classes:
"solinux" expression => "linux|solaris";

files: # Phase
solinux:: # Einschränkung
"/etc/shadow" # promise
perms => p_shadow; # promise body

}

body perms p_shadow { # snippet, template
mode => "640";
owners => {"root"};
groups => {"shadow"};
} "'Real Programmers' are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly"
(Ed Post, Real Programmers Don't Use PASCAL) Install Server neuer Server Netzwerkaddresse via DHCP beziehen
TFTP download Kernel + Initrd
Download automatisches Kickstart Bootskript
Installation durchführen Herkömmliche
Netzwerkinstallation manuelle Netzwerkinstallation neue Mac Addresse in /etc/dhcpd.conf eintragen
PXE Boot Datei auf TFTP Server anlegen
Copy & Paste Kickstart Datei von einem Template
DHCPD neustarten
neuen Server einschalten
warten
über Fehler in obiger Prozedur ärgern http://www.fotopedia.com/items/flickr-5685814540 Artefakte Source
Code Zielplattform Umgebung Stages Latest Integration QA Prod1
(inaktiv) Prod2
(aktiv) VMs
Services VMs
Services VMs
Services VMs
Services VMs
Services Version trunk r4711 Integration-Build-42 Integration-Build-42 Integration-Build-41 packages.csv
CFEngine
masterfiles Konfiguration (änderbare Parameter)
Anwendungen
Infrastruktur http://en.wikipedia.org/wiki/File:The_giant_wenger.jpg Clonen und patchen
oder neu bauen? Infrastructure
as Code Jenkins für Infrastruktur CI Server bauen Softwareprojekte
... und jetzt auch virtuelle Maschinen
Jenkins Jobs reinstallieren virtuelle Maschinen und
testen, ob die Infrastruktur Maschinen noch baubar sind
führen funktionale Tests für fachlichen Anwendungen durch Staging und Yum Repositories CI fordert Versionierung
Konfiguration und Source Code
keine Binaries
Zusammenstellung der Yum Repositories muss versioniert werden
Zentrale RPM Halde
Stage Yum Repos mit Symlinks
Linkliste mit RPM Pfaden versionieren (trunk)
Symlinks wiederherstellen (andere Stages) Tags Versionskontrolle Trunk Stages Artefakte Source
Code Zielplattform Umgebung Integrations-Build Latest Integration QA Prod1
(inaktiv) Prod2
(aktiv) (1) RPM
Patch
Applikation (1) CFEngine Policy CI Server VMs
Services VMs
Services VMs
Services VMs
Services VMs
Services (2) Trigger
Build Paketzusammenstellung +
Konfiguration Policies (3) Reinstall
VMs (4) Konfigurieren
Parameter Konfiguration (änderbare Parameter)
Anwendungen
Infrastruktur (4) Konfigurieren Policies (5) Integration
Test (6) Tag Build Also werden Infrastrukturprojekte jetzt Entwicklungsprojekte - nicht ganz. Der Code ist nahe an der wahren Welt.
Es gibt viele Abhängigkeiten.
Schreib mal schnell einen Stub für einen Netzwerk-Switch - das geht so einfach nicht.
Trotz Virtualisierung bleiben viele gemeinsame Ressourcen - Testen ist schwierig wie bei Code mit vielen Singletons.
Speziell Unit-Tests sind nicht wirklich gelöst. Tests vs. Monitore - Wo ist der Unterschied? nehmen die Welt, wie sie ist,
laufen kontinuierlich,
finden Störungen, obwohl sich "nichts verändert" hat,
sind oft Teil einer gemeinsamen Infrastruktur. Tests: Monitore: stellen einen definierten Zustand her,
sind irgendwann beendet,
suchen nach Fehlern aufgrund von bekannten, gewollten Veränderungen,
laufen in spezieller Test- oder CI-Umgebung. Aber: Beide Verfahren führen Prüfungen/Checks durch und liefern das Ergebnis zurück. Gemeinsamkeiten nutzen, gemeinsame Testfälle nutzen, z.B. Fitnesse-Tests mit Icinga steuern. Netzwerkinstallation mit Cobbler vmdestroy, vmcreate, cobbler reinstall, Applikationen Integration Tests (Fitnesse), CFEngine Smoke Test vmdestroy, vmcreate,
cobbler reinstall,
Infrastructure* ausführen SVN VM Installation abwarten,
Smoke Repository anlegen,
checkout testen Jenkins VM Installation abwarten,
Smoke Job ausführen,
blaue Ampel überprüfen CFE Master VM Installation abwarten,
Policy Verarbeitung auf Fehler überprüfen Applikation bauen, Unittests, Artefakt
in Yum Repository einspielen Artefakt Versionierung und Paket Auswahl Typischer Artefaktname <Name>-<Major>.<Minor>.<Release>
Strategie bei der Artefaktauswahl für Entwicklungsumgebung
immer die höchste Version installieren
aktuell bleiben
Konfigurationsaufwand minimieren
Problem bei Bugfixes
Lösungsidee Feature Toggling
Bugfixes und Features werden gleichzeitig ausgeliefert.
Neue Features sind jedoch über die Umgebungskonfiguration initial deaktiviert. Ressourcen Planung,
Virtualisierung Infrastructure as Code Werkzeuge Continuous Delivery yum/latest yum/int yum/qa packages.csv
CFEngine
masterfiles packages.csv
CFEngine
masterfiles ... ... Patchen schon damals eine Bad Practice Infrastructure as Code Projekt Kunde: Internetdienstleister, IT Abteilung ~100 MA
vorher
Umgebungen unterschiedlich
manuell installiert
Hardware schlecht ausgelastet
lange Deployment Zyklen
Aufgabe
Rechenzentrum von Grund auf neu bauen
Team
2 x TNG, 2 x Sysadmins, Tester, Anwendungsentwickler, Netzwerker
Zeit: 1 Jahr VM Storage Konfiguration Jede VM hat eine System Disk und eine Persistente Disk
System Disk (transiente Daten)
wird beim Build der Stage mit der VM zerstört
enthält Installationsdaten

Persistente Disk
Anwendungsdaten
GUI Anwendungen
schlecht versionierbare Tools
DB
SSH + CFEngine Keys Fazit Akzeptanz der IaC Umgebung Errungenschaften
Automatisierung mit klarem Schichtenmodell
VMs bauen in 5-7 Minuten
großes Vertrauen in Umgebungen
tägliche Deployments in Produktion

Schwierigkeiten
Prozesse kontinuierlich überprüfen und ändern
Herkömmliches CFEngine gibt wenig Struktur vor
Zeit in eigene High Level CFEngine Bibliothek und Dev Umgebung investieren Culture
Automation
Measurement
Sharing Devops is About CAMS John Willis
Damon Edwards Bekannte Features Mehrere OS Installationen passen auf einen Rechner.
Hardware wird teilbar:
Virtualisierung ermöglicht die Betrachtung der Hardware als Pool aus CPU-, Speicher-, Storage- und Netzwerkressourcen.
Virtuelle Maschinen sind baubar, solange die Pools reichen.
Robustheit:
Virtuelle Maschinen migrieren bei Überlast auf andere Rechner.
Bei Ausfällen starten VMs auf anderen Rechnern.
Konfiguration dafür ist leicht einstellbar und änderbar. Virtualisierung erleichtert
Automatisierung Zusätzliche Maschinen lassen sich ohne Hardwarekauf erstellen.
Das VM-Deployment wird programmiert.
Die Virtualisierungsplatform abstrahiert von Spezialhardware, VMs sehen nur einfache "Standard" Hardware. Das Ganze gibt es wirklich RZ Integration und Projekt Integration Software Projekte benötigen eigenen Integrationsbuild
Projekt Integration
baut Applikations RPM
testet neue Features
RZ Integration
testet die in Produktion aktivierten Features App-VMs Infrastruktur-VMs Metadaten Was ist ein Build? ... in einem IaC Projekt? Ein Build ist Sequenz von Schritten, die aus Source Code ein deploybares Artefakt erstellt. Ein Build ist eine Sequenz von Schritten, die für eine bestimmte Paketzusammenstellung und Sammlung von Konfigurationspolicies virtuelle Maschinen baut.

Der CFEngine Masterserver checkt CFEngine Policies in bestimmter Version aus.
Cobbler baut YUM Repos mit bestimmter Paketzusammenstellung.

Ein Skript löst die komplette Neuinstallation für eine Gruppe von VMs aus. ... in einem Software Projekt Hartes Staging Produktionsinstallation ohne Stress
Standardisierte Umgebungen
in Entwicklungsumgebung Flexibilität auf Anforderung
CFEngine Daemon deaktivieren
ggf. zusätzliche YUM Repositories nutzen
Anwendungen müssen Feature Toggling unterstützen
Oberste Priorität, schnelle Pipeline, häufig stabile Integrationsumgebung
möglicher Konflikt
Sicherheitspatches täglich in Produktion bringen
Anwendung oder CFEngine Policy debuggen