kdevops_vagrant

kdevops_vagrant ist eine Ansible-Rolle, die eine gemeinschaftlich genutzte kdevops Vagrant-Datei in dein Projekt einfügt. Diese Ansible-Rolle kopiert die Vagrantfile-Projekt-Namespace-Verzeichnis und kann optional Vagrant für dich ausführen.

Das Ziel dieser Ansible-Rolle ist es, die Möglichkeit zu bieten, die gleiche skalierbare Vagrantfile einfach zwischen Projekten zu teilen und der Vagrantfile einen Ort zu geben, um es voranzutreiben und zu dokumentieren.

Projekt-Namespace-Verzeichnis

Das Projekt-Namespace-Verzeichnis ist das oberste Verzeichnis deines Projekts, das dein Projekt definiert. Angenommen, du hast ein Entwicklungsprojekt namens kdevops, und alle Dateien dafür sind unter:

/home/user/devel/kdevops/

gespeichert. In diesem Fall ist das Projekt-Namespace-Verzeichnis kdevops. Diese Ansible-Rolle erkennt standardmäßig, welches dein Projekt-Namespace-Verzeichnis ist, indem sie den Basenamen des Verzeichnisses verwendet, in dem sich die Playbook-Datei befindet, die diese Rolle aufruft. Zum Beispiel, wenn deine Playbook-Datei unter:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes.yml

gespeichert ist, kannst du die Daten in einer anderen Datei überschreiben:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Das Verzeichnis, in dem sich deine Playbook-Datei befindet, ist:

/home/user/devel/kdevops/playbooks/

Der Basename dieses Verzeichnisses ist:

/home/user/devel/kdevops/

Dies wäre das erkannte Projekt-Namespace-Verzeichnis für dieses Projekt. Du kannst dies durch die Verwendung der Rolle-Variable force_project_dir, die weiter unten beschrieben wird, überschreiben.

Projekt-Namespace

Der Projekt-Namespace wird innerhalb der Vagrantfile verwendet, die von dieser Rolle getragen wird, um es dir zu ermöglichen, die Standards, die für Vagrant verwendet werden, über Umgebungsvariablen zu überschreiben. Der Projekt-Namespace wird aus dem oben beschriebenen Projekt-Namespace-Verzeichnis abgeleitet. Zum Beispiel im obigen Fall, wo das Projektverzeichnis-Namespace ist:

/home/user/devel/kdevops/

Wird der Projekt-Namespace als kdevops abgeleitet. Die Großbuchstaben-Version davon wird als Präfix für Umgebungsvariablen verwendet, also KDEVOPS. Bindestriche werden durch Unterstriche ersetzt, da Shell-Variablen keine Bindestriche enthalten können. Wenn also das Projektverzeichnis-Namespace wäre:

/home/user/devel/some-cool-project/

Wäre der Projekt-Namespace: SOME_COOL_PROJECT.

Anforderungen

Du musst Vagrant installiert haben.

Vagrant wird verwendet, um einfach nicht-cloud-basierte virtuelle Maschinen bereitzustellen. Unten findest du die unterstützten Anbieter:

• Virtualbox
• libvirt (KVM)

Die folgenden Betriebssysteme werden unterstützt:

• OS X
• Linux

Ausführen von libvirt als regulärer Benutzer

Wir nutzen die https://github.com/mcgrof/libvirt-user Ansible-Rolle, um einen regulären Benutzer zu ermöglichen. Lies die dortige Dokumentation für die Logik dazu.

Überschreiben der Knoten-Konfiguration mit einer anderen Datei

Der bessere Weg, um Variablen in Vagrant zu überschreiben, ist durch die Datei $(project)_node_override.yaml. Zum Beispiel kannst du für das https://github.com/mcgrof/kdevops Daten in einer anderen optionalen Datei außerhalb von Git überschreiben:

/home/user/devel/kdevops/playbooks/kdevops_vagrant_nodes_override.yaml

Umgebungsvariablen

Nur wenn die Verwendung einer Überschreibungsdatei nicht funktioniert, kannst du Umgebungsvariablen verwenden. Aber die Verwendung von Umgebungsvariablen erfolgt fallweise, da wir Unterstützung für jede neue hinzugefügte Variable implementieren müssen. Mit der Überschreibungsdatei kannst du alles überschreiben, sobald neues Material hinzugefügt wird.

Umgebungsvariablen werden mit der Großbuchstaben-Version des Projekt-Namespace, wie oben beschrieben, vorangestellt. Lass uns dies als ${PN_U} bezeichnen. Unter Berücksichtigung dieses Präfixes ändern die folgenden Umgebungsvariablen die Funktionsweise der Vagrantfile:

• ${PN_U}_VAGRANT_NODE_CONFIG: lässt dich die Standardkonfigurationsdatei überschreiben, die verwendet wird.
• ${PN_U}_VAGRANT_PROVIDER: lässt dich den Anbieter ändern, der von Vagrant verwendet wird.
• ${PN_U}_VAGRANT_LIMIT_BOXES: ermöglicht dir das Aktivieren der Box-Beschränkung.
• ${PN_U}_VAGRANT_LIMIT_NUM_BOXES: Anzahl der Boxen, die begrenzt werden sollen.
• ${PN_U}_VAGRANT_QEMU_GROUP: überschreibt den zu verwendenden QEMU-Benutzer.

Begrenzung der Anzahl der Vagrant-Boxen

Standardmäßig versucht Vagrant, alle Knoten zu erstellen, die in deiner Knoten-Konfigurationsdatei angegeben sind. Standardmäßig ist dies ${PN_L}_nodes.yml, wobei $PN_L die Kleinbuchstaben-Version deines oben beschriebenen Projekt-Namespace ist. Zum Beispiel wäre dies für das kdevops-Projekt kdevops_nodes.yml.

Wenn du Vagrant beispielsweise auf nur eine Box im kdevops-Projekt beschränken möchtest, verwendest du:

export KDEVOPS_VAGRANT_LIMIT_BOXES="yes"
export KDEVOPS_VAGRANT_LIMIT_NUM_BOXES=1

Offensichtlich würdest du ein anderes Präfix für unterschiedlich benannte Projekte verwenden.

Damit wird sichergestellt, dass nur der erste Host, zum Beispiel, erstellt und eingerichtet wird. Dies kann nützlich sein, wenn du zum Beispiel auf einem Laptop arbeitest und die Menge der verwendeten Ressourcen begrenzen möchtest.

Einsatzbereich von Ansible

kdevops als Ganzes ist so konzipiert, dass es unabhängig von der Einrichtung eines Systems funktioniert, ob es sich um ein virtualisiertes lokales System mit libvirt / Virtualbox, ein Bare-Metal-System oder eine Cloud-Umgebung handelt.

Deshalb gibt es 3 Phasen, um es hochzufahren:

• Hochfahren: virtuell / Cloud / Bare Metal
• Konfigurieren und Installieren von Abhängigkeiten: Systeme zu ~/.ssh/config hinzufügen und die bevorzugten Bash-Skripts des Benutzers, .gitconfig und allgemeine Entwicklungspakete installieren. Dies wird durch die http://github.com/mcgrof/update_ssh_config_vagrant und http://github.com/mcgrof/devconfig Ansible-Rollen behandelt.
• Lass es laufen: erledige deine Arbeit, und dies wird typischerweise jetzt durch Ansible gefördert.

Unser Einsatz von Vagrant mit Ansible beschränkt sich auf die ersten beiden oben genannten Teile. Und so verwenden wir Ansible nur um die beiden Ansible-Rollen zu verwenden:

• http://github.com/mcgrof/update_ssh_config_vagrant
• http://github.com/mcgrof/devconfig

Wir möchten diese Praxis absichtlich nicht erweitern, und der Grund dafür ist, dass wir möchten, dass die Benutzer Ansible direkt für spätere Ziele verwenden. Die Arbeit des Hochfahrens sowie der Konfiguration und Installation von Entwickler-Abhängigkeiten muss entweder von Vagrant, Terraform oder dem Benutzer, der die Bare-Metal-Systeme manuell eingerichtet hat, erledigt werden.

Wegen dieser Gründe fördern wir nicht, zusätzliche Ansible-Rollen für die Verwendung mit Vagrant hinzuzufügen. Diese beiden Rollen sollten für typische Setups ausreichen, und die übrige Verwendung von Ansible sollte manuell erfolgen.

Ansible Python-Interpreter

Ansible ist auf Python auf den entfernten Systemen angewiesen. Welche Version von Python verwendet werden soll, variiert, aber standardmäßig wird Ansible versuchen, eine alte Version des Python-Interpreters zu verwenden, um ältere Systeme zu unterstützen. Diese Entscheidung ist nicht die beste für neuere Systeme, und deshalb wird empfohlen, den Interpreter anzugeben. Am besten wird dies in der Inventardatei festgelegt. Die Vagrantfile geht davon aus, dass du eine Inventardatei namens ../hosts hast, du kannst dies jedoch in der Ansible-Konfiguration wie folgt überschreiben:

ansible_playbooks:
  # Wenn diese Datei existiert, kannst du dort beliebige Ansible-Variablen überschreiben.
  # Diese Datei ist optional.
  extra_vars: "../extra_vars.yml"
  inventory: "../hosts"
  playbooks:
    - name: "../playbooks/update_ssh_config_vagrant.yml"
    - name: "../playbooks/devconfig.yml"

Deine Host-Datei könnte etwa so aussehen:

[all]
newsystem1
oldsystem1
[all:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[new]
newsystem1
[new:vars]
ansible_python_interpreter =  "/usr/bin/python3"

[old]
oldsystem1
[dev:vars]
ansible_python_interpreter =  "/usr/bin/python2"

In diesem Fall wird in der Gruppe [all] der Python-Interpreter auf Python3 gesetzt, allerdings wird im letzten Eintrag sichergestellt, dass das alte System stattdessen Python2 verwendet.

Verwendung von Ansible-Extra-Variablen mit Vagrant

Ansible hat eine eigene Hierarchie, wie Variablen Priorität haben, sei es über die Befehlszeile oder die Rollen-Dateien usw., und dies ist auf der https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html dokumentiert.

Während dies für die meisten Anwendungen geeignet sein kann, hilft es nicht wirklich bei Projekten, die Benutzern erlauben möchten, eigene Varianten der Standardwerte in einer nicht unter Versionskontrolle stehenden Datei anzugeben, ohne die Befehlszeile erweitern zu müssen.

Da kdevops aus einer einheitlichen Reihe von Ansible-Rollen besteht, unterstützen wir eine einheitliche Methode zur Definition von Überschreibungen für Ansible. Wir tun dies, indem wir es dem Benutzer ermöglichen, Ansible-Variablen im Stammverzeichnis des Projekts in einer Datei namens:

• extra_vars.yml

zu überschreiben. Im Beispiel des kdevops-Projekts wäre dies:

/home/user/devel/kdevops/extra_vars.yml

Wenn diese Datei gesetzt ist, wird das Vagrant-Ansible-Plugin sicherstellen, dass nur die Datei direkt über die Befehlszeile an Ansible übergeben wird via --extra-vars=@file. Das Präfix @ ist erforderlich, wenn du eine Datei angibst. Du musst das @ nicht angeben, das erledigen wir für dich.

Alle Ansible-Rollen, die mit kdevops verwendet werden, unterstützen die Suche nach dieser extra_vars-Datei.

Ansible-Rollen-Variablen

• run_vagrant: standardmäßig ist dies auf False gesetzt; wenn auf True gesetzt, führen wir Vagrant für dich aus.
• force_project_dir: Wenn gesetzt, wird dies als das Verzeichnis verwendet, in dem wir nach dem Vagrant-Verzeichnis suchen und schließlich die Vagrantfile kopieren. Standardmäßig ist dies auf leer gesetzt, und wir erkennen dein Projektverzeichnis als das übergeordnete Verzeichnis, in dem sich die Playbook-Datei befindet.

Abhängigkeiten

Keine.

Beispiel-Playbook

Nachfolgend findest du ein Beispiel-Playbook, das im kdevops-Projekt verwendet wird, also in der Datei kdevops/playbooks/kdevops_vagrant.yml:

---
- hosts: localhost
  roles:
    - role: kdevops_vagrant

Beachte in diesem speziellen Fall, wie localhost verwendet wird. Dies liegt daran, dass wir die Vagrantfile lokal in das kdevops/vagrant/-Verzeichnis bereitstellen. Du könntest offensichtlich einen anderen Host verwenden.

Weitere Informationen

Für weitere Beispiele verweise auf eines der Benutzer dieser Rolle, das https://github.com/mcgrof/kdevops Projekt oder das https://github.com/mcgrof/oscheck Projekt, aus dem dieser Code ursprünglich stammt.

Lizenz

GPLv2