Weiter zum Inhalt

Ansible Tower verwenden, um OpenShift in Azure bereitstellen zu können: Folge 2

Erstellen Sie ein Projekt und Anmeldeinformationen für Tower

In der zweiten Folge unserer Blogpost-Serie zeigen wir Ihnen, wie Sie Tower für ein paar Playbooks vorbereiten können, die wir für Sie auf Gitlab vorbereitet haben.

Sie müssen ein Projekt einrichten, bei dem es sich um eine logische Sammlung von Playbooks handelt. Das Projekt können Sie direkt auf dem Server erstellen und in ein vordefiniertes Verzeichnis wie / var / lib / awx / projects / ablegen. Es ist jedoch besser, ein Versionssystem wie Mercurial, Subversion oder Git zu verwenden. Wir haben einige Playbooks für Sie auf Gitlab vorbereitet.

Legen wir los! Loggen Sie sich jetzt in Ihren Ansible Tower ein:

1. Erstellen Sie ein Projekt

Erstellen Sie zunächst ein Projekt auf dem Tower. Ein Projekt ist eine logische Sammlung von Ansible-Playbooks, die in Tower angezeigt werden. Wir haben alle in diesem Labor verwendeten Playbooks in einem GITLab-Repository gespeichert und fügen dieses Repo dem Projekt hinzu.

Klicken Sie im Ansible Tower auf RESOURCES / Projects und dann auf die Schaltfläche + ADD -, um ein neues Projekt zu erstellen. Füllen Sie auf der Registerkarte DETAIL die folgenden Felder aus:

NAME: Azure-Bereitstellung OKD
ORGANISATION: Standardeinstellung
SCM-TYP: Git
SCM-URL: https://odyssey.devoteam.be/publicOKD/deployOkdAzure.git
SCM-UPDATE-OPTIONEN: Aktivieren Sie nur das Kontrollkästchen „Clean“.

Sie benötigen kein SCM CREDENTIAL, da dieses Repo öffentlich ist.

 

Der Punkt vor AzureDeploymentOKD sollte grün sein, was bedeutet, dass die Synchronisation des Repos erfolgreich war. Sie können auf das Cloud-Symbol klicken, um eine neue Synchronisierung zu erzwingen. Wenn Sie auf den Punkt klicken, werden die Details dieser Aktionen angezeigt. Im STANDARD OUT-Bildschirm sehen Sie, dass Ansible Tower ein Playbook verwendet, um das Repository mit GitLab zu synchronisieren.

2. Erstellen Sie ssh-keys auf Ihrem Computer

Im nächsten Schritt erstellen Sie einen Schlüssel, damit Tower mit der virtuellen Maschine kommunizieren kann, die wir bereitstellen.

Erstellen Sie einen SSH-Schlüssel auf Ihrer lokalen Maschine. Generieren Sie Ihr SSH-Schlüsselpaar. Geben Sie für diese Übung KEINE Passphrase an und akzeptieren Sie alle Standardwerte.

Erstellen Sie den privaten Schlüssel:

$ ssh-keygen -f ~/towerLabKeyPrivate

Geben Sie KEINE Passphrase ein.

Um den PRIVATEN Schlüssel zu kopieren, können Sie cat verwenden:

$ cat ~/towerLabKeyPrivate

 

Erstellen Sie den ÖFFENTLICHEN Schlüssel:

$ ssh-keygen -y -f ~/towerLabKeyPrivate > ~/towerLabKeyPublic

Um den ÖFFENTLICHEN Schlüssel zu kopieren, können Sie cat verwenden:

$ cat ~/towerLabKeyPublic

 

3. Erstellen Sie Anmeldeinformationen in Tower

Tower verwendet Anmeldeinformationen für die Authentifizierung beim Starten von Jobs gegen Maschinen, beim Synchronisieren mit Bestandsquellen und beim Importieren von Projektinhalten aus einem Versionskontrollsystem.

Sie können Benutzern und Teams die Möglichkeit geben, diese Anmeldeinformationen zu verwenden, ohne sie tatsächlich dem Benutzer offenzulegen. Wenn ein Teammitglied zu einem anderen Team wechselt oder die Organisation verlässt, müssen Sie nicht alle Ihre Systeme neu eingeben, nur weil dieser Berechtigungsnachweis in Tower verfügbar war.

Klicken Sie auf RESOURCES / Credentials.

Ein Maschinen-Berechtigungsnachweis ist erforderlich, damit Tower eine Verbindung zu den VMs herstellen kann, die wir bereitstellen. Sie benötigen dafür den privaten SSH-Schlüssel.

$ cat ~/towerLabKeyPrivate

 

Um den Schlüssel anzuzeigen, kopieren Sie diesen in Ihre Zwischenablage:

Klicken Sie auf die Schaltfläche + ADD.

NAME: clusteradmin
KREDENTLICHER TYP: Machine
TYP DETAILS:
BENUTZERNAME: clusteradmin
SSH PRIVATE KEY: <Einfügen von id_rsa>

Sie können alle anderen Felder leer lassen.

speichern

Der Schlüssel ist jetzt verschlüsselt und nur Tower kann darauf zugreifen.

4. Erstellen Sie Inventories

Ein Inventory ist eine Sammlung von Hosts, die von Tower verwaltet werden. Ansible Tower 3.2 bietet die Möglichkeit, eine Bestandsdatei aus der Quellcodeverwaltung auszuwählen, anstatt sie von Grund auf neu zu erstellen.

Diese Funktion ist identisch mit benutzerdefinierten Inventarscripts, mit der Ausnahme, dass der Inhalt von der Quellcodeverwaltung abgerufen wird, anstatt den Inhaltsbrowser zu bearbeiten. Dies bedeutet, dass die Dateien nicht bearbeitet werden können. Wenn Bestände an der Quelle aktualisiert werden, werden auch die Bestände in den Projekten entsprechend aktualisiert, einschließlich der Dateien group_vars und host_vars oder des zugehörigen Verzeichnisses.

Klicken Sie im Tower auf RESSOURCES/Inventories.

Sie benötigen zwei Inventories. Das localhost-Inventory wird von unserem Playbook 1 verwendet. Neben diesem localhost benötigen wir ein weiteres Inventory, eines für Playbook 2 und 3. Diese Intenvtories werden durch das erste Playbook, das wir ausführen, dynamisch aktualisiert. Daher verwenden wir eine Source.

Klicken Sie auf die Schaltfläche + und wählen Sie auf der Registerkarte DETAILS die Option Inventory aus.

NAME: localhost
ORGANISATION: Standardeinstellung

speichern

Klicken Sie auf der Registerkarte HOSTS auf die Schaltfläche +.

Name des Hosts: localhost

speichern

Das localhost-Inventory wird erstellt. Jetzt brauchen wir noch ein Inventory.

 

Klicken Sie auf die Schaltfläche + und wählen Sie auf der Registerkarte DETAILS die Option Inventory aus.

NAME: okd
ORGANISATION: Standardeinstellung

speichern

In der Registerkarte SOURCES.

Klicken Sie auf die Schaltfläche +.

 

Wir verwenden eine SOURCE, um die INVENTORY dynamisch zu aktualisieren.

NAME: okd
SOURCE: Aus einem Projekt gewonnen
PROJEKT: Azure-Bereitstellung OKD
INVENTORY DATEI: Inventar / Hosts (Dies ist nicht in der Dropdown-Liste, die Sie eingeben müssen!)
VERBOSITY: 2 (DEBUG)
UPDATE-OPTIONEN:
flag: Überschreiben, Variablen überschreiben, Update beim Start

Später wird dieses Inventar von Playbook 2 und 3 verwendet.

speichern

Bitte beachten Sie, dass dieses neue Inventory noch nicht synchronisiert werden kann, da die ausgewählten Dateien momentan leer sind. Sie werden durch unser erstes Playbook aktualisiert.

Was kommt als nächstes?

Dieser Blogbeitrag ist Teil der Reihe „Ansible Tower verwenden, um OpenShift in Azure bereitstellen zu können: eine Step-by-Step-Anleitung„. In der nächsten Folge erstellen wir unsere erste Jobvorlage in Ansible Tower. Diese Vorlage verwendet ein Playbook, in dem die für OKD benötigten virtuellen Maschinen in Azure installiert werden.

Schauen Sie vorbei!