Montag Aug 05, 2013

Linux Container (LXC) — Teil 2: Arbeiten mit Containern

Teil 1 dieser Artikelserie vermittelte einen Überblick über die Linux-Container-Technologie. In diesem zweiten Teil soll der Umgang mit Containern anhand einiger Beispiele erläutert werden. Diese lassen sich auf einem aktuellen Oracle Linux 6 System nachvollziehen. Für die ersten Schritte empfiehlt sich die Installation von Oracle Linux in einer virtuellen Umgebung wie z.B. Oracle VM VirtualBox. Für diese Plattform bietet Oracle ein bereits vorinstalliertes Oracle Linux 6 Image zum Download vom Oracle Technology Network (OTN) an.

Die Administration von Linux-Containern erfolgt auf der Kommandozeile; bisher existiert noch keine Integration oder Unterstützung von Linux-Containern in Applikationen wie dem Oracle VM Manager oder dem Oracle Enterprise Manager. Viele von Oracle entwickelte Verbesserungen sind jedoch in das in Oracle Linux 6.4 enthaltene lxc-Paket eingeflossen; diese wurden auch an das LXC-Projekt übergeben und sind damit Bestandteil aktueller LXC-Versionen. Die Unterstützung von Linux-Containern ist weiterhin in das libvirt-Projekt integriert, welches eine grafische Oberfläche für die komfortable Verwaltung von virtuellen Maschinen oder Linux-Containern mit Hilfe des virt-manager (und anderen Werkzeugen) ermöglicht. Libvirt ist ebenfalls Bestandteil von Oracle Linux.

Das Anlegen eines Oracle Linux-Containers ist aber auch mit Hilfe der LXC-Kommandozeilenwerkzeuge in wenigen Schritten erledigt. Zuerst sollte ein dediziertes Verzeichnis für die Container-Dateisysteme angelegt werden, als Standard wird /container als Verzeichnis-Name vorgegeben. Wird dieses Verzeichnis auf einem Btrfs-Dateisystem angelegt, ergeben sich einige weitere interessante Möglichkeiten, wie z.B. das "Einfrieren" eines Container-Dateisystems zu einem bestimmten Zeitpunkt oder das schnelle Erzeugen (Clonen) von weiteren Containern, basierend auf einer "Muster-Vorlage" (Template). Das Clonen mit Hilfe von Btrfs-Snapshots erfolgt extrem schnell und platzsparend; nur die Veränderungen zum "Template" werden gespeichert. Die Erstellung und Verwaltung von Btrfs-Dateisystemen wird im Kapitel " The Btrfs File System" des "Oracle Linux Administrator's Solutions Guide for Release 6" im Detail erläutert.

Um beispielsweise ein Btrfs-Dateisystem auf einem zweiten Festplattenlaufwerk anzulegen und es unter /container als Verzeichnis einzuhängen, können folgende Kommandos verwendet werden:

# mkfs.btrfs /dev/sdb

WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

fs created label (null) on /dev/sdb
	nodesize 4096 leafsize 4096 sectorsize 4096 size 4.00GB
Btrfs v0.20-rc1

# mdkir -v /container
mkdir: created directory `/container'
# mount -v /dev/sdb /container
mount: you didn't specify a filesystem type for /dev/sdb
       I will try type btrfs
/dev/sdb on /container type btrfs (rw)

Anschließend können Sie einen Container mit dem Kommando lxc-create erzeugen. Dessen Option "-t" bestimmt den generellen Distributions-Typ der erstellt werden soll (das sogenannte "Template"), z.B. "oracle", "ubuntu" oder "fedora". Je nach ausgewählten Template lassen sich nach den zwei Trennzeichen ("--") weitere Template-spezifische Optionen angeben. Für das Oracle-Template läßt sich z.B. mit der "--release"-Option die Distributions-Version auswählen, z.B. "5.8", "6.3" oder "6.latest". Weitere Informationen über die hier verfügbaren Konfigurationsmöglichkeiten finden Sie im Kapitel "About the lxc-oracle Template Script" des Oracle Linux 6 Administrator's Solutions Guide.

Um also beispielsweise einen Container mit dem Namen "ol6cont1" mit der aktuellsten Version von Oracle Linux 6 und Standardvorgaben zu erzeugen verwenden Sie folgendes Kommando:

# lxc-create -n ol6cont1 -t oracle -- --release=6.latest
/usr/share/lxc/templates/lxc-oracle is /usr/share/lxc/templates/lxc-oracle
Note: Usually the template option is called with a configuration
file option too, mostly to configure the network.
For more information look at lxc.conf (5)

Host is OracleServer 6.4
Create configuration file /container/ol6cont1/config
Downloading release 6.latest for x86_64
Loaded plugins: refresh-packagekit, security
ol6_latest                                               | 1.4 kB     00:00     
ol6_latest/primary                                       |  31 MB     01:23     
ol6_latest                                                          21879/21879
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package chkconfig.x86_64 0:1.3.49.3-2.el6 will be installed
--> Processing Dependency: libc.so.6(GLIBC_2.4)(64bit) for package: chkconfig-1.3.49.3-2.el6.x86_64
--> Processing Dependency: libc.so.6(GLIBC_2.3.4)(64bit) for package: chkconfig-1.3.49.3-2.el6.x86_64
[...]
--> Processing Dependency: rpm-python for package: yum-3.2.29-40.0.1.el6.noarch
--> Running transaction check
---> Package audit-libs.x86_64 0:2.2-2.el6 will be installed
---> Package bash.x86_64 0:4.1.2-15.el6_4 will be installed
[...]
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package               Arch   Version                          Repository  Size
================================================================================
Installing:
 chkconfig             x86_64 1.3.49.3-2.el6                   ol6_latest 158 k
 dhclient              x86_64 12:4.1.1-34.P1.0.1.el6           ol6_latest 316 k
[...]
 yum                   noarch 3.2.29-40.0.1.el6                ol6_latest 995 k
Installing for dependencies:
 MAKEDEV               x86_64 3.24-6.el6                       ol6_latest  88 k
 audit-libs            x86_64 2.2-2.el6                        ol6_latest  60 k
 basesystem            noarch 10.0-4.0.1.el6                   ol6_latest 4.3 k
[...]
 yum-metadata-parser   x86_64 1.1.2-16.el6                     ol6_latest  26 k
 zlib                  x86_64 1.2.3-29.el6                     ol6_latest  72 k

Transaction Summary
================================================================================
Install     135 Package(s)

Total download size: 79 M
Installed size: 294 M
Downloading Packages:
(1/135): MAKEDEV-3.24-6.el6.x86_64.rpm                   |  88 kB     00:00     
(2/135): audit-libs-2.2-2.el6.x86_64.rpm                 |  60 kB     00:00     
[...]
(135/135): zlib-1.2.3-29.el6.x86_64.rpm                  |  72 kB     00:00     
--------------------------------------------------------------------------------
Total                                           271 kB/s |  79 MB     04:59     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : libgcc-4.4.7-3.el6.x86_64                                  1/135 
  Installing : setup-2.8.14-20.el6.noarch                                 2/135 
[...]
  Installing : rootfiles-8.1-6.1.el6.noarch                             135/135 
  Verifying  : gamin-0.1.10-9.el6.x86_64                                  1/135 
  Verifying  : procps-3.2.8-25.el6.x86_64                                 2/135 
[...]
  Verifying  : 1:findutils-4.4.2-6.el6.x86_64                           135/135 

Installed:
  chkconfig.x86_64 0:1.3.49.3-2.el6                                             
  dhclient.x86_64 12:4.1.1-34.P1.0.1.el6                                        
[...]
Dependency Installed:
  MAKEDEV.x86_64 0:3.24-6.el6                                                   
  audit-libs.x86_64 0:2.2-2.el6                                                 
[...]
  zlib.x86_64 0:1.2.3-29.el6                                                    

Complete!
Rebuilding rpm database
Configuring container for Oracle Linux 6.4
Added container user:oracle password:oracle
Added container user:root password:root
Container : /container/ol6cont1/rootfs
Config    : /container/ol6cont1/config
Network   : eth0 () on virbr0
'oracle' template installed
'ol6cont1' created

Das Script lädt hierbei die erforderlichen RPM-Pakete von Oracles "public-yum" Server herunter, um eine Minimalinstallation (ca. 400 MB) der aktuellsten Oracle Linux 6 Version zu erstellen. Die Verzeichnis-Struktur des Containers befindet sich unter /container/ol6cont1/rootfs und kann vom Host-System aus wie eine reguläre Verzeichnisstruktur eingesehen werden. Das Script legt weiterhin zwei Benutzerkonten "root" und "oracle" an und konfiguriert eine virtuelle Netzwerk-Schnittstelle, die ihre IP-Adresse per DHCP vom zu libvirt gehörenden DHCP-Server bezieht. Die von lxc-create generierte Container-Konfigurationsdatei befindet sich in /container/ol6cont1/config und kann mit einem herkömmlichen Text-Editor an die eigenen Bedürfnisse angepasst werden. Vorab empfiehlt es sich, vom frisch installierten Container einen Snapshot zu erzeugen, von dem sich bei Bedarf schnell weitere Container erzeugen lassen:

# lxc-clone -o ol6cont1 -n ol6cont2
Tweaking configuration
Copying rootfs...
Create a snapshot of '/container/ol6cont1/rootfs' in '/container/ol6cont2/rootfs'
Updating rootfs...
'ol6cont2' created
# lxc-ls -1
ol6cont1
ol6cont2

Gestartet wird der Container anschließend mit dem folgenden Kommando:

# lxc-start -n ol6cont1 -d -o /container/ol6cont1/ol6cont1.log
# lxc-info -n ol6cont1
state:   RUNNING
pid:       311
# lxc-info -n ol6cont2
state:   STOPPED
pid:        -1

Der Container wird nun im Hintergrund gestartet; eventuelle log-Meldungen werden in die Datei ol6cont.log umgeleitet. Wie der Ausgabe von lxc-info entommen werden kann, wurde nur der Container ol6cont1 gestartet, während ol6cont2 sich weiterhin im gestoppen Zustand befindet, bis er ebenfalls mit lxc-start hochgefahren wird.

Anschließend können Sie sich mit dem folgenden Kommando an der Konsole des Linux-Containers anmelden. Die Systemkonfiguration kann nun mit den üblichen Bordmitteln (z.B. yum/rpm zur Software-Installation) innerhalb des laufenden Containers angepasst werden.

#  lxc-console -n ol6cont1

Oracle Linux Server release 6.4
Kernel 2.6.39-400.109.4.el6uek.x86_64 on an x86_64

ol6cont1 login: root
Password: 
[root@ol6cont1 ~]# ps x
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:00 /sbin/init
  184 ?        Ss     0:00 /sbin/dhclient -H ol6cont1 -1 -q -lf /var/lib/dhclien
  207 ?        Sl     0:00 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
  249 ?        Ss     0:00 /usr/sbin/sshd
  256 lxc/console Ss+   0:00 /sbin/mingetty /dev/console
  260 ?        Ss     0:00 login -- root     
  262 lxc/tty2 Ss+    0:00 /sbin/mingetty /dev/tty2
  264 lxc/tty3 Ss+    0:00 /sbin/mingetty /dev/tty3
  266 lxc/tty4 Ss+    0:00 /sbin/mingetty /dev/tty4
  267 lxc/tty1 Ss     0:00 -bash
  278 lxc/tty1 R+     0:00 ps x
[root@ol6cont1 ~]# logout

Oracle Linux Server release 6.4
Kernel 2.6.39-400.109.4.el6uek.x86_64 on an x86_64

ol6cont1 login: CTRL-A Q
Die Tastensequenz CTRL-A, Q beendet die Konsolen-Sitzung. Alternativ ist es auch möglich, sich vom Host aus mittels SSH am Container-System anzumelden. Alle Container haben eine eigene IP-Adresse und sind standardmäßig über eine virtuelle Ethernet-Brücke virbr0 miteinander verbunden, die auch vom Host-System aus erreichbar ist. Auf diesem Weg lassen sich z.B. recht schnell einfache Client-Server-Architekturen innerhalb eines Host-Systems aufsetzen.

Ein laufender Container läßt sich jederzeit mit dem Kommando lxc-freeze im aktuellen Zustand "einfrieren". Die laufenden Prozesse werden hierbei angehalten und verbrauchen keine CPU-Ressourcen mehr, bis der Container mittels lxc-unfreeze wieder freigegeben wird. Da Linux-Container auf den Linux-Control Groups (CGroups) basieren, ist es weiterhin auch möglich, den Ressourcenverbrauch eines Containers zu limitieren.

Heruntergefahren werden kann ein Container auf verschiedene Weise: Entweder vom Host-System aus mittels lxc-stop, oder innerhalb des Containers mit den üblichen Kommandos wie shutdown -h oder poweroff. Nicht mehr benötigte Container lassen sich mit Hilfe des Kommandos lxc-destroy entfernen.

Dem Thema "Linux Container" wird im Oracle Linux Administrator's Solutions Guide ebenfalls ein eigenes Kapitel gewidmet. Dieses behandelt im Detail unter anderem das Erstellen, Konfigurieren und Starten von Linux-Containern, sowie dem Monitoring und Herunterfahren. Auch die Erstellung eines Container-Repositories auf einem Btrfs-Dateisystem und wie sich bestehende Container sehr schnell und platzsparend duplizieren (klonen) lassen wird dort ausführlich beschrieben.

Weitere Links zum Thema Linux Container:

Montag Sep 10, 2012

Eine komplette Virtualisierungslandschaft auf dem eigenen Laptop – So geht’s

Wenn man sich mit dem Virtualisierungsprodukt Oracle VM in der aktuellen Version 3.x näher befassen möchte, bietet es sich natürlich an, eine eigene Umgebung zu Lern- und Testzwecken zu installieren.

Doch leichter gesagt als getan:

Bei näherer Betrachtung der Architektur wird man schnell feststellen, dass mehrere Rechner benötigt werden, um überhaupt alle Komponenten abbilden zu können:

  • Zum einen gilt es, den oder die OVM Server selbst zu installieren. Das ist leicht und schnell erledigt, aber da Oracle VM ein „Typ 1 Hypervisor ist“ - also direkt auf dem Rechner („bare metal“) installiert wird – ist der eigenen Arbeits-PC oder Laptop dafür eher ungeeignet. (Eine Dual-Boot Umgebung wäre zwar denkbar, aber recht unpraktisch.)

  • Zum anderen wird auch ein Rechner benötigt, auf dem der OVM Manager installiert wird. Im Gegensatz zum OVM Server erfolgt dessen Installation nicht „bare metal“, sondern auf einem bestehenden Oracle Linux. Aber was tun, wenn man gerade keinen Linux-Server griffbereit hat und auch keine extra Hardware dafür opfern will?

  • Möchte man alle Funktionen von Oracle VM austesten, so sollte man zusätzlich über einen Shared Storage verfügen. Dieser kann wahlweise über NFS oder über ein SAN (per iSCSI oder FibreChannel) angebunden werden. Zwar braucht man zum Testen nicht zwingend entsprechende „echte“ Storage-Hardware, aber auch die „Simulation“ entsprechender Komponenten (z.B. über fertige „Software Storage Appliances“ wie z.B. OpenFiler oder FreeNAS) erfordert zusätzliche Hardware mit entsprechendem freien Plattenplatz.

Angenommen, es steht tatsächlich keine „echte“ Server- und Storage Hardware zur Verfügung, so benötigt man für die oben genannten drei Punkte  drei bzw. vier Rechner (PCs, Laptops...) - je nachdem ob man einen oder zwei OVM Server starten möchte.

Erfreulicherweise geht es aber auch mit deutlich weniger Aufwand:

Wie bereits kurz im Blogpost anlässlich des letzten OVM-Releases 3.1.1 beschrieben, ist diese Version in der Lage, selbst vollständig innerhalb von VirtualBox als Gast zu laufen. Wer bei dieser „doppelten Virtualisierung“ nun an das Prinzip der russischen Matroschka-Puppen denkt, liegt genau richtig. Oracle VM VirtualBox stellt dabei gewissermaßen die äußere Hülle dar – und da es sich bei VirtualBox im Gegensatz zu Oracle VM Server um einen „Typ 2 Hypervisor“ handelt, funktioniert dieser Ansatz auch auf einem „normalen“ Arbeits-PC bzw. Laptop, ohne dessen eigentliche Betriebsystem komplett zu überschreiben.

Doch das beste dabei ist: Die Installation der jeweiligen VirtualBox VMs muss man nicht selber durchführen. Sowohl der OVM Manager als auch der OVM Server stehen bereits als vorgefertigte „VirtualBox Appliances“ im Oracle Technology Network zum Download zur Verfügung und müssen im Grunde nur noch importiert und konfiguriert werden.

Das folgende Schaubild verdeutlicht das Prinzip:

OVM in VirtualBox - Schaubild

Die dunkelgrünen Bereiche stellen jeweils Instanzen der eben erwähnten VirtualBox Appliances für OVM Server und OVM Manager dar. (Hier im Bild sind zwei OVM Server zu sehen, als Minimum würde natürlich auch einer genügen. Dann können aber viele Features wie z.B. OVM HA nicht ausprobieren werden.)

Als cleveren Trick zur Einsparung einer weiteren VM für Storage-Zwecke hat Wim Coekaerts (Senior Vice President of Linux and Virtualization Engineering bei Oracle), der „Erbauer“ der VirtualBox Appliances, die OVM Manager Appliance bereits so vorbereitet, dass diese gleichzeitig als NFS-Share (oder ggf. sogar als iSCSI Target) dienen kann. Dies beschreibt er auch kurz auf seinem Blog.

Die hellgrünen Ovale stellen die VMs dar, welche dann innerhalb einer der virtualisierten OVM Server laufen können. Aufgrund der Tatsache, dass durch diese „doppelte Virtualisierung“ die Fähigkeit zur Hardware-Virtualisierung verloren geht, können diese „Nutz-VMs“ demzufolge nur paravirtualisiert sein (PVM).

Die hier in blau eingezeichneten Netzwerk-Schnittstellen sind virtuelle Interfaces, welche beliebig innerhalb von VirtualBox eingerichtet werden können. Wer die verschiedenen Netzwerk-Rollen innerhalb von Oracle VM im Detail ausprobieren will, kann hier natürlich auch mehr als zwei dieser Interfaces konfigurieren.

Die Vorteile dieser Lösung für Test- und Demozwecke liegen auf der Hand: Mit lediglich einem PC bzw. Laptop auf dem VirtualBox installiert ist, können alle oben genannten Komponenten installiert und genutzt werden – genügend RAM vorausgesetzt. Als Minimum darf hier 8GB gelten. Soll auf der „Host-Umgebung“ (also dem PC auf dem VirtualBox läuft) nebenbei noch gearbeitet werden und/oder mehrere „Nutz-VMs“ in dieser simulierten OVM-Server-Umgebung laufen, empfehlen sich natürlich eher 16GB oder mehr.

Da die nötigen Schritte zum Installieren und initialen Konfigurieren der Umgebung ausführlich in einem entsprechenden Paper beschrieben sind, möchte ich im Rest dieses Artikels noch einige zusätzliche Tipps und Details erwähnen, welche einem das Leben etwas leichter machen können:

  • Um möglichst entstpannt und mit zusätzlichen „Sicherheitsnetz“ an die Konfiguration der Umgebung herangehen zu können, empfiehlt es sich, ausgiebigen Gebrauch von der in VirtualBox eingebauten Funktionalität der VM Snapshots zu machen. Dies ermöglicht nicht nur ein Zurücksetzen falls einmal etwas schiefgehen sollte, sondern auch ein beliebiges Wiederholen von bereits absolvierten Teilschritten (z.B. um eine andere Idee oder Variante der Umgebung auszuprobieren).

  • Sowohl bei den gerade erwähnten Snapshots als auch bei den VMs selbst sollte man aussagekräftige Namen verwenden. So ist sichergestellt, dass man nicht durcheinander kommt und auch nach ein paar Wochen noch weiß, welche Umgebung man da eigentlich vor sich hat. Dies beinhaltet auch die genaue Versions- und Buildnr. des jeweiligen OVM-Releases. (Siehe dazu auch folgenden Screenshot.) Weitere Informationen und Details zum aktuellen Zustand sowie Zweck der jeweiligen VMs kann in dem oft übersehenen Beschreibungsfeld hinterlegt werden.


  • Es empfiehlt sich, bereits VOR der Installation einen Notizzettel (oder eine Textdatei) mit den geplanten IP-Adressen und Namen für die VMs zu erstellen. (Nicht vergessen: Auch der Server Pool benötigt eine eigene IP.) Dabei sollte man auch nochmal die tatsächlichen Netzwerke der zu verwendenden Virtualbox-Interfaces prüfen und notieren.

    Wichtig ist im Zusammenhang mit der Netzwerkkonfiguration auch, dass alle beteiligten "Knoten" (d.h. die Virtualbox VMs für OVM Manager und OVM Server) über eine funktionierende Namensauflösung verfügen. Am einfachsten erreicht man dies über eine entsprechende /etc/hosts - Datei, die man auf alle drei (oder mehr) VMs kopiert und dann auch über gegenseitige Pings sowohl über Namen als auch IPs verifiziert.
  • Achtung: Es gibt im Rahmen der Installation einige Passworte, die vom Nutzer gesetzt werden können – und solche, die zunächst fest eingestellt sind. Zu letzterem gehört das Passwort für den ovs-agent sowie den root-User auf den OVM Servern, welche beide per Default „ovsroot“ lauten. (Alle weiteren Passwort-Informationen sind in dem „Read me first“ Dokument zu finden, welches auf dem Desktop der OVM Manager VM liegt.)

  • Aufpassen muss man ggf. auch in der initialen „Interview-Phase“ welche die VirtualBox VMs durchlaufen, nachdem sie das erste mal gebootet werden. Zu diesem Zeitpunkt ist nämlich auf jeden Fall noch die amerikanische Tastaturbelegung aktiv, so dass man z.B. besser kein „y“ und „z“ in seinem selbst gewählten Passwort verwendet.

  • Aufgrund der Tatsache, dass wie oben erwähnt der OVM Manager auch gleichzeitig den Shared Storage bereitstellt, sollte darauf geachtet werden, dass dessen VM vor den OVM Server VMs gestartet wird. (Andernfalls „findet“ der dem OVM Server Pool zugrundeliegende Cluster sein sog. „Server Pool File System“ nicht.)

About

Dieses Blog befasst sich mit Themen rund um Oracle Linux, Virtualisierung (primär mit Oracle VM) sowie Cloud Computing mit Oracle Produkten. Es wird betreut von Manuel Hoßfeld
- - - - - - - - - - - - - - - - - - - -
DISCLAIMER: Die Artikel und Kommentare in diesem Blog entsprechen den Meinungen der jeweiligen Autoren, und nicht notwendigerweise denen der Oracle Deutschland B.V. & Co. KG oder der Oracle Corporation.

Search

Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute