Ansible-Ansatz mit mehreren Anwendungsrollen

Question

Nur ein bisschen Hintergrundwissen: Ich habe drei Jahre lang mit Puppet gearbeitet und verstehe die Architektur ziemlich gut. Unser Unternehmen überarbeitet gerade unser gesamtes Produkt, wobei die Architektur auf Microservices basiert, und beginnt, Continuous Integration/Deployment zu verwenden. Ich habe diese Gelegenheit genutzt, um unser Konfigurationsmanagement auf Ansible umzustellen, sodass ich nur ein Tool sowohl für die Bereitstellung als auch für die Konfiguration/Orchestrierung verwenden kann.

Unsere Architektur wird vollständig auf AWS basieren, mit Live-, Staging- und 3 Integrations-/QA-Umgebungen. Jeder Microservice wird seinen eigenen Bereitstellungsprozess haben und die Integrations-/QA-Umgebungen werden alle Anwendungen in einer einzigen Instanz enthalten, während Live/Staging mehrere Instanzen und in einigen Fällen verschiedene Instanzpools pro Microservice haben wird.

Mein Ziel ist es, ein einziges Ansible-Konfigurations-/Bereitstellungs-„Repository“ für alle Umgebungen zu haben, in dem Variablen verwendet werden, um die Vorlagen durch die Umgebungen zu parametrisieren. Auf diese Weise können wir sicher sein, dass wir während unseres gesamten Entwicklungszyklus einen konsistenten Konfigurations- und Bereitstellungsprozess haben.

Was mir derzeit nicht ganz klar ist, ist, wie ich die Rollenerstellung für diese verschiedenen Anwendungen angehen soll. Ich finde es auch ziemlich schwierig, dieses Thema zu „googeln“, da die meisten Beiträge, die ich finde, einfache Tutorials oder Beispiele für die Bereitstellung einzelner Anwendungen sind.

Was ich jetzt überlege ist:

1. Habe separate Rollen für jeden „Dienst“, den ich brauche, wie z. B. nginx, java, logstash usw., mit jeder Anwendungskonfigurationsdatei darin. Auf diese Weise sorge ich für die Wiederverwendbarkeit von Rollen und vermeide Wiederholungen, wenn zwei oder mehr Apps eine ziemlich ähnliche Konfigurationsdatei verwenden, die über Variablen unterschiedlich gemacht werden kann. Ich werde auch eine Bereitstellungsrolle mit allen Bereitstellungsaufgaben darin haben. Dies ist der Ansatz, den ich normalerweise verwende, wenn ich mit Puppet arbeite, aber er kann die Konfiguration manchmal verstreuen, was es „schwer“ macht, einige Fälle zu finden und hinzuzufügen, in denen eine Änderung in einer Anwendungskonfiguration Auswirkungen auf eine andere haben kann (hauptsächlich aufgrund einzelner Vorlagen, die mehr als eine App bedienen).

2. Verwenden Sie eine Rolle für den Microservice. Damit lässt sich leichter arbeiten, da sich alle Konfigurationen und Variablen in derselben Rolle befinden, aber ich muss Aufgaben und Konfigurationen für jeden Microservice wiederholen, und das ist mir ein wenig peinlich.

Der Grund für diese Frage besteht darin, herauszufinden, wie Leute mit demselben Problem damit umgehen, da es fast unmöglich erscheint, über eine Google-Suche vernünftige Antworten darauf zu finden und ich keine Freunde/Bekannten habe, die mit Ansible/Multi-App-Bereitstellungen arbeiten.

Entschuldigen Sie, wenn ich mich undeutlich/verwirrend ausgedrückt habe, und danke für jede Aufklärung, die Sie mir geben können.

Answer 1

Ich würde für jeden eine Rolle festlegenSystemdienstdie Ihre Anwendung benötigt,spielenund einRollefür jede Anwendung/jeden Microservice undGruppen- und/oder HostvariablenUndRollenvariablen und Standardwertedie definieren, was zu tun ist.

Ich setze viele PHP-basierte Anwendungen ein, das sieht also ungefähr so ​​aus:

Ich werde spielen app_microservice.yml:

---
- hosts: app_microservice_servers
  roles:
    - nginx
    - mariadb
    - php-fpm
    - app_microservice

Also werde ich eineRolle roles/app_microservicedas den Code bereitstellt. Wenn ich dieses Spiel ausführe, werden zuerst die Voraussetzungen für Nginx, MariaDB und PHP-FPM installiert und konfiguriert, falls dies noch nicht geschehen ist.

Zusätzlich zum Aufruf roleskann ein Spiel auch beliebig ausgeführt werden tasks. Fühlen Sie sich frei, diese zu kombinieren, wenn etwas so einfach ist, dass keine vollständige Rolle erforderlich ist.

Dieses Spiel wird auch zusammen mit jedem anderen Spiel ausgeführt all.yml, sodass ich gelegentlich ausführen kann ansible-playbook all.yml. Denken Sie daran, dass Ansible keine Idempotenz garantiert, wie Puppet dies versucht. Sie müssen also hier vorsichtig sein.

- include: app_microservice.yml

ich benutzeGruppeVariablen, um Dinge zu definieren, die einer Gruppe gemeinsam sind (obwohl es nur sehr wenige davon gibt, die nicht in dieRolleVariablen oder Standardwerte stattdessen), Gruppenvariablen allfür globale Dinge undGastgeberVariablen für alles, was für einen Host eindeutig ist.

Beispielsweise gebe ich jedem Host ein eindeutiges MySQL-Root-Passwort, habe aber SSL-Chiffren und -Protokolle definiert, group_vars/all/main.ymlsodass es für den Fall, dass sie geändert werden müssen, eine einzige zuverlässige Quelle dafür gibt.