From c3a0edf46e03385aa22c5a462f9bf57ebf869bdb Mon Sep 17 00:00:00 2001 From: Elisabeth Anzer Date: Thu, 30 Jun 2022 09:26:56 +0000 Subject: [PATCH 1/3] language editing in German optimist Tutorial version --- docs/_optimist/guided_tour/index.de.md | 5 +- docs/_optimist/guided_tour/step01/index.de.md | 67 +++--- docs/_optimist/guided_tour/step02/index.de.md | 36 ++-- docs/_optimist/guided_tour/step03/index.de.md | 69 +++---- docs/_optimist/guided_tour/step04/index.de.md | 148 ++++++-------- docs/_optimist/guided_tour/step05/index.de.md | 78 ++++--- docs/_optimist/guided_tour/step06/index.de.md | 63 +++--- docs/_optimist/guided_tour/step07/index.de.md | 71 +++---- docs/_optimist/guided_tour/step07/index.en.md | 3 +- docs/_optimist/guided_tour/step08/index.de.md | 50 ++--- docs/_optimist/guided_tour/step09/index.de.md | 46 ++--- docs/_optimist/guided_tour/step10/index.de.md | 55 ++--- docs/_optimist/guided_tour/step11/index.de.md | 119 +++++------ docs/_optimist/guided_tour/step12/index.de.md | 46 ++--- docs/_optimist/guided_tour/step13/index.de.md | 73 +++---- docs/_optimist/guided_tour/step14/index.de.md | 193 ++++++------------ docs/_optimist/guided_tour/step15/index.de.md | 46 ++--- docs/_optimist/guided_tour/step16/index.de.md | 55 ++--- docs/_optimist/guided_tour/step17/index.de.md | 82 +++----- docs/_optimist/guided_tour/step18/index.de.md | 57 +++--- docs/_optimist/guided_tour/step19/index.de.md | 42 ++-- docs/_optimist/guided_tour/step20/index.de.md | 63 ++---- docs/_optimist/guided_tour/step21/index.de.md | 115 +++++------ docs/_optimist/guided_tour/step22/index.de.md | 36 ++-- docs/_optimist/guided_tour/step23/index.de.md | 62 +++--- 25 files changed, 669 insertions(+), 1011 deletions(-) diff --git a/docs/_optimist/guided_tour/index.de.md b/docs/_optimist/guided_tour/index.de.md index 94741f813..edbf3ed94 100644 --- a/docs/_optimist/guided_tour/index.de.md +++ b/docs/_optimist/guided_tour/index.de.md @@ -6,7 +6,6 @@ nav_order: 1000 has_children: true --- -Guided Tour -------------- +# Guided Tour -Aus dem Browser zum eigenen Stack per Heat +Vom Browser zum eigenen Stack mit Heat diff --git a/docs/_optimist/guided_tour/step01/index.de.md b/docs/_optimist/guided_tour/step01/index.de.md index 96a5ae809..dea23f2aa 100644 --- a/docs/_optimist/guided_tour/step01/index.de.md +++ b/docs/_optimist/guided_tour/step01/index.de.md @@ -1,69 +1,60 @@ --- -title: "01: Das Dashboard (Horizon)" +title: "01: Das Horizon Dashboard" lang: "de" permalink: /optimist/guided_tour/step01/ nav_order: 1010 parent: Guided Tour --- -Schritt 1: Das Dashboard (Horizon) -=================================================================== -Vorwort -------- +# Schritt 1: Das Horizon Dashboard -In diesem Schritt für Schritt Tutorial werden wir uns schrittweise der -Bedienung von Openstack widmen. +## Einführung -Den Anfang macht das Horizon(Dashboard), nach einer kleinen Einführung, -wird dann auf die Konsole gewechselt und der Abschluss bildet die -Erstellung eigener Heat-Templates. +In diesem Schritt-für-Schritt Tutorial lernen wir OpenStack zu bedienen. -Login ------ +Sie starten mit dem Horizon Dashboard, wechseln nach einer kurzen Einführung auf die Konsole und erstellen abschließend Ihre eigenen Heat-Templates. -Nachdem die Zugangsdaten vorliegen, ist der erste Schritt der Login. +## Login -**WICHTIG:** Es gibt keinen Reset-Knopf für das Passwort. Für -ein neues Passwort, schreiben Sie uns bitte eine E-Mail -an . +Nachdem Sie Ihre Zugangsdaten erhalten haben, können Sie sich mit Ihrem Benutzername und Passwort anmelden. + +Geben Sie dazu im Browser folgende URL ein: -Hierzu wechseln wir im Browser auf folgende -URL:  +**WICHTIG:** Es gibt keinen Reset-Knopf für das Passwort. Falls Sie +ein neues Passwort benötigen, schreiben Sie eine E-Mail +an . [![](attachments/13536092.png)](https://dashboard.optimist.innovo.cloud/) -Im sich öffnenden Fenster wählen wir bei Domain *default*, und tragen den -zugesendeten Benutzer (User-Name) sowie das zugehörige Passwort(Password) ein -und klicken auf *Connect*. +Im sich öffnenden Browserfenster wählen Sie bei Domain *Default*, und tragen den +zugesendeten Benutzernamen (User-Name) und das Passwort (Password) ein. +Klicken Sie anschließend auf *Connect*. -Nun öffnet sich das Horizon(Dashboard). +Nun öffnet sich das Horizon Dashboard. ![](attachments/13536090.png) -Passwort ändern ---------------- +## Passwort ändern -Da aus Sicherheitsgründen empfohlen wird das Passwort nach Erhalt zu -ändern, klicken wir im Horizon(Dashboard) dafür rechts oben auf den -Benutzernamen(1) und auf *Settings*(2). +Aus Sicherheitsgründen empfehlen wir, das Passwort nach Erhalt zu +ändern. Klicken Sie dazu im Dashboard rechts oben auf den +Benutzernamen (1) und anschließend auf *Settings* (2). ![](attachments/13536091.png) -Im sich nun öffnenden Fenster sehen wir zuerst Settings, wo unter -anderem auch die Sprache umgestellt werden kann. +Im sich öffnenden Fenster sehen Sie zuerst die *Settings*, wo Sie unter +anderem auch die Sprache umstellen können. -Um das Passwort zu ändern, klicken wir rechts auf *Change Password*(1). -Hier können nun das Passwort geändert werden. Dafür geben wir zunächst -unser bisheriges Passwort ein(2), geben dann das neue an(3) und -bestätigen es in der neuen Zeile (4). +Um das Passwort zu ändern, klicken Sie rechts auf *Change Password* (1). +Geben Sie zunächst +Ihr bisheriges Passwort ein (2) und anschließend das neue (3). Bestätigen Sie Ihr neues Passwort (4). -Damit das neue Passwort auch übernommen wird, fehlt noch ein Klick auf -*Change*(5). +Damit das neue Passwort übernommen wird, klicken Sie auf +*Change* (5). ![](attachments/13536097.png) -Abschluss ---------- +## Zusammenfassung -Sie haben Ihre ersten Schritte im Dashboard ausgeführt und Ihr Passwort geändert! +Sie haben Ihre ersten Schritte im Horizon Dashboard ausgeführt und Ihr Passwort geändert. diff --git a/docs/_optimist/guided_tour/step02/index.de.md b/docs/_optimist/guided_tour/step02/index.de.md index ec3cb9240..9ddfdd89a 100644 --- a/docs/_optimist/guided_tour/step02/index.de.md +++ b/docs/_optimist/guided_tour/step02/index.de.md @@ -1,46 +1,36 @@ --- -title: "02: SSH-Key per Horizon anlegen" +title: "02: SSH-Key mit Horizon anlegen" lang: "de" permalink: /optimist/guided_tour/step02/ nav_order: 1020 parent: Guided Tour --- -Schritt 2: SSH-Key per Horizon anlegen -====================================== +# Schritt 2: SSH-Key mit Horizon anlegen -Vorwort -------- +## Einführung -Um im nächsten Schritt einen Stack inkl. einer Instanz zu starten, wird -ein SSH Keypair (Schlüsselpaar) benötigt. +Damit Sie im nächsten Kapitel einen Stack inkl. einer Instanz starten können, benötigen Sie ein SSH Keypair (Schlüsselpaar). -Für den Fall, dass bereits ein Keypair vorhanden ist und der Umgang damit -bekannt ist, kann dieser Schritt übersprungen werden. +Für den Fall, dass Sie bereits ein Keypair haben und Ihnen der Umgang damit vertraut ist, können Sie diesen Schritt überspringen und mit [Schritt 3](/optimist/guided_tour/step03/) weitermachen. -Installation ------------- +## Installation Es gibt verschiedene Wege, um ein Keypair zu erzeugen. -Einer der späteren Schritte erklärt den Weg zu einem selbst erstellten -Keypair. Hier wird der Schlüssel direkt im Horizon(Dashboard) erstellt, -um im nächsten Schritt den Stack zu erstellen. +Ein anderes Kapitel in dem Tutorial zeigt Ihnen, wie Sie ein Keypair selbst erstellen +können. In diesem Kapitel hier wird der Schlüssel im Horizon (Dashboard) erstellt. Sie können damit im nächsten Schritt den Stack erstellen. -Um nun den Schlüssel zu erstellen, wechseln wir im Horizon(Dashboard) in -der Navigation auf *Compute* → *Key Pairs* und klicken dort auf *Create +Um den Schlüssel zu erstellen, wechseln Sie im Horizon Dashboard im +Navigationsmenü auf *Compute* → *Key Pairs* und klicken auf *Create Key Pair*. ![](attachments/13536100.png) -Im sich öffnenden Fenster kann nun ein Name für den Key vergeben werden, -in dem Beispiel wird *BeispielKey* verwendet, anschließend klicken wir -auf *Create Key Pair*. +Im sich öffnenden Fenster können Sie einen Namen für den Key vergeben. In unserem Beispiel verwenden wir *BeispielKey*. Klicken Sie anschließend auf *Create Key Pair*. ![](attachments/13536101.png) -Abschluss ---------- +## Zusammenfassung -Wir haben jetzt unser SSH Keypair erstellt und sind bereit für den Rest des -Tutorials! +Sie haben Ihr SSH Keypair erstellt und können nun mit dem nächsten Schritt fortfahren. diff --git a/docs/_optimist/guided_tour/step03/index.de.md b/docs/_optimist/guided_tour/step03/index.de.md index 9ead53fec..630903bb2 100644 --- a/docs/_optimist/guided_tour/step03/index.de.md +++ b/docs/_optimist/guided_tour/step03/index.de.md @@ -6,49 +6,42 @@ nav_order: 1030 parent: Guided Tour --- -Schritt 3: Einen Stack starten -============================== +# Schritt 3: Einen Stack starten -Vorwort -------- +## Einführung -In diesem Schritt beschäftigen wir uns damit, im Horizon Dashboard -einen Stack zu starten und damit auch das Horizon Dashboard besser -kennenzulernen. +In diesem Schritt lernen Sie, im Horizon Dashboard +einen Stack zu starten. -Wichtige Voraussetzung ist an dieser Stelle ein SSH-Key, den wir in -Schritt 2 erzeugt haben. +Wichtige Voraussetzung ist an dieser Stelle ein SSH-Key, den Sie in +[Schritt 2](/optimist/guided_tour/step02/) erzeugt haben. -Start ------ +## Start -Um einen Stack zu starten, loggen wir uns zunächst im Horizon Dashboard -mit denen in [Schritt 1](schritt01.md) geänderten Zugangsdaten ein. +Um einen Stack zu starten, melden Sie sich zunächst im Horizon Dashboard +mit den in [Schritt 1](/optimist/guided_tour/step01/) geänderten Zugangsdaten ein. -Hier navigieren wir über *Orchestration* zu *Stacks* und klicken auf *Launch -Stack*. +Navigieren Sie über *Orchestration* zu *Stacks* und klicken Sie anschließend auf *Launch Stack*. -Um den Stack auch zu starten, benötigen wir zunächst ein Template, -welches in dem Stack eine Instanz startet. +Um den Stack zu starten, benötigen Sie zunächst ein Template, +das in dem Stack eine Instanz startet. -Hierfür nutzen wir die [SingleServer.yaml](https://github.com/gecio/openstack_examples/blob/master/heat/templates/SingleServer/SingleServer.yaml) aus dem [GECio Github Repository](https://github.com/gecio/). +Nutzen Sie dazu die [SingleServer.yaml](https://github.com/gecio/openstack_examples/blob/master/heat/templates/SingleServer/SingleServer.yaml) Datei aus dem [GECio Github Repository](https://github.com/gecio/). ![](attachments/13536111.png) -In dem sich nun öffnenden Fenster, wählen wir bei *Template Source* -**File** aus und nehmen bei *Template File*, die eben heruntergeladene -`SingleServer.yaml`. +In dem sich nun öffnenden Fenster, wählen Sie bei *Template Source* +**File** aus und verwenden Sie bei *Template File*, die zuvor heruntergeladene `SingleServer.yaml` Datei. -Den Rest belassen wir so wie es ist und klicken auf *Next*. +Belassen Sie den Rest unverändert und klicken Sie auf *Next*. ![](attachments/13536112.png) -Nun werden weitere Eingaben benötigt, genauer sind das folgende und am -Ende klicken wir auf Launch: +Machen Sie nun folgende Eingaben und klicken Sie anschließend auf *Launch*: - Stack Name: BeispielServer - Creation Timeout: 60 -- Password for User: Bitte das eigene Passwort eintragen +- Password for User: Tragen Sie hier Ihr eigenes Passwort ein - availability\_zone: ix1 - flavor\_name: m1.micro - key\_name: BeispielKey @@ -57,32 +50,30 @@ Ende klicken wir auf Launch: ![](attachments/13536113.png) -Nun wird der Stack auch direkt gestartet und das Horizon Dashboard +Nun wird der Stack direkt gestartet und das Horizon Dashboard sieht dann so aus: ![](attachments/13536114.png) -Um nun zu überprüfen ob die Instanz korrekt gestartet wurde, wechseln -wir in der Navigation auf *Compute* → *Instances* und die Übersicht sieht -dann wie folgt aus: +Um zu überprüfen, ob die Instanz korrekt gestartet wurde, wechseln Sie im Navigationsmenü zu *Compute* → *Instances*. + +Die Übersicht sieht wie folgt aus: ![](attachments/13536115.png) -Nachdem nun also der Stack und auch die darin enthaltene Instanz -gestartet wurden, löschen wir jetzt wieder den Stack inklusive Instanz. +Nachdem nun der Stack und die darin enthaltene Instanz +gestartet wurden, löschen Sie jetzt wieder den Stack inklusive der Instanz. -Wir könnten auch die Instanz alleine löschen, das kann aber im Nachgang -zu Problemen beim löschen des Stacks führen. +Sie könnten auch die Instanz alleine löschen, das kann aber im Nachgang +zu Problemen beim Löschen des Stacks führen. -Um den Stack zu löschen, wechseln wir in der Navigation wieder auf +Um den Stack zu löschen, wechseln Sie im Navigationsmenü wieder zu *Orchestration* → *Stacks*. -Klicken hinter dem Stack, unter *Actions*, auf den Pfeil nach unten und -wählen dort *Delete Stack*. +Klicken Sie im Fenster rechts unter *Actions* auf den Pfeil nach unten und wählen dort *Delete Stack*. ![](attachments/13536116.png) -Abschluss ---------- +## Zusammenfassung -Wir haben unseren ersten Stack erstellt ... und ihn dann gelöscht! +Sie haben Ihren ersten Stack erstellt und anschließend wieder gelöscht. diff --git a/docs/_optimist/guided_tour/step04/index.de.md b/docs/_optimist/guided_tour/step04/index.de.md index 16417b33f..1ad60b784 100644 --- a/docs/_optimist/guided_tour/step04/index.de.md +++ b/docs/_optimist/guided_tour/step04/index.de.md @@ -1,63 +1,54 @@ --- -title: "04: Der Weg vom Horizon auf die Kommandozeile" +title: "04: Der Weg vom Horizon Dashboard zur Kommandozeile" lang: "de" permalink: /optimist/guided_tour/step04/ nav_order: 1040 parent: Guided Tour --- -# Schritt 4: Der Weg vom Horizon auf die Kommandozeile +# Schritt 4: Der Weg vom Horizon Dashboard zur Kommandozeile -## Vorwort +## Einführung -Auf den ersten Blick kann es komfortabel erscheinen, seine OpenStack +Auf den ersten Blick mag es komfortabel erscheinen, die OpenStack Umgebung mit dem Horizon Dashboard zu verwalten. -Für einfache, nicht wiederkehrende Aufgaben, kann das Horizon Dashboard -mit seinen grafische Ansichten wirklich hilfreich sein. +Für einfache, nicht wiederkehrende Aufgaben, ist das Horizon Dashboard mit seinen grafischen Ansichten sehr hilfreich. -Sobald Aufgaben regelmäßig wiederholt werden oder ein komplexerer Stack -verwaltet werden soll, ist es sinnvoller, den OpenStack Client und auch -Heat(welches in den späteren Schritten mit erklärt wird) zu verwenden. +Für sich regelmäßig wiederholende Aufgaben oder für die Verwaltung eines komplexeren Stacks, ist es jedoch sinnvoller, den OpenStack Client und auch Heat (welches in einem späteren Schritt erklärt wird) zu verwenden. -Anfangs mag die Handhabung ungewohnt sein, mit ein wenig Übung kann die -Arbeit an den eigenen Stacks schnell und effizient erledigt werden. +Anfangs mag die Handhabung mit OpenStack ungewohnt sein. Mit ein wenig Übung kann die Arbeit an den eigenen Stacks jedoch schnell und effizient erledigt werden. Der OpenStack Client ist sehr hilfreich bei der Administration der OpenStack Umgebung, da dort bereits Komponenten wie Nova, Glance, Heat, -Cinder, Neutron enthalten sind. +Cinder, und Neutron enthalten sind. -Da wir auch im weiteren Verlauf der Dokumentation den Client nutzen, -installieren wir ihn in diesem Schritt. +Da wir auch im weiteren Verlauf des Tutorials den Client nutzen, +installieren wir ihn in diesem Kapitel. ## Installation -Um den OpenStackClient installieren zu können, wird mindestens [Python -2.7](https://www.python.org/downloads/release/python-2713/) noch die [Python +Um den OpenStackClient zu installieren, benötigen Sie mindestens [Python +2.7](https://www.python.org/downloads/release/python-2713/) und die [Python Setuptools](https://pypi.python.org/pypi/setuptools) (diese sind bei macOS bereits vorinstalliert). -Es gibt verschiedene Optionen die Installation durchzuführen, `pip` hat -sich hierbei als eine gute Lösung herausgestellt und wird als Grundlage -in der Dokumentation verwendet. +Es gibt verschiedene Optionen, die Installation durchzuführen; `pip` hat +sich hierbei als eine gute Lösung erwiesen und wird als Grundlage +in dieser Dokumentation verwendet. -Selbiges ist einfach zu bedienen, stellt sicher das die aktuellste -Version der Pakete genutzt wird und kann im Nachhinein Updates -einspielen. +`pip` ist einfach zu bedienen und stellt sicher, dass die aktuellste +Version der Pakete genutzt wird. Sie können damit auch im Nachhinein Updates einspielen. -Man kann den Client ohne weiteres in root/admin installieren, das kann -aber zu weiteren Problem führen, daher nutzen wir eine virtuelle -Umgebung für den Clienten. +Sie können den Client als root/admin installieren, was aber zu weiteren Problem führen kann. Daher nutzen wir für den Client eine virtuelle +Umgebung. ### macOS -Damit nun der [OpenStack -Client](https://docs.openstack.org/python-openstackclient/latest/) installieren werden -kann, wird zunächst `pip` benötigt. +Damit der [OpenStack +Client](https://docs.openstack.org/python-openstackclient/latest/) installiert werden kann, installieren Sie zunächst `pip`. -Um `pip` zu installieren, wird zunächst die Konsole geöffnet (diese kann -zum Beispiel über das Launchpad → Konsole geöffnet werden)  und dann -folgender Befehl ausgeführt: +Öffnen Sie dazu die Konsole (zum Beispiel über *Launchpad → Konsole*) und führen Sie den folgenden Befehl aus: ```bash $ easy_install pip @@ -73,8 +64,8 @@ Processing dependencies for pip Finished processing dependencies for pip ``` -Sobald die Installation von `pip` abgeschlossen ist, wird nun die -Virtuelle Umgebung angelegt: +Sobald die Installation von `pip` abgeschlossen ist, legen Sie die +virtuelle Umgebung an: ```bash $ pip install virtualenv @@ -85,8 +76,8 @@ Installing collected packages: virtualenv Successfully installed virtualenv-15.1.0 ``` -Nachdem wir nun mit `virtualenv` eine virtuelle Umgebung nutzen können, -erstellen wir direkt eine: +Nachdem Sie nun mit `virtualenv` eine virtuelle Umgebung nutzen können, +erstellen Sie direkt eine solche Umgebung: ```bash $ virtualenv ~/.virtualenvs/openstack @@ -94,41 +85,38 @@ New python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/python Installing setuptools, pip, wheel...done. ``` -Jetzt wechseln wir in die erzeugte virtuelle Umgebung: +Wechseln Sie jetzt in die erzeugte virtuelle Umgebung: ```bash $ source ~/.virtualenvs/openstack/bin/activate (openstack) $ ``` -Nachdem dieser Wechsel funktioniert hat, können wir in der geschaffenen -Umgebung auch direkt den OpenStackClient installieren: +Anschließend können Sie in der Umgebung direkt den OpenStackClient installieren: ```bash (openstack) $ pip install python-openstackclient ``` -Da wir im Verlauf der Dokumentation auch andere Services benutzen, installieren wir -die entsprechenden Clienten gleich mit: +Da im Verlauf des Tutorials auch andere Services benutzt werden, installieren wir die entsprechenden Klienten gleich mit: ```bash (openstack) $ pip install python-heatclient python-designateclient python-octaviaclient ``` -Nun verlassen wir die Umgebung auch direkt wieder: +Verlassen Sie nun die Umgebung wieder: ```bash (openstack) $ deactivate ``` -Damit wir den OpenStackClient auch nutzen können, ist es nun notwendig -dies in die Path Variablen aufzunehmen. +Damit Sie den OpenStackClient nutzen können, müssen Sie diesen in die Path Variable aufnehmen: ```bash export PATH="$HOME/.virtualenvs/openstack/bin/:$PATH" ``` -Um zu sehen ob alles korrekt funktioniert hat, testen wir die Ausgabe: +Um zu sehen, ob alles korrekt funktioniert hat, testen Sie die Ausgabe: ```bash $ type -a openstack @@ -137,11 +125,9 @@ openstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack ### Windows -Um pip zu nutzen, ist zuerst der Wechsel in den Ordner der Python -Installation notwendig (Speicherort der Standart Installation: -`C:\Python27\Scripts`). +Um `pip` nutzen zu können, müssen Sie zuerst in den Installationsordner von Python wechseln (Standard-Ordner: `C:\Python27\Scripts`). -`pip` wird dann mit dem Befehl `easy_install pip` installiert: +Um `pip` zu installieren, benutzen Sie den Befehl `easy_install pip`: ```text C:\Python27\Scripts>easy_install pip @@ -164,9 +150,8 @@ Processing dependencies for pip Finished processing dependencies for pip ``` -Nach der erfolgreichen Installation von `pip`, kann direkt mit pip -install `python-openstackclient` der OpenStackClient auch installiert -werden: +Nach der erfolgreichen Installation von `pip`, können Sie mit `pip +install python-openstackclient` den OpenStackClient installieren: ```text C:\Python27\Scripts>pip install python-openstackclient @@ -177,7 +162,7 @@ Collecting python-openstackclient ### Linux (in diesem Beispiel Ubuntu) -Zunächst wird auch hier `pip` benötigt, dafür wird `apt-get` genutzt: +Zunächst wird auch hier `pip` benötigt. Wir nutzen dafür `apt-get`: ```bash $ sudo apt-get install python3-pip @@ -186,8 +171,8 @@ Building dependency tree Reading state information... Done ``` -Sobald die Installation von `pip` abgeschlossen ist, wird nun die -Virtuelle Umgebung angelegt: +Sobald die Installation von `pip` abgeschlossen ist, legen Sie die +Virtuelle Umgebung an: ```bash $ sudo apt-get install python3-virtualenv @@ -196,8 +181,8 @@ Building dependency tree Reading state information... Done ``` -Nachdem wir nun mit `virtualenv` eine virtuelle Umgebung nutzen können, -erstellen wir direkt eine: +Nachdem Sie nun mit `virtualenv` eine virtuelle Umgebung nutzen können, +erstellen Sie direkt eine solche Umgebung: ```bash $ virtualenv ~/.virtualenvs/openstack @@ -205,41 +190,39 @@ New python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/python Installing setuptools, pip, wheel...done. ``` -Jetzt wechseln wir in die erzeugte virtuelle Umgebung: +Wechseln Sie jetzt in die erzeugte virtuelle Umgebung: ```bash $ source ~/.virtualenvs/openstack/bin/activate (openstack) $ ``` -Nachdem dieser Wechsel funktioniert hat, können wir in der geschaffenen -Umgebung auch direkt den OpenStackClient installieren: +Anschließend können Sie in der Umgebung direkt den OpenStackClient installieren: ```bash (openstack) $ pip install python-openstackclient ``` Da wir im Verlauf der Dokumentation auch Heat benutzen, installieren wir -den entsprechenden Heat Clienten gleich mit: +den entsprechenden Heat Client gleich mit: ```bash (openstack) $ pip install python-heatclient ``` -Nun verlassen wir die Umgebung auch direkt wieder: +Verlassen Sie die Umgebung wieder: ```bash (openstack) $ deactivate ``` -Damit wir den OpenStackClient auch nutzen können, ist es nun notwendig -dies in die Path Variablen aufzunehmen. +Damit Sie den OpenStackClient nutzen können, müssen Sie diesen in die Path Variable aufnehmen: ```bash export PATH="$HOME/.virtualenvs/openstack/bin/:$PATH" ``` -Um zu sehen ob alles korrekt funktioniert hat, testen wir die Ausgabe: +Um zu sehen ob alles korrekt funktioniert hat, testen Sie die Ausgabe: ```bash $ type -a openstack @@ -248,20 +231,17 @@ openstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack ## Zugangsdaten -Nachdem der OpenStackClient nun installiert ist, werden noch die -Zugangsdaten für Openstack benötigt. +Nachdem der OpenStackClient installiert ist, benötigen Sie noch die +Zugangsdaten für Openstack. -Diese können direkt im [Horizon -Dashboard](https://dashboard.optimist.innovo.cloud/identity/) heruntergeladen -werden. Dafür loggen wir uns ein und klicken dann rechts oben in der Ecke auf -die E-Mail-Adresse und dann auf *Download OpenStack RC File v3*. -Die heruntergeladene Datei trägt den Projektnamen (Projektname.sh), -in unserem Beispiel nennen wir sie Beispiel.sh +Sie können diese direkt im [Horizon +Dashboard](https://dashboard.optimist.innovo.cloud/identity/) herunterladenn. Loggen Sie sich dazu ein und klicken Sie rechts oben auf die E-Mail-Adresse. Klicken Sie anschließend auf *Download OpenStack RC File v3*. +Die heruntergeladene Datei trägt den Projektnamen (Projektname.sh). In unserem Beispiel nennen wir sie `Beispiel.sh`. ### macOS | Linux -Um die Zugangsdaten in den OpenStackClienten einzulesen, führen wir -nun folgenden Befehl aus: +Um die Zugangsdaten in den OpenStackClienten einzulesen, führen Sie +den folgenden Befehl aus: ```bash source Beispiel.sh @@ -269,20 +249,18 @@ source Beispiel.sh ### Windows -Um unter Windows die Zugangsdaten einzulesen, ist es notwendig entweder -*PowerShell*, *Git for Windows* oder [*Linux on Windows*](https://docs.microsoft.com/en-us/windows/wsl/install-win10) zu nutzen. +Um in Windows die Zugangsdaten einzulesen, müssen Sie entweder +*PowerShell*, *Git for Windows* oder [*Linux on Windows*](https://docs.microsoft.com/en-us/windows/wsl/install-win10) nutzen. -Bei *Linux on Windows* und *Git for Windows* via *Git Bash*, wird der gleiche Befehl wie im Beispiel für -macOS | Linux genutzt: +Bei *Linux on Windows* und *Git for Windows* mithilfe von *Git Bash*, wird der gleiche Befehl wie im Beispiel für macOS | Linux genutzt: ```bash source Beispiel.sh ``` Bei der Nutzung von *PowerShell* müssen die Variablen einzeln gesetzt werden. -Alle notwendigen Variablen befinden sich in der Datei Beispiel.sh und diese kann -mit einem Editor geöffnet werden. -Um die Variablen zu setzen, kann folgender Befehl genutzt werden: +Sie finden alle notwendigen Variablen in der Datei `Beispiel.sh`. Sie können die Datei mit einem Editor öffnen. +Um die Variablen zu setzen, können Sie den folgenden Befehl benutzen: ```bash set-item env:OS_AUTH_URL -value "https://identity.optimist.innovo.cloud/v3" @@ -297,13 +275,11 @@ set-item env:OS_INTERFACE -value "public" set-item env:OS_IDENTITY_API_VERSION -value "3" ``` -## Ziel +## Zusammenfassung -Die Installation des OpenStackClienten ist abgeschlossen und die ersten -Befehle können damit getestet werden. +Die Installation des OpenStackClienten ist nun abgeschlossen und Sie können die ersten Befehle damit testen. -Eine Übersicht über alle Befehle, kann mit folgendem Kommando abgerufen -werden: +Sie erhalten eine Übersicht über sämtliche Befehle mit dem folgendem Kommando: ```bash openstack --help diff --git a/docs/_optimist/guided_tour/step05/index.de.md b/docs/_optimist/guided_tour/step05/index.de.md index 9f79c9b25..ed51269d7 100644 --- a/docs/_optimist/guided_tour/step05/index.de.md +++ b/docs/_optimist/guided_tour/step05/index.de.md @@ -8,16 +8,15 @@ parent: Guided Tour # Schritt 5: Die wichtigsten Befehle des OpenStackClients -## Vorwort +## Einführung -Nachdem in Schritt 4 der OpenStack Client installiert wurde, -werden wir in diesem Schritt alle wichtigen Befehle einmal auflisten. +Nachdem in [Schritt 4](/optimist/guided_tour/step4/) der OpenStack Client installiert wurde, lernen Sie in diesem Schritt alle wichtigen OpenStack fehle kennen. Die Übersicht der spezifischen Subbefehle kann in der Kommandozeile mit einem `--help` hinter dem eigentlichen Befehl separat angezeigt werden. Um alle Befehle aufzulisten, kann der Schalter `--help` auch ohne -weitere Angaben von einem Bestandteil  verwendet +weitere Angaben von einem Bestandteil verwendet werden: ```bash @@ -26,24 +25,24 @@ openstack --help ## Server -Mit dem Kommando `openstack server` ist es mögliche eigene Instanz -zu erstellen, diese zu verwalten, zu löschen und -andere} administrative Aufgaben durchzuführen. +Mit dem Kommando `openstack server` können eigene Instanz +erstellt, verwaltet, gelöscht und +andere administrative Aufgaben durchgeführt werden. -Hier eine Liste der wichtigsten Kommandos:} +Hier ist eine Liste der wichtigsten Befehle: - `openstack server add` - Einer bestehenden Instanz können verschiedene Bestandteile (Fixed IP, Floating IP, Security - Group, Volume) zugewiesen werden + Weist einer bestehenden Instanz verschiedene Bestandteile zu (Fixed IP, Floating IP, Security + Group, Volume) - `openstack server create` - Mit diesem Befehl kann eine neue Instanz erstellt werden + Erstellt eine neue Instanz - `openstack server delete` Löscht die im Befehl angegebene Instanz - `openstack server list` Listet alle bestehenden Instanzen auf - `openstack server remove` - Kann verschiedene Bestandteile (Fixed IP, Floating IP, Security - Group, Volume) wieder entfernen + Entfernt verschiedene Bestandteile (Fixed IP, Floating IP, Security + Group, Volume) - `openstack server show` Zeigt alle verfügbaren Informationen zu der im Befehl genannten Instanz an @@ -51,13 +50,13 @@ Hier eine Liste der wichtigsten Kommandos:} ## Stack (Heat) Genauso wie mit `openstack server ...` Befehlen einzelne Instanzen -administriert werden, kann man mit `openstack stack ...` ganze -Stacks verwalten. +administriert werden, können mit `openstack stack ...` ganze +Stacks verwaltet werden. -Auch hier eine kurze Auflistung der wichtigsten Befehle: +Hier ist eine Liste der wichtigsten Befehle: - `openstack stack create` - Kann einen neuen Stack erstellen + Erstellt einen neuen Stack - `openstack stack list` Listet alle bestehenden Stacks auf - `openstack stack show` @@ -71,8 +70,9 @@ Security Groups werden verwendet, um Instanzen eingehende und ausgehende Netzwerk-Verbindungen basierend auf IP-Adressen und Ports zu erlauben oder zu verbieten. -Auch Security Groups kann man mit dem OpenStackClienten verwalten. Hier -eine beispielhafte Liste üblicher Aufrufe: +Security Groups können ebenfalls mit dem OpenStackClient verwaltet werden. + +Hier ist eine Liste wichtiger Befehle: - `openstack security group create` Erstellt eine neue Security Group @@ -90,8 +90,8 @@ eine beispielhafte Liste üblicher Aufrufe: ## Network -Um später auch Instanzen sinnvoll nutzen zu können, benötigen diesen ein -Netzwerk, hier eine kurze Auflistung der wichtigsten Befehle um ein +Um später auch Instanzen sinnvoll nutzen zu können, benötigen diese ein +Netzwerk. Hier ist eine Liste der wichtigsten Befehle, um ein Netzwerk zu erstellen: - `openstack network create` @@ -105,27 +105,24 @@ Netzwerk zu erstellen: ## Router -Damit eine Instanz mit einem Netzwerk verbunden werden kann, ist ein virtueller -Router notwendig und lässt sich mit diesen Kommando administrieren. +Damit eine Instanz mit einem Netzwerk verbunden werden kann, ist ein virtueller Router notwendig. -Hier eine kurze Liste der möglichen Befehle: +Hier ist eine Liste wichtiger Befehle: - `openstack router create` Erstellt einen neuen Router - `openstack router delete` Löscht einen bestehenden Router - `openstack router add port` - Weist dem angegebenen Router, den angegebenen Port zu + Weist dem angegebenen Router den angegebenen Port zu - `openstack router add subnet` - Weist dem angegeben Router, das angegebene Subnet zu + Weist dem angegeben Router das angegebene Subnet zu ## Subnet -Um den virtuellen Router korrekt zu betreiben, wird auch ein Subnet -benötigt, welches mit dem Kommando `openstack subnet` administriert -werden kann. +Um den virtuellen Router korrekt betreiben zu können, wird auch ein Subnet benötigt, welches mit dem Kommando `openstack subnet` administriert werden kann. -Möglich Befehle sind: +Hier ist eine Liste wichtiger Befehle: - `openstack subnet create` Erstellt ein neues Subnet @@ -137,9 +134,9 @@ Möglich Befehle sind: ## Port Nachdem nun bereits virtuelle Router und Subnets bekannt sind, darf der -Port nicht fehlen. +Port nicht fehlen. Ports verbinden die VMs mit dem Netzwerk. -Die wichtigsten Befehle: +Hier ist eine Liste wichtiger Befehle - `openstack port create` Erstellt einen neuen Port @@ -151,7 +148,9 @@ Die wichtigsten Befehle: ## Volume Volumes sind persistente Speicherorte, die über die Existenz von -einzelnen Instanzen hinaus erhalten bleiben. Wichtige Befehle sind: +einzelnen Instanzen hinaus erhalten bleiben. + +Hier ist eine Liste wichtiger Befehle: - `openstack volume create` Erstellt ein neues Volume @@ -160,13 +159,10 @@ einzelnen Instanzen hinaus erhalten bleiben. Wichtige Befehle sind: - `openstack volume show` Zeigt alle verfügbaren Informationen zu einem Volume an -## Abschluss - -In diesem Schritt wurden die wichtigsten Befehle einmal aufgelistet und -auch mit einer kleinen Erklärung versehen. +## Zusammenfassung -Die genannten Befehle werden in den nächsten Schritten benötigti und -bilden somit die Grundlage für die Guided Tour. +In diesem Schritt sind die wichtigsten OpenStack Befehle aufgelistet und +erklärt. +Die Befehle werden für die nächsten Schritten der Guided Tour benötigt. -In Schritt 6 wird das Thema ein selbst erstelltes SSH Key Pair -sein. +In [Schritt 6](/optimist/guided_tour/step6/) zeigen wir, wie Sie ein SSH Key Pair mit der Kommandokonsole erzeugen und benutzen können. diff --git a/docs/_optimist/guided_tour/step06/index.de.md b/docs/_optimist/guided_tour/step06/index.de.md index 99aaf1de1..e057a49ed 100644 --- a/docs/_optimist/guided_tour/step06/index.de.md +++ b/docs/_optimist/guided_tour/step06/index.de.md @@ -1,33 +1,25 @@ --- -title: "06: Einen eigenen SSH-Key per Konsole erstellen und nutzen" +title: "06: Einen eigenen SSH-Key mit der Kommando-Konsole erstellen und nutzen" lang: "de" permalink: /optimist/guided_tour/step06/ nav_order: 1060 parent: Guided Tour --- -Schritt 6: Einen eigenen SSH-Key per Konsole erstellen und nutzen -================================================================= +# Schritt 6: Einen eigenen SSH-Key mit der Kommando-Konsole erstellen und nutzen -Vorwort -------- +## Einführung -Um später Zugriff auf den ersten deployten Stack per SSH zu erhalten, ist es -notwendig, ein Key Pair zu erzeugen und dieses im Gegensatz zu Schritt -2 auch zu nutzen. +Um später Zugriff auf den ersten deployten Stack über SSH zu erhalten, muss ein Key Pair erzeugt und im Gegensatz zu [Schritt 2](/optimist/guided_tour/step02/) auch verwendet werden. -Sollte bereits ein Keypair vorhanden sein, ist es nicht notwendig einen neuen -zu erstellen. +Falls bereits ein Keypair vorhanden ist, ist es nicht notwendig, einen neuen Key zu erstellen. -Installation ------------- +## Installation -Wie in Schritt 2 erwähnt, gibt es mehrere Optionen um einen Key zu +Wie in Schritt 2 erwähnt, gibt es mehrere Möglichkeiten, einen Key zu erstellen. -Da wir bereits per Horizon(Dashboard) einen Key erzeugt haben, wird in -diesem Schritt er direkt über einen Befehl in der Kommandozeile -erstellt. +Sie haben bereits mit dem Horizon Dashboard einen Key erzeugt. In diesem Schritt lernen Sie, den Key mit dem folgenden Befehl in der Kommandozeile zu erstellen. ```bash $ ssh-keygen -t rsa -f Beispiel.key @@ -52,24 +44,21 @@ The key's randomart image is: +----[SHA256]-----+ ``` -Mit dem oben genutzten Befehl (`ssh-keygen -t rsa -f Beispiel.key`) -werden zwei Dateien erzeugt, also das vorher genannte Keypair. +Mit dem oben genannten Befehl (`ssh-keygen -t rsa -f Beispiel.key`) +werden zwei Dateien (das Keypair) erzeugt, die `Beispiel.key` Datei und die `Beispiel.key.pub` Datei. Dabei ist +`Beispiel.key` der private Teil, der nur Ihnen bekannt und an einem sicheren Ort gespeichert sein soll und +`Beispiel.key.pub`, der als öffentlicher Teil genutzt wird. -Zum einen die `Beispiel.key` Datei und die `Beispiel.key.pub`, dabei ist -`Beispiel.key` der private Teil, der nur uns bekannt sein soll und -`Beispiel.key.pub` wird als öffentlicher Teil genutzt. +## Einsatzort -Einsatzort ----------- - -Um den gerade erstellten Key zu nutzen, muss dieser eingebunden und für +Um den gerade erstellten Key zu nutzen, muss dieser in die OpenStack Umgebung eingebunden und für später erstellte Instanzen/Stacks bereit gestellt werden. -Dies geht direkt mit dem vorher installierten OpenStackClient. +Dies geht direkt mit dem vorher installierten OpenStack Client. -In der Dokumentation gehen wir davon aus, dass der erzeugte Key in -`~/.ssh/ liegt`, sollte sich dieser an einer anderen Stelle befinden, -muss das Keypair dorthin kopiert werden oder der Befehl entsprechend +In dieser Dokumentation gehen wir davon aus, dass der erzeugte Key in +`~/.ssh/` liegt. Falls er sich an einer anderen Stelle befindet, +muss das Keypair dorthin kopiert oder der Befehl entsprechend angepasst werden: ```bash @@ -83,12 +72,12 @@ $ openstack keypair create --public-key ~/.ssh/Beispiel.key.pub Beispiel +-------------+-------------------------------------------------+ ``` -Da im weiteren Verlauf der SSH-Key genutzt wird, sollte der Name, der -statt `Beispiel` vergeben wird, leicht merkbar sein. +Da im weiteren Verlauf der SSH-Key genutzt wird, sollten Sie einen Namen +anstelle von `Beispiel` vergeben, den Sie sich leicht merken können. Um zu überprüfen, ob der Key korrekt abgelegt wurde oder um sich den -Namen erneut anzeigen zu lassen, nutzt man folgenden -Befehl: +Namen erneut anzeigen zu lassen, können Sie folgenden +Befehl verwenden: ```bash $ openstack keypair list @@ -99,10 +88,8 @@ $ openstack keypair list +----------+-------------------------------------------------+ ``` -Abschluss ---------- +## Zusammenfassung -Da der SSH Key jetzt genutzt werden kann, wird es Zeit weiter vorzugehen und -eine eigene Instanz zu erstellen. +Sie haben ein neues SSH Keypair erzeugt und den öffentlichen Key hochgeladen. Sie können den SSH Key nun nutzen und eine eigene Instanz erstellen. -Wie das genau funktioniert, erklären wir in Schritt 7. +Wie das genau funktioniert, erfahren Sie in [Schritt 7](/optimist/guided_tour/step07/). diff --git a/docs/_optimist/guided_tour/step07/index.de.md b/docs/_optimist/guided_tour/step07/index.de.md index 9f07816e4..b2153865c 100644 --- a/docs/_optimist/guided_tour/step07/index.de.md +++ b/docs/_optimist/guided_tour/step07/index.de.md @@ -6,24 +6,18 @@ nav_order: 1070 parent: Guided Tour --- -Schritt 7: Die erste eigene Instanz -=================================== +# Schritt 7: Die erste eigene Instanz -Vorwort -------- +## Einführung -Wir wissen jetzt alles, was nötig ist, um die erste eigene Instanz -anzulegen und zu starten. +Sie wissen jetzt alles, was nötig ist, um die erste eigene Instanz anzulegen und zu starten. -Es ist am sinnvollsten, das gleich in einem Stack zu organisieren und -diesen mit einem Template zu beschreiben, anstatt alle notwendigen -Arbeitsschritte von Hand durchzuführen. +Es ist am sinnvollsten, das ganze in einem Stack zu organisieren und +diesen mit einem Heat-Template oder mit Terraform zu beschreiben, anstatt alle notwendigen Arbeitsschritte von Hand durchzuführen. -Trotzdem erzeugen wir im allerersten Schritt erst mal eine Instanz von -Hand. +Um sicher zu gehen, dass Sie die vorherigen Schritte verstanden haben und anwenden können, erzeugen wir jedoch zunächst eine Instanz von Hand. -Installation ------------- +## Installation Der Grundbefehl für das Erstellen einer Instanz in der Kommandozeile lautet: @@ -32,7 +26,7 @@ lautet: openstack server create test ``` -Wenn der Befehl ohne weitere Zusätze ausgeführt wird, erscheint direkt +Wenn Sie den Befehl ohne weitere Zusätze ausführen, erscheint direkt eine Fehlermeldung: ```bash @@ -58,10 +52,10 @@ openstack server create: error: argument --flavor is required Der Fehler besagt, dass kein Flavor angegeben ist. -Damit nun eine Instanz gestartet werden kann, wird dem Befehl noch der -entsprechende Flavor hinzugefügt. +Damit eine Instanz gestartet werden kann, müssen Sie dem Befehl noch die +entsprechende Flavor hinzufügen. -Um zu sehen welche Flavors bereit stehen, führen wir folgenden Befehl +Um zu sehen, welche Flavors vorhanden sind, führen Sie folgenden Befehl aus: ```bash @@ -80,24 +74,21 @@ $ openstack flavor list +--------------------------------------+------------+-------+------+-----------+-------+-----------+ ``` -Sollte man nun den Befehl `openstack stack create Beispiel` mit +Falls Sie den Befehl `openstack stack create Beispiel` mit `--flavor m1.micro` starten, würde erneut eine Fehlermeldung angezeigt werden, da weitere Parameter fehlen. -Um eine Instanz über diesen Weg zu starten, wird neben dem -Flavor(`--flavor`) auch noch der SSH-Key (`--key-name`), das +Um eine Instanz über diesen Weg zu starten, benötigen Sie neben dem +Flavor(`--flavor`) auch den SSH-Key (`--key-name`), das Image (`--image`), das verfügbare Netz (`--network`, in alten Versionen des Clients muss `--nic net_id=` verwendet werden) und eine -SecurityGroup (`--security-group`) benötigt. +SecurityGroup (`--security-group`). -Der SSH-Key wurde im letzten Schritt bereits erstellt und braucht so -nicht erneut angelegt werden. +Der SSH-Key wurde in einem vorherigen Schritt bereits erstellt und braucht somit nicht erneut angelegt werden. -Damit fehlen noch das Image (`--image`) und das Netz. +Es fehlen noch das Image (`--image`) und das Netz. -Starten wir zunächst mit dem Image, wie bereits bei dem Flavor, kann -auch hier eine Übersicht der möglichen Images mit folgendem Befehl -angezeigt werden: +Wir starten zunächst mit dem Image. Wie bereits bei dem Flavor, können Sie sich auch hier eine Übersicht der möglichen Images mit dem folgenden Befehl anzeigen lassen: ```bash $ openstack image list @@ -116,9 +107,7 @@ $ openstack image list Nun fehlt noch ein Netzwerk. -An dieser Stelle gibt es 2 Möglichkeiten für das Netzwerk, zum einen -kann man ein sehr simples Netzwerk anlegen und so die Instanz starten, -dafür nutzt man folgenden Befehl: +Mit dem folgenden Befehl können Sie ein sehr einfaches Netzwerk anlegen: ```bash $ openstack network create BeispielNetzwerk @@ -155,15 +144,12 @@ $ openstack network create BeispielNetzwerk Der Nachteil an diesem Netzwerk ist, dass man die Instanz nicht erreichen kann. Soll die Instanz nutzbar sein, wird ein funktionierendes -Netz benötigt, welches in [Schritt 10](schritt10.md) komplett angelegt -wird. +Netz benötigt, welches in [Schritt 10](/optimist/guided_tour/step10/) komplett angelegt wird. -Nachdem alle Bestandteile jetzt bekannst sind, kann die erste Instanz -erstellt werden. +Nachdem alle Bestandteile jetzt bekannt sind, können Sie die erste Instanz erstellen. -Dafür wird das `--flavor m1.small`, der SSH-Key aus Schritt 6, das Netzwerk -von weiter oben, das `--image "Ubuntu 16.04 Xenial Xerus - Latest"` und die -`--security-group default`: +Dafür benötigen Sie das `--flavor m1.small`, den SSH-Key aus [Schritt 6](/optimist/guided_tour/step06/), das Netzwerk +von weiter oben, das `--image "Ubuntu 16.04 Xenial Xerus - Latest"` und die `--security-group default`: ```bash $ openstack server create BeispielServer --flavor m1.small --key-name Beispiel --image 82242d21-d990-4fc2-92a5-c7bd7820e790 --network=BeispielNetzwerk --security-group default @@ -200,8 +186,7 @@ $ openstack server create BeispielServer --flavor m1.small --key-name Beispiel - +-----------------------------+--------------------------------------------------------+ ``` -Weitere mögliche Parameter für die Erstellung einer Instanz können -mit `--help` abgefragt werden: +Weitere mögliche Parameter für die Erstellung einer Instanz können Sie mit `--help` abfragen: ```bash $ openstack server create --help @@ -297,9 +282,7 @@ shell formatter: --prefix PREFIX add a prefix to all variable names ``` -Abschluss ---------- +## Zusammenfassung -Nachdem wir in diesem Schritt nicht nur eine neue Instanz erstellt , -sondern auch noch einige Basis Befehle für OpenStack angewedet haben. -Werden wir im Schritt 8 diese VM wieder löschen. +In diesem Schritt haben Sie eine neue Instanz erstellt und einige Basis-Befehle für OpenStack angewendet. +In [Schritt 8](/optimist/guided_tour/step08/) zeigen wir Ihnen, wie Sie diese VM wieder löschen können. diff --git a/docs/_optimist/guided_tour/step07/index.en.md b/docs/_optimist/guided_tour/step07/index.en.md index 4ad23199f..34598fd28 100644 --- a/docs/_optimist/guided_tour/step07/index.en.md +++ b/docs/_optimist/guided_tour/step07/index.en.md @@ -15,8 +15,7 @@ In the previous steps, you learned everything you need to create a VM. In general, it is best to create VMs as part of a stack, and to create these stacks with *Heat*, or other automation tools like *Terraform*. -To ensure that you know the basics, this step deals with creating a single VM -manually. +To ensure that you know the basics, this step deals with creating a single VM manually. ## Installation diff --git a/docs/_optimist/guided_tour/step08/index.de.md b/docs/_optimist/guided_tour/step08/index.de.md index 988e7fb00..6114ece98 100644 --- a/docs/_optimist/guided_tour/step08/index.de.md +++ b/docs/_optimist/guided_tour/step08/index.de.md @@ -6,34 +6,25 @@ nav_order: 1080 parent: Guided Tour --- -Schritt 8: Löschen der ersten eigenen Instanz -============================================= +# Schritt 8: Löschen der ersten eigenen Instanz -Vorwort -------- +## Einführung -Nachdem in Schritt 7: Die erste eigene Instanz die Instanz in -der Kommandozeile angelegt wurde, wird in diesem Schritt erklärt, wie man eine -Instanz wieder löscht. +Nachdem Sie in [Schritt 7](/optimist/guided_tour/step07/), die erste eigene Instanz in der Kommandozeile angelegt haben, erklären wir in diesem Schritt, wie Sie eine Instanz wieder löschen. -Vorgehen --------- +## Vorgehensweise -Damit eine Instanz generell gelöscht werden kann, wird entweder der -Name oder die ID der zu löschenden Instanz benötigt. +Damit Sie eine Instanz löschen können, benötigen Sie entweder den Namen oder die ID der zu löschenden Instanz. -Bei wenigen Instanzen in einem Stack, kann der Name für das Löschen -verwendet werden. +Existieren nur wenige Instanzen in einem Stack, können Sie den Namen für das Löschen verwenden. -Sobald allerdings mehrere Instanzen verwendet werden, wird von uns -empfohlen für das Löschen die ID zu nutzen, da Namen im Gegensatz zu IDs +Werden allerdings mehrere Instanzen verwendet, empfehlen wir Ihnen, für das Löschen die ID zu nutzen, da Namen im Gegensatz zu IDs nicht einzigartig sind. -Der OpenStackClient zeigt einem sonst an, dass es mehrere Instanzen mit -dem entsprechenden Namen gibt. +Der OpenStackClient zeigt Ihnen ansonsten an, dass es mehrere Instanzen mit dem entsprechenden Namen gibt. -Um nun eine Liste aller verfügbaren Instanzen zu erhalten, kann -`openstack server list` als Befehl ausgeführt werden: +Sie können sich eine Liste aller verfügbaren Instanzen mit dem Befehl +`openstack server list` anzeigen lassen: ```bash $ openstack server list @@ -44,12 +35,12 @@ $ openstack server list +--------------------------------------+--------------+--------+---------------------------------------------------+------------------------------------+ ``` -Die angezeigte Liste listet alle verfügbaren Instanzen auf und enthält -neben dem Namen der jeweiligen Instanz, auch die zugehörige ID. +Die angezeigte Liste enthält alle verfügbaren Instanzen und +neben dem Namen der jeweiligen Instanz auch die zugehörige ID. -Um die im vorigen Schritt erstelle Instanz zu löschen, wird der Befehl -`openstack server delete ID` verwendet, wobei "ID" durch die korrekte -ID der Instanz ausgetauscht wird. +Um die im vorigen Schritt erstellte Instanz zu löschen, verwenden Sie den Befehl +`openstack server delete ID`, wobei Sie "ID" durch die korrekte +ID der Instanz ersetzen müssen. In unserem Beispiel lautet der Befehl also wie folgt: @@ -66,13 +57,10 @@ $ openstack server list $ ``` -Abschluss ---------- +## Zusammenfassung -Nachdem im vorigen Schritt eine Instanz per Hand erstellt wurde, haben -wir diese Instanz hier gelöscht. +Nachdem Sie in [Schritt 7](/optimist/guided_tour/step07/) eine Instanz per Hand erstellt haben, haben Sie in diesem Schritt diese Instanz wieder gelöscht. -Außerdem konnte mit dem Befehl `openstack server list` eine Übersicht -über alle Instanzen gewonnen werden. +Außerdem haben Sie gelernt, wie Sie sich mit dem Befehl `openstack server list` eine Liste aller Instanzen anzeigen lassen können. -In Schritt 9: Die erste Security-Group wird an den bisherigen Erfahrungen angeknüpft und das gewonnene Wissen um das Thema Security-Groups erweitert. +In [Schritt 9](/optimist/guided_tour/step09/) beschäftigen wir uns mit dem Thema Security-Groups. diff --git a/docs/_optimist/guided_tour/step09/index.de.md b/docs/_optimist/guided_tour/step09/index.de.md index 9b80d2f93..a3d4f8700 100644 --- a/docs/_optimist/guided_tour/step09/index.de.md +++ b/docs/_optimist/guided_tour/step09/index.de.md @@ -6,26 +6,26 @@ nav_order: 1090 parent: Guided Tour --- -Schritt 9: Die erste Security-Group -=================================== +# Schritt 9: Die erste Security-Group -Vorwort -------- +## Einführung Standardmäßig ist jeglicher Zugriff auf eine Instanz von außerhalb -verboten. Um Zugriff auf eine Instanz zu erlauben, muss (mindestens) +verboten. Um Zugriff auf eine Instanz zu erlauben, muss mindestens eine Security Group definiert und der Instanz zugewiesen werden. Es ist möglich, alle Zugriffsregeln in einer Security Group -zusammenzufassen, doch für komplexe Stacks macht es Sinn, die Regeln +zusammenzufassen, doch für komplexe Stacks ist es sinnvoll, die Regeln nach Aufgabe einzelner Instanzen in eigenen Security Groups zu hinterlegen. -Vorgehen --------- +## Vorgehensweise -Der Grundbefehl für das erstellen einer Security Group lautet -`openstack security group create allow-ssh-from-anywhere --description Beispiel`: +Der Grundbefehl für das Erstellen einer Security Group lautet: + +`openstack security group create allow-ssh-from-anywhere` + +Beispiel: ```bash $ openstack security group create allow-ssh-from-anywhere --description Beispiel @@ -46,10 +46,10 @@ $ openstack security group create allow-ssh-from-anywhere --description Beispiel +-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+ ``` -Damit eine Security Group nicht nur eine leere Hülle ist, kann der -Befehl durch weitere Zusätze sinnvoll erweitert werden. +Damit eine Security Group nicht nur eine leere Hülle ist, können Sie den +Befehl durch weitere Zusätze sinnvoll erweitern. -Hier eine kurze Übersicht der wichtigsten Optionen: +Hier ist eine kurze Übersicht der wichtigsten Optionen: - `--protocol` = Definition des genutzten Protokolls (mögliche Optionen: icmp, tcp, udp) @@ -61,11 +61,9 @@ Hier eine kurze Übersicht der wichtigsten Optionen: - `--ingress` bzw. `--egress` = ingress definiert den eingehenden Verkehr, egress den ausgehenden -Da die wichtigsten Optionen nun bekannt sind, kann jetzt eine Security -Group erstellt werden, die es erlaubt theoretisch Zugriff per SSH zu -erhalten. +Da die wichtigsten Optionen nun bekannt sind, können Sie jetzt eine Security Group erstellen, mit der Sie theoretisch von überall Zugriff mit SSH erhalten. -Der Befehl lautet +Der Befehl lautet: `openstack security group rule create allow-ssh-from-anywhere --protocol tcp --dst-port 22:22 --remote-ip 0.0.0.0/0` ```bash @@ -92,8 +90,9 @@ $ openstack security group rule create allow-ssh-from-anywhere --protocol tcp -- ``` Um zu prüfen, ob die Security Group korrekt angelegt wurde und um eine -Übersicht über alle zu erhalten, kann folgender Befehl genutzt -werden, `openstack security group show allow-ssh-from-anywhere` +Übersicht über alle Gruppen zu erhalten, können Sie folgenden Befehl verwenden: + + `openstack security group show allow-ssh-from-anywhere` ```bash $ openstack security group show allow-ssh-from-anywhere @@ -116,11 +115,6 @@ $ openstack security group show allow-ssh-from-anywhere +-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+ ``` -Abschluss ---------- - -Nach dem erfolgreichen erstellen der Security-Group, ist der nächste -Schritt ein Netzwerk hinzuzufügen. +## Zusammenfassung -Dies erfolgt im Schritt 10: Zugriff aus dem Internet vorbereiten: Ein -Netzwerk anlegen. +Sie haben erfolgreich eine Security-Group erstellt. Im nächsten Schritt lernen Sie, wie man ein Netzwerk hinzufügt. diff --git a/docs/_optimist/guided_tour/step10/index.de.md b/docs/_optimist/guided_tour/step10/index.de.md index 6b60d9d8a..fcb7a3653 100644 --- a/docs/_optimist/guided_tour/step10/index.de.md +++ b/docs/_optimist/guided_tour/step10/index.de.md @@ -6,25 +6,21 @@ nav_order: 1100 parent: Guided Tour --- -Schritt 10: Zugriff aus dem Internet vorbereiten: Ein Netzwerk anlegen -====================================================================== +# Schritt 10: Zugriff aus dem Internet vorbereiten: Ein Netzwerk anlegen -Vorwort -------- +## Einführung -In Schritt 7 wurde zuerst eine Instanz manuell erstellt und in Schritt 9 -dann eine Security Group. +In [Schritt 7](/optimist/guided_tour/step07/) haben wir zuerst eine Instanz manuell erstellt und in [Schritt 9](/optimist/guided_tour/step09/ dann eine Security Group. -Nun ist der nächste Schritt ein virtuelles Netzwerk zu erstellen. +In diesem Schritt erstellen wir ein virtuelles Netzwerk. -Netzwerk --------- +## Netzwerk -Den Start dafür macht das eigentliche Netzwerk. Wie bisher gibt es -mehrere zusätzliche Optionen, die wie gewohnt mit dem Zusatz `--help` -aufgelistet werden können. +Wir beginnen mit dem Netzwerk. Wie bisher gibt es +mehrere zusätzliche Optionen, die wir wie gewohnt mit dem Zusatz `--help` +auflisten können. -Um das Netzwerk zu erstellen, nutzen wir den Befehl: +Um das Netzwerk zu erstellen, nutzen Sie den Befehl: ```bash $ openstack network create BeispielNetzwerk @@ -59,14 +55,12 @@ $ openstack network create BeispielNetzwerk +---------------------------+--------------------------------------+ ``` -Subnet ------- +## Subnet -Da das Netzwerk nun angelegt wurde, ist der nächste logische Schritt, -ein zugehöriges Subnet. +Da das Netzwerk nun angelegt wurde, ist der nächste logische Schritt, ein zugehöriges Subnet anzulegen. -Auch das Subnet hat sehr viele zusätzliche Optionen, für das Beispiel -werden folgende genutzt: +Auch das Subnet hat viele zusätzliche Optionen. Für das Beispiel +nutzen wir folgende: - `--network` = Gibt an, in welchem Netzwerk das Subnet angelegt werden soll @@ -106,11 +100,9 @@ $ openstack subnet create BeispielSubnet --network BeispielNetzwerk --subnet-ran +-------------------------+--------------------------------------+ ``` -Router ------- +## Router -Damit das Subnet auch sinnvoll genutzt werden kann, wird noch ein virtueller -Router benötigt: +Damit das Subnet auch sinnvoll genutzt werden kann, wird noch ein virtueller Router benötigt: ```bash $ openstack router create BeispielRouter @@ -137,21 +129,19 @@ $ openstack router create BeispielRouter ``` Um eine Verbindung ins Internet zu ermöglichen, benötigt der Router ein -externes Gateway, welches mit diesem Befehl gesetzt wird: +externes Gateway, welches wir mit diesem Befehl setzen: ```bash openstack router set BeispielRouter --external-gateway provider ``` -Da nun schon die Verbindung hergestellt ist, wird dem Router nun noch das -Subnet zugewiesen: +Da nun schon die Verbindung hergestellt ist, weisen wir dem Router nun noch das Subnet zu: ```bash openstack router add subnet BeispielRouter BeispielSubnet ``` -Port ----- +## Port Nachdem nun bereits der Router und das Subnet erstellt wurden, fehlt im letzten Schritt noch der zugehörige Port. @@ -197,9 +187,8 @@ $ openstack port create BeispielPort --network BeispielNetzwerk +-----------------------+----------------------------------------------------------------------------+ ``` -Abschluss ---------- +## Zusammenfassung -Nachdem Router, Subnet und Port angelegt und diese miteinander verknüpft -wurden, ist die Einrichtung des Beispielnetzwerks abgeschlossen und im -nächsten Schritt fügen wir noch den Zugriff per IPv6 hinzu. +Nachdem wir Router, Subnet und Port angelegt und diese miteinander verknüpft +haben, ist die Einrichtung des Beispielnetzwerks abgeschlossen. Im +nächsten Schritt fügen wir noch den Zugriff mit IPv6 hinzu. diff --git a/docs/_optimist/guided_tour/step11/index.de.md b/docs/_optimist/guided_tour/step11/index.de.md index 2108af161..3959a99ba 100644 --- a/docs/_optimist/guided_tour/step11/index.de.md +++ b/docs/_optimist/guided_tour/step11/index.de.md @@ -6,30 +6,26 @@ nav_order: 1110 parent: Guided Tour --- -Schritt 11: Zugriff aus dem Internet vorbereiten: Wir ergänzen IPv6 -=================================================================== +# Schritt 11: Zugriff aus dem Internet vorbereiten: Wir ergänzen IPv6 -Vorwort -------- +## Einführung -In Schritt 10 wurde von uns bereits ein Netzwerk angelegt und -in diesem Schritt erweitern wir selbiges um IPv6. +In [Schritt 10](/optimist/guided_tour/step10/) haben wir bereits ein Netzwerk angelegt und in diesem Schritt erweitern wir dieses um IPv6. -Dabei nutzen wir die bereits bestehenden Router etc. Wichtig ist, dass +Dabei nutzen wir unter anderem die bereits bestehenden Router. Wichtig ist, dass die IPv4-Adresse auf dem ersten Interface läuft. Die Cloud Images sind so konzipiert, dass das primäre Interface mit [DHCP](https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) vorkonfiguriert ist. Erst wenn das erfolgt ist, wird auf den Metadata -Service zugegriffen um IPv6 überhaupt hoch zu fahren. +Service zugegriffen, um IPv6 hochzufahren. -Subnet ------- +## Subnet -Für die IPv6 Netze gibt es bereits einen Pool, aus dem man sich einfach -ein eigenes Subnetz generieren lassen kann. +Für die IPv6 Netze gibt es bereits einen Pool, aus dem Sie sich einfach +ein eigenes Subnetz generieren lassen können. -Welche Pools es gibt, findet man mit diesem Befehl heraus: +Welche Pools es gibt, können Sie sich mit diesem Befehl anzeigen lassen: ```bash $ openstack subnet pool list @@ -40,17 +36,13 @@ $ openstack subnet pool list +--------------------------------------+---------------+---------------------+ ``` -Aus diesem Pool kann man sich nun eigene Subnetze generieren lassen und -die Prefixlänge von 64Bit ist dabei pro generiertem Subnet fest +Aus diesem Pool können Sie sich nun eigene Subnetze generieren lassen. Die Prefixlänge von 64 Bit ist dabei pro generiertem Subnet fest vorgegeben. -Bei der Erstellung der Pools kann man die Subnets direkt mit angeben -oder man überlässt es OpenStack. +Bei der Erstellung der Pools können Sie die Subnets direkt mit angeben. +oder Sie überlassen es OpenStack. -Dafür wird im Befehl -`openstack subnet create --network BeispielNetzwerk --ip-version 6 --use-default-subnet-pool --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful BeispielSubnetIPv6` -einfach der Zusatz `--use-default-subnet-pool` -genutzt. +Nutzen Sie dazu im folgenden Befehl den Zusatz `--use-default-subnet-pool`: ```bash $ openstack subnet create --network BeispielNetzwerk --ip-version 6 --use-default-subnet-pool --ipv6-address-mode dhcpv6-stateful --ipv6-ra-mode dhcpv6-stateful BeispielSubnetIPv6 @@ -81,29 +73,25 @@ $ openstack subnet create --network BeispielNetzwerk --ip-version 6 --use-defaul +-------------------------+----------------------------------------------------------+ ``` -Router ------- +## Router -Da nun das IPv6 Netz auch erstellt ist, werden wir in diesem Schritt das +Da nun auch das IPv6 Netz erstellt ist, werden wir in diesem Schritt das neue Netz mit dem in Schritt 10 erstellten Router verbinden. -Dafür nutzen wir den Befehl: +Nutzen Sie dazu den folgenden Befehl: ```bash openstack router add subnet BeispielRouter BeispielSubnetIPv6 ``` -Security Group --------------- +## Security Group -Die Regeln die wir zuvor in Schritt 9 angelegt haben, beziehen +Die Regeln, die wir zuvor in Schritt 9 angelegt haben, beziehen sich nur auf IPv4. -Damit auch IPv6 genutzt werden kann, legen wir noch zwei weitere Regeln -in den schon bestehenden SecurityGroups an. +Damit auch IPv6 genutzt werden kann, legen wir noch zwei weitere Regeln in den schon bestehenden SecurityGroups an. -Um auch per IPv6 Zugriff per SSH auf die VM zu erlangen nutzen wir den -Befehl: +Um auch über IPv6 Zugriff per SSH auf die VM zu erlangen, nutzen wir den Befehl: ```bash $ openstack security group rule create --remote-ip "::/0" --protocol tcp --dst-port 22:22 --ethertype IPv6 --ingress allow-ssh-from-anywhere @@ -128,8 +116,7 @@ $ openstack security group rule create --remote-ip "::/0" --protocol tcp --dst-p +-------------------+--------------------------------------+ ``` -Nun fehlt noch der Zugriff per ICMP, damit wir die VM auch über IPv6 per -Ping erreichen können. +Nun fehlt noch der Zugriff per ICMP, damit wir die VM auch über IPv6 mit Ping erreichen können. Dies geht mit diesem Befehl: @@ -156,25 +143,21 @@ $ openstack security group rule create --remote-ip "::/0" --protocol ipv6-icmp - +-------------------+--------------------------------------+ ``` -Anpassungen am Betriebssystem ------------------------------ +## Anpassungen am Betriebssystem -Startet man nun eine VM innerhalb des angelegten Netzes, bekommt diese -eine IPv4, als auch eine IPv6 Adresse. +Startet man nun eine VM innerhalb des angelegten Netzes, bekommt diese sowohl eine IPv4 als auch eine IPv6 Adresse. -Die Standardimages der Hersteller sind aber leider noch nicht für IPv6 -vorkonfiguriert, weshalb tatsächlich nur die IPv4 Adresse in der VM -ankommt. +Die Standard-Images der Hersteller sind aber leider noch nicht für IPv6 vorkonfiguriert, weshalb tatsächlich nur die IPv4 Adresse in der VM ankommt. -Nutzt man unsere bereitgestellten Heat Templates, sind die notwendigen +Nutzt man die bereitgestellten Heat Templates, sind die notwendigen Anpassungen bereits im Template enthalten. -Um dies auch bei bestehenden Instanzen nachträglich auch zu ermöglichen, -gibt es hier für verschiedene Distributionen einen Anleitung. +Um dies auch bei bestehenden Instanzen nachträglich zu ermöglichen, +gibt es hier für verschiedene Linux-Distributionen eine Anleitung. ### Ubuntu 16.04 -Um IPv6 korrekt nutzen zu können, müssen folgende Dateien, mit dem +Um IPv6 korrekt nutzen zu können, müssen folgende Dateien mit dem angegeben Inhalt erstellt werden. - `/etc/dhcp/dhclient6.conf` @@ -204,20 +187,19 @@ angegeben Inhalt erstellt werden. up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true ``` -Im Anschluss wird das entsprechende Interface neugestartet: +Im Anschluss wird das entsprechende Interface neu gestartet: ```bash sudo ifdown ens3 && sudo ifup ens3 ``` Die VM hat jetzt eine weitere IPv6 Adresse auf dem Interface, auf dem -vorher nur die IPv4 Adresse existierte und kann somit auch per IPv6 +vorher nur die IPv4 Adresse existierte und kann somit auch über IPv6 korrekt erreicht werden. -Damit man die beschriebenen Punkte nicht jedes mal manuell abarbeiten -muss, kann man folgende `cloud-init` Konfiguration verwenden (Was -`cloud-init` genau ist, erklären wir in [Schritt 19: Unsere Instanz lernt -IPv6](schritt19.md)): +Damit Sie die beschriebenen Punkte nicht jedes mal manuell abarbeiten +müssen, können Sie die folgende `cloud-init` Konfiguration verwenden (was +`cloud-init` genau ist, erklären wir in [Schritt 19](/optimist/guided_tour/step19)): ```yaml #cloud-config @@ -244,7 +226,7 @@ runcmd: ### CentOS 7 Die genannten Parameter müssen den angegebenen Dateien neu hinzugefügt -oder falls diese bereits vorhanden sind ergänzt werden: +oder falls diese bereits vorhanden sind, ergänzt werden: - `/etc/sysconfig/network` @@ -259,19 +241,17 @@ oder falls diese bereits vorhanden sind ergänzt werden: DHCPV6C=yes ``` -Anschließend wird das entsprechende Interface neugestartet: +Anschließend wird das entsprechende Interface neu gestartet: ```bash sudo ifdown eth0 && sudo ifup eth0 ``` -Die VM hat jetzt eine weitere IPv6 Adresse auf dem Interface, auf dem -vorher nur die IPv4 Adresse existierte und kann somit auch per IPv6 -korrekt erreicht werden. +Die VM hat jetzt eine weitere IPv6 Adresse auf dem Interface, auf dem vorher nur die IPv4 Adresse existierte und kann somit auch über IPv6 korrekt erreicht werden. -Damit man die beschriebenen Punkte nicht jedes mal manuell abarbeiten -muss, kann man folgende `cloud-init` Konfiguration verwenden(Was -`cloud-init` genau ist, erklären wir für Ubuntu 16.04 in [Schritt 19: Unsere Instanz lernt IPv6](/optimist/guided_tour/step19/): +Damit Sie die beschriebenen Punkte nicht jedes mal manuell abarbeiten +müssen, können Sie die folgende `cloud-init` Konfiguration verwenden (was +`cloud-init` genau ist, erklären wir für Ubuntu 16.04 in [Schritt 19](/optimist/guided_tour/step19/)): ```yaml #cloud-config @@ -301,30 +281,27 @@ runcmd: - [ ifup, eth0] ``` -Externer Zugriff ----------------- +## Externer Zugriff -**Wichtig**: Diese VM ist ab sofort von überall auf der Welt über ihre -IPv6 Adresse zu erreichen. Natürlich nur auf den Ports, die wir auch in +**Wichtig**: Diese VM ist ab sofort weltweit über ihre +IPv6 Adresse zu erreichen. Das funktioniert natürlich nur auf den Ports, die wir auch in den Security Groups aktiviert haben. Wir benötigen also keine weitere Floating IP um externen Zugriff auf diese VM zu ermöglichen. -Es ist deshalb so wichtig zu erwähnen, da wir hier ein anderes Verhalten +Das ist wichtig zu erwähnen, da wir hier ein anderes Verhalten haben, als mit den IPv4 Adressen. -Möchte man per IPv4 aus dem Internet auf diese VM zugreifen, muss man +Möchte man über IPv4 aus dem Internet auf diese VM zugreifen, muss man weiterhin auf die Floating IPs zurückgreifen. -Hat man selbst lokal kein IPv6, möchte aber testen ob seine VM -prinzipiell erreichbar ist, kann man auf Online Tools zurückgreifen, wie -z.B.  +Hat man selbst lokal kein IPv6, möchte aber testen ob die VM +prinzipiell erreichbar ist, kann man auf Online Tools zurückgreifen, zum Beispiel . -Abschluss ---------- +## Zusammenfassung Nachdem im letzten Schritt bereits eine Verbindung per IPv4 erfolgte, wurde nun auch noch der Zugriff per IPv6 hinzugefügt. -Im nächsten Schritt wird dann die Instanz aus [Schritt 7](/optimist/guided_tour/step07/) als Vorlage genutzt und erreichbar von außen. +Im nächsten Schritt nutzen wir die Instanz aus [Schritt 7](/optimist/guided_tour/step07/) als Vorlage und machen sie von außen zugänglich. diff --git a/docs/_optimist/guided_tour/step12/index.de.md b/docs/_optimist/guided_tour/step12/index.de.md index fbb99e235..f28d05483 100644 --- a/docs/_optimist/guided_tour/step12/index.de.md +++ b/docs/_optimist/guided_tour/step12/index.de.md @@ -6,24 +6,19 @@ nav_order: 1120 parent: Guided Tour --- -Schritt 12: Eine nutzbare Instanz -================================= +# Schritt 12: Eine nutzbare Instanz -Vorwort -------- +## Einführung -In [Schritt 7](/optimist/guided_tour/step07/) wurde bereits eine Instanz erstellt, diese konnte jedoch nur genutzt werden, wenn man ein paar Schritte übersprungen hat und das entsprechende Netzwerk mit erstellt. +In [Schritt 7](/optimist/guided_tour/step07/) wurde bereits eine Instanz erstellt. Diese konnte jedoch nur genutzt werden, wenn ein paar Schritte übersprungen und das entsprechende Netzwerk mit erstellt wurden. -Es gab nur so die Möglichkeit eine Verbindung zu dieser herzustellen. +Nur so konnte eine Verbindung zu dieser Instanz hergestellt werden. -Daher werden wir in diesem Schritt eine Instanz erstellen, die diese -Problematik nicht mehr hat. +In diesem Schritt werden wir eine Instanz erstellen, die diese Problematik nicht mehr hat. -Installation ------------- +## Installation -Damit die Instanz all die fehlenden Einstellungen enthält, wird der -Befehl aus Schritt 7 modifiziert: +Damit die Instanz alle fehlenden Einstellungen enthält, modifizieren wir den Befehl aus [Schritt 7](/optimist/guided_tour/step07/): `openstack server create BeispielInstanz --flavor m1.small --key-name Beispiel --image "Ubuntu 16.04 Xenial Xerus - Latest" --security-group allow-ssh-from-anywhere --network=BeispielNetzwerk` @@ -100,25 +95,22 @@ $ openstack floating ip create provider +---------------------+--------------------------------------+ ``` -Die gerade erstellte IP wird im nächsten Schritt mit der vorher -erstellten Instanz verbunden. +Im nächsten Schritt wird die gerade erstellte IP mit der vorher erstellten Instanz verbunden. ```bash openstack server add floating ip BeispielInstanz 185.116.245.145 ``` -Nutzung -------- +## Nutzung Die erstellte Instanz ist nun erreichbar. -Um zu testen, ob alle Schritte funktionieren, stellen wir nun eine +Um zu testen, ob alle Schritte funktionieren, stellen wir eine Verbindung per SSH her. Wichtig ist hierbei, dass eine Verbindung nur funktioniert, wenn der weiter oben genutzte SSH Key auch existiert und verwendet wird -(Siehe Schritt 6: Einen eigenen SSH-Key per Konsole erstellen und -nutzen): +(siehe [Schritt 6](/optimist/guided_tour/step06/)): ```bash $ ssh ubuntu@185.116.245.145 @@ -129,15 +121,13 @@ Warning: Permanently added '185.116.245.145' (ECDSA) to the list of known hosts. Enter passphrase for key '/Users/ubuntu/.ssh/id_rsa': ``` -Clean-Up --------- +## Clean-Up Für den Fall, dass die in den vorigen Schritten erstellten Bestandteile wieder gelöscht werden sollen, muss das in folgender Reihenfolge, mit dem entsprechenden Befehl geschehen. -Sollte man dies nicht befolgen, kann es dazu führen, dass Bestandteile -sich nicht löschen lassen. +Sollte man dies nicht befolgen, kann es dazu führen, dass Bestandteile sich nicht löschen lassen. - Instanz - `openstack server delete BeispielInstanz` @@ -152,12 +142,8 @@ sich nicht löschen lassen. - Netzwerk - `openstack network delete BeispielNetzwerk` -Abschluss ---------- +## Zusammenfassung -In den Schritten 7 bis 11 wurde eine Instanz Schritt für Schritt erstellt und -jeder Schritt hat einen Teilbereich hinzugefügt (inklusive Netzwerk und einer -eigenen Security-Group). +In den Schritten 7 bis 11 wurde eine Instanz erstellt und mit jedem Schritt ein Teilbereich hinzugefügt (inklusive Netzwerk und einer eigenen Security-Group). -Im nächsten Schritt lösen wir uns von einzelnen Instanzen und -erstellen einen Stack. +Im nächsten Schritt lösen wir uns von einzelnen Instanzen und erstellen einen Stack. diff --git a/docs/_optimist/guided_tour/step13/index.de.md b/docs/_optimist/guided_tour/step13/index.de.md index 94c49d7eb..17daacb8e 100644 --- a/docs/_optimist/guided_tour/step13/index.de.md +++ b/docs/_optimist/guided_tour/step13/index.de.md @@ -6,46 +6,36 @@ nav_order: 1130 parent: Guided Tour --- -Schritt 13: Der strukturierte Weg zu einer Instanz (mit Stacks) -=============================================================== +# Schritt 13: Der strukturierte Weg zu einer Instanz (mit Stacks) -Vorwort -------- +## Einführung -Nachdem die erste Instanz, inklusive einer Security Group und virtuellem -Netzwerk, in einem sehr aufwendigen Prozess per Hand angelegt wurde, -wird in diesem Schritt eine Alternative aufgezeigt. +Nachdem wir die erste Instanz, inklusive einer Security Group und virtuellem +Netzwerk, in einem sehr aufwendigen Prozess per Hand angelegt haben, +zeigen wir in diesem Schritt eine Alternative auf. -Wie diese funktioniert und was es hierbei zu beachten gibt, wird auch -wie gewohnt Schritt für Schritt erklärt. Voraussetzung für die folgenden -Schritte ist die Installation des Paketes `python-heatclient`. -Siehe [Schritt 4: Der Weg vom Horizon auf die Kommandozeile](/optimist/guided_tour/step04/). +Voraussetzung für die folgenden +Schritte ist die Installation des Paketes `python-heatclient` (siehe [Schritt 4](/optimist/guided_tour/step04/)). -Installation -------------- +## Installation -Anstatt einzelne Instanzen von Hand anzulegen, kann man beliebige +Anstatt einzelne Instanzen von Hand anzulegen, können beliebige OpenStack Resourcen (z.B. Instanzen, Netzwerke, Router, Security Groups) -auch in einem definierten Verbund, einem so genannten **Stack** (oder Heat -Stack) betreiben. +auch in einem definierten Verbund, einem sogenannten **Stack** (oder Heat +Stack) betrieben werden. -Dadurch werden sie logisch zusammengefaßt und können einfach erstellt -und gelöscht werden -- je nach Verwendungszweck. +Dadurch werden sie logisch zusammengefaßt und können -- je nach Verwendungszweck -- einfach erstellt +und gelöscht werden. -Wir verwenden in diesem Schritt Heat-Templates, die auch Grundlage für -folgende Schritte sind. +Für die folgenden Schritte verwenden wir Heat-Templates als Grundlage. -Die bisherigen Schritte 9 bis 11, lassen sich einfach in einem Template -zusammenfassen. +Die bisherigen Schritte 9 bis 11, lassen sich einfach in einem Template zusammenfassen. -Um nicht zu theoretisch zu bleiben, gibt es ein Template unter [BeispielTemplates](https://github.com/innovocloud/openstack_examples/tree/master/heat/templates). +Hierzu gibt es ein Template unter [BeispielTemplates](https://github.com/innovocloud/openstack_examples/tree/master/heat/templates). -Dieses Template erstellt einen Stack, in diesem ist eine Instanz, zwei -Security Groups, ein virtuelles Netzwerk (inkl. Router, Port, Subnet) -und eine Floating-IP enthalten. +Dieses Template erstellt einen Stack, in dem eine Instanz, zwei Security Groups, ein virtuelles Netzwerk (inkl. Router, Port, Subnet) und eine Floating-IP enthalten sind. -Um den Stack zu erstellen, ist es notwendig, sich im Verzeichnis des -Templates zu befinden und dann folgenden Befehl zu nutzen: +Um den Stack erstellen zu können, müssen wir ins Verzeichnis des Templates wechseln und den folgenden Befehl ausführen: ```bash $ openstack stack create -t SingleServer.yaml --parameter key_name=Beispiel SingleServer --wait @@ -84,21 +74,19 @@ $ openstack stack create -t SingleServer.yaml --parameter key_name=Beispiel Sing +---------------------+-------------------------------------------------+ ``` -Der Befehl `openstack stack create` erstellt dabei den Stack, mit +Der Befehl `openstack stack create` erstellt dabei den Stack. Mit `-t SingleServer.yaml` wird festgelegt, dass das angegebene Template verwendet werden soll. -Außerdem wird mit `--parameter key_name=BEISPIEL` noch ein SSH-Schlüssel -angegeben und mit `SingleServer` wird der Name des Stacks festgelegt. +Mit `--parameter key_name=BEISPIEL` wird ein SSH-Schlüssel +angegeben und mit `SingleServer` der Name des Stacks festgelegt. -Der letzte Bestandteil `--wait` zeigt alle Zwischenschritte der -Erstellung an. (Siehe das obere Bild) +Der letzte Bestandteil `--wait` zeigt alle Zwischenschritte der Erstellung an (siehe das obere Bild). -Nach kurzer Zeit ist der Stack inkl. Instanz erstellt und kann per SSH -erreicht werden. +Nach kurzer Zeit ist der Stack einschließlich der Instanz erstellt und kann mit SSH erreicht werden. -Die notwendige IP lässt sich mit folgendem Befehl herausfinden, wichtig -ist dabei die korrekte ID zu nutzen: +Die notwendige IP findet man mit dem folgenden Befehl heraus, wichtig +ist dabei, die korrekte ID zu nutzen: ```bash $ openstack stack output show 0f5cdf0e-24cc-4292-a0bc-adf2e9f8618a instance_fip @@ -111,7 +99,7 @@ $ openstack stack output show 0f5cdf0e-24cc-4292-a0bc-adf2e9f8618a instance_fip +--------------+---------------------------------+ ``` -Nun stellen wir noch die Verbindung per SSH her: +Nun stellen wir noch die Verbindung über SSH her: ```bash $ ssh ubuntu@185.116.245.70 @@ -122,11 +110,8 @@ Warning: Permanently added '185.116.245.70' (ECDSA) to the list of known hosts. Enter passphrase for key '/Users/ubuntu/.ssh/id_rsa': ``` -Abschluss ---------- +## Zusammenfassung -Wir haben die Schritte 9 bis 11 in einem Heat-Template zusammengefaßt -und können sie nun leicht wiederholen. +Wir haben die bisherigen Schritte 9 bis 11 in einem Heat-Template zusammengefaßt. -In den folgenden Schritten gehen wir weiter auf Heat ein und zeigen -weiterführende Beispiele. +In den folgenden Schritten gehen wir weiter auf Heat ein und zeigen weitere Beispiele. diff --git a/docs/_optimist/guided_tour/step14/index.de.md b/docs/_optimist/guided_tour/step14/index.de.md index f552e0f65..f1ee11f94 100644 --- a/docs/_optimist/guided_tour/step14/index.de.md +++ b/docs/_optimist/guided_tour/step14/index.de.md @@ -1,35 +1,27 @@ --- -title: "14: Unsere ersten Schritte mit Heat" -lang: "de" +title: "14: Die ersten Schritte mit Heat" +lang: de permalink: /optimist/guided_tour/step14/ nav_order: 1140 parent: Guided Tour --- -Schritt 14: Unsere ersten Schritte mit Heat -=========================================== +# Schritt 14: Die ersten Schritte mit Heat -Vorwort -------- +## Einführung -Nachdem im letzten Schritt die erste Berührung mit einem Template -erfolgte, ist der nächste Schritt, zu verstehen, wie Templates mit Heat -aufgebaut sind und funktionieren. +Nachdem Sie im letzten Schritt die erste Berührung mit einem Template +hatten, lernen Sie in diesem Schritt wie Heat-Templates aufgebaut sind und funktionieren. -Dieser Schritt erklärt nur die einzelnen Punkte eines Templates und soll -diese näher bringen. +## Das Template -Das Template ------------- - -Jedes Heat-Template folgt der gleichen Struktur und diese ist wie folgt -aufgebaut: +Jedes Heat-Template folgt der gleichen Struktur: ```yaml heat_template_version: 2016-10-14   description: -# Die Beschreibung des Templates (optional) +# Beschreibung des Templates (optional)   parameter_groups: # Die Definition der Eingabeparameter Gruppen und deren Reihenfolge @@ -47,14 +39,11 @@ conditions: # Die Definition der Bedingungen ``` -Heat Template Version ---------------------- +## Version des Heat Templates -Die Template Version kann tatsächlich nicht willkürlich gewählt werden, -sondern hat feste Vorgaben. +Die Template-Version kann nicht willkürlich gewählt werden, sondern hat feste Vorgaben. -Diese unterscheiden sich in den möglichen Befehlen und aktuell sind -folgende Daten möglich: +Diese unterscheiden sich in den möglichen Befehlen. Aktuell sind folgende Daten möglich: - 2013-05-23 - 2014-10-16 @@ -64,36 +53,28 @@ folgende Daten möglich: - 2016-10-14 - 2017-02-24 -Description ------------ - -Die Description oder auch Beschreibung ist ein komplett optionales -Feld. +## Description -Das bedeutet, dass das Feld nicht genutzt werden muss. +Die Description (Beschreibung) ist ein optionales Feld und muss nicht genutzt werden. -Es bietet sich allerdings an, denn damit kann das Template in seinen -Grundzügen beschrieben und direkt auf mögliche Besonderheiten -hingewiesen werden. +Es bietet sich allerdings an, denn damit können Sie das Template in seinen +Grundzügen beschreiben und auf mögliche Besonderheiten +hinweisen. -Auch besteht die Möglichkeit jederzeit eine Zeile mit dem Zeichen `#` +Sie haben auch die Möglichkeit, jederzeit eine Zeile mit dem Zeichen `#` auszukommentieren und dadurch das Template nach den jeweiligen Bedürfnissen zu verändern oder mehr Kommentare zu verfassen. -Parameter Groups ----------------- +## Parameter Groups -In diesem Bereich ist es möglich zu spezifizieren, wie Parameter -gruppiert werden sollen und die Reihenfolge für die Gruppierung -festzulegen. +In diesem Bereich können Sie spezifizieren, wie Parameter gruppiert werden sollen und die Reihenfolge für die Gruppierung festlegen. Die Gruppen sind in eine Liste aufgegliedert, welche wiederum die einzelnen Parameter enthält. -Jeder Parameter sollte nur einer Gruppe zugeordnet sein, damit es später -zu keinen Problemen führt. +Jeder Parameter sollte nur einer Gruppe zugeordnet sein, damit es später zu keinen Problemen kommt. -Jede Parameter Group ist dabei wie folgt aufgebaut: +Jede Parameter-Gruppe ist wie folgt aufgebaut: ```yaml parameter_groups: @@ -105,25 +86,18 @@ parameter_groups: ``` - `label`: Name der Gruppe. -- `description`: Dieses Attribut gibt  die Möglichkeit die Parameter - Gruppe zu beschreiben und so für jeden verständlich zu machen, wofür - diese genutzt wird. -- `parameter`: Eine Auflistung aller Parameter die für diese Parameter - Gruppe gelten. -- `Name des Parameters`: Der in der Parameter Sektion definiert wurde. +- `description`: Mit diesem Attribut wird die Parameter-Gruppe beschrieben und für jeden verständlich gemacht, wofür + sie genutzt wird. +- `parameter`: Eine Auflistung aller Parameter, die für diese Parameter-Gruppe gelten. +- `Name des Parameters`: Name, der in dem Parameter-Bereich definiert wurde. -Parameter ---------- +## Parameter -Diese Sektion erlaubt es die eingegebenen Parameter zu spezifizieren, -welche für die Ausführung benötigt werden. +Mit diesem Bereich können die eingegebenen Parameter spezifiziert werden, die für die Ausführung benötigt werden. -Die Parameter werden typischerweise dafür genutzt, jedes deployment zu -individualisieren. +Die Parameter werden typischerweise dafür genutzt, jedes Deployment zu individualisieren. -Dabei wird jeder Parameter in einem separaten Block definiert, wobei am -Anfang immer der Parameter genannt wird und dann weitere Attribute -diesem zugeordnet werden. +Dabei wird jeder Parameter in einem separaten Block definiert, beginnend mit dem Namen des Parameters, und den weiteren Attributen. ```yaml  parameters: @@ -141,25 +115,16 @@ diesem zugeordnet werden. - `Parameter Name`: Der Name des Parameters. - `type`: Der Typ des Parameters. Unterstützte Typen: string, number, json, comma\_delimited\_list, boolean. -- `label`: Name des Parameters. (optional) -- `description`: Dieses Attribut gibt die Möglichkeit den Parameter zu - beschreiben und so für jeden verständlich zu machen, wofür dieser - genutzt wird. (optional) +- `label`: Name des Parameters (optional). +- `description`: Mit diesem Attribut wird der Parameter beschrieben und für jeden verständlich gemacht, wofür dieser genutzt wird (optional). - `default`: Der vorgegebene Wert des Parameters. Dieser Wert wird genutzt, wenn durch den User kein spezifischer Wert festgelegt - werden soll. (optional) -- `hidden`: Gibt an ob der Parameter bei einer Abfrage nach der - Erstellung angezeigt wird oder versteckt ist. (optional und per - Default auf *false* gesetzt) -- `constraints`: Hier kann eine Liste von Vorgaben definiert werden. - Sollten diese beim deployment nicht erfüllt werden, schlägt die - Erstellung des Stacks fehl. -- `immutable`: Definiert ob der Parameter aktualisiert werden kann. - Für den Fall, dass der Parameter auf *true* gesetzt ist und sich der - Wert bei einem stack update ändert, schlägt das Update fehl. - -Resources ---------- + werden soll (optional). +- `hidden`: Gibt an, ob der Parameter bei einer Abfrage nach der Erstellung angezeigt wird oder versteckt ist (optional und standardmäßig auf *false* gesetzt). +- `constraints`: Hier kann eine Liste von Vorgaben definiert werden. Sollten diese beim deployment nicht erfüllt werden, schlägt die Erstellung des Stacks fehl. +- `immutable`: Definiert, ob der Parameter aktualisiert werden kann. Für den Fall, dass der Parameter auf *true* gesetzt ist und sich der Wert bei einem stack update ändert, schlägt das Update fehl. + +## Resources Dieser Punkt definiert die aktuell genutzten Resourcen, die bei der Erstellung des Stacks genutzt werden. @@ -178,43 +143,28 @@ resources: update_policy: deletion_policy: external_id: - condition: + condition: ``` -- `ID der Ressource`: Diese muss einzigartig im Bereich der Ressourcen - sein. Es darf durchaus ein sprechender Name gewählt werden z. B. +- `ID der Ressource`: Diese muss einzigartig im Bereich der Ressourcen sein. Es darf durchaus ein sprechender Name gewählt werden z.B. (`web_network`). -- `type`: Der Typ der Ressource, wie zum - Beispiel `OS::NEUTRON::SecurityGroup` (für eine Security Group). - (benötigt) -- `properties`: Eine Liste der Ressourcen spezifischen Eigenschaften. - (optional) -- `metadata`: Hier können für die jeweilige Ressource spezifische - Metadaten hinterlegt werden. (optional) -- `depends_on`: Hier können verschiedene Abhängigkeiten zu anderen - Ressourcen hinterlegt werden. (optional) -- `update_policy`: Hier können Update Regeln festgelegt werden. Die - Voraussetzung dafür ist, dass die entsprechende Resource dies auch - unterstützt. (optional) -- `deletion_policy`: Hier werden die Regeln für das Löschen - festgelegt. Erlaubt sind Delete, Retain und Snapshot. Mit der - heat_template_version 2016-10-14 ist nun auch die Kleinschreibung - der Werte erlaubt - -- `external_id`: Falls notwendig, können externe Ressourcen IDs - verwendet werden -- `condition`: Anhand der Kondition wird entschieden, ob die Ressource - erstellt wird oder nicht. (optional) - -Output ------- - -Die Output-Sektion definiert die ausgegeben Parameter die für den User -oder auch für andere Templates nach dem Erstellen des Stacks verfügbar +- `type`: Typ der Ressource, zum + Beispiel `OS::NEUTRON::SecurityGroup` (für eine Security Group) (benötigt). +- `properties`: Eine Liste der Ressourcen spezifischen Eigenschaften (optional). +- `metadata`: Hier können für die jeweilige Ressource spezifische Metadaten hinterlegt werden (optional). +- `depends_on`: Hier können verschiedene Abhängigkeiten zu anderen Ressourcen hinterlegt werden (optional). +- `update_policy`: Hier können Update-Regeln festgelegt werden. Die Voraussetzung dafür ist, dass die entsprechende Ressource dies auch unterstützt (optional). +- `deletion_policy`: Hier werden die Regeln für das Löschen festgelegt. Erlaubt sind Delete, Retain und Snapshot. Mit der heat_template_version 2016-10-14 ist nun auch die Kleinschreibung der Werte erlaubt. + +- `external_id`: Falls notwendig, können externe Ressourcen IDs verwendet werden. +- `condition`: Anhand der Bedingung wird entschieden, ob die Ressource erstellt wird oder nicht (optional). + +## Output + +Der Output-Bereich definiert die ausgegeben Parameter, die für den User oder auch für andere Templates nach dem Erstellen des Stacks verfügbar sind. -Das können zum Beispiel Parameter wie die IP-Adresse der erstellten -Instanz oder auch die URL der erstellten Web-App sein. +Das können zum Beispiel Parameter wie die IP-Adresse der erstellten Instanz oder auch die URL der erstellten Web-App sein. Auch wird jeder Parameter in einem eigenen Block definiert: @@ -227,21 +177,15 @@ outputs: ``` - `Name des Parameters`: Dieser muss wieder einzigartig sein. -- `description`: Es kann eine Beschreibung für den Parameter - hinterlegt werden. (optional) -- `value`: Hier wird der Wert des Parameters vermerkt. (benötigt) -- `condition`: Hier kann eine Kondition für den Parameter festlegt - werden. (optional) +- `description`: Es kann eine Beschreibung für den Parameter hinterlegt werden (optional). +- `value`: Hier wird der Wert des Parameters vermerkt (benötigt). +- `condition`: Hier kann eine Bedingung für den Parameter festgelegt werden (optional). -Condition ---------- +## Condition -Dieser Bereich legt die verschiedenen Konditionen fest und das auf Basis -der eingegebenen Parameter des Users, beim Erstellen oder updaten des -Stacks. +Dieser Bereich legt die verschiedenen Bedingungen beim Erstellen oder Update des Stacks fest auf Basis der eingegebenen User-Parameter. -Die Konditionen können mit Resources, Resource properties und -Outputs verbunden werden. +Die Bedingungen können mit Resources, Resource Properties und Outputs verbunden werden. Auch dieser Bereich folgt wieder einem Muster: @@ -251,16 +195,11 @@ conditions: : {Bezeichnung2} ``` -- `Name der Condition`: Dieser muss wieder einzigartig im Bereich der - Condition sein. -- `Bezeichnung`: Bei der Bezeichnung wird erwartet, dass sie ein - *true* oder *false* zurückgibt. +- `Name der Condition`: Dieser muss wieder einzigartig im Bereich der Bedingung sein. +- `Bezeichnung`: Bei der Bezeichnung wird erwartet, dass sie ein *true* oder *false* zurückgibt. -Abschluss ---------- +## Zusammenfassung -In diesem Schritt wurden wichtige Bestandteile eines Heat-Templates -vorgestellt. +In diesem Schritt haben Sie wichtige Bestandteile eines Heat-Templates kennengelernt. -Mit diesem Wissen wird im nächsten Schritt das erste eigene -Heat-Template erstellt. +Mit diesem Wissen können Sie im nächsten Schritt das erste eigene Heat-Template erstellen. diff --git a/docs/_optimist/guided_tour/step15/index.de.md b/docs/_optimist/guided_tour/step15/index.de.md index 9f6dd34b1..925ef5bc4 100644 --- a/docs/_optimist/guided_tour/step15/index.de.md +++ b/docs/_optimist/guided_tour/step15/index.de.md @@ -6,31 +6,25 @@ nav_order: 1150 parent: Guided Tour --- -Schritt 15: Das erste eigene Heat Orchestration Template (HOT) -============================================================== +# Schritt 15: Das erste eigene Heat Orchestration Template (HOT) -Vorwort -------- +## Einführung -Im folgenden Schritt sind die wichtigsten Elemente eines Templates -erläutert worden und auf dieses Wissen, wird in diesem Schritt -aufgebaut. +Im vorherigen Schritt haben wir die wichtigsten Elemente eines Templates +erläutert. In diesem Schritt bauen wir auf dieses Wissen auf. -Der Anfang ------------------------- +# Der Anfang Dieser ist bei jedem Template gleich und ist immer `heat_template_version` -Für das Beispiel wird Version `2016-10-14` genutzt und somit sieht das -Template erst einmal so aus: +Für das Beispiel wird Version `2016-10-14` genutzt: ```yaml heat_template_version: 2016-10-14 ``` -Nachdem die `heat_template_version` festgelegt ist, wird dem Template -nun eine Beschreibung hinzugefügt: +Nachdem die `heat_template_version` festgelegt ist, können Sie dem Template eine Beschreibung hinzufügen: ```yaml heat_template_version: 2016-10-14 @@ -38,17 +32,15 @@ heat_template_version: 2016-10-14 description: Ein einfaches Template, um eine Instanz zu erstellen ``` -Nachdem die Beschreibung in das Template integriert wurde, wird nun eine -Ressource, also die Instanz hinzugefügt. +Nachdem die Beschreibung in das Template integriert wurde, fügem wir nun eine +Ressource, also die Instanz hinzu. -Dabei sind einige Punkte zu beachten, starten wir zunächst mit der -Ressource. +Dabei sind einige Punkte zu beachten. Wir starten zunächst mit der Ressource. -Wichtig ist dabei, dass eine Strukturierung mit Leerzeichen genutzt -wird. +Wichtig ist dabei, dass wir eine Strukturierung mit Leerzeichen vornehmen. Dies dient der Übersichtlichkeit, außerdem würden Tabstops zu Fehlern -führen und nur so kann das Template korrekt ausgeführt werden: +führen. Nur so kann das Template korrekt ausgeführt werden: ```yaml heat_template_version: 2016-10-14 @@ -59,11 +51,11 @@ resources: Instanz: ``` -Der nächste Schritt ist dann den Typ der Ressource zu benennen. +Der nächste Schritt ist, den Typ der Ressource zu benennen. Eine ausführliche Liste aller verfügbaren Typen befindet sich unter anderem in der [offiziellen OpenStack -Dokumentation](https://docs.openstack.org/developer/heat/template_guide/openstack.html) +Dokumentation](https://docs.openstack.org/developer/heat/template_guide/openstack.html). Da im Beispiel eine Instanz erstellt werden soll, ist der Typ dann folgender: @@ -78,9 +70,9 @@ resources: type: OS::Nova::Server ``` -Nach dem Typ sind dann die Eigenschaften der nächste Punkt. +Nun geben wir die Eigenschaften an. -Im Beispiel soll dies ein SSH-Key, ein Flavor und ein Image sein: +Im Beispiel ist das ein SSH-Key, ein Flavor und ein Image: ```yaml heat_template_version: 2016-10-14 @@ -96,8 +88,6 @@ resources: flavor: m1.small ``` -Abschluss ----------- +## Zusammenfassung -Damit ist das Erste eigenes Template fertiggestellt und kann, wenn es -gespeichert wird, einfach mit dem OpenStackClienten wie in [Schritt 13: "Der strukturierte Weg zu einer Instanz (mit Stacks)"](/optimist/guided_tour/step13/) beschrieben, gestartet werden. +Sie haben Ihr erstes eigenes Template fertiggestellt. Nachdem Sie es gespeichert habe, können Sie es mit dem OpenStack Client wie in [Schritt 13](/optimist/guided_tour/step13/) beschrieben, starten. diff --git a/docs/_optimist/guided_tour/step16/index.de.md b/docs/_optimist/guided_tour/step16/index.de.md index 7b3fccea9..4d0982f6d 100644 --- a/docs/_optimist/guided_tour/step16/index.de.md +++ b/docs/_optimist/guided_tour/step16/index.de.md @@ -6,31 +6,25 @@ nav_order: 1160 parent: Guided Tour --- -Schritt 16: Wir lernen Heat besser kennen -========================================= +# Schritt 16: Wir lernen Heat besser kennen -Vorwort -------- +## Einführung -Bisher konnte der Eindruck entstehen, das Heat und das manuelle -Erstellen per Kommandozeile genau so viel Zeit in Anspruch nimmt, was -beim einmaligen Erstellen auch stimmt. +Bisher konnte bei Ihnen der Eindruck erweckt werden, dass das Erstellen einer VM mit *Heat* und das manuelle +Erstellen mit der Kommandozeile gleich viel Zeit in Anspruch nimmt. Das stimmt auch beim einmaligen Erstellen der VM. +Der Vorteil von *Heat* besteht jedoch darin, dass das Template für weitere VMs wiederverwendet und weiterentwickelt werden kann. -Dadurch das nun ein Template existiert, können wir diese Grundlage immer -wieder nutzen und im Zweifel weiter entwickeln. +Wie das geht zeigen wir Ihnen in diesem Schritt. Dazu fügen wir zusätzliche Parameter in das Template ein. -Damit dies auch möglich ist, wird in diesem Schritt weiter auf Heat -eingegangen. +## Parameter -Parameter ---------- +Zunächst ist es sinnvoll, bekannte oder individuelle Parameter zu definieren. -Da das Ganze aufgebaut werden soll, ist es zunächst sinnvoll, bekannte -oder individuelle Parameter zu definieren. +In unserem Beispiel ersetzen wir den vorgegebenen SSH-Key und definieren ihn anstelle eines festen Werts als individuellen Parameter, der beim Start angegeben werden kann. Das hat den Vorteil, dass für eine VM andere Schlüssel verwendet werden können, ohne dass die Vorlage geändert werden muss. -In diesem Kontext wird der vorgegebene SSH-Key ersetzt und statt einem -festen Wert, wird er als individueller Parameter definiert, der beim -Start angegeben werden kann: +Wie Sie bereits wissen, beginnt das Template mit der Version und wird mit `parameters` fortgeführt. + +Danach wird ein individueller Name vergeben und der Typ angegeben. In unserem Fall verwenden wir als Typ `string`: ```yaml heat_template_version: 2014-10-16 @@ -40,18 +34,9 @@ parameters: type: string ``` -Wie bisher gelernt, beginnt das Template mit der Version und wird dann -mit `parameters` fortgeführt. - -Nach dem Parameter wird der Name, welcher individuell benannt werden -kann, vergeben. - -Auch ist es notwendig den Typ anzugeben, in diesem Fall ist es `string`. - -Nachdem der Parameter festgelegt ist, nutzen wir als Vorlage das vorige -Template und ergänzen es. +Nachdem wir den Parameter festgelegt haben, nutzen wir das vorige Template als Vorlage und ergänzen es. -Damit sieht das Template dann so aus: +Das Template sieht dann so aus: ```yaml heat_template_version: 2014-10-16 @@ -70,13 +55,11 @@ resources: flavor: m1.small ``` -Um das Template zu komplettieren, wird `key_name` durch den vorher -definierten Parameter ersetzt. +Um das Template zu vervollständigen, ersetzen wir `key_name` durch den vorher definierten Parameter. Der Befehl dafür lautet `get_param`. -Dieser sagt aus, dass er einen definierten Parameter nutzen soll und -damit das Template weiß, welchen Parameter er nutzen soll, ergänzen wir +Dieser Befehl sagt aus, dass ein definierter Parameter genutzt werden soll. Damit das Template weiß, welchen Parameter es nutzen soll, ergänzen wir den Befehl `get_param` um `key_name`: ```yaml @@ -95,8 +78,6 @@ resources: flavor: m1.small ``` -Abschluss ---------- +## Zusammenfassung -Das Template wurde jetzt bereits über einen frei definierbaren Parameter -erweitert und im nächsten Schritt wird das Netzwerk hinzugefügt. +Wir haben das Template mit einem frei definierbaren Parameter erweitert. Im nächsten Schritt fügen wir das Netzwerk hinzu. diff --git a/docs/_optimist/guided_tour/step17/index.de.md b/docs/_optimist/guided_tour/step17/index.de.md index 204d33062..6a0bf8b75 100644 --- a/docs/_optimist/guided_tour/step17/index.de.md +++ b/docs/_optimist/guided_tour/step17/index.de.md @@ -1,28 +1,22 @@ --- -title: "17: Das Netzwerk im Heat" +title: "17: Das Netzwerk in Heat" lang: "de" permalink: /optimist/guided_tour/step17/ nav_order: 1170 parent: Guided Tour --- -Schritt 17: Das Netzwerk im Heat -================================ +# Schritt 17: Das Netzwerk in Heat -Vorwort -------- +## Einführung -Im letzten Schritt war ein individueller Parameter das Ziel und in -diesem das komplette Netzwerk. +Im letzten Schritt haben wir ein einfaches Template mit einem individuellen Parameter erstellt. In diesem Schritt fügen wir das Netzwerk hinzu. -Das Template ------------- +## Das Template -Um nicht bei Null zu starten, dient das Template aus dem vorigen Schritt -als Vorlage. - -Wichtig ist dabei, dass direkt ein neuer Parameter hinzufügt wird, -genauer die ID des öffentlichen Netzwerks: +Wir verwenden wieder das Template aus dem vorigen Schritt +als Vorlage und fügen einen neuen Parameter hinzu. +In unserem Fall ist das die ID des öffentlichen Netzwerks. Wir nennen sie `public_network_id`, und definieren als default `provider`: ```yaml heat_template_version: 2014-10-16 @@ -43,14 +37,12 @@ resources: flavor: m1.small ``` -Netzwerk --------- +## Netzwerk -Nachdem dieser Parameter eingefügt wurde, ist es Zeit das Netzwerk in -das Template einzufügen. +Nachdem dieser Parameter eingefügt wurde, fügen wir das Netzwerk in +das Template hinzu. -Hierbei handelt es sich um eine weitere Ressource und wird unter dem -Punkt `resources` eingefügt. +Hierbei handelt es sich um eine weitere Ressource. Diese wird unter `resources` eingefügt. Der zugehörige Typ lautet `OS::Neutron::Net`: @@ -78,17 +70,15 @@ resources: name: BeispielNetzwerk ``` -Der Port --------- +## Der Port -Der nächste Schritt ist dann der Port, der Typ lautet dafür +Nun fügen wir den Port hinzu. Der Typ dafür lautet: `OS::Neutron::Port`. -Wichtig ist, dass der Port in das bestehende Netzwerk eingegliedert wird -und die Instanz dem Port zuzuordnen ist. +Wichtig ist, dass der Port in das bestehende Netzwerk eingegliedert wird und die Instanz dem Port zugeordnet wird. -Um dies zu erreichen, wird erneut ein get Befehl genutzt und statt dem -Parameter eine Ressource eingebunden: +Dazu nutzen wir erneut einen `get` Befehl und binden anstelle des +Parameters eine Ressource ein: ```yaml heat_template_version: 2014-10-16 @@ -119,11 +109,10 @@ resources: network: { get_resource: Netzwerk } ``` -Der Router ----------- +## Der Router -Nachdem Netzwerk und Port, wird nun ein Router (Typ = -`OS::Neutron::Router`) in das Template eingebunden. +Nachdem wir Netzwerk und Port hinzugefügt haben, binden wir einen Router (Typ = +`OS::Neutron::Router`) in das Template ein. Bei diesem Typ ist es wichtig, das öffentliche Netzwerk einzubinden: @@ -161,14 +150,11 @@ resources: name: BeispielRouter ``` -Das Subnet ----------- +## Das Subnet -Der vorletzte Schritt ist das Subnet (Typ = `OS::Neutron::Subnet` ) +Im vorletzten Schritt definieren wir das Subnet (Typ = `OS::Neutron::Subnet` ). -In selbigem werden eigene Nameserver eintragen, die Informationen des -Netzwerks eingebunden, die IP-Version sowie der IP-Adressraum festgelegt -und die verfügbaren IPs definiert: +In diesem tragen wir eigene Nameserver ein, binden die Netzwerk-Informationen ein, legen die IP-Version und den IP-Adressraum fest und definieren die verfügbaren IPs: ```yaml heat_template_version: 2014-10-16 @@ -217,20 +203,19 @@ resources: - { start: 10.0.0.10, end: 10.0.0.250 } ``` -Subnet Bridge -------------- +## Subnet Bridge -Im letzten Schritt wird eine Subnet Bridge (Typ = -`OS::Neutron::RouterInterface`) angelegt, also eine Brücke zwischen Router und +Im letzten Schritt legen wir eine Subnet Bridge (Typ = +`OS::Neutron::RouterInterface`) an, also eine Brücke zwischen Router und Subnet. -Auch gibt es hier eine weitere neue Komponente, genauer `depends_on`. +Auch gibt es hier eine weitere neue Komponente, `depends_on`. -Damit können wir Resource erstellen lassen, die nur dann gebaut werden, +Damit können wir Resourcen erstellen lassen, die nur dann gebaut werden, wenn es die referenzierte Resource auch gibt.   In unserem Beispiel wird die Bridge zwischen Subnet und Router nur -gebaut, wenn es auch ein Subnet gibt. +gebaut, wenn es ein Subnet gibt. ```yaml heat_template_version: 2014-10-16 @@ -286,9 +271,8 @@ resources: subnet: { get_resource: Subnet } ``` -Abschluss ---------- +## Zusammenfassung -Nachdem nun das komplette Netzwerk eingerichtet wurde, wird im nächsten -Schritt eine eigene Security Group erstellt und zusätzlich der Instanz -eine öffentliche IP-Adresse zugewiesen. +Wir haben nun das komplette Netzwerk eingerichtet. Im nächsten +Schritt erstellen wir eine eigene Security Group und weisen der Instanz +eine öffentliche IP-Adresse zu. diff --git a/docs/_optimist/guided_tour/step18/index.de.md b/docs/_optimist/guided_tour/step18/index.de.md index 4fe5e3453..d45d6a5d4 100644 --- a/docs/_optimist/guided_tour/step18/index.de.md +++ b/docs/_optimist/guided_tour/step18/index.de.md @@ -1,29 +1,25 @@ --- -title: "18: Unsere Instanz wird von außen per IPv4 erreichbar" +title: "18: Unsere Instanz wird von außen über IPv4 erreichbar" lang: "de" permalink: /optimist/guided_tour/step18/ nav_order: 1180 parent: Guided Tour --- -Schritt 18: Unsere Instanz wird von außen per IPv4 erreichbar -============================================================= +# Schritt 18: Unsere Instanz wird von außen über IPv4 erreichbar -Vorwort -------- +## Einführung -Im letzten Schritt wurde das komplette Netzwerk eingerichtet -und es ist nun an der Zeit, die Instanz von außen zu erreichen (u.a. per ICMP +Im letzten Schritt haben wir das komplette Netzwerk eingerichtet. In diesem Schritt zeigen wir, wie +die Instanz von außen erreicht werden kann (u.a. über ICMP und SSH Zugriff). -Floating-IP ------------ +## Floating-IP -Den Anfang macht die öffentliche IP-Adresse, welche auch als Ressource -hinzugefügt wird. (Der zugehörige Typ lautet `OS::Neutron::FloatingIP`). +Zunächst definieren wir die öffentliche IP-Adresse, welche auch als Ressource +hinzugefügt wird. Der zugehörige Typ lautet `OS::Neutron::FloatingIP`. -Wichtig ist, dass der Floating IP der entsprechende Port und welches das -öffentliche Netz genutzt wird, mitgeteilt wird: +Wichtig ist, dass wir der Floating IP den entsprechenden Port und das öffentliche Netz, das genutzt wird, mitteilen: ```yaml heat_template_version: 2014-10-16 @@ -87,27 +83,22 @@ resources: port_id: { get_resource: Port } ``` -Security Groups ---------------- +## Security Groups -Wird das oben geschriebene Template gestartet, würde die Instanz -erstellt werden, nur kann diese aufgrund der voreingestellten Security -Group nicht erreicht werden. +Wenn das oben geschriebene Template gestartet wird, würde die Instanz +zwar erstellt werden, kann aber aufgrund der voreingestellten Security Group nicht erreicht werden. -Um dies zu ändern, wird eine Security Group (Typ -= `OS::Neutron::SecurityGroup`). +Um dies zu ändern, legen wir eine Security Group an mit dem Typ += `OS::Neutron::SecurityGroup`. -Auch gibt es einige Besonderheiten zu beachten, es wird zum einen mit -Regeln (rules) gearbeitet und zum anderen müssen selbige noch dem Port -zugewiesen werden. +Auch gibt es einige Besonderheiten zu beachten. So wird mit +Regeln (`rules`) gearbeitet, die dem Port zugewiesen werden müssen. -So kann die `direction` (Richtung des Traffics) in `ingress` (eingehend) -oder `egress` (ausgehend) eingeteilt, der entsprechende Port oder auch -die Range der Ports definiert und auch das Protokoll festgelegt -werden. +Dann kann die `direction` (Richtung des Traffics) in `ingress` (eingehend) +oder `egress` (ausgehend) eingeteilt werden. Außerdem können der entsprechende Port oder auch +die Range der Ports definiert und das Protokoll festgelegt werden. -Außerdem kann mit `remote_ip_prefix` noch festgelegt werden, wer die -Instanz erreicht (falls nötig). +Außerdem wird mit `remote_ip_prefix` festgelegt, wer die Instanz erreicht (falls nötig). ```yaml heat_template_version: 2014-10-16 @@ -180,10 +171,8 @@ resources: - { direction: ingress, remote_ip_prefix: 0.0.0.0/0, protocol: icmp } ``` -Abschluss ---------- +## Zusammenfassung -Die erstellte Instanz ist von außen erreichbar inklusive einer -öffentliche IP. +Die erstellte Instanz ist nun von außen erreichbar einschließlich. -Im nächsten Schritt wird die Instanz per CloudConfig angepasst. +Im nächsten Schritt passen wir die Instanz mit CloudConfig an. diff --git a/docs/_optimist/guided_tour/step19/index.de.md b/docs/_optimist/guided_tour/step19/index.de.md index 7ff1f50a8..184ac86fa 100644 --- a/docs/_optimist/guided_tour/step19/index.de.md +++ b/docs/_optimist/guided_tour/step19/index.de.md @@ -6,34 +6,25 @@ nav_order: 1190 parent: Guided Tour --- -Schritt 19: Unsere Instanz lernt IPv6 -===================================== +# Schritt 19: Unsere Instanz lernt IPv6 -Vorwort -------- +## Einführung Nachdem im letzten Schritt die Instanz mit einer öffentlichen -IPv4 Adresse versehen wurde und diese auch per SSH erreichbar ist, wird es nun -Zeit die Instanz selber anzupassen. +IPv4 Adresse versehen wurde und diese auch mit SSH erreichbar ist, passen wir in diesem Schritt die Instanz an. -Dafür nutzen wir in diesem Schritt CloudConfig und passen auch die Security Group an. +Dafür nutzen wir CloudConfig und passen auch die Security Group an. -CloudConfig ------------ +## CloudConfig -Ist eine Ressource und wird daher auch unter `resources` geführt. (Typ = -`OS::HEAT::CloudConfig`) +`CloudConfig` ist eine Ressource und wird daher unter `resources` geführt (Typ = +`OS::HEAT::CloudConfig`). -Es gibt sehr viele Möglichkeiten, was alles in einer Instanz mit -CloudConfig bearbeiten werden kann. +In einer Instanz kann mit +`CloudConfig` alles mögliche bearbeitet werden. +Im diesem Schritt nutzen wir die Ressource, um alles notwendige für IPv6 vorzubereiten. -Im diesem Schritt beschäftigen wir uns damit, alles notwendige für IPv6 -vorzubereiten. - -Der Start macht hierbei das erstellen der entsprechenden Dateien mit dem -notwendigen Inhalt, den wir bereits aus Schritt 11: Zugriff aus -dem Internet vorbereiten: Wir ergänzen IPv6 kennen und nutzen CloudConfig -in der `cloud_config` den Befehl `write_files`: +Wir beginnen mit dem Erstellen der entsprechenden Dateien. Dazu nutzen wir den Inhalt aus [Schritt 11](/optimist/guided_tour/step11/) und in `cloud_config` den Befehl `write_files`: ```yaml heat_template_version: 2014-10-16 @@ -127,9 +118,9 @@ resources: - { direction: ingress, remote_ip_prefix: 0.0.0.0/0, protocol: icmp } ``` -Wir haben die Dateien erstellt und den entsprechenden Inhalt eingefügt. +Wir haben nun die Dateien erstellt und den entsprechenden Inhalt eingefügt. -Wie in [Schritt 11: Zugriff aus dem Internet vorbereiten: Wir ergänzen IPv6](/optimist/guided_tour/step11/) beschrieben, ist es noch notwendig das Interface mit dem Befehl `runcmd` neu zustarten. +Wie in [Schritt 11](/optimist/guided_tour/step11/) beschrieben, muss das Interface mit dem Befehl `runcmd` neu gestartet werden. ```yaml heat_template_version: 2014-10-16 @@ -325,9 +316,8 @@ resources: - { direction: ingress, remote_ip_prefix: "::/0", protocol: ipv6-icmp, ethertype: IPv6 } ``` -Abschluss ---------- +## Zusammenfassung -Wir haben nun die Möglichkeit Instanzen per Cloud-Init anzupassen und IPv6 nutzbar gemacht. +Sie wissen nun, wie man Instanzen mit Cloud-Init anpassen und IPv6 nutzen kann. -Im nächsten und letzten Schritt werden wir mehrere Instanzen per Heat starten. +Im nächsten und letzten Schritt werden wir mehrere Instanzen mit Heat starten. diff --git a/docs/_optimist/guided_tour/step20/index.de.md b/docs/_optimist/guided_tour/step20/index.de.md index 92b2adfb5..3e3844ef6 100644 --- a/docs/_optimist/guided_tour/step20/index.de.md +++ b/docs/_optimist/guided_tour/step20/index.de.md @@ -6,27 +6,21 @@ nav_order: 1200 parent: Guided Tour --- -Schritt 20: Mehrere Instanzen gleichzeitig erstellen -==================================================== +# Schritt 20: Mehrere Instanzen gleichzeitig erstellen -Vorwort -------- +## Einführung -Nachdem im Schritt 15 eine Instanz inklusive aller wichtigen -Einstellungen angelegt wurde, ist der nächste Schritt, mehr als eine -Instanz per Template zu starten. +Nachdem Sie in [Schritt 15](/optimist/guided_tour/step15/) eine Instanz inklusive aller wichtigen +Einstellungen angelegt haben, lernen Sie in diesem Schritt, wie Sie mehr als eine Instanz pro Template starten können. -In diesem Schritt, werden zwei Instanzen erstellt, die ein gemeinsames -Netzwerk nutzen. +Dazu erstellen wir zwei Instanzen, die ein gemeinsames Netzwerk nutzen. -Start ------ +## Start -Neben den beiden Instanzen wird auch das Template aufgeteilt und in zwei -Dateien erstellt. +Neben den beiden Instanzen teilen wir auch das Template in zwei Dateien auf. -Dies hat verschiedene Teile und den Start macht ein simples Template, -welches nur ein Net und ein Subnet enthält: +Wir starten mit einem einfachen Template, +welches nur ein Netzwerk und ein Subnet enthält: ```yaml heat_template_version: 2014-10-16 @@ -54,18 +48,13 @@ resources: - {start: 10.0.0.10, end: 10.0.0.250} ``` -Dies stellt das Grundgerüst des Stacks dar und wird vorerst als -`Gruppen.yaml` gespeichert. +Dieses Template stellt das Grundgerüst des Stacks dar und wird vorerst als `Gruppen.yaml` gespeichert. -Die Instanzen selber werden in einer zweiten Datei `BeispielServer.yaml` -beschrieben, welche dem gleichen Aufbau wie in den vorigen Schritten -folgt. - -Um `image:` zu füllen kann wahlweise der Image Name oder die Image-ID benutzt werden. +Die Instanzen selbst beschreiben wir in einer zweiten Datei `BeispielServer.yaml`. Sie haben den gleichen Aufbau wie in den vorigen Schritten. +Um `image:` zu füllen, kann wahlweise den Image Name oder die Image-ID benutzt werden. Eine korrekte Image-ID bzw. einen korrekten Namen erhält man mit `openstack image list`. -Es ist wichtig, dass kein Server-Namen definiert wird und -`network_id` auch keinen Eintrag erfährt: +Es ist wichtig, dass kein Server-Namen definiert wird und `network_id` keinen Eintrag hat: ```yaml heat_template_version: 2014-10-16 @@ -96,17 +85,11 @@ resources: network: { get_param: network_id } ``` -Nachdem die Datei fertiggestellt wurde, wird diese wie oben beschrieben -als `BeispielServer.yaml` gespeichert. - -Um weiter fortzufahren, wird die Arbeit am ursprünglichen Template -(`Gruppen.yaml`) fortgesetzt. +Nachdem wir die Datei fertiggestellt haben, wird diese wie oben beschrieben als `BeispielServer.yaml` gespeichert. -Hier gilt es nun, das zweite erstellte Template als RessourceGroup -einzubinden. +Als nächstes setzen wir die Arbeit am ursprünglichen Template (`Gruppen.yaml`) fort und binden das zweite erstellte Template als `RessourceGroup` ein. -Auch ist so direkt die Möglichkeit gegeben, die Anzahl der Instanzen, -die Namen etc. anzugeben: +Dadurch können wir direkt die Anzahl der Instanzen, die Namen, usw. angeben: ```yaml heat_template_version: 2014-10-16 @@ -145,17 +128,15 @@ resources: - {start: 10.0.0.10, end: 10.0.0.250} ``` -Nachdem die Arbeit an `Gruppen.yaml` abgeschlossen wurde, kann der so -erstellte Stack direkt mit dem OpenStackClient gestartet werden: +Nachdem wir die Arbeit an `Gruppen.yaml` abgeschlossen haben, können wir den so +erstellten Stack direkt mit dem OpenStackClient starten: ```bash openstack stack create -t Gruppen.yaml ``` -Abschluss ---------- +## Zusammenfassung -Nachdem am Anfang der Guided Tour noch Instanzen per Hand erstellt -wurden, können nun bereits mehrere Instanzen gleichzeitig per Template -ausgerollt werden und stellen einen guten Startpunkt für die Administration -von OpenStack dar. +Nachdem Sie am Anfang der Guided Tour noch Instanzen per Hand erstellt +haben, können Sie nun bereits mehrere Instanzen gleichzeitig über ein Template +ausrollen. Dies stellt einen guten Ausgangspunkt für die Administration von OpenStack dar. diff --git a/docs/_optimist/guided_tour/step21/index.de.md b/docs/_optimist/guided_tour/step21/index.de.md index 39f37312a..404ae60d4 100644 --- a/docs/_optimist/guided_tour/step21/index.de.md +++ b/docs/_optimist/guided_tour/step21/index.de.md @@ -6,88 +6,74 @@ nav_order: 1210 parent: Guided Tour --- -Schritt 21: Eine Instanz von einem SSD-Volume starten -===================================================== +# Schritt 21: Eine Instanz von einem SSD-Volume starten -Vorwort -------- +## Einführung -In den vorigen Schritten haben wir uns bereits eine eigene Instanz erstellt -und auch die ersten Grundlagen in HEAT sind gelegt. -Wir werden in diesem Schritt eine Instanz von einem Volume starten -und dafür den SSD-Speicher nutzen. -Auch hier gibt es mehrere Wege unser Ziel zu erreichen, -daher werden wir in diesem Schritt sowohl das Horizon(Dashboard) nutzen, -als auch unser HEAT Template aus [Schritt 18](/optimist/guided_tour/step18/) weiter modifizieren. +In den vorherigen Schritten haben Sie bereits eine eigene Instanz erstellt. +In diesem Schritt lernen Sie wie man eine Instanz von einem Volume startet und dafür den SSD-Speicher nutzt. +Auch hier gibt es mehrere Wege, um das zu erreichen. Wir werden in diesem Schritt sowohl das Horizon Dashboard nutzen, +als auch das HEAT-Template aus [Schritt 18](/optimist/guided_tour/step18/) weiter modifizieren. -Der Weg über das Horizon(Dashboard) ------ +## Der Weg über das Horizon Dashboard -Um zu starten, loggen wir uns zunächst wie in -"Schritt 1: Das Dashboard (Horizon)" erklärt ins Horizon(Dashboard) ein. -Hier wechseln wir links in der Seitenleiste auf -Project → Volumes → Volumes und klicken dann rechts auf "+ Create Volume" +Loggen Sie sich zunächst wie in +[Schritt 1](/optimist/guided_tour/step01/) erklärt, ins Horizon Dashboard ein. +Wechseln Sie links in der Seitenleiste auf +*Project → Volumes → Volumes* und klicken rechts auf *+ Create Volume*. ![](attachments/04052019211.png) -In dem sich öffnenden Fenster geben wir folgende Optionen an -und klicken dann auf "Create Volume": + Machen Sie in dem sich öffnenden Fenster die folgenden Eingaben: -- Volume Name: Hier wird der Name des Volumes vergeben, dieser kann frei gewählt werden. Im Beispiel wird nach der Auswahl des Images automatisch "Ubuntu 16.04 Xenial Xerus - Latest" eingetragen. -- Description: In diesem Feld kann eine Beschreibung hinzugefügt werden, je nach Bedarf. Im Beispiel wird keine Beschreibung verwendet. -- Volume Source: Hier kann zwischen "Image" und "No source, empty image" gewählt werden. Für unser Beispiel nutzen wir "Image". -- Use image as a source: Es kann ein beliebiges Image genutzt werden. Im Beispiel wird "Ubuntu 16.04 Xenial Xerus - Latest (276.2 MB)" verwendet. -- Type: Hier besteht die Wahl zwischen "high-iops", "low-iops" und "default". Da wir SSD-Speicher nutzen wollen, wählen wir "high-iops" aus. -- Size: In diesem Feld bestimmen wir die Größe des Volumes, bei unseren Flavors sind es 20 GiB, daher nutzen wir dies auch für unser Beispiel -- Availability Zone: Hier kann man zwischen 3 Optionen "Any Availability Zone", "es1" oder "ix1" wählen und die entsprechende Zone festlegen. Im Beispiel nutzen wir ix1. +- `Volume Name`: Vergeben Sie den Namen des *Volumes*. Dieser ist frei wählbar. Im Beispiel wird nach der Auswahl des Images automatisch *Ubuntu 16.04 Xenial Xerus - Latest* eingetragen. +- `Description`: In diesem Feld können Sie, je nach Bedarf, eine Beschreibung hinzufügen. In unserem Beispiel verwenden wir keine Beschreibung. +- `Volume Source`: Hier können Sie zwischen *Image* und *No source, empty image* wählen. Für unser Beispiel nutzen wir *Image*. +- `Use image as a source`: Sie können ein beliebiges Image nutzen. Im Beispiel verwenden wir *Ubuntu 16.04 Xenial Xerus - Latest (276.2 MB)*. +- `Type`: Hier können Sie zwischen *high-iops*, *low-iops* und *default* wählen. Da wir SSD-Speicher nutzen wollen, wählen Sie *high-iops* aus. +- `Size`: In diesem Feld bestimmen Sie die Größe des Volumes. Bei unseren Flavors sind es 20 GiB, daher nutzen wir dies auch für unser Beispiel. +- `Availability Zone`: Hier können Sie zwischen drei Optionen *Any Availability Zone*, *es1* oder *ix1* wählen und die entsprechende Zone festlegen. Im Beispiel nutzen wir *ix1*. ![](attachments/04052019212.png) -Nachdem das Horizon das Volume korrekt erstellt hat, -sollte es in etwa so aussehen: +Klicken Sie anschließend auf *Create Volume*. + +Nachdem Horizon das Volume korrekt erstellt hat, sollte es in etwa so aussehen: ![](attachments/04052019213.png) -Um eine neue Instanz von diesem Volume zu starten, können wir entweder -rechts auf den Pfeil nach unten, neben "Edit Volume", -klicken und dann auf "Launch as Instance" oder -alternativ dazu kann man auch links in der Seitenleiste auf -Compute → Instances wechseln und dort auf "Launch Instane" klicken. +Um eine neue Instanz von diesem Volume zu starten, können Sie rechts auf den Pfeil nach unten neben *Edit Volume* +klicken und dann auf *Launch as Instance*. Alternativ dazu können Sie links in der Seitenleiste zu +*Compute → Instances* wechseln und auf *Launch Instance* klicken. -Im sich öffnenden Fenster geben wir der Instanz einen Namen (Instance Name), -wählen dieselbe Availability Zone wie weiter oben, -also ix1 und wechseln dann links auf Source. +Geben Sie in dem sich öffnenden Fenster der Instanz einen Namen (Instance Name), +wählen dieselbe *Availability Zone* wie weiter oben, +also *ix1*, und wechseln links auf *Source*. ![](attachments/04052019214.png) -Unter Source wählen wir Volume als Select Boot Source aus und klicken dann -neben unserem erstellten Volume auf den Pfeil nach oben. +Unter *Source* wählen Sie *Volume* als *Select Boot Source* aus und klicken neben dem erstellten Volume auf den Pfeil nach oben. ![](attachments/04052019215.png) -Nun klicken wir links auf Flavor und wählen einen der möglichen Flavors aus, -indem wir auf den Pfeil nach oben neben dem gewünschten Flavor klicken. +Klicken Sie nun links auf *Flavor* und wählen einen der möglichen Flavors aus. Klicken Sie dazu neben dem gewünschten Flavor auf den Pfeil nach oben. ![](attachments/04052019216.png) -Im nächsten Schritt wählen wir links, -über den Reiter Networks das Netzwerk für die VM aus. -Auch hier klicken wir neben dem gewünschten Netzwerk auf den Pfeil nach oben. +Wählen Sie nun links über den Reiter *Networks* das Netzwerk für die VM aus. Klicken Sie auch hier neben dem gewünschten Netzwerk auf den Pfeil nach oben. ![](attachments/04052019217.png) -Damit sind alle wichtigen Einstellungen getroffen -und die Instanz kann mit "Launch Instance" gestartet werden. -Falls benötigt, können noch eigene Security Groups und/oder -Key Pairs der Instanz hinzugefügt werden. +Damit sind alle wichtigen Einstellungen vorhanden und Sie können die Instanz mit *Launch Instance* starten. +Falls nötig, können Sie der Instanz noch eigene Security Groups und/oder +Key Pairs hinzufügen. -Der Weg über HEAT ---------------- +## Der Weg über HEAT -Wie bereits im Vorwort erwähnt, nutzen wir unser HEAT Template aus Schritt 18. +Wie bereits im Vorwort erwähnt, nutzen wir unser HEAT-Template aus [Schritt 18](/optimist/guided_tour/ste18/). Dieses Template startet bereits eine Instanz. Damit diese nun aber ein SSD-Volume nutzt, bedarf es einiger Änderungen. -Zunächst fügen wir unseren Parametern noch die "availability_zone" hinzu: +Fügen Sie zunächst Ihren Parametern noch die "availability_zone" hinzu: ```yaml heat_template_version: 2014-10-16 @@ -103,8 +89,7 @@ parameters: default: ix1 ``` -Der nächste Schritt ist am Ende des Templates -einen eigenen Punkt "boot_ssd" für das Volume hinzuzufügen: +Als nächstes müssen Sie am Ende des Templates einen eigenen Punkt *boot_ssd* für das Volume hinzufügen: ```yaml boot_ssd: @@ -117,15 +102,12 @@ einen eigenen Punkt "boot_ssd" für das Volume hinzuzufügen: image: "Ubuntu 16.04 Xenial Xerus - Latest" ``` -Nun haben wir bereits einen Parameter hinzugefügt -und nutzten diesen auch direkt in unserem neu erstellten Boot-Volume. -Damit die Instanz auch vom Volume startet, -überarbeiten wir den Punkt "Instanz" in unserem HEAT-Template . -Dort können wir den Punkt "image" entfernen -(im Beispiel ist er per # auskommentiert), +Nun haben Sie einen Parameter hinzugefügt und nutzten diesen auch direkt in dem neu erstellten Boot-Volume. +Damit die Instanz auch vom Volume startet, müssenSie den Punkt "Instanz" in Ihrem HEAT-Template überarbeiten. +Dort können Sie den Punkt *image* entfernen (im Beispiel ist er mit # auskommentiert), da dieser ja über das Volume bereitgestellt wird. -Wir fügen nun noch die "availability_zone", einen Namen "name", -das Netzwerk "networks" und das Volume "block_device_mapping" hinzu: + Fügen Sie nun noch die `availability_zone` , einen Namen `name`, +das Netzwerk `networks` und das Volume *block_device_mapping* hinzu: ```yaml Instanz: @@ -144,7 +126,7 @@ das Netzwerk "networks" und das Volume "block_device_mapping" hinzu: delete_on_termination: "true" } ] ``` -Damit ist unser HEAT-Template für diesen Schritt fertig und sollte so aussehen: +Damit ist Ihr HEAT-Template für diesen Schritt fertig und sollte so aussehen: ```yaml heat_template_version: 2014-10-16 @@ -238,11 +220,8 @@ resources: image: "Ubuntu 16.04 Xenial Xerus - Latest" ``` -Abschluss ---------- +## Zusammenfassung -In diesem Schritt haben wir gelernt, dass es ohne Weiteres möglich ist, -eine Instanz auch von einem Volume zu starten -und auch gleichzeitig schnellen SSD Speicher zu nutzen. -Außerdem haben wir unsere HEAT-Kenntnisse aufgefrischt +In diesem Schritt haben Sie gelernt, eine Instanz auch von einem Volume zu starten +und gleichzeitig einen schnellen SSD Speicher zu nutzen. Außerdem haben Sie Ihre HEAT-Kenntnisse aufgefrischt und ein Volume mit eingebunden. diff --git a/docs/_optimist/guided_tour/step22/index.de.md b/docs/_optimist/guided_tour/step22/index.de.md index 7fc0d62b6..36fa75126 100644 --- a/docs/_optimist/guided_tour/step22/index.de.md +++ b/docs/_optimist/guided_tour/step22/index.de.md @@ -8,17 +8,17 @@ parent: Guided Tour # Schritt 22: Anlegen eines DNS-Record in Designate -## Vorwort +## Einführung -Die Openstackplattform Optimist enthält eine Technologie namens DNS-as-a-Service (DNSaaS), auch bekannt als Designate. +Die Openstack Plattform Optimist enthält eine Technologie namens DNS-as-a-Service (DNSaaS), auch bekannt als Designate. DNSaaS enthält eine REST-API für die Domänen- und Datensatzverwaltung, ist multi-tenant und integriert den OpenStack Identity Service (Keystone) für die Authentifizierung. -Wir werden in diesem Schritt eine fiktive Zone (Domain) mit MX und A-Records erstellen und die entsprechende IP/CNAME hinterlegen. +In diesem Schritt lernen Sie, wie Sie eine fiktive Zone (Domain) mit MX und A-Records erstellen und die entsprechende IP/CNAME hinterlegen können. ------ +## Start -Um zu starten, lesen wir uns zunächst wie in ["Schritt 4: Der Weg vom Horizon auf die Kommandozeile"](/optimist/guided_tour/step04/) erklärt die Zugangsdaten ein und sorgen dafür das der `python-designateclient` installiert ist (pip install python-openstackclient python-designateclient) -Anschliessend bedienen wir den Openstack-Client und erstellen zuerst eine Zone für unser Projekt. +Lesen Sie zunächst wie in [Schritt 4](/optimist/guided_tour/step04/) erklärt, die Zugangsdaten ein und stellen Sie sicher, dass der `python-designateclient` installiert ist (pip install python-openstackclient python-designateclient). +Bedienen Sie anschliessend den Openstack-Client und erstellen Sie eine Zone für unser Projekt. ```bash $ openstack zone create --email webmaster@foobar.cloud foobar.cloud. @@ -45,7 +45,7 @@ $ openstack zone create --email webmaster@foobar.cloud foobar.cloud. +----------------+--------------------------------------+ ``` -Man beachte den abschliessenden "." an der zu erstellenden Zone/Domain. +Beachten Sie den abschliessenden "." an der zu erstellenden Zone/Domain. Das Resultat bisher: ```bash @@ -81,9 +81,9 @@ $ openstack zone show foobar.cloud. ``` Nun ist die Domain "foobar.cloud" für unser Projekt registriert und einsatzbereit (status: ACTIVE). -Wir wollen im nächsten Schritt MX-Records (Datensätze für Mailserver in dieser Zone) für diese Domain erstellen. +Erstellen Sie nun MX-Records (Datensätze für Mailserver in dieser Zone) für diese Domain. -Doch zuerst schauen wir, welche Inhalte (Recordsets) unsere neue Zone bereits jetzt besitzt. +Schauen Sie zuerst, welche Inhalte (Recordsets) Ihre neue Zone bereits besitzt. ```bash $ openstack recordset list foobar.cloud. @@ -96,7 +96,7 @@ $ openstack recordset list foobar.cloud. +--------------------------------------+---------------+------+--------------------------------------------------------------------------------+--------+--------+ ``` -Hier sehen wir eine "leere Hülle" einer Domain mit automatisch erstellen NS und SOA-Einträgen, die sofort zur Abfrage bereit stehen. +Hier sehen Sie eine "leere Hülle" einer Domain mit automatisch erstellen NS und SOA-Einträgen, die sofort zur Abfrage bereit stehen. ```bash $ dig +short @dns1.ddns.innovo.cloud foobar.cloud NS @@ -108,8 +108,9 @@ dns2.ddns.innovo.cloud. webmaster.foobar.cloud. 1534315524 3507 600 86400 3600 ``` Anlegen eines MX-Records: -Nun können wir Datensätze innerhalb dieser Zone hinzufügen, verändern oder löschen (openstack recordset --help). -Als nächstes fügen wir einen MX und einen A-Record hinzu. Bei den MX-Records richten wir auch gleich die typischen Mailserver-Prioritäten (10,20) mit ein. Wobei immer der niedrigere Wert als erstes angesteuert wird und der zweite Eintrag als "Backup" dient. + +Nun können Sie Datensätze innerhalb dieser Zone hinzufügen, verändern oder löschen (openstack recordset --help). +Fügen Sie als nächstes einen MX und einen A-Record hinzu. Bei den MX-Records richten Sie auch gleich die typischen Mailserver-Prioritäten (10,20) mit ein. Hier wird immer der niedrigere Wert als erstes angesteuert. Der zweite Eintrag dient als "Backup" . ```bash $ openstack recordset create --record '10 mx1.foobar.cloud.' --record '20 mx2.foobar.cloud.' --type MX foobar.cloud. foobar.cloud. @@ -184,11 +185,10 @@ $ openstack recordset list foobar.cloud. +--------------------------------------+-------------------+------+--------------------------------------------------------------------------------+--------+--------+ ``` -Wenn die Recordsets aktiv sind können wir die dafür vorgesehenen DNS-Server +Wenn die Recordsets aktiv sind, können Sie die dafür vorgesehenen DNS-Server nach diesen Records abfragen: * dns1.ddns.innovo.cloud * dns2.ddns.innovo.cloud -nach diesen Records abfragen. ```bash $ dig +short @dns1.ddns.innovo.cloud foobar.cloud NS @@ -212,7 +212,7 @@ Damit dieses Konstrukt weltweit benutzt werden kann, muss jede im Designate verw > * dns1.ddns.innovo.cloud: '185.116.244.45' / '2a00:c320:0:1::d' > * dns2.ddns.innovo.cloud: '185.116.244.46' / '2a00:c320:0:1::e' -Um die die Mail-Records abzuschliessen, bietet sich noch an für die Mailserver entsprechende A-Records zu hinterlegen +Um die Mail-Records abzuschliessen, bietet es sich an, für die Mailserver entsprechende A-Records zu hinterlegen. ```bash $ openstack recordset create --type A --record 2.3.4.5 foobar.cloud. mx1 @@ -256,7 +256,7 @@ $ openstack recordset create --type A --record 3.4.5.6 foobar.cloud. mx2 +-------------+--------------------------------------+ ``` -Das Resultat nach einigen Sekunden: +Hier ist das Ergebnis nach einigen Sekunden: ```bash $ openstack recordset list foobar.cloud. @@ -274,6 +274,6 @@ $ openstack recordset list foobar.cloud. +--------------------------------------+-------------------+------+--------------------------------------------------------------------------------+--------+--------+ ``` -## Abschluss +## Zusammenfassung -In diesem Schritt haben wir gelernt, wie man eine Zone anlegt, einen Recordset konfiguriert und diesen abfragen kann. +In diesem Schritt haben Sie gelernt, wie man eine Zone anlegt, einen Recordset konfiguriert und diesen abfragen kann. diff --git a/docs/_optimist/guided_tour/step23/index.de.md b/docs/_optimist/guided_tour/step23/index.de.md index 5aa6c7512..39d97b09a 100644 --- a/docs/_optimist/guided_tour/step23/index.de.md +++ b/docs/_optimist/guided_tour/step23/index.de.md @@ -6,20 +6,17 @@ nav_order: 1230 parent: Guided Tour --- -Schritt 23: Der Object Storage (S3 kompatibel) -================================================= +# Schritt 23: Der Object Storage (S3 kompatibel) -Vorwort -------- +## Einführung In den vorigen Schritten haben wir bereits einige interessante Bausteine kennengelernt. -Als nächstes widmen wir uns dem [Object Storage](https://en.wikipedia.org/wiki/Object_storage), der uns interessante Möglichkeiten bietet, Dateien zu speichern. +Als nächstes beschäftigen wir uns mit dem [Object Storage](https://en.wikipedia.org/wiki/Object_storage), der uns interessante Möglichkeiten bietet, Dateien zu speichern. -Der Start (Benutzerdaten) ------ +## Der Start (Benutzerdaten) -Damit wir auf den Object Storage zugreifen können, benötigen wir zunächst Login Daten(Credentials), um auf diesen zugreifen zu können. -Dafür benötigen wir den OpenStackClienten(siehe [Schritt 4](/optimist/guided_tour/step04/)), damit wir per OpenstackAPI die entsprechenden Daten erstellen. +Damit wir auf den Object Storage zugreifen können, benötigen wir zunächst Login Daten (Credentials). +Dafür benötigen wir den OpenStack Client (siehe [Schritt 4](/optimist/guided_tour/step04/)), damit wir über OpenstackAPI die entsprechenden Daten erstellen können. Der Befehl in der Kommandozeile dafür lautet: ```bash @@ -44,24 +41,23 @@ $ openstack ec2 credentials create +------------+-----------------------------------------------------------------+ ``` -Nachdem die Zugangsdaten (Credentials) vorliegen, brauchen wir eine Möglichkeit auf den S3 kompatiblen ObjectStorage zuzugreifen. +Nachdem die Zugangsdaten (Credentials) vorliegen, brauchen wir eine Möglichkeit, auf den S3 kompatiblen ObjectStorage zuzugreifen. -Zugriff auf den S3 kompatiblen ObjectStorage ---------- +## Zugriff auf den S3 kompatiblen ObjectStorage -Es gibt natürlich verschiedene Optionen auf den ObjectStorage zuzugreifen. Wir empfehlen dafür die Nutzung von [s3cmd](https://s3tools.org/s3cmd) +Es gibt verschiedene Optionen, auf den ObjectStorage zuzugreifen. Wir empfehlen dafür [s3cmd](https://s3tools.org/s3cmd). Dieses kleine Tool ist einfach zu bedienen und zu nutzen. -Da wir bereits in Schritt 4 "pip" als Paketmanager installiert haben und nutzen, können wir S3cmd auch über "pip" installieren: +Da wir bereits in [Schritt 4](/optimist/guided_tour/step04/) *pip* als Paketmanager installiert haben und nutzen, können wir S3cmd auch mit *pip* installieren: ```bash pip install s3cmd ``` -Da jetzt S3cmd installiert ist, müssen die vorher erstellten Zugangsdaten (Credentials) eingetragen werden, nur so lässt sich S3cmd auch korrekt nutzen. -Alle wichtigen Informationen finden wir in der .s3cfg , sollte diese noch nicht existieren, erstellen wir diese vorher. +Da jetzt S3cmd installiert ist, müssen die vorher erstellten Zugangsdaten (Credentials) eingetragen werden. Nur so lässt sich S3cmd korrekt nutzen. +Alle wichtigen Informationen finden wir in der `.s3cfg` Datei. Falls diese noch nicht existiert, erstellen wir diese vorher. -Folgende Daten tragen wir dann in der .s3cfg ein: +Folgende Daten tragen wir dann in `.s3cfg` ein: ```bash access_key = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa @@ -73,11 +69,10 @@ secret_key = dddddddddddddddddddddddddddddddd use_https = True ``` -Der Bucket ---------- +## Der Bucket -Da wir Zugriff auf den S3 kompatiblen Object Storage haben, ist es an der Zeit damit auch zu arbeiten. -Alle verfügbaren Befehle von s3cmd können mit folgendem Befehl angezeigt werden: +Da wir Zugriff auf den S3 kompatiblen Object Storage haben, ist es an der Zeit, damit auch zu arbeiten. +Alle verfügbaren Befehle von s3cmd können mit dem folgendem Befehl angezeigt werden: ```bash s3cmd --help @@ -85,27 +80,28 @@ s3cmd --help Als Nächstes erstellen wir einen Bucket. Buckets entsprechen dabei im weitesten Sinne Ordnern, die wir für eine Struktur benötigen. -Eine Datei kann also nur in einem existierenden Bucket gespeichert werden und der Name vom Bucket selber ist einzigartig (über den gesamten Optimist). +Eine Datei kann also nur in einem existierenden Bucket gespeichert werden. Der Name vom Bucket selbst ist einzigartig (über den gesamten Optimisten). Wenn also bereits ein Bucket mit dem Namen "Test" besteht, kann dieser nicht erneut angelegt werden. Daher ist es aus unserer Sicht eine gute Option, eine UUID zu nutzen und diese dann in der entsprechenden Applikation aufzulösen. Auch gibt es die Möglichkeit, bei Buckets und auch bei Dateien, zwischen *public* und *private* zu unterscheiden. -Alle Buckets die erstellt und Dateien die hochgeladen werden, sind per default *private*, d.h. wenn keine weiteren Einstellungen vorgenommen werden, kann nur der Ersteller auf den Bucket und den Inhalt zugreifen. +Alle Buckets, die erstellt und die Dateien, die hochgeladen werden, sind per default *private*, d.h. wenn keine weiteren Einstellungen vorgenommen werden, kann nur der Ersteller auf den Bucket und den Inhalt zugreifen. Dies lässt sich zum Beispiel per *Access Control List (ACL)* ändern. -WICHTIG: Sollte man einen kompletten Bucket auf *public* stellen, können auch Informationen über Dateien, in diesem Bucket, die auf *private* gesetzt sind, abgerufen werden. +WICHTIG: Sollte man einen kompletten Bucket auf *public* stellen, können auch Informationen über Dateien in diesem Bucket, die auf *private* gesetzt sind, abgerufen werden. -Da wir die wichtigsten Details kennen, ist es Zeit, einen Bucket mit einer UUID zu erstellen: +Nun kennen wir die wichtigsten Details und es ist Zeit, einen Bucket mit einer UUID zu erstellen: ```bash $ s3cmd mb s3://e4d05df3-aa8e-4a37-b1b5-2745d189b189 Bucket 's3://e4d05df3-aa8e-4a37-b1b5-2745d189b189/' created ``` -Eine Datei hochladen ---------- +## Eine Datei hochladen -Da wir jetzt einen Bucket erstellt haben, ist der nächste Schritt, eine oder auch mehrere Dateien hochzuladen. -Dafür nehmen wir den Befehl `s3cmd put Dateiname s3://Name_des_Buckets` und eine Ausgabe kann dann so aussehen: +Da wir jetzt einen Bucket erstellt haben können wir im nächsten Schritt, eine oder auch mehrere Dateien hoch laden. +Dafür nehmen wir den Befehl `s3cmd put Dateiname s3://Name_des_Buckets`. + +Eine Ausgabe kann dann so aussehen: ```bash $ s3cmd put test.yaml s3://e4d05df3-aa8e-4a37-b1b5-2745d189b189 @@ -113,10 +109,9 @@ upload: 'test.yaml' -> 's3://e4d05df3-aa8e-4a37-b1b5-2745d189b189/test.yaml' [1 4218 of 4218 100% in 0s 4.61 kB/s done ``` -Zugriff auf die Datei erhalten ---------- +## Zugriff auf die Datei erhalten -Die generelle URL für den Zugriff auf Dateien lautet im Optimisten **. +Die generelle URL für den Zugriff auf Dateien lautet in Optimist **. Damit auf die Datei aus unserem Beispiel zugegriffen werden kann, ist es notwendig, die Einstellung von *private* auf *public* zu ändern. Dafür können wir, wie bereits unter dem Punkt "Der Bucket" erwähnt, die *Access Control List (ACL)* nutzen: @@ -136,7 +131,6 @@ $ s3cmd setacl s3://e4d05df3-aa8e-4a37-b1b5-2745d189b189/test.yaml --acl-private s3://e4d05df3-aa8e-4a37-b1b5-2745d189b189/test.yaml: ACL set to Private [1 of 1] ``` -Abschluss ---------- +## Zusammenfassung In diesem Schritt haben wir den S3 kompatiblen Storage kennengelernt und die ersten Schritte im Umgang damit geübt. From 99355d59f8b5ac360172a295e6c511f1bb54aee3 Mon Sep 17 00:00:00 2001 From: Elisabeth Anzer Date: Fri, 1 Jul 2022 15:57:21 +0000 Subject: [PATCH 2/3] language changes on FAQ --- docs/_optimist/faq/index.de.md | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/docs/_optimist/faq/index.de.md b/docs/_optimist/faq/index.de.md index 0dcc90db9..edb6e38bc 100644 --- a/docs/_optimist/faq/index.de.md +++ b/docs/_optimist/faq/index.de.md @@ -11,13 +11,13 @@ last_modified_date: 2021-03-02 ## Der Befehl `openstack --help` zeigt bei vielen Punkten "Could not load EntryPoint.parse" an. In diesem Fall ist eine der mit dem OpenStack Client installierten Komponenten nicht aktuell. Um zu sehen, welche der Komponenten -aktualisiert werden muss, rufen wir folgenden Befehl auf: +aktualisiert werden muss, rufen Sie folgenden Befehl auf: ```bash openstack --debug --help ``` -Hier wird nun vor jedem Punkt angezeigt, was genau der Fehler ist und man kann einfach die jeweilige Komponente mit dem folgenden Befehl +Hier wird nun vor jedem Punkt angezeigt, was genau der Fehler ist und Sie können einfach die jeweilige Komponente mit dem folgenden Befehl aktualisieren (`` muss durch die richtige Komponente ersetzt werden): ```bash @@ -26,7 +26,7 @@ pip install python-client -U ## Wie kann ich [VRRP](https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol) nutzen? -Um VRRP nutzen zu können, muss dies in einer Security-Group aktiviert und dann den jeweiligen Instanzen zugeordnet werden. Aktuell ist dies +Um VRRP nutzen zu können, müssen Sie dies in einer Security-Group aktivieren und den jeweiligen Instanzen zuordnen werden. Aktuell ist dies nur mit dem Openstack Client möglich. Zum Beispiel: ```bash @@ -35,13 +35,13 @@ openstack security group rule create --remote-ip 10.0.0.0/24 --protocol vrrp --e ## Warum werden mir Floating IPs berechnet, die ich gar nicht benutze? -Der Grund dafür ist mit hoher Wahrscheinlichkeit, dass Floating IPs erstellt wurden, aber nach der Benutzung nicht korrekt gelöscht wurden. -Um eine Übersicht über die aktuell verwendeten Floating IPs zu erhalten, kann man zum einen das +Mit hoher Wahrscheinlichkeit wurden Floating IPs erstellt, aber nach der Benutzung nicht korrekt gelöscht worden. +Um eine Übersicht über die aktuell verwendeten Floating IPs zu erhalten, können Sie das [Horizon Dashboard](https://dashboard.optimist.innovo.cloud/) nutzen. Dort befindet sich der entsprechende Punkt unter _Project_ → _Network_ → _Floating-IPs_. -Alternativ der Weg per OpenStack Client: +Alternativ können Sie den OpenStack Client benutzen und folgenden Befehl eingeben: ```bash $ openstack floating ip list @@ -56,7 +56,7 @@ $ openstack floating ip list ### Resizing über die Command Line -Geben Sie den Namen oder die UUID des Servers an, dessen Größe Sie ändern möchten, und ändern Sie die Größe mit dem Befehl +Geben Sie den Namen oder die UUID des Servers an, dessen Größe Sie ändern möchten. Sie können die Größe mit dem folgenden Befehl ändern: `openstack server resize`. Geben Sie das gewünschte neue Flavor und dann den Instanznamen oder die UUID an: @@ -67,7 +67,7 @@ openstack server resize --flavor FLAVOR SERVER Die Größenänderung kann einige Zeit in Anspruch nehmen. Während dieser Zeit wird der Instanzstatus als RESIZE angezeigt. -Wenn die Resizing abgeschlossen ist, wird der Instanzstatus VERIFY_RESIZE angezeigt. Sie können nun die Größenänderung bestätigen, um den +Wenn das Resizing abgeschlossen ist, wird der Instanzstatus VERIFY_RESIZE angezeigt. Sie können nun die Größenänderung bestätigen, um den Status auf ACTIVE zu ändern: ```bash @@ -76,29 +76,28 @@ openstack server resize --confirm SERVER ### Resizing über das Optimist-Dashboard -Navigieren Sie auf [Optimist Dashboard → Instances](https://dashboard.optimist.innovo.cloud/project/instances/) zu der Instanz, deren Größe +Navigieren Sie im [Optimist Dashboard → Instances](https://dashboard.optimist.innovo.cloud/project/instances/) zu der Instanz, deren Größe geändert werden soll, und wählen Sie dann _Actions_ → _Resize Flavor_. -Der aktuelle Flavor wird angezeigt, verwenden Sie die Dropdown-Liste "Select a new flavor", um den neuen Flavor auszuwählen und bestätigen +Der aktuelle Flavor wird angezeigt. Verwenden Sie die Dropdown-Liste "Select a new flavor", um den neuen Flavor auszuwählen und bestätigen Sie mit "Resize". ## Warum ist das Logfile der Compute Instanz im Optimist Dashboard leer? -Bedingt durch Wartungsarbeiten oder einem Umverteilen der Last im OpenStack wurde die Instanz verschoben. In diesem Fall wird das Logfile +Aufgrund von Wartungsarbeiten oder einem Umverteilen der Last im OpenStack wurde die Instanz verschoben. In diesem Fall wird das Logfile neu angelegt und neue Meldungen werden wie gewohnt protokolliert. ## Warum erhalte ich den Fehler "Conflict (HTTP 409)" beim Erstellen eines Swift Containers? -Swift verwendet einzigartige Namen über die gesamte OpenStack Umgebung hinweg. Die Fehlermeldung besagt, dass der gewählte Name bereits in -Verwendung ist. +Swift verwendet einzigartige Namen über die gesamte OpenStack Umgebung hinweg. Die Fehlermeldung besagt, dass der gewählte Name bereits verwendet wird. ## Anbringen von Cinder-Volumes an Instanzen per UUID Wenn Sie mehrere Cinder-Volumes an eine Instanz anhängen, werden die Mount-Punkte möglicherweise bei jedem Neustart neu gemischt. Durch das -Mounten der Volumes per UUID wird sichergestellt, dass die richtigen Volumes wieder an die richtigen Mount-Punkte angehängt werden, falls +Mounten der Volumes mit UUID wird sichergestellt, dass die richtigen Volumes wieder an die richtigen Mount-Punkte angehängt werden, falls für die Instanz ein Aus- und Wiedereinschalten erforderlich ist. -Nachdem Sie die UUID des Volumes mit `blkid` in der Instanz abgerufen haben ändern Sie den Mountpunkt in `/etc/fstab` wie folgt, um die +Nachdem Sie die UUID des Volumes mit `blkid` in der Instanz abgerufen haben, ändern Sie den Mountpunkt in `/etc/fstab` wie folgt, um die UUID zu verwenden. Zum Beispiel: ```bash From 3c6c7c5ac556b98030140aa8eca18081af1ed7a7 Mon Sep 17 00:00:00 2001 From: "t.kearney_admin" Date: Thu, 6 Oct 2022 14:28:33 +0000 Subject: [PATCH 3/3] Fixes --- docs/_optimist/faq/index.de.md | 3 +- docs/_optimist/guided_tour/step04/index.de.md | 8 +- docs/_optimist/guided_tour/step04/index.en.md | 8 +- docs/_optimist/guided_tour/step08/index.de.md | 3 +- docs/_optimist/guided_tour/step11/index.de.md | 129 +----------------- docs/_optimist/guided_tour/step11/index.en.md | 120 ---------------- docs/_optimist/guided_tour/step18/index.de.md | 2 +- 7 files changed, 12 insertions(+), 261 deletions(-) diff --git a/docs/_optimist/faq/index.de.md b/docs/_optimist/faq/index.de.md index edb6e38bc..f39bd7eb4 100644 --- a/docs/_optimist/faq/index.de.md +++ b/docs/_optimist/faq/index.de.md @@ -26,8 +26,7 @@ pip install python-client -U ## Wie kann ich [VRRP](https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol) nutzen? -Um VRRP nutzen zu können, müssen Sie dies in einer Security-Group aktivieren und den jeweiligen Instanzen zuordnen werden. Aktuell ist dies -nur mit dem Openstack Client möglich. Zum Beispiel: +Um VRRP nutzen zu können, müssen Sie dies in einer Security-Group aktivieren und den jeweiligen Instanzen zuordnen werden. Zum Beispiel: ```bash openstack security group rule create --remote-ip 10.0.0.0/24 --protocol vrrp --ethertype IPv4 --ingress default diff --git a/docs/_optimist/guided_tour/step04/index.de.md b/docs/_optimist/guided_tour/step04/index.de.md index 1ad60b784..782991fec 100644 --- a/docs/_optimist/guided_tour/step04/index.de.md +++ b/docs/_optimist/guided_tour/step04/index.de.md @@ -81,7 +81,7 @@ erstellen Sie direkt eine solche Umgebung: ```bash $ virtualenv ~/.virtualenvs/openstack -New python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/python +New python executable in /Users/GEC/.virtualenvs/openstack/bin/python Installing setuptools, pip, wheel...done. ``` @@ -120,7 +120,7 @@ Um zu sehen, ob alles korrekt funktioniert hat, testen Sie die Ausgabe: ```bash $ type -a openstack -openstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack +openstack is /home/GEC/.virtualenvs/openstack/bin/openstack ``` ### Windows @@ -186,7 +186,7 @@ erstellen Sie direkt eine solche Umgebung: ```bash $ virtualenv ~/.virtualenvs/openstack -New python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/python +New python executable in /Users/GEC/.virtualenvs/openstack/bin/python Installing setuptools, pip, wheel...done. ``` @@ -226,7 +226,7 @@ Um zu sehen ob alles korrekt funktioniert hat, testen Sie die Ausgabe: ```bash $ type -a openstack -openstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack +openstack is /home/GEC/.virtualenvs/openstack/bin/openstack ``` ## Zugangsdaten diff --git a/docs/_optimist/guided_tour/step04/index.en.md b/docs/_optimist/guided_tour/step04/index.en.md index f2151937b..e0d269d47 100644 --- a/docs/_optimist/guided_tour/step04/index.en.md +++ b/docs/_optimist/guided_tour/step04/index.en.md @@ -80,7 +80,7 @@ After you have installed `virtualenv`, you can create the virtual environment. ```bash $ virtualenv ~/.virtualenvs/openstack -New python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/python +New python executable in /Users/GEC/.virtualenvs/openstack/bin/python Installing setuptools, pip, wheel...done. ``` @@ -119,7 +119,7 @@ Now you can check that everything works. It should look like this: ```bash $ type -a openstack -openstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack +openstack is /home/GEC/.virtualenvs/openstack/bin/openstack ``` ### Windows @@ -160,7 +160,7 @@ Now you can create a virtual environment where you install the OpenStack client. ```bash $ virtualenv ~/.virtualenvs/openstack -New python executable in /Users/iNNOVO/.virtualenvs/openstack/bin/python +New python executable in /Users/GEC/.virtualenvs/openstack/bin/python Installing setuptools, pip, wheel...done. ``` @@ -201,7 +201,7 @@ Now you can check that everything works. It should look like this: ```bash $ type -a openstack -openstack is /home/iNNOVO/.virtualenvs/openstack/bin/openstack +openstack is /home/GEC/.virtualenvs/openstack/bin/openstack ``` ## Credentials diff --git a/docs/_optimist/guided_tour/step08/index.de.md b/docs/_optimist/guided_tour/step08/index.de.md index 6114ece98..deea63f01 100644 --- a/docs/_optimist/guided_tour/step08/index.de.md +++ b/docs/_optimist/guided_tour/step08/index.de.md @@ -18,8 +18,7 @@ Damit Sie eine Instanz löschen können, benötigen Sie entweder den Namen oder Existieren nur wenige Instanzen in einem Stack, können Sie den Namen für das Löschen verwenden. -Werden allerdings mehrere Instanzen verwendet, empfehlen wir Ihnen, für das Löschen die ID zu nutzen, da Namen im Gegensatz zu IDs -nicht einzigartig sind. +Werden allerdings mehrere Instanzen verwendet, empfehlen wir Ihnen, für das Löschen die ID zu nutzen, da Namen im Gegensatz zu IDs nicht einzigartig sind. Der OpenStackClient zeigt Ihnen ansonsten an, dass es mehrere Instanzen mit dem entsprechenden Namen gibt. diff --git a/docs/_optimist/guided_tour/step11/index.de.md b/docs/_optimist/guided_tour/step11/index.de.md index 3959a99ba..9076e8a75 100644 --- a/docs/_optimist/guided_tour/step11/index.de.md +++ b/docs/_optimist/guided_tour/step11/index.de.md @@ -36,8 +36,7 @@ $ openstack subnet pool list +--------------------------------------+---------------+---------------------+ ``` -Aus diesem Pool können Sie sich nun eigene Subnetze generieren lassen. Die Prefixlänge von 64 Bit ist dabei pro generiertem Subnet fest -vorgegeben. +Aus diesem Pool können Sie sich nun eigene Subnetze generieren lassen. Die Prefixlänge von 64 Bit ist dabei pro generiertem Subnet fest vorgegeben. Bei der Erstellung der Pools können Sie die Subnets direkt mit angeben. oder Sie überlassen es OpenStack. @@ -155,132 +154,6 @@ Anpassungen bereits im Template enthalten. Um dies auch bei bestehenden Instanzen nachträglich zu ermöglichen, gibt es hier für verschiedene Linux-Distributionen eine Anleitung. -### Ubuntu 16.04 - -Um IPv6 korrekt nutzen zu können, müssen folgende Dateien mit dem -angegeben Inhalt erstellt werden. - -- `/etc/dhcp/dhclient6.conf` - - ``` - timeout 30; - ``` - -- `/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg` - - ``` - network: {config: disabled} - ``` - -- `/etc/network/interfaces.d/lo.cfg` - - ``` - auto lo - iface lo inet loopback - ``` - -- `/etc/network/interfaces.d/ens3.cfg` - - ``` - iface ens3 inet6 auto - up sleep 5 - up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true - ``` - -Im Anschluss wird das entsprechende Interface neu gestartet: - -```bash -sudo ifdown ens3 && sudo ifup ens3 -``` - -Die VM hat jetzt eine weitere IPv6 Adresse auf dem Interface, auf dem -vorher nur die IPv4 Adresse existierte und kann somit auch über IPv6 -korrekt erreicht werden. - -Damit Sie die beschriebenen Punkte nicht jedes mal manuell abarbeiten -müssen, können Sie die folgende `cloud-init` Konfiguration verwenden (was -`cloud-init` genau ist, erklären wir in [Schritt 19](/optimist/guided_tour/step19)): - -```yaml -#cloud-config -write_files: - - path: /etc/dhcp/dhclient6.conf - content: "timeout 30;" - - path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg - content: "network: {config: disabled}" - - path: /etc/network/interfaces.d/lo.cfg - content: | - auto lo - iface lo inet loopback - - path: /etc/network/interfaces.d/ens3.cfg - content: | - iface ens3 inet6 auto - up sleep 5 - up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true - -runcmd: - - [ ifdown, ens3] - - [ ifup, ens3] -``` - -### CentOS 7 - -Die genannten Parameter müssen den angegebenen Dateien neu hinzugefügt -oder falls diese bereits vorhanden sind, ergänzt werden: - -- `/etc/sysconfig/network` - - ``` - NETWORKING_IPV6=yes - ``` - -- `/etc/sysconfig/network-scripts/ifcfg-eth0` - - ``` - IPV6INIT=yes - DHCPV6C=yes - ``` - -Anschließend wird das entsprechende Interface neu gestartet: - -```bash -sudo ifdown eth0 && sudo ifup eth0 -``` - -Die VM hat jetzt eine weitere IPv6 Adresse auf dem Interface, auf dem vorher nur die IPv4 Adresse existierte und kann somit auch über IPv6 korrekt erreicht werden. - -Damit Sie die beschriebenen Punkte nicht jedes mal manuell abarbeiten -müssen, können Sie die folgende `cloud-init` Konfiguration verwenden (was -`cloud-init` genau ist, erklären wir für Ubuntu 16.04 in [Schritt 19](/optimist/guided_tour/step19/)): - -```yaml -#cloud-config -write_files: - - path: /etc/sysconfig/network - owner: root:root - permissions: '0644' - content: | - NETWORKING=yes - NOZEROCONF=yes - NETWORKING_IPV6=yes - - path: /etc/sysconfig/network-scripts/ifcfg-eth0 - owner: root:root - permissions: '0644' - content: | - DEVICE="eth0" - BOOTPROTO="dhcp" - ONBOOT="yes" - TYPE="Ethernet" - USERCTL="yes" - PEERDNS="yes" - PERSISTENT_DHCLIENT="1" - IPV6INIT=yes - DHCPV6C=yes -runcmd: - - [ ifdown, eth0] - - [ ifup, eth0] -``` - ## Externer Zugriff **Wichtig**: Diese VM ist ab sofort weltweit über ihre diff --git a/docs/_optimist/guided_tour/step11/index.en.md b/docs/_optimist/guided_tour/step11/index.en.md index fae79016a..7d4c042b1 100644 --- a/docs/_optimist/guided_tour/step11/index.en.md +++ b/docs/_optimist/guided_tour/step11/index.en.md @@ -146,126 +146,6 @@ Many standard vendor images do not have IPv6 configured and only have IPv4 enabl If you want to enable IPv6 on a VM where it is not already enabled, you can follow the instructions below. -### Ubuntu 16.04 - -To use IPv6 correctly, the following files must be created with the specified content. - -- `/etc/dhcp/dhclient6.conf` - - ```text - timeout 30; - ``` - -- `/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg` - - ```text - network: {config: disabled} - ``` - -- `/etc/network/interfaces.d/lo.cfg` - - ```text - auto lo - iface lo inet loopback - ``` - -- `/etc/network/interfaces.d/ens3.cfg` - - ```text - iface ens3 inet6 auto - up sleep 5 - up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true - ``` - -Now that you have created the files, you can reenable the interface: - -```bash -sudo ifdown ens3 && sudo ifup ens3 -``` - -Once complete, you will have working IPv4 and IPv6 addresses. - -If you want to automate the actions above, you can add this to the *cloud-init* -part of our heat template (we will go over cloud-init in [Step 19](/optimist/guided_tour/step19/): - -```yaml -#cloud-config -write_files: - - path: /etc/dhcp/dhclient6.conf - content: "timeout 30;" - - path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg - content: "network: {config: disabled}" - - path: /etc/network/interfaces.d/lo.cfg - content: | - auto lo - iface lo inet loopback - - path: /etc/network/interfaces.d/ens3.cfg - content: | - iface ens3 inet6 auto - up sleep 5 - up dhclient -1 -6 -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.ens3.leases -v ens3 || true - -runcmd: - - [ ifdown, ens3] - - [ ifup, ens3] -``` - -### CentOS 7 - -To use IPv6 correctly, the following files must be created with the specified content. - -- `/etc/sysconfig/network` - - ```text - NETWORKING_IPV6=yes - ``` - -- `/etc/sysconfig/network-scripts/ifcfg-eth0` - - ```text - IPV6INIT=yes - DHCPV6C=yes - ``` - -Now that you have created the files, you can reenable the interface: - -```bash -sudo ifdown eth0 && sudo ifup eth0 -``` - -Once complete, you will have working IPv4 and IPv6 addresses. - -If you want to automate the actions above, you can add this to the *cloud-init* -part of our heat template (we will go over cloud-init in [Step 19](/optimist/guided_tour/step19/): - -```yaml -#cloud-config -write_files: - - path: /etc/sysconfig/network - owner: root:root - permissions: '0644' - content: | - NETWORKING=yes - NOZEROCONF=yes - NETWORKING_IPV6=yes - - path: /etc/sysconfig/network-scripts/ifcfg-eth0 - owner: root:root - permissions: '0644' - content: | - DEVICE="eth0" - BOOTPROTO="dhcp" - ONBOOT="yes" - TYPE="Ethernet" - USERCTL="yes" - PEERDNS="yes" - PERSISTENT_DHCLIENT="1" - IPV6INIT=yes - DHCPV6C=yes -runcmd: - - [ ifdown, eth0] - - [ ifup, eth0] -``` - ## External access **Important:** This VM can now be reached from anywhere in the world via its IPv6 address (only on the ports that you allowed in the diff --git a/docs/_optimist/guided_tour/step18/index.de.md b/docs/_optimist/guided_tour/step18/index.de.md index d45d6a5d4..a3bbecb6f 100644 --- a/docs/_optimist/guided_tour/step18/index.de.md +++ b/docs/_optimist/guided_tour/step18/index.de.md @@ -173,6 +173,6 @@ resources: ## Zusammenfassung -Die erstellte Instanz ist nun von außen erreichbar einschließlich. +Die erstellte Instanz ist nun von außen erreichbar. Im nächsten Schritt passen wir die Instanz mit CloudConfig an.