From bcf56490a1e23d4814bce6021cc89466b846b502 Mon Sep 17 00:00:00 2001 From: Frank Brehm Date: Thu, 16 Sep 2021 12:46:29 +0200 Subject: [PATCH] Update README.md --- README.md | 164 +++++++++++++++++++++++++++++++++--------------------- 1 file changed, 102 insertions(+), 62 deletions(-) diff --git a/README.md b/README.md index 65360dc..fec42b9 100644 --- a/README.md +++ b/README.md @@ -350,72 +350,110 @@ Boolscher Wert. Wenn wahr, ist das identisch damit, als ob *'create-terraform'* Schalter *'--simulate'* aufgerufen wird. Es wird also nur so getan, als ob, und die Terraform-Projekt-Verzeichnisse und -Dateien werden nicht angelegt. -* **simulate**: Boolscher Wert. Wenn wahr, ist das identisch damit, als ob *'create-terraform'* immer mit dem - Schalter *'--simulate'* aufgerufen wird. Es wird also nur so getan, als ob, und die Terraform-Projekt-Verzeichnisse - und -Dateien werden nicht angelegt. -* **defaults**: Wie bereits erwähnt, werden hier die globalen Vorgabewerte für alle VMs definiert. -* **vms**: Liste der nicht gruppierten VMs. Das heißt, sie beziehen ihre Vorgaben ausschließlich aus den - Vorgabewerten der obersten Ebene. - In dieser Liste werden alle VMs, die provisioniert werden sollen, als Hashes aufgelistet, wobei minimal - der Name und eine IPv4-Adresse pro VM definiert werden müssen. -* **groups**: Liste von Gruppen von VMs, die wiederum gemeinsame, von den globalen abweichende Vorgabewerte - haben. Jede Gruppe ist ein Hash mit drei notwendigen Schlüsseln: *'name'*, *'defaults'* und *'vms'*, sowie - dem optionalen Schlüssel *'groups'*. - Mit **name** wird jeder Gruppe ein eindeutiger Gruppenname zugewiesen. Dieser wird zwar in Terraform - nicht verwendet, aber dient zum einfacheren Auffinden von Fehlern in der Konfiguration. - Die Schlüssel **defaults**, **vms** und **groups** haben exakt die selbe Bedeutung wie auf der obersten - Ebene. In den *defaults* in einer Gruppe können Vorgabewerte der nächsthöheren Ebene überschrieben werde. +##### defaults + +Wie bereits erwähnt, werden hier die globalen Vorgabewerte für alle VMs definiert. + +##### vms + +Liste der nicht gruppierten VMs. Das heißt, sie beziehen ihre Vorgaben ausschließlich aus den +Vorgabewerten der obersten Ebene. + +In dieser Liste werden alle VMs, die provisioniert werden sollen, als Hashes aufgelistet, wobei minimal +der Name und eine IPv4-Adresse pro VM definiert werden müssen. + +##### groups + +Liste von Gruppen von VMs, die wiederum gemeinsame, von den globalen abweichende Vorgabewerte +haben. Jede Gruppe ist ein Hash mit drei notwendigen Schlüsseln: `name`, `defaults` und `vms`, sowie +dem optionalen Schlüssel `groups`. + +Mit **name** wird jeder Gruppe ein eindeutiger Gruppenname zugewiesen. Dieser wird zwar in Terraform +nicht verwendet, aber dient zum einfacheren Auffinden von Fehlern in der Konfiguration. + +Die Schlüssel **defaults**, **vms** und **groups** haben exakt die selbe Bedeutung wie auf der obersten +Ebene. In den **defaults** in einer Gruppe können Vorgabewerte der nächsthöheren Ebene überschrieben werde. #### 2.1.2. Konfigurations-Parameter für eine VM Die nachfolgenden Parameter können pro defaults-Abschnitt und pro VM vergeben werden. -* **vsphere**: Name der der VSPhere-Umgebung aus der Konfiguration dieser Anwendung, also im Falle von Pixelpark - entweder _test_ oder _live_. **Achtung**: Durch die Limitierung von Terraform darf es in einem Terraform-Projekt - nur ein VSphere geben, damit macht es Sinn, diesen Parameter nur ein einziges Mal anzugeben, nämlich im - obersten Template. - -* **vm_folder**: Der Name des Ordners innerhalb des Baums der 'VMs und Vorlagen'-Ansicht in VSPhere. Dabei achtet - VSPhere auf Groß- und Kleinschreibung, also sind _'Pixelpark'_ und _'pixelpark'_ zwei unterschiedliche Ordner. - Empfohlen wird auf oberster Ebene der Kunde als Ordnername, und darunter bei kleineren Kunden das Tier (z.Bsp. - 'live', 'test' und 'dev') als zweite Ebene, bei größeren Kunden sollte noch das Projekt als zweite Ebene - dazwischen geschoben werden. Damit ergeben sich bei kleineren Kunden Ordnernamen wie _'Mubea/live'_, und bei - größeren Kunden zum Beispiel _'Pixelpark/DNS/test'_. Wenn der Ordner in VSphere nicht existieren sollte, wird - er vom Create-Script angelegt. Die Ordner werden nicht als Terraform-Resourcen behandelt, das heißt, wenn nach - dem Wegwerfen von VMs mittels Terraform der Ordner leer ist, wird er von Terraform nicht weggeräumt. Das - obliegt dann dem Admin, der die VMs weggeräumt hat, manuell. - -* **num_cpus**: Die Anzahl der CPUs der VM als Integer-Zahl. Der Einfachheit halber ist damit grundsätzlich die - Anzahl der CPUs mit jeweils einem Core gemeint. Wer Spielereien wie 'X CPUs mit Y Cores' unbedingt und dringend - benötigt, richtet die VM erst mal nach obigem Schema ein und konfiguriert diese anschließend manuell in VSPhere. - Bislang hat sich mir derlei Notwendigkeit aber noch nicht dargestellt. - -* **memory**: Die Größe des Haupspeichers der VM. Wenn keine Einheit angegeben wurde, werden MiByte (also 2^20 Bytes) - angenommen. Man kann aber auch eine Float- oder Integerzahl zusammen mit einer Maßeinheit wie GiB oder TiB - angeben. Zu beachten ist, dass der resultierende Haupspeicher mindestens 256 MiB groß sein sowie ein Vielfaches - von 256 MiB sein muss. SI-konforme Einheiten werden hier nicht beachtet, das heißt beispielsweise, dass - 1 GB identisch mit 1 GiB ist, also 2^30 Bytes, und nicht 10^9 entspricht. Im Normalfall verwendet man aber - ein Vielfaches von 1 GiB als Hauptspeicher. - -* **boot_delay**: Die Verweildauer im POST nach dem Einschalten als Float-Zahl in Sekunden. In diesem Zeitraum kann - in der VM-Konsole in VSPhere zum Beispiel das Boot-Menü aufgerufen werden, um die VM beispiesweise vom Netz oder - einer verbundenen Live-CD zu booten, oder um die BIOS-Einstellungen zu gelangen. Wenn man unbedingt das - VSPhere-Standard-Verhalten haben möchte (sofortiger Boot ohne Warten), stellt man den Wert auf '**0**'. In diesem - Fall kann man aber auch keine Tasten für BIOS usw. drücken. Der Standardwert, wenn er nicht gesetzt wird, - beträgt 5 Sekunden. - -* **datastore_cluster**: Welcher Datenstore-Cluster soll für alle Disks der VM verwendet werden? Ene Angabe an dieser - Stelle hat Vorrang vor *datastore_type*. Man muss allerdings beachten, dass zum Zeitpunkt des Schreibens dieser - Dokumentation (2020-01-07) im live-VSPhere noch keine Datenstore-Cluster verfügbar sind und es demzufolge keinen - Sinn macht, bei Provisionierung in das live-Cluster hier etwas anzugeben. Bei Provisionierungen in das test-Cluster - hingegen macht das wiederum viel Sinn, da es dort Datenstore-Cluster gibt. - -* **datastore_type**: Auf welchem Typ Storage sollen die Disks der VM angelegt werden, wenn kein Datenstore-Cluster - angegeben wurde. Mögliche Angaben sind **ssd**, **sas** und **sata**, wobei letzteres die Vorgabe ist, wenn hier - nichts angegeben wird. Kriterium für die Auswahl eines Datastores ist es, ob der angegebene String im Namen des - Datastores auftaucht und genügend Platz für alle Disks aufweist. Lokale Datastores und solche auf NFS werden nicht - berücksichtigt. Wenn bei einem Typ kein Datastore gefunden wird, wird die Suche auf andere Typen ausgedehnt, wobei - ausgehend von der Angabe in folgender Reihenfolge gesucht wird: +##### vsphere + +Name der der VSPhere-Umgebung aus der Konfiguration dieser Anwendung, also im Falle von Pixelpark +entweder `test` oder `live`. + +**Achtung**: Durch die Limitierung von Terraform darf es in einem Terraform-Projekt nur ein VSphere geben, +damit macht es Sinn, diesen Parameter nur ein einziges Mal anzugeben, nämlich im obersten Template. + +##### vm\_folder + +Der Name des Ordners innerhalb des Baums der 'VMs und Vorlagen'-Ansicht in VSPhere. Dabei achtet +VSPhere auf Groß- und Kleinschreibung, also sind `Pixelpark` und `pixelpark` zwei unterschiedliche Ordner. + +Empfohlen wird auf oberster Ebene der Kunde als Ordnername, und darunter bei kleineren Kunden das Tier (z.Bsp. +`live`, `test` und `dev`) als zweite Ebene, bei größeren Kunden sollte noch das Projekt als zweite Ebene +dazwischen geschoben werden. Damit ergeben sich bei kleineren Kunden Ordnernamen wie `Mubea/live`, und bei +größeren Kunden zum Beispiel `Pixelpark/DNS/test`. + +Wenn der Ordner in VSphere nicht existieren sollte, wird er vom Create-Script angelegt. Die Ordner werden +nicht als Terraform-Resourcen behandelt, das heißt, wenn nach dem Wegwerfen von VMs mittels Terraform der +Ordner leer ist, wird er von Terraform nicht weggeräumt. +Das obliegt dann dem Admin, der die VMs weggeräumt hat, manuell. + +##### num\_cpus + +Die Anzahl der CPUs der VM als Integer-Zahl. Der Einfachheit halber ist damit grundsätzlich die +Anzahl der CPUs mit jeweils einem Core gemeint. + +Wer Spielereien wie 'X CPUs mit Y Cores' unbedingt und dringend benötigt, richtet die VM erst mal nach +obigem Schema ein und konfiguriert diese anschließend manuell in VSPhere. + +Bislang hat sich mir derlei Notwendigkeit aber noch nicht dargestellt. + +##### memory + +Die Größe des Haupspeichers der VM. Wenn keine Einheit angegeben wurde, werden MiByte (also 2^20 Bytes) +angenommen. Man kann aber auch eine Float- oder Integerzahl zusammen mit einer Maßeinheit wie GiB oder TiB +angeben. + +Zu beachten ist, dass der resultierende Haupspeicher mindestens 256 MiB groß sein sowie ein Vielfaches +von 256 MiB sein muss. SI-konforme Einheiten werden hier nicht beachtet, das heißt beispielsweise, dass +1 GB identisch mit 1 GiB ist, also 2^30 Bytes, und nicht 10^9 entspricht. Im Normalfall verwendet man aber +ein Vielfaches von 1 GiB als Hauptspeicher. + +##### boot\_delay + +Die Verweildauer im POST nach dem Einschalten als Float-Zahl in Sekunden. In diesem Zeitraum kann +in der VM-Konsole in VSPhere zum Beispiel das Boot-Menü aufgerufen werden, um die VM beispiesweise vom Netz oder +einer verbundenen Live-CD zu booten, oder um die BIOS-Einstellungen zu gelangen. + +Wenn man unbedingt das VSPhere-Standard-Verhalten haben möchte (sofortiger Boot ohne Warten), stellt man den +Wert auf '**0**'. In diesem Fall kann man aber auch keine Tasten für BIOS usw. drücken. + +Der Standardwert, wenn er nicht gesetzt wird, beträgt 5 Sekunden. + +##### datastore\_cluster + +Welcher Datenstore-Cluster soll für alle Disks der VM verwendet werden? Ene Angabe an dieser +Stelle hat Vorrang vor *datastore_type*. + +Man muss allerdings beachten, dass zum Zeitpunkt des Schreibens dieser Dokumentation (2021-09-15) im live-VSPhere +nur Datenstore-Cluster mit SATA-Platten verfügbar waren. Es macht demzufolge keinen Sinn, hier etwas anzugeben, +wenn man SSD-Storage benötigt. + +Der Standard-Wert für diesen Eintrag ist **'~'** - also nicht angegeben. + +##### datastore\_type + +Auf welchem Typ Storage sollen die Disks der VM angelegt werden, wenn kein Datenstore-Cluster +angegeben wurde. Mögliche Angaben sind **ssd**, **sas** und **sata**, wobei letzteres die Vorgabe ist, wenn hier +nichts angegeben wird. + +Kriterium für die Auswahl eines Datastores ist es, ob der angegebene String im Namen des Datastores auftaucht +und genügend Platz für alle Disks aufweist. Lokale Datastores und solche auf NFS werden nicht berücksichtigt. +Wenn bei einem Typ kein Datastore gefunden wird, wird die Suche auf andere Typen ausgedehnt, wobei +ausgehend von der Angabe in folgender Reihenfolge gesucht wird: **\*** *sata* -> *sas* -> *ssd* @@ -423,7 +461,9 @@ Die nachfolgenden Parameter können pro defaults-Abschnitt und pro VM vergeben w **\*** *ssd* -> *sas* -> *sata* - +Vorgesehen ist, vorher eine ähnliche Suche über alle Datenstore-Cluster zu machen, wenn keiner angegeben +wurde, und erst danach, wenn kein entsprechender Datenstore-Cluster gefunden wurde, die Suche auf +Datastores auszudehnen. ## 3. FeatureRequests -- 2.39.5