Automatisierte Linux installation 0603_version2012_inoxt_rz

Hinter der Maske das gewünschte Bildmotiv platzieren

Automatisierte Installation
OSS im Enterprise Umfeld
06.03.2012
16.00 – 17.00 Uhr

Projekt: Webinar-Reihe der inoXtech University
Referent: Florian Rosenegger | Systems Engineer | inoX-tech
Datum: 22.03.12
Seite: 1

Inhaltsverzeichnis

1.Vier gute Gründe
2.Ihr Wissensvorsprung für morgen

3.Webinar „Automatisierte Installation“ / 06.03.2012
Zielsetzung
Cobbler: Grundlagen. Wissenswertes. Praxisbeispiele.
Puppet: Grundlagen. Wissenswertes. Praxisbeispiele.
FUNC: Zentrales Daten-Management
4.Zusammenfassung

5.Kontakt

Datum: 22.03.12
Seite: 2

Vier gute Gründe


In der Webinar-Reihe der inoXtech University erfahren Sie:
 Lebendiger Austausch von Wissen in der IT Community
 Trends im Bereich Open Source, Virtualisierung und Cloud erkennen und
weiterentwickeln
 Seien Sie vorne mit dabei wenn Innovationen geschaffen werden!
 Treffen Sie unsere Fachleute auch persönlich auf Get-Together-
Veranstaltungen zu angeregten Fachgesprächen


Die Idee hinter den inoXtech-Webinaren: Wir möchten Sie schon heute fit machen
für die Technologien, die in naher Zukunft Arbeitsprozesse maßgeblich bestimmen
werden. Nutzen Sie unser Webinar-Angebot.

Datum: 22.03.12
Seite: 3

Ihr Wissensvorsprung für morgen


Die inoXtech University möchte einen fruchtbaren Dialog für den aktiven,
branchenübergreifenden Wissenstransfer in einer lebendigen IT-Community
fördern. Regelmäßige Veranstaltungen, Webinare und unser Videoportal bieten
Fachleuten und Neulingen gleichermaßen die Möglichkeit, ausgewiesenen
Experten auf Augenhöhe zu begegnen und erfolgversprechende IT-Modelle für
morgen zu diskutieren.


So profitieren Sie von einem Wissensvorsprung, mit dem Sie heute schon
Lösungen mit konkreten wirtschaftlichen und technologischen Vorteilen
realisieren und vorstellen.


Vielen Dank für Ihre Teilnahme.

Ihr Michael Döderlein

Datum: 22.03.12
Seite: 4

Zielsetzung


Recovery. Synchronisierung. Support.

Datum: 22.03.12
Seite: 5

Zielsetzung

 Installation eines Systems ohne Eingriff des Benutzers
 Recovery des OS im Notfall
- mit einem Mindestmaß an Aufwand
- bis zum Anstarten des Backups der fehlenden Benutzerdaten

 Gemeinsame Datenbasis zwischen Installation (Build Up) und täglicher
Konfiguration (Run)
 Support unterschiedlichster Betriebssysteme

Datum: 22.03.12
Seite: 6

Cobbler


Grundlagen. Wissenswertes. Praxisbeispiele.

Datum: 22.03.12
Seite: 7

Cobbler – Definition

 Open Source – Python – Software
 Installations und Provisionierungsserver
 Beinhaltet:
- DHCP/TFTP – Server für PXE-Boot
- Erstellung von CD-Images für CD-Boot
- Repository-Management aller benötigten Paketquellen
- Webserver zur Auslieferung der Installationsquellen
- Zentrale Verwaltung für Systeme samt Mac-Adressen, IP,...
- Web-GUI
- Kommandozeile
- Offene Schnittstelle zur Administration

Datum: 22.03.12
Seite: 8

Cobbler – Grundlagen

 Cobbler unterstützt:
- Red Hat basiertes Linux
- Suse Linux
- Debian
- Auslieferung von Images (notfalls in Zukunft sogar Windows?)
- Kickstart Automatismen sowohl von Red Hat als auch AutoYast von SuSE
- Virtuelle Umgebungen wie KVM und XEN
- VMware in Arbeit bzw. noch mit Aufwand

Datum: 22.03.12
Seite: 9

Cobbler – Funktionsweise I

Verwaltungshierarchie:
 Repositories – beinhalten die Pakete/Installationsquellen – je Derivat min. eine
Quelle
 Distributionen – Enthält Informationen über die Art des OS, die zu
verwendenden Paketquellen, sowie Boot-Informationen des Setups
 Profile – Definiert Gemeinsamkeiten von Systemen entweder direkt oder über
Snippets
 Systeme – Beinhaltet die Grundinformationen über die zu installierenden
Systeme
(MAC, IP, Gateway,...)
 Snippets – Benutzerspezifische Anpassung via Cheetah bzw. jeder beliebigen
Sprache

Datum: 22.03.12
Seite: 10

Cobbler – GUI

Datum: 22.03.12
Seite: 11

Cobbler – Funktionsweise II

 Konfiguration einer Distribution in Cobbler mit entsprechendem
Repository (z.b.: RHEL 5.7)
 Erstellen eines Profils auf Basis dieser Distribution
- Auswahl des entsprechenden Kickstarts
» Zu installierende Pakete
» Festplatten-Layout
» Evtl. Registrierung bei einem Satellite
- Über das Kickstart können noch zusätzlich weitere Snippets eingebunden
werden

Datum: 22.03.12
Seite: 12

Cobbler – Funktionsweise III

Konfiguration eines Systems – z.B.: Webserver01
Beinhaltet Zuordnung zu:
- Mac – Adresse(n)
- IP – Adresse(n)
- Spezielles Festplatten-Layout

Snippets könnten z.B.: folgende Dinge während der Installation erledigen:
- Installation der Backup-Software
- Installation des Monitorings
- Automatisierte E-Mail als Fertig-Meldung
- Erst-Konfiguration von Puppet
- Anbindung an LDAP / Anlegen von Admin-Benutzern

Datum: 22.03.12
Seite: 13

Cobbler – Funktionsweise III


Installationsablauf:
Boot des Servers über Netz (DHCP/TFTP) oder über die erstellte Boot-CD
Auswahl des korrekten Systems im Boot-Menü (auf Grub Basis)
Start der entsprechenden automatisierten Installation
Warten / Kaffee-Trinken 
Server neustarten (wird automatisch durchgeführt)
Einloggen und Server verwenden!

Datum: 22.03.12
Seite: 14

Puppet


Grundlagen. Wissenswertes. Praxisbeispiele.

Datum: 22.03.12
Seite: 15

Puppet – Grundlagen

 OSS Software basierend auf Ruby
 Eigene für Puppet entwickelte deklarative Sprache zur Konfiguration
 Modellbasierend
 Komplett verschlüsselte Kommunikation und Authentifzierung mittels PKI
 Unterstützt nahezu alle gängigen Betriebssysteme inkl. Linux und Solaris

Datum: 22.03.12
Seite: 16

Puppet – Probleme

 Virtualisierung und die Cloud erhöhen den "Wildwuchs" sowie die Anzahl
neuer Server
 Die Dokumentation ist meist 2 oder 3 Schritte zurück und generell ab der
Installation veraltet
 Die Konfiguration ist zumeist auf allen Servern unterschiedlich
- Es gibt meist soviele Konfigurationen wie es Administratoren gibt

 Bei Konfigurationsupdates werden immer Server vergessen

Datum: 22.03.12
Seite: 17

Puppet – Lösung

 Zentrales Konfigurationsmanagement
 Aus der zentral gespeicherten Konfiguration stets aktuelle Dokumentation
- Puppetdoc erstellt eine komplette Doku-Seite für alle bekannten Nodes/Server

 Vereinheitlichte Konfiguration auf allen Servern
 Erweiterung oder Veränderung grundlegender Konfigurationen mit wenigen
Zeilen Code möglich => Refactoring

Datum: 22.03.12
Seite: 18

Puppet – Funktionsweise I

 Die Puppetinfrastruktur besteht im Wesentlichen aus dem Puppetmaster, sowie
den Nodes
 Der Puppetmaster ist der Kopf der PKI
 Die Nodes registrieren sich am PM
 Nodes erhalten ein Zertifikat vom PM und liefern grundlegende Informationen
- Die Informationen werden via Facter gesammelt. Facter selbst basiert auf Ruby
und liefert standardisiert Informationen vom Hostnamen bis zum Mainboard-
Hersteller
 Der PM verwendet diese "Facts" um eine spezielle Konfiguration für diesen
Server abzuleiten
 Node meldet zurück ob und wie die Konfiguration umgesetzt wurde
- Als gute Übersicht bietet sich hier zum Beispiel das Puppet Dashboard
- Eine weitere Alternative ist die Verwendung von Foreman => Zukunftsausblick

Datum: 22.03.12
Seite: 19

Puppet – Im Detail

 Modell und "Fakten" – basierend
 Definiert werden nicht Konfigurationsdateien / -zeilen sondern die Zielvorgabe
 Beispiel:
_ Server A soll folgendes beinhalten:
» Webserver mit Standard-Konfiguration1
» 2 NFS-Shares
» Firewall mit nur 2 offenen Ports
» Benutzergruppe WebAdmins1 hat Zugang zur Konfiguration

Datum: 22.03.12
Seite: 20

Puppet – Im Detail II

 Die Sprache Puppet ist angelehnt an Ruby sowie objektorientierte
Programmierung:

service { "funcd":
provider => "redhat",
enable => true,
ensure => running,
require => Package["funcd"],
}
 Was Puppet daraus macht:
- Stelle sicher dass das RPM „funcd“ installiert ist – bei Bedarf installiere über yum
- Füge den Dienst in den entsprechenden RunLevel hinzu und stelle sicher dass er
beim Boot gestartet wird
 Entsprechend „einfach“ zu erlernen / zu lesen

Datum: 22.03.12
Seite: 21

Puppet – Im Detail III

 Interaktion mit Cobbler möglich
 Server werden in Cobbler mit Tags versehen
- Funktioniert auf Profil oder auch auf System-Ebene

 Puppet erkennt anhand der Tags die Server-Eigenschaften und konfiguriert
diesen entsprechend
 Konfiguration => Dokumentation

Datum: 22.03.12
Seite: 22

FUNC


Zentrale Steuerung

Datum: 22.03.12
Seite: 23

FUNC – Grundlagen

 Fedora Unified Network Controller
 OSS Software basierend auf Python
 Gleiche PKI wie für Puppet
 Zentrales Ausführen von Kommandos auf einer
Teilmenge oder auch allen bekannten Servern

Datum: 22.03.12
Seite: 24

FUNC – Probleme

 Viele Server sind zu betreuen
 z.B.: For-Schleifen um Routinetasks auf allen durchzuführen
 SSH samt gepflegten authorized Keys oder expect-Hacks erforderlich

Datum: 22.03.12
Seite: 25

FUNC – Lösung

 XMLRPC mit SSL Verschlüsselung
 Einfache Syntax sowohl in der Bash als auch über die Python API
 Dank API erweiterbar – bereits viele Module verfügbar
 Beispiele:

func “*“ –list-minions

func “*.webservers.example.com“ service restart httpd

Datum: 22.03.12
Seite: 26

FUNC – Erweiterbarkeit

 FUNC als Hilfestellung für Helpdesk
 Graphisches Interface mittels opensymbolic
 Einfache Basistasks automatisiert per Klick auf bestimmten Servern ausführen
 Die Möglichkeiten der Erweiterbarkeit und Anpassbarkeit sind dank API nahezu
endlos

Datum: 22.03.12
Seite: 27

Zusammenfassung


Cobbler. Puppet. FUNC.

Datum: 22.03.12
Seite: 28

Zusammenfassung

 Verwaltung von vielen Servern kann vereinfacht werden:
- Zentrale konsistente Installation dank Cobbler
- Zentrale Konfiguration und Dokumentation mittels Puppet
- Zentrales Ausführen von Kommandos (Updates, Wartung) mittels FUNC

 Alle hier vorgestellten Lösungen können untereinander kombiniert werden

 Vielen Dank für Ihre Aufmerksamkeit

Datum: 22.03.12
Seite: 29

Zukunftsausblick


Katello. Foreman. Pulp. Candlepin

Datum: 22.03.12
Seite: 30

Zukunftsausblick

 Katello (www.katello.org)
_ Initiiert und betreut unter anderem von Red Hat
- Soll eine Verwaltung der Umgebungen sowie Unterstützung zum Staging zur Verfügung
stellen (Dev => Test => Prod)
- Bringt sowohl gemeinsame GUI als auch CLI mit für
» Foreman – Provisions und Konfigurations-Verwaltung
» Pulp – Repository-Verwaltung
» Candlepin – Subscription-Management

Datum: 22.03.12
Seite: 31

Zukunftsausblick II

 Foreman
- Setzt auf Puppet und Cobbler auf und führt diese zusammen
- Funktioniert über den kompletten Lebenszyklus einer Maschine (Installation, Erst-
Konfiguration, Dokumentation, Betrieb...)
- Enthält „Smart-Proxy“ für DNS, DHCP, TFTP und Puppet um auch in verteilten
Netzwerken funktionieren zu können
- Ermöglicht die automatisierte Wiederherstellung eines Servers aus dem Nichts in
kürzester Zeit

Datum: 22.03.12
Seite: 32

inoX-tech GmbH / Gutenbergstr. 8
94036 Passau / Deutschland
Mail: event@inox-tech.de
Fon: +49 (0)851 / 98 77 97 50
Fax: +49 (0)851 / 98 77 97 99

www.xing.de/inoxtech
www.plus.google.com/inoxtech
www.facebook.com/inoxtech
www.twitter.com/inoxtech www.inox-tech.de

Automatisierte Linux installation 0603_version2012_inoxt_rz

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (16)

Semelhante a Automatisierte Linux installation 0603_version2012_inoxt_rz

Semelhante a Automatisierte Linux installation 0603_version2012_inoxt_rz (20)

Automatisierte Linux installation 0603_version2012_inoxt_rz