|
|
|
Die Versionen "apk-*-linux-ub" sind mit den folgenden Betriebssystem-Distributionen kompatibel:
Zum Installieren von APK benötigen Sie:
Das Image muss das ext3-Dateisystem enthalten, wenn die von APK bereitgestellten Kernel- und initrd-Dateien verwendet werden.
Die Linux-Versionen von APK unterstützen einen HVM-Start für VMWare und XEN-Hypervisoren. Der von CA AppLogic mitgelieferte PVM-Kernel ist optional.
Wenn der von CA 3Tera AppLogic bereitgestellte Kernel vor dem Ausführen der APK-Installation entpackt wird, wird er automatisch als der Kernel konfiguriert, der gestartet wird, wenn die Appliance im PVM-Modus gestartet wird: Hierfür wird die neue Datei "boot/grub/menu.lst" erstellt. Der installierte vom Betriebssystem angegebene Kernel wird beim HVM-Start verwendet. (Die GRUB-Konfigurationsdatei des Standardbetriebssystems für Red Hat-kompatible Betriebssysteme ist "boot/grub/grub.conf".)
Wenn der von CA 3Tera AppLogic bereitgestellte Kernel vor dem Ausführen der APK-Installation entpackt wird, wird er als der Start-Kernel in "boot/grub/menu.lst" festgelegt. Die ursprüngliche GRUB-Konfigurationsdatei wird als "boot/grub/menu.lst.apkbk" gesichert. Der Appliance-Ersteller kann das gespeicherte Backup umbenennen und den GRUB-Boot-Loader erneut konfigurieren, um einen anderen Dateinamen als die Konfigurationsdatei zu verwenden, sodass dieser verwendet wird, wenn die Appliance im HVM-Modus startet. Bei einem Start im PV-Modus wird immer "boot/grub/menu.lst" verwendet.
Wenn die APK-Installation ausgeführt wird, ohne dass der von CA 3Tera AppLogic bereitgestellte Kernel entpackt wird, bleibt die GRUB-Konfiguration intakt. Es wird angenommen, dass die Appliance im HVM-Modus ausgeführt wird oder der vom Betriebssystem angegebene Kernel im XEN-PV-Modus starten kann. (Viele der neueren BS-Distributionen bieten ein XEN-PV-Kernel-Build, das als Standard installiert und konfiguriert werden kann.)
Die folgenden Schritte können je nach der ursprünglichen Installation des Betriebssystems variieren. Sie werden nicht vom APK-Setupskript ausgeführt, und werden dem Ermessen des Administrators überlassen, da einige von ihnen invasiv sind und destruktiv sein können, wenn sie versehentlich auf einem Live-System ausgeführt werden (statt auf dem Image, das vorbereitet wird). Daher wird davon abgeraten, sie über ein automatisiertes Skript ablaufen zu lassen. Überspringen Sie Schritte, die für Sie nicht zutreffend sind.
So bereiten Sie das Image vor
run tune2fs -j
Um "ext2" (oder ein anders Dateisystem als "ext3") zu verwenden, muss die im Lieferumfang von APK enthaltene Datei "initrd" neu erstellt werden.
/dev/hda1
Das Installationsprogramm führt auch eine Überprüfung durch und zeigt eine Warnung an, wenn das Stammgerät durch eine Bezeichnung oder UUID angegeben wird.
Hinweis: Wenn Sie andere ausführbare 32-Bit-Dateien als die Dateien in APK ausführen müssen, berücksichtigen Sie die Installation des Metapackets "ia32-libs". Das Metapaket installiert alle Pakete, die 32-Bit-Bibliotheken enthalten.
Wichtig! Deinstallieren oder deaktivieren Sie NetworkManager. Dieses Programm gerät mit der CA 3Tera AppLogic-Netzwerkkonfiguration in Konflikt. Ausnahme: Wenn ein VPS-Server mit grafischer Benutzeroberfläche eingerichtet wird, kann das NetworkManager-Applet verwendet werden, um eine manuelle IP-Konfiguration auszuführen. (Das Applet muss aber im manuellen Modus eingerichtet werden, bevor die neue BS-Installation in CA 3Tera AppLogic gestartet wird.)
Hinweis: Nach der Bereinigung kann das Volume verkleinert werden, um ein kleineres Start-Volume-Image für die Appliance zu erhalten. Stellen Sie aber sicher, dass mindestens 10-15 MB freier Speicherplatz verbleiben, um genügend Platz für die Installation des XEN DomU-Kernels und APK und für Protokolldateien, temporäre Dateien usw. zu haben.
APK verwendet ein einfaches Initial-Ramdisk-Image (initrd), das das "nash"-Bootstrap-Programm von Red Hat erstellt hat. Es werden keine Kernel-Module geladen. Der einzige Zweck des Programms ist die Einrichtung des Ramdisk-basierten Verzeichnisses "/dev/" für das "udev" und die Auffüllung.
Es funktioniert problemlos beim Starten einer Ubuntu-basierten virtuellen Appliance, und es muss kein Ubuntu-spezifisches initrd-Image für die Appliance erstellt werden. Die Ubuntu 6/7 initrd-Images sind größer und besitzen mehr erweiterte Funktionen, die in den meisten Appliances nicht notwendig sind. Wenn dies aber erwünscht ist, kann eine Ubuntu-spezifische initrd-Datei erstellt und verwendet werden. Bearbeiten Sie einfach die Datei "/boot/grub/menu.lst", um auf ein anderes initrd-Image hinzuweisen. Beachten Sie, dass diese Änderung erneut angewendet werden muss, wenn APK später wieder installiert wird.
Die hier angegebenen Installationsanweisungen setzen voraus, dass die APK-Installation auf einem BS-Image vorgenommen wird, das eigentlich nicht ausführt wird, aber zuvor vorbereitet wurde, indem entweder ein sauberes BS installiert, heruntergefahren und auf den Startdatenträger zurückgegriffen wurde, oder indem eine vorhandene CA 3Tera AppLogic-Appliance wird mit einer neuen APK-Version aktualisiert wurde.
Auch eine Live-Installation (auf einem laufenden Betriebssystem) ist möglich. Verwenden Sie sie zusammen mit dem Hilfsprogramm "iso2class", das ab CA 3Tera AppLogic ServicePack 2.4.5 bereitgestellt wird. Führen Sie für eine Installation in einem Live-System die folgenden Schritte aus; verwenden Sie jedoch "/" als aktuelles Verzeichnis für alle Vorgänge. Dies wird am besten auf einem virtuellen XEN-Computer durchgeführt (z. B. "using iso2class"). Wenn APK nur mit dem CA 3Tera AppLogic-XEN-PV-Kernel installiert wird, kann der Computer nicht mehr gestartet werden.
Laden Sie das Betriebssystem-Image in Ihr Dateisystem. Wenn das Image bereits als ein Volume auf einem CA 3Tera AppLogic-Grid installiert ist, kann darauf mithilfe des Befehls "vol manage" zugegriffen werden. Kopieren Sie die APK-Dateien in das Verzeichnis "/tmp" auf dem Image selbst oder in ein temporäres Verzeichnis auf dem Host, auf dem das Image geladen wird. Wenn sich das Image bereits auf einem Grid befindet, kopieren Sie die Dateien über die Webschnittstelle auf das Image selbst. (Ohne Grid: Beachten Sie, dass die folgenden Vorgänge als Benutzer "root" durchgeführt werden müssen.)
So installieren Sie "wget"
cd /mnt/vol tar -zxf tmp/domu-linux-2.6.18.8.i386.tar.gz tar -zxf tmp/apk-2.0.14-ub.tar.gz
Das Setupskript wird ins Verzeichnis "./tmp" entpackt.
Wichtig! Verwenden Sie das richtige domu-linux-Archiv für Ihre Distro-Architektur. Wenn Sie ein 32-Bit Kernel installieren, funktioniert es auf einem 64-Bit-Distro nicht.
tmp/apk-install
Hinweis: Die im Lieferumfang von APK enthaltenen init-Skripte unterstützen die Appliance-spezifischen Skripte nicht mehr, die unter "/appliance" installiert sind. Wenn es vorhanden ist, hält das Installationsskript an und fordert eine Benutzereingabe an. Wenn keine Appliance-spezifische Anpassung in diesem Verzeichnis vorgenommen wurde (d. h., die Inhalte sind gleich oder ähneln dem LUX-Inhalt), können Sie es löschen. Die ganze Standardfunktionalität, die dort installiert wurde, wird jetzt von APK bereitgestellt. Klicken Sie anderenfalls, um nach "/tmp" zu speichern und mit der Installation fortzufahren.
Das Setupskript (und die Dateien mit der Erweiterung "tar", falls sie in das Image selbst kopiert wurden) können jetzt entfernt werden:
rm tmp/apk-install = =tmp/domu-linux-*.tar.gz = tmp/apk-*.tar.gz=
Weitere Informationen finden Sie im Benutzerhandbuch.
Wenn die Datei "/etc/sysconfig/applogic_init" vorhanden ist, liest das APK-Initialisierungsskript sie als "shell include"-Skript (mit dem Befehl "."). Die folgenden Parameter können in "/etc/sysconfig/applogic_init" definiert werden:
|
APK_AUTH_KEY_PATH |
Speicherort, an dem der öffentliche Schlüssel für den SSH-Zugriff der Appliance gespeichert wird. Über den Befehl "3t comp shh" wird anhand des entsprechenden privaten Schlüssels eine Verbindung zu Appliances hergestellt. Der Standard ist "/root/.ssh". Wenn eine leere Zeichenfolge festgelegt wird, wird der Schlüssel nirgends gespeichert. |
|
APK_CONFIG_FILES |
Durch Leerzeichen getrennte Liste von Dateien, auf die Appliance-Eigenschaften angewendet werden. Dies ersetzt die angegebene Konfigurationsdateiliste im Dialogfeld "Begrenzung ändern" in der GUI (für Appliances, die nicht APK verwenden). Eine Appliance mit APK verwendet die Liste "APK_CONFIG_FILES", die sich in der Appliance selbst befindet, und nicht die in der GUI angegebene Liste. |
Wichtig! Die Datei "/etc/sysconfig/applogic_init" wird ausgeführt, bevor Konfigurationsdaten abgerufen oder angewandt werden. Daher kann sich das Skript nicht auf die Anwesenheit der Konfigurationsdateien der Appliance verlassen. Verwenden Sie diese Datei nicht dafür, Initialisierungscode auszuführen, sondern nur für die oben definierten Konfigurationsvariablen.
Beispiel "/etc/sysconfig/applogic_init":
APK_CONFIG_FILES=/etc/httpd/conf.d/myconfig.conf APK_AUTH_KEY_PATH=/root/.ssh/alternate_keys
Wenn die Datei "/etc/sysconfig/applogic_appliance" vorhanden ist, liest das APK-Skript "late init" sie als Skript "shell include" (mit dem Befehl "."), nachdem alle Dienste auf der Appliance gestartet wurden. Der Rückgabestatus vom Skript zeigt an, ob die Appliance als richtig gestartet oder fehlgeschlagen betrachtet werden soll. Wenn das Skript eine Meldung in stderr druckt und einen Fehler zurückgibt, wird die Schlusszeile dieser Meldung als Fehlermeldung an den Controller gesandt.
Beispieldatei für die Überprüfung nach dem Start für eine Webserver-Appliance - überprüft, dass der Server läuft und auf "HTTP GET" an die Startseite reagiert:
if ! wget -q -O /dev/null http://localhost/ ; then
echo "start failed - web server is not responding" >&2
return 1
fi
return 0
Wichtig! Einige Appliances im Systemkatalog verwenden ein angepasstes Skript in "/appliance", um Dienste zu initialisieren. Dies wird nicht mehr unterstützt. Dieses Verzeichnis wird gelöscht, wenn APK installiert wird, damit die Stammverzeichnisstruktur (!!) sauber und mit dem Dateisystem-Hierarchie-Standard kompatibel ist. Der Code aus solchen Skripten könnte zu "/etc/sysconfig/applogic_appliance" verschoben werden, um das alte Verhalten nachzuahmen. Dies ist jedoch nicht die Absicht der Datei für die Überprüfung nach dem Start und wird nicht empfohlen. Statt dessen muss ein installierter Dienst sein eigenes Initialisierungsskript haben und allgemein in der Lage sein, vollständig außerhalb von CA 3Tera AppLogic ausgeführt zu werden.
| Copyright © 2011 CA. Alle Rechte vorbehalten. | Senden Sie CA Technologies eine E-Mail zu diesem Thema. |