Vortrag auf den Kieler Linuxtagen 2013

1. Infrastruktur als Code

2. Wer bin ich?
● Jan Gehring
● System Architekt
● Bei inovex seit 2008

3. Um was geht’s?
● Von der Turnschuh-Administration
● Zur automatisierten Umgebung

4. Turnschuh-Administration
● Der unglückliche Umstand, sämtliche Rechner
im Netzwerk zu Fuß abklappern zu müssen,
um vor Ort administrative Tätigkeiten
durchzuführen.
http://www.wikiservice.at

5. Turnschuh-Administration
● Funktioniert bei wenigen Servern
● Kann funktionieren wenn jeder Server
unterschiedlich ist
● Skaliert nur durch mehr Mitarbeiter

6. Turnschuh-Administration
Oft gehört...

7. ● Wirklich?
● Was ist mit
– ntp
– Benutzer und Gruppen
– ssh
– logrotate
– resolv.conf
– profile
– Apache Security Einstellungen
– ...
Jeder Server ist unterschiedlich

8. ● Wieviele Server kann eine Person
administrieren?
– 10
– 25
– 50
● Krankheit oder Urlaub?
Skaliert?

9. ● Der Tag hat 24 Stunden
● Naja, eigentlich nur 8 …
Zeit ist knapp

10. ● Mails lesen und beantworten
Zeit ist knapp

11. ● Mails lesen und beantworten (1-2h)
● Mailinglisten verfolgen (Security, ...)
Zeit ist knapp

12. Sicherheitsproblem im Apache...
auch bei uns.
Infrastruktur als Code

13. Muss heute mittag gepatched
werden!
Infrastruktur als Code

14. ● Mails lesen und beantworten (1-2h)
● Mailinglisten verfolgen (1h)
● Updates aus der IT Welt (heise, golem, ...)
Zeit ist knapp

15. ● Mails lesen und beantworten (1-2h)
● Mailinglisten verfolgen (1h)
● Updates aus der IT Welt (1h)
Zeit ist knapp

16. Vormittag ist rum
Zeit ist knapp

17. Bleiben noch 4 Stunden
Zeit ist knapp

18. Ein Kollege von der Entwicklung
schaut rein, hat ein Problem...
Zeit ist knapp

19. 3 Stunden
Zeit ist knapp

20. Neue Softwarerelease soll deployed
werden...
Zeit ist knapp

21. Funktioniert nicht!
Zeit ist knapp

22. Hotfix 1...
Zeit ist knapp

23. Hotfix 2...
Zeit ist knapp

24. -2 Stunden
Zeit ist knapp

25. Feierabend!
Zeit ist knapp

26. Security Update kommt morgen...
Zeit ist knapp

27. .oO( Vielleicht )
Zeit ist knapp

28. Kommt das bekannt vor?
Infrastruktur als Code

29. Wenn ja, dann seid ihr hier richtig!
Infrastruktur als Code

30. Was braucht man um zu
Automatisieren?
Infrastruktur als Code

31. Tools!
Infrastruktur als Code

32. Infrastruktur als Code
http://www.immobilienwirtschaft360.de/

33. Continuous Integration Tool
Infrastruktur als Code

34. Infrastruktur als Code
http://jenkins-ci.org/
http://travisci.com/
Bild von: https://www.openshift.com

35. Configuration/Deployment
Management Tool
Infrastruktur als Code

36. Infrastruktur als Code
http://www.opscode.com/
Bild von: http://developer.rackspace.com/

37. Source Control Management
Infrastruktur als Code

38. Infrastruktur als Code
http://git-scm.com/
http://mercurial.selenic.com/
http://subversion.tigris.org/

39. Infrastruktur als Code

40. Was bedeutet das?
Infrastruktur als Code

41. ● Das Wissen über die Infrastruktur ist nicht in
eurem Kopf sondern in einem Script.
● Wenn ihr mal krank seid kann ein Kollege
kucken wie es funktioniert und muss nicht
stören.
● Das gilt auch für den Urlaub.
● Oder wenn ihr mal die Firma gewechselt habt.
Was bedeutet das?

42. Außerdem macht es sich gut bei
einem Bewerbungsgespräch...

43. Inovex sucht übrigens Linux System
Engineers!

44. ● Wenn es nur von einem verwendet /
upgedatet wird?
● Wenn es nur auf einer Plattform läuft?
Was bringt uns ein Script?

45. ● Dezentrale Versionsverwaltung
● Funktioniert auch offline
● Schöne Oberflächen
Git – und jeder macht mit

46. Git – und jeder macht mit
http://gitlab.org/

47. ● Dezentrale Versionsverwaltung
● Funktioniert auch offline
● Schöne Oberflächen
● Scripte sind versioniert
● Vielleicht machen auch die Entwickler mit
● Man lernt dazu
Git – und jeder macht mit

48. ● Unterschiedliche Entwicklungszweige
● Für Testsysteme ein Entwicklungszweig
(branch)
● Für Livesysteme ein „Production“ Branch
Git – und jeder macht mit

49. Git – und jeder macht mit
http://erickryski.com/

50. ● Standard Aufgaben kann man hier hinterlegen
– Testen des Development Branchs
– Automatische Prüfung von Backup/Restore
– Deployment von neuen Software-Releases
– Erstellen von Test-VMs
– …
● Gibt auch eine Android / iPhone App
Jenkins – Ein-Klick Administration

51. Jenkins – Ein-Klick Administration

52. http://devcentral.f5.com/

53. ● Keine selbst geschriebenen Scripte
– Auf die Arbeit von anderen aufbauen
● Ganz einfaches Perl
– Kennt eigentlich jeder
– Lesbar
● Benötigt (fast) nichts auf dem Zielsystem
● Kein Agent nötig
● Verwendet SSH
● Logik läuft auf dem lokalen Rechner
Rex – Remote Execution

54. ● Wird entwickelt seid 2010
● Genau für dieses Einsatzgebiet
● Bruch der Kompatibilität = Bug
● Aktive Community
● Professioneller Support verfügbar
Rex – Remote Execution

55. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● Begrifflichkeiten
● Rex Interna
● Aus der Praxis
● Installation
● 1. Schritte
● ...
Infrastruktur als Code

56. Begrifflichkeiten
Was ist was?
Infrastruktur als Code

57. WKS
Rex
Workstation

58. WKS
Rex
SSH
Workstation

59. SRV02SRV01 SRV03 SRV04 SRV05 SRV06
WKS
Rex
SSH
Workstation & Server

60. Gruppen

61. LB01 LB02
FE01 FE03FE02
MW01 MW02
DBS01 DBS02
DBM01
Gruppen

62. DB Write
DB Read
Middleware
Frontend
Loadbalancer LB01 LB02
FE01 FE03FE02
MW01 MW02
DBS01 DBS02
DBM01
Funktions-Gruppen

63. group “ourgroup“ => “server1“, “server2“, “server3“;
Funktions-Gruppen

64. group “ourgroup“ => “server1“, “server2“, “server3“;
Funktions-Gruppen

65. group “ourgroup“ => “server1“, “server2“, “server3“;
Funktions-Gruppen

66. group “ourgroup“ => “server[1..3]“;
Funktions-Gruppen

67. group “ourgroup“ => “server[01..03]“;
Funktions-Gruppen

68. group “ourgroup“ => get_servers_from_db();
Funktions-Gruppen

69. Environments

70. LIVE STAGE TEST
Loadbalancer
Frontend
Middleware
DB Read
DB Write
LB01 LB02
FE01 FE03FE02
MW01 MW02
DBS01 DBS02
DBM01
LB01
FE01
MW01
DBS01
DBM01
FE01
MW01
DBM01

71. environment “live“ => sub {
group “frontend“ => “fe01[01..03].live“;
};
environment “stage“ => sub {
group “frontend“ => “fe01.stage“;
};
environment “test“ => sub {
group “frontend“ => “fe01.test“;
};
Environments

72. environment “live“ => sub {
group “frontend“ => “fe01[01..03].live“;
};
environment “stage“ => sub {
group “frontend“ => “fe01.stage“;
};
environment “test“ => sub {
group “frontend“ => “fe01.test“;
};
Environments

73. environment “live“ => sub {
group “frontend“ => “fe01[01..03].live“;
};
environment “stage“ => sub {
group “frontend“ => “fe01.stage“;
};
environment “test“ => sub {
group “frontend“ => “fe01.test“;
};
Environments

74. Tasks

75. task “mytask“, group => “ourgroup“, make {
};
Tasks

76. task “mytask“, group => “ourgroup“, make {
};
Tasks

77. task “mytask“, group => “ourgroup“, make {
};
Tasks

78. task “mytask“, group => “ourgroup“, make {
};
Tasks

79. task “mytask“, group => “ourgroup“, make {
};
Tasks

80. task “mytask“, group => “ourgroup“, make {
};
Tasks

81. task “mytask“, group => “ourgroup“, make {
run “unzip -q /tmp/my.zip“;
};
Tasks

82. task “mytask“, group => “ourgroup“, make {
run “unzip -q /tmp/my.zip“;
};
Tasks

83. task “mytask“, group => “ourgroup“, make {
run “unzip -q /tmp/my.zip“;
};
Tasks

84. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● Begrifflichkeiten
● Rex Interna
● Aus der Praxis
● Installation
● 1. Schritte
● ...

85. Aufteilung in Module und Services

86. ● Unabhängig
● Wiederverwendbar
● Für einen Einsatzzweck gemacht
Module sind

87. ... ein spezieller Dienst
Services sind ...

88. z.b.: der Intranet-Server
Services sind ...

89. oder: der Proxy-Server
Services sind ...

90. oder: das Frontend
Services sind ...

91. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● Begrifflichkeiten
● Rex Interna
● Aus der Praxis
● Installation
● 1. Schritte
● ...

92. Installation

93. echo 'deb http://rex.linux-files.org/ubuntu/ precise rex' >>
/etc/apt/sources.list
wget -O -
http://rex.linux-files.org/DPKG-GPG-KEY-REXIFY-REPO
| apt-key add -
apt-get update
apt-get install rex
Installation / Ubuntu

94. Installation / CentOS
rpm –import
http://rex.linux-files.org/RPM-GPG-KEY-REXIFY-REPO.CENTOS6
cat >/etc/yum.repos.d/rex.repo <<EOF
[rex]
name=Fedora $releasever - $basearch - Rex Repository
baseurl=http://rex.linux-files.org/CentOS/$releasever/rex/
$basearch/
enabled=1
EOF
yum install rex

95. Installation / Windows
● Strawberry-Perl (http://strawberryperl.com/)
● cmd> cpanm Rex

96. curl -L get.rexify.org
| perl - --sudo -n Rex
Installation / Source

97. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● Installation
● 1. Schritte
● Templates
● 1. Modul
● Verzeichnisstruktur
● Das Modul
● Ein Service

98. Ausgangspunkt: das Rexfile

99. user “root“;
password “box“;
Das Rexfile

100. user “root“;
password “box“;
pass_auth;
Das Rexfile

101. user “root“;
password “box“;
private_key “/home/jan/.ssh/id_rsa_root“;
public_key “/home/jan/.ssh/id_rsa_root.pub“;
key_auth;
Das Rexfile

102. user “root“;
password “box“;
group “frontend“ => “fe[01..03]";
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
};
Das Rexfile

103. bash# rex install_ntpd

104. group “frontend“ => “fe[01..03]";
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
source => “files/etc/ntp.conf“,
owner => “root“,
group => “root“,
mode => 644;
};
Das Rexfile

105. bash# rex install_ntpd
Das Rexfile

106. group “frontend“ => “fe[01..03]";
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
source => “files/etc/ntp.conf“,
owner => “root“,
group => “root“,
mode => 644;
service ntpd => ensure => “started“;
};
Das Rexfile

107. bash# rex install_ntpd

108. group “frontend“ => “fe[01..03]";
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
source => “files/etc/ntp.conf“,
owner => “root“,
group => “root“,
mode => 644,
on_change => make { service ntpd => “restart“ };
service ntpd => ensure => “started“;
};
Das Rexfile

109. bash# rex install_ntpd

110. ● Benutzer & Gruppen
● Cron
● Filesystem Funktionen
– mkdir, rmdir, ls, ln, rm, chown, chgrp, chmod
– is_file, is_dir, mv, cp, mount, umount, ...
● LVM
● Kernel
● Process-Management
● Virtualization (KVM, Xen)
● Cloud (Amazon, Jiffybox, OpenNebula, ...)
Mehr Funktionen

111. http://rexify.org/api/
Mehr Funktionen

112. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● Installation
● 1. Schritte
● Templates
● 1. Modul
● Verzeichnisstruktur
● Das Modul
● Ein Service

113. Templates

114. group “frontend“ => “fe[01..03]";
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
source => “files/etc/ntp.conf“,
owner => “root“,
group => “root“,
mode => 644,
on_change => make { service ntpd => “restart“ };
service ntpd => ensure => “started“;
};
Templates

115. driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server ntp01.intern.lan
server ntp02.intern.lan
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
Templates

116. driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
<% for my $server (@{ $servers }) { %>
server <%= $server %>
<% } %>
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
Templates

117. group “frontend“ => “fe[01..03]";
my $servers = [“ntp01.company.lan“, “ntp02.company.lan“];
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
content => template(“files/etc/ntp.conf.tpl“,
servers => $servers),
owner => “root“,
group => “root“,
mode => 644,
on_change => make { service ntpd => “restart“ };
service ntpd => ensure => “started“;
};
Templates

118. Templates
● $eth0_ip
● $eth0_netmask
● $hostname
● $domain
● $architecture
● $kernel
● ...

119. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● 1. Schritte
● Templates
● 1. Modul
● Verzeichnisstruktur
● Das Modul
● Ein Service

120. Module

121. bash# rexify NTP --create-module

122. ├── lib
│ └── NTP
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Verzeichnisstruktur

123. bash# rexify Common::NTP
--create-module

124. ├── lib
│ └── Common
│ └── NTP
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Verzeichnisstruktur

125. ├── lib
│ └── Common
│ └── NTP
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Verzeichnisstruktur

126. > cat lib/NTP/meta.yml
Name: NTP
Description: {{ DESCRIPTION }}
Author: {{ your name <your.name@email.com> }}
License: {{ THE LICENSE }}
# If you have dependencies to other Rex Modules.
Require:
- Other::Rex::Module
- 2nd::Rex::Module
Verzeichnisstruktur

127. Bis hier hin Fragen?
Weiter geht’s mit: Rex
● 1. Schritte
● Templates
● 1. Modul
● Verzeichnisstruktur
● Das Modul
● Ein Service

128. group “frontend“ => “fe[01..03]";
my $servers = [“ntp01.company.lan“, “ntp02.company.lan“];
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
content => template(“files/etc/ntp.conf.tpl“,
servers => $servers),
owner => “root“,
group => “root“,
mode => 644,
on_change => make { service ntpd => “restart“ };
service ntpd => ensure => “started“;
};
Das Modul

129. group “frontend“ => “fe[01..03]";
my $servers = [“ntp01.company.lan“, “ntp02.company.lan“];
task “install_ntpd“, group => “frontend“, make {
install “ntpd“;
file “/etc/ntp.conf“,
content => template(“files/etc/ntp.conf.tpl“,
servers => $servers),
owner => “root“,
group => “root“,
mode => 644,
on_change => make { service ntpd => “restart“ };
service ntpd => ensure => “started“;
};
Das Modul

130. package Common::NTP;
use Rex -base;
task example => sub {
my $output = run "uptime";
say $output;
};
1;
Das Modul

131. package Common::NTP;
use Rex -base;
task “setup“ => make {
my $params = shift;
install “ntpd“;
file “/etc/ntp.conf“,
content => template(“files/etc/ntp.conf.tpl“, %{ $params }),
owner => “root“,
group => “root“,
mode => 644,
on_change => make { service ntpd => “restart“ };
service ntpd => ensure => “started“;
};
1;
Das Modul

132. ├── lib
│ └── NTP
│ ├── files
│ │ └── etc
│ │ └── ntp.conf.tpl
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Das Modul

133. ├── files
│ └── etc
│ └── ntp.conf.tpl
├── lib
│ └── NTP
│ ├── files
│ │ └── etc
│ │ └── ntp.conf.tpl
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Das Modul

134. ├── files
│ └── etc
│ └── ntp.conf.tpl
├── lib
│ └── NTP
│ ├── files
│ │ └── etc
│ │ └── ntp.conf.tpl
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Das Modul

135. ├── files
│ └── etc
│ └── ntp.conf.tpl
├── lib
│ └── NTP
│ ├── files
│ │ └── etc
│ │ └── ntp.conf.tpl
│ ├── meta.yml
│ └── __module__.pm
└── Rexfile
Das Modul

136. include “NTP“;
group “frontend“ => “fe[01..03]";
my $servers = [“ntp01.company.lan“, “ntp02.company.lan“];
task “prepare“, group => “frontend“, make {
NTP::setup(servers => $servers);
};
Das Modul / der Service

137. include “NTP“;
group “frontend“ => “fe[01..03]";
my $servers = [“ntp01.company.lan“, “ntp02.company.lan“];
task “prepare“, group => “frontend“, make {
NTP::setup(servers => $servers);
};
Das Modul / der Service

138. Vielen Dank für Eure Aufmerksamkeit!
Kontakt
Jan Gehring
Systems Architecture
inovex GmbH
Office Pforzheim
Karlsruhe Straße 71
75179 Pforzheim
+49 (0)173 3181 133
jan.gehring@inovex.de

139. Fragen?
http://rexify.org/
irc: freenode / #rex