Freitag Dez 04, 2015

OVM Templates fuer SPARC - Teil 2: Templates Erstellen

Der wesentliche Sinn eines Templates ist es, eine Anwendung mit einer Umgebung auszuliefern, in der alles vorhanden ist, was die Anwendung braucht, aber auch nicht mehr als noetig.  Ein Template wird mehrfach installiert werden - dazu muss jede Instanz konfiguriert werden um eine "Persoenlichkeit" zu bekommen und evtl. mit anderen Komponenten verknuepft zu werden.  Um ein solches Template zu erstellen, muss man daher die Anwendung sehr gut kennen.  Evtl. braucht man ein Script, um die Anwendung nach der Installation des Templates beim ersten Start der Instanz zu konfigurieren.  Alles, was nicht automatisch beim ersten Start konfiguriert wird, muss manuell nachgearbeitet werden, was ja gerade vermieden werden soll.  Wie man solche First-Boot-Scripts schreibt, werde ich hier nicht naeher betrachten.

(Dieser Artikel ist die Blog-Version des zweiten Teils von MOS DocID 2063739.1 die hier fuer einfachen Zugriff wiedergegeben wird.)

Dies sind die Schritte um ein Template zu erstellen:
  1. Eine neue Domain erzeugen und Solaris und die ovmtutils installieren.
  2. Die fuer die Anwendung notwendigen Parameter definieren.
  3. Die Anwendung installieren und so weit wie moeglich konfigurieren.
  4. Ein First-Boot Script oder SMF Service schreiben und testen um Werte fuer diese Parameter mittels der Ovmt Tools auszulesen und die Anwendung damit zu konfigurieren.
  5. Solaris dekonfigurieren, ungenutzte Dateien loeschen und die Domain anhalten.
  6. Das Template erzeugen. 
  7. Das Template testen.  Ggf. obiges wiederholen um Probleme zu loesen.

Bevor wir uns diese Schritte naeher ansehen, hier ein wenig Hintergrund zu den Parametern oder Eigenschaften eines Templates.

Parameter eines Templates

Die meisten Anwendungen brauchen ein wenige Konfiguration, bevor man sie nutzen kann.  Typische Parameter sind z.B. TCP Ports auf denen die Anwendung erreichbar ist, Admin Passwoerter fuer ein Web User Interface oder die IP-Adresse einer zentralen Instanz.  Diese Werte werden normalerweise bei der manuellen Installation der Anwendung gesetzt.  Aber genau das wollen wir bei Templates ja vermeiden.  Deswegen brauchen wir eine Moeglichkeit, der Anwendung in unserem Template diese Werte bei der Installation mit auf den Weg zu geben.  Hier kommen die Parameter ins Spiel.  Alles womit man die Anwendung konfiguiert, wird als Parameter des Templates definiert.  Dazu gibt es eine Datei, in der diese Parameter definiert werden.  Diese Datei wird ein Teil des Templates.  Wichtig ist hier, dass in dieser Datei nur die Parameter definiert werden, nicht jedoch die Werte, die diese Parameter einmal haben werden!  Diese Werte werden erst bei der Installation des Templates vergeben.  Wie das bemacht wird, wurde schon im ersten Teil kurz gezeigt, als wir Solaris-Parameter an das Template weitergaben.

Parameter werden in einer kleinen XML-Datei definiert.  Sie haben ihrerseits diverse Eigenschaften wie bspw. einen Namen, der entweder voll qualifiziert oder einfach sein kann.  Desweiteren gibt es verschiedene Datentypen - Text, Zahl, Auswahlliste etc.  Diese werden ausfuehrlich im "Template Authoring Guide" beschrieben, der derzeit noch in Arbeit ist.  In unserem einfachen Beispiel verwenden wir lediglich Text-Parameter.

Die Werte fuer diese Parameter werden dem Template waehrend der Installation mit dem Tool "ovmtconfig" mitgegeben.  Dafuer gibt es zwei verschiedene Methoden.  Die Kompliziertere mounted dazu das Dateisystem des fertig installierten Zielsystems in der Control Domain und ruft dann ein beliebiges Script auf.  Diese Script kann dann durch direktes Arbeiten auf dem Dateisystem das Zielsystem konfigurieren.  Auf diese Weise wird bspw. ein AI Profil generiert und an die Domain weitergegeben, damit Solaris beim ersten Starten korrekt konfiguriert wird.  Die zweite Methode verwendet VM Variablen, um Parameter-Werte an die Domain weiter zu geben.  Diese koennen dann nach dem ersten Booten mit "ovmtprop" ausgelesen werden.  Deswegen ist es hilfreich, die OVMT Utilities im Template zu installieren.  Wie man das macht, sehen wir gleich im Beispiel.

Eine Quell-Domain erstellen

Der erste Schritt in der Entwicklung eines Templates ist die Erstellung einer Quell-Domain.  Hier wird die Anwendung installiert, konfiguriert und getestet.  Insb. das First-Boot-Script welches die Anwendung anhand der Parameter des Templates konfiguriert sollte gut getestet werden.  Hier ein paar Empfehlungen fuer diese Domain:

  • Man sollte ein einzelnes SPARC sun4v system verwenden, um das Template zu entwickeln, keinesfalls jedoch die Control Domain eines SuperCluster.  Dies ist nicht supported und wird auch nicht funktionieren.
  • Die Domain sollte moeglichst einfach gehalten werden:
    • Nach Moeglichkeit nur ein Netzwerk-Interface verwenden.  Das macht es hinterher einfacher, das Template in unterschiedlichen Umgebungen einzusetzen.
    • Nur eine einzelnes Disk-Image fuer das Betriebsystem verwenden.  Dieses Image sollte nicht unnoetig gross sein, damit das Template einfach zu transportieren ist.  Auch die Installation wird dadurch einfacher.
    • Falls erforderlich, kann man ein oder mehrere weitere Disk Images fuer die Anwendung verwenden.  Eine Trennung vom Betriebsystem ist auch hier oft von Vorteil.
    • CPU und Memory sollten ebenfalls nur sparsam verwendet werden.  Bei Bedarf kann die installierte Ziel-Domain spaeter immer noch vergroessert werden.
    • Auch das Betriebsystem sollte moeglichst klein gehalten werden und nur die Pakete enthalten, die von der Anwendung gebraucht werden.  Am besten faengt man mit "solaris-minimal-server" an und fuegt das hinzu, was die Anwendung braucht.
  • Die Disk-Images muessen einfache "flat files" sein.  Eine spaetere Version der Tools wird auch andere Disk-Optionen unterstuetzen.
  • Die Namen aller Disk-Image Dateien muessen mit ".img" enden.  Das ist zwar nicht grundsaetzlich notwendig, aber eine zwingende Voraussetzung um das Template auch auf SuperCluster zu installieren.
    • Die Image-Namen sollten sinnvolle Namen haben, da diese Namen auch in den Meta-Daten des Templates verwendet werden.
  • Um die Testzyklen zu beschleunigen empfiehlt es sich, das Paket "pigz" zu installieren, eine parallele Implementierung von gzip.  Falls vorhanden, wird es von den Tools automatisch verwendet, um die Kompression und Dekompression der Disk Images zu beschleunigen.
  • Da man idR. ovmtprop verwenden wird, um Parameter fuer die Anwendung auszulesen, sollte man die "ovmtutilities" in der Quell-Domain installieren.
  • Die Anwendung sollte vollstaendig fertig konfiguriert sein.  Wenn das bedeutet, zusaetzliche Benutzer oder Dateisysteme hinzu zu fuegen oder die Systemkonfiguration anzupassen, dann nur zu.  Alle diese Aenderungen werden im Template erhalten bleiben.
  • System-Eigenschaften wie IP-Adressen, root Passworte oder Zeitzonen bleiben natuerlich nicht erhalten.  Diese werden aus dem Template entfernt und bei der Installation neu gesetzt.

Die Parameter Definieren

Welche Parameter man fuer das Template braucht, haengt natuerlich von der Anwendung ab.  Deswegen sollte man diese genau kennen und wissen, wie sie installiert und konfiguriert wird.  Hier ist ein Beispiel fuer eine sehr sehr einfache Anwendung:  Ein Apache Webserver der eine einfache Text-Seite zeigt, in der die drei Beispiel-Parameter mit ihren Werten angezeigt werden:  property1, property2 und property3.  Hier ist die XML-Datei, mit der diese Parameter definiert werden:

<ovf:ProductSection ovf:class="com.oracle.supercluster.client">
        <ovf:Product>Oracle SuperCluster</ovf:Product>
        <ovf:Category>OVM Templates</ovf:Category>
        <ovf:Version>1</ovf:Version>
        <ovf:Property ovf:key="property1" ovf:type="string" 
                      ovf:userConfigurable="true" ovf:value="Value1">
                <ovf:Description>Specifies property 1</ovf:Description>
        </ovf:Property>
        <ovf:Property ovf:key="property2" ovf:type="string"
                      ovf:userConfigurable="true" ovf:value="Value2">
                <ovf:Description>Specifies property 2</ovf:Description>
        </ovf:Property>
        <ovf:Property ovf:key="property3" ovf:type="string"
                      ovf:userConfigurable="true" ovf:value="Value3">
                <ovf:Description>Specifies property 3</ovf:Description>
        </ovf:Property>
</ovf:ProductSection> 

Diese Datei wird bei der Erzeugung ein Teil des Templates werden.  In dieser Definition stehen zwar Werte fuer die jeweiligen Parameter.  Diese werden jedoch bei der Installation nicht verwendet!  Eine ausfuehrliche Beschreibung aller Optionen fuer die Parameter wird es in dem bald erscheinenden "Template Authoring Guide" geben.

Installation und Konfiguration der Anwendung

Auch dieser Schritt haengt wieder stark von der jeweiligen Anwendung ab.  In unserem einfachen Beispiel ist nicht sehr viel zu tun.  Hier wird auch das einfachste aller First-Boot-Scripte gezeigt:

root@source:~# pkg install ovmtutils

root@source:~# pkg install apache22

root@source:~# svcadm enable apache22

root@source:~# more /etc/rc3.d/S99template-demo 

#!/bin/sh

# simplest of all first-boot scripts
# just for demo purposes

OUTFILE=/var/apache2/2.2/htdocs/index.html
OVMTPROP=/opt/ovmtutils/bin/ovmtprop
BASEKEY=com.oracle.supercluster.client.property

if [ ! -f $OUTFILE ]
then
   cat >>$OUTFILE << EOF
<html><body>
<h1>OVM Template Demo</h1>
EOF
   for i in 1 2 3
   do
      $OVMTPROP -q get-prop -k $BASEKEY$i >> $OUTFILE
      echo "</br>" >> $OUTFILE
   done
cat >>$OUTFILE << EOF
</body></html>
EOF
fi

Wenn alles perfekt laeuft und das First-Boot-Script zuverlaessig funktioniert muss als letzter Schritt Solaris de-konfiguriert werden.  Das macht man mit dem Kommando "sysconfig unconfigure --destructive --include-site-profile".  Damit wird die gesamte System-Identitaet, also Hostname, IP adressen, Zeitzonen und root Passwoerter entfernt.  Das ist notwendig, damit das System nach der Installation neu konfiguriert werden kann.  Auch Dateien wie bspw. SSH-Keys und temporaere Dateien in /var/tmp kann man jetzt noch loeschen.

Das Template Erzeugen

Nachdem nun endlich alle Vorbereitungen abgeschlossen sind, ist die eigentliche Erzeugung des Templates sehr einfach.  Das Kommando "ovmtcreate" sammelt all die Teile zusammen und baut daraus einen OVF Container.

root@mars:~# ovmtcreate -d source -o /templates/apache-template.ova \
             -s "OVM S11.2 SPARC Apache 2.2 Demo" \
             -P /development/apache-template.properties.xml

Dieses Kommando komprimiert alle Disk Images und fuegt sie gemeinsam mit den Parameter-Definitionen im OVF-Format zusammen.  Diese Datei kann dann verteilt und dorthin transportiert werden, wo das Template installiert werden soll.  Mit dem Parameter "-s" gibt man dem Ganzen eine sinnvolle Beschreibung, um das Template zu identifizieren.  Diese Beschreibung wird bspw. im SuperCluster verwendet, um die in der Template-Library vorhandenen Templates anzuzeigen.

Zum Schluss noch, wie man nun das Template mit passenden Werten fuer die Parameter versieht und installiert:

Installation

Die Werte fuer die Parameter des Templates werden fuer die Installation in eine kleine Text-Datei geschrieben:

root@mars:~# cat custom.values
com.oracle.supercluster.client.property1=Value1
com.oracle.supercluster.client.property2=Value2
com.oracle.supercluster.client.property3=Value3

Auch Solaris selbst muss man natuerlich mit Konfigurationsdaten versehen.  Wie das geht, habe ich bereits im ersten Teil dieser Mini-Serie gezeigt.  Diese Konfiguration verwenden wir hier einfach wieder.

Um die Ziel-Domain zu installieren und zu konfigurieren, braucht man jetzt nur zwei einfache Kommandos:

root@mars:~# ovmtdeploy -d target -o /domains \
    -s /templates/apache-template.ova
root@mars:~# ovmtconfig -d target  \
    -c /opt/ovmtutils/share/scripts/ovmt_s11_scprofile.sh \
    -P solaris_11.props.values,custom.values

Nachdem die Domain gebootet hat, sollte auf Port 80 der Apache die einfache HTML-Seite anzeigen, die durch das First-Boot-Script erzeugt wurde.

Noch einige Bemerkungen

  • Die Paramter fuer die Ziel-Domain sind in der Control Domain sichtbar.  Sie werden als normale VM Variablen an die Domain weiter gegeben.  Daher sind sie mit dem Kommando "ldm ls-variable <domain>" einzusehen.  Das bedeutet auch, dass sensitive Informationen die auf diese Weise an die Domain geleitet wird, fuer jedermann sichtbar sind, der die notwendigen Rechte fuer das Kommando "ldm ls" hat.  Die gleichen Informationen sind auch in der Zieldomain selbst jedem Benutzer ueber das Kommando ovmtprop zugaenglich.  So praktisch das fuer das Debuggen sein mag, sollte man daher keine sensitive Information wie z.B. Passworte, in solche Parameter stecken.  Besser sind verschluesselte Passwort-Strings, falls moeglich.  Falls das nicht moeglich ist, sollte man die Variablen nach erfolgreicher Installation des Templates mit dem Kommando "ldm rm-variable" loeschen.  Grundsaetzlich ist es auch eine gute Idee, den Benutzer der Anwendung (und der Domain) beim ersten einloggen zu einem Passwort-Wechsel aufzufordern.
  • Grundsaetzlich unterstuetzen OVMT Templates auch Solaris Zonenen.  Das bedeutet, man kann ein Template erzeugen, das eine oder mehrere Zonen enthaelt.  Allerdings muss man die Konfiguration dieser Zonen (IP Adressen, Hostname etc) selbst ueber das First-Boot-Script erledigen, das dies nicht Teil der normalen Solaris-Konfiguration ist.  Templates mit Zonen werden derzeit nicht auf SuperCluster unterstuetzt.

Weitere Links gab es bereits am Ende des ersten Teils dieser Mini-Serie.

Donnerstag Mai 24, 2012

OVM Server for SPARC 2.2 verfuegbar!

Schon laenger erwartet, ist sie jetzt da:  Die neue Version 2.2 von Oracle VM Server for SPARC. Ohne hier die Dinge nur zu wiederholen, das wichtigste in Kuerze:

Eine gute Zusammenfassung gibt es im Oracle Virtualization Blog. Zusaetzlich natuerlich:

Froehliches Virtualisieren!

Donnerstag Jun 09, 2011

OVM Server for SPARC 2.1 ist da!

Die neueste Version von OVM Server for SPARC aka LDoms ist da!  Hier die Presse-Meldung...

Was, schon wieder eine neue Version?  Na ja, das am meisten vermisste Feature in den bisherigen Versionen wurde fertig, und da war ein Release einfach unumgänglich ;-)  In der neuen Version 2.1 wird aus "Warm Migration" endlich "Live Migration".  Was es sonst noch an Neuerungen gibt, steht in "What's New".  Weitere Details zur Live Migration werden sicherlich auch bald bekannt und ggf. auch hier erwähnt werden.  Den Download gibt es bei eDelivery, die Dokumentation wie immer auf OTN.

Mittwoch Jan 26, 2011

Logical Domains - aber sicher

LDoms Oracle VM Server for SPARC werden schon lange eingesetzt.  Und ich bekam immer mal wieder die Frage zu hoeren, wie sicher sie denn eigentlich seien.  Ein Kunde wollte es ganz genau wissen, und so beauftragten wir einen unabhaengigen Gutachter.  Das Ergebnis war erfreulich, aber leider nicht als Bettlektuere geeignet.  Deswegen, und um die eigentliche Untersuchung um Empfehlungen zum Betrieb zu erweitern, schrieb ich auf dieser Grundlage ein Whitepaper.  Dank der Uebernahme durch Oracle verzoegerte sich die Veroeffentlichung etwas.  Das hat aber den Vorteil, dass es jetzt auch auf dem aktuellesten Stand ist.  Ich bin deshalb froh, endlich vorstellen zu koennen:


Secure Deployment of Oracle VM for SPARC


Meinen Dank an Steffen Gundel von der Cirosec, der mit seiner Untersuchung die Grundlage fuer dieses Papier schuf!


Ich hoffe, das Papier hilft dem einen oder anderen weiter!


Viel Spass beim Lesen!

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« Juni 2016
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