Let's talk about Open Source Data Center Management with Foreman, Puppet & docker.io! We invite everyone who's interested to join us at our inovex Meetup in Cologne. This time we will cover the following topics: [01] An introduction to docker.io: Secure and portable containers made easy "Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere." Learn how docker.io can be a huge benefit for you by bringing operations and development closer together. [02] OSS Data Center Management with The Foreman & Puppet. Have you ever wondered why your IT department needs about 5-10 weeks to have a new project infrastructure up and running? We will discuss the reasons and show you how to fix the issue using our Open Source Data Center Management setup.

1. puppet,
the
foreman
and
everything
Opensource
Tools
für
das
Datacenter
Management
Nils
Domrose
Köln,
24.
Juni-­‐2014

2. 2
Aufgabenstellung
im
Datacenter
▸ Konsistente,
nachvollziehbare
Erstellung
von
physikalischen
Servern
und
virtuellen
Instanzen
▸ Flexible
Anbindung
von
„Virtual
Infrastructure“
und
Cloud-­‐
Lösungen
▸ Deployment
von
Cloud-­‐Lösungen
und
„Virtual
Infrastructure“
▸ ConfiguraTon
Management
▸ Patch
Management
▸ ggf.
Mandantenfähigkeit
▸ ApplicaTon
Deployment
▸ Monitoring
und
User
Management
▸ Kurzum:
Infrastructure
as
Code

3. 3
Was
ist
Foreman?
Lifecycle
Management
Tool
für
virtuelle
und
physikalische
Server-­‐
und
Compute-­‐Instanzen
▸ RedHat-­‐Projekt
▸ Image-­‐basierte
Deployments
▸ PXE-­‐
und
ISO*-­‐basierte
Deployments
▸ IntegraTon
und
Provisionierung
von
Basis-­‐Infrastruktur-­‐
Komponenten
wie
TFTP,
DHCP
und
DNS
▸ External
Node
Classifier
(ENC)
für
Puppet
und
andere
cfgmgmt-­‐
Systeme
▸ Dashboard
für
Puppet
und
Chef
▸ IntegraTon
von
Katello
für
Repository
Management
▸ Gute
Erweiterbarkeit
durch
Plugins
(GUI
und
Features)
▸ Autodiscovery
via
Discovery-­‐Plugin
*
verbesserungsfähig
durch
Automa6sierung

4. 4
Foreman
Deployment
Workflow
1 create new host
2 request lease
3 create DNS entries
4 request kernel & initrd
5 provision TFTP & PXE
6 create auto sign entry
7 create compute instance
8 DHCP request
Quelle:
inovex
Smart-
Proxy
DHCP
DNS
Puppet
Master
12 12
TFTP
Puppet
CA
compute
Resource
OS Repo
query unattended Resources
virtual / physical
Instances
9 PXE Boot
unattended
Resources
2
4 3
5
6
7
8
9
request puppet certificate
GET ENC & catalog, upload facts
notify finish
10
11
12
13
10
10
11
13
1
13

5. 5
Was
deckt
Foreman
ab?
ü Konsistente,
nachvollziehbare
Erstellung
von
physikalischen
Servern
und
virtuellen
Instanzen
ü Flexible
Anbindung
von
„Virtual
Infrastructure“
und
Cloud-­‐
Lösungen
ü Deployment
von
Cloud-­‐Lösungen
und
„Virtual
Infrastructure“
ü Patch
Management
via
Katello
oder
standalone
via
Pulp
ü Mandantenfähigkeit
✗ ConfiguraTon
Management
✗ ApplicaTon
Deployment
✗ Monitoring
und
User
Management
✗ Infrastructure
as
Code

6. 6
Mandantenfähigkeit
Quelle:
theforeman.org
/
inovex
GmbH

7. 7
Foreman
Roadmap
▸ Docker.io
Support
▸ Neues
Permission
Management
▸ Service
OS
für
Discovery
Plugin
(Firmware
Updates,
Inventory)
▸ AutomaTsierte,
ISO-­‐Image-­‐basierte
InstallaTon
für
virtuelle
Systeme
milels
API
und
physikalischer
Server
milels
IPMI

8. 8
ConfiguraTon
Management
Puppet
als
Basis
▸ Gitlab
als
Quell-­‐VCS
für
Puppet-­‐Klassen
▸ Foreman
als
ENC
zur
Parametrisierung
von
Puppet
Rollen
▸ Hiera
Daten
Parametrisierung
von
Modulen
▸ Gitlab
Commit
Hooks
zur
Synchronisierung
auf
die
Puppet-­‐Master
inkl.
Syntax-­‐Validierung
via
Jenkins
Job
▸ Milels
Crypt-­‐Modul
können
Strings
im
ENC
oder
Hiera
verschlüsselt
abgelegt
werden.
Die
Entschlüsselung
erfolgt
zentral
durch
den
Puppetmaster.

9. 9
ApplicaTon
Deployment
!=
ConfiguraTon
Management
▸ Das
ConfiguraTon
Management
beschreibt
die
Laufzeit-­‐Umgebung
einer
ApplikaTon
auf
Basis
von
Host-­‐spezifischen
InformaTonen
(z.B.
puppet
facts).
▸ Das
Deployment-­‐Tool
provisioniert
die
Laufzeitumgebung
mit
den
ApplikaTonen.
▸ Wir
nutzen
(R)?ex
(www.rexify.org)
und
Jenkins.
AlternaTven:
mcollecTve,
rundeck,
saltstack
▸ Das
Lifecycle
Management
(Foreman)
dient
als
CMDB.
(Welche
Systeme
gibt
es,
wie
sind
diese
parametrisiert?)
▸ Das
Deployment-­‐Tool
fragt
die
InformaTonen
ab
und
deployed
auf
Basis
der
InformaTonen
die
ApplikaTon
in
der
Laufzeitumgebung.

10. puppetlabs.com
10
Puppet
‣ entwickelt
Luke
Kanies
‣ in
ruby
geschrieben
‣ maintained
by
puppetlabs
‣ Seit
Version
2.7.0
unter
Apache
2.0
Lizenz
‣ enterprise
version
verfügbar
“Puppet
Open
Source
is
a
flexible,
customizable
framework
available
under
the
Apache
2.0
license
designed
to
help
system
administrators
automate
the
many
repe66ve
tasks
they
regularly
perform.
As
a
declara6ve,
model-­‐based
approach
to
IT
automa6on,
it
lets
you
define
the
desired
state
-­‐
or
the
“what”
-­‐
of
your
infrastructure
using
the
Puppet
configura6on
language.”*

11. 11
Warum
Puppet
‣ Viele
User
‣ Viele
Module
‣ Skaliert
gut
‣ Wir
haben
viel
Erfahrung
gesammelt
‣ …
‣ Manchmal
Komplex
‣ Steile
Lernkurve
‣ Teilweise
inkonsistent
‣ …
Pros:
Cons:
…es
gibt
Alterna?ven:
Saltstack,
Ansible,
Chef,
Cfengine…
Letzten
Endes
ist
es
eine
Frage
des
verfügbaren
Know-­‐Hows.

12. 12
Puppet
Architektur
‣ Lokal
oder
Master-­‐Agent
Setup,
Agent
fragt
sporadisch
beim
Master
an.
‣ Eine
Puppet
CA
‣ Master
erzeugt
eine
Agent-­‐spezifischen
Ausführungsplan
(catalog),
Agent
wendet
den
catalog
an.
‣ OpTonal
mehrere
Masters
(Skalierbarkeit)
‣ OpTonal
PuppetDB
zum
Austausch
von
Daten
wie
Reports
und
exported
resources
Puppet
DB
Puppet
Master
Puppet
CA
Puppet
Agent
kick

13. Puppet
Module
Basics
‣ Puppet
DSL
‣ OpTonal
Dateien
und
Templates
‣ OpTonal
Facts
‣ OpTonal
Tests
13

14. Puppet
Module
Basics
class openssh {
package { 'openssh-server':
ensure => installed,
before => File['/etc/ssh/sshd_config'],
}
file { '/etc/ssh/sshd_config':
ensure => file,
owner => 'root',
group => 'root',
mode => '0600',
source => “puppet:///modules/openssh/${::operatingsystem}/
sshd_config“,
}
service { 'ssh':
ensure => running,
enable => true,
subscribe => File['/etc/ssh/sshd_config'],
}
}
14

15. 15
Puppet
Module
Types
Puppet Module Design
Roles - Business Logic (optional)
1 1 Node / ENC
Hiera
optional params.pp
Profiles - Technology Abstraction (optional)
environment specific data
1..n
Component Modules - Resource Modelling params.pp
os and module specific data
1
1..n
1
1..n
1
1..n
R R R R
R R R
1 1
node to role classification
Create
roles
from
profiles
Create
service
specific
profiles
from
component
modules
+
config
These
are
puppet
forge
modules

16. 16
Puppet
Profiles
class profile_one {
class {'one':
oned => true
sunstone => true
}
}

17. 17
Puppet
Roles
class role_one_node {
class {‘profile_base‘:} ->
class {‘profile_ceph ‘:} ->
class {‘profile_one ‘:}
}

18. 18
Puppet
and
Version
Control
Module
Repository
Puppet Master
Module
Repository
Puppet Master
Jenkins
Job
(R)ex? task
Puppet Master Server Puppet Master Server
commit hook
(R)ex? task

19. 19
Deployment
&
Lifecycle
Management
Virtual Network
Physical Network
Hosted Virtual Real
Foreman REST API
CMDB
Deployment Lifecycle Mgmt.

20. 20
Was
decken
Foreman,
Puppet,
Rex
&
Jenkins
ab?
ü Konsistente,
nachvollziehbare
Erstellung
von
virtuellen
Instanzen
ü Flexible
Anbindung
von
„Virtual
Infrastructure“
und
Cloud-­‐
Lösungen
ü Deployment
von
Cloud-­‐Lösungen
und
„Virtual
Infrastructure“
ü Patch
Management
via
Katello
oder
standalone
via
Pulp
ü Mandantenfähigkeit
ü ConfiguraTon
Management
ü ApplicaTon
Deployment
✗ Monitoring
und
User
Management
✗ Infrastructure
as
Code

21. 21
Monitoring
mit
puppet
und
check_mk
1 puppet agent deploys check_mk agent and checks
2 master stores exported resources in puppetDB
3 puppet agent on OMD server collects check_mk resources
4 host.mk is regenerated and inventory is triggered
5 inventory and agent checks of all deployed service checks
Mathias-­‐kelner.de
/
inovex
checks
checks
Puppet Agent
inventory and check agent
Puppet DB
Puppet Master Server Server or Instance
Puppet Agent
hosts.mk
Puppet Master
check_mk Agent
check_mk OMD Server
2 1
3
4
5

22. 22
Usermanagement
▸ SSSD
mit
Anbindung
an
LDAP
▸ Dedizierter
LDAP
wird
vom
Konzern
IdenTty
Management
System
befüllt
▸ Rechte
auf
Systemen
auf
Basis
von
Gruppenzugehörigkeiten
▸ SSH
Schlüssel
im
LDAP,
Host-­‐Keys
via
puppet
exported
resources
▸ Anbindung
aller
Subsysteme
und
Frontends
an
das
AD
oder
den
LDAP
(GitLab,
Foreman,
usw.)

23. 23
Infrastructure
as
Code

24. 24
Vielen
Dank
für
Ihre
Aufmerksamkeit
Kontakt
Nils
Domrose
Senior
Systems
Engineer
inovex
GmbH
Office
cologne
Schanzenstr.
6-­‐20
51063
Köln
nils.domrose@inovex.de