Dieser Artikel beschreibt die Fähigkeit / Idee / das Konzept, globale Einstellungen auf lokalen Befehlsservern in einer großen Infrastruktur mithilfe von Gitlab CI und Ansible zu ändern.
Angenommen, Sie haben 20 Entwicklungsteams und 1 Admin- / DevOps-Team. Wie ändere ich Administratorkennwörter auf allen Servern? Wie füge ich allen Servern ein Enterprise-Stammzertifikat hinzu? Usw.
Welches Problem löst es?
Typische Situation:
Es gibt globale Administratoren / DevOps.
Es gibt globale Einstellungen (NTP, DNS, Proxy usw.)
Es gibt lokale Entwicklungsteams: TeamA, TeamB, TeamC, TeamD usw.
Es gibt Entwickler, die nur zu den Servern ihres Teams gehen können.
Wie füge ich globale Administratoren und globale Einstellungen hinzu / aktualisiere sie?
Die Aufgabe wird durch die Tatsache erschwert, dass globale Einstellungen getrennt von lokalen Befehlseinstellungen in privaten Repositorys gespeichert werden.
Wenn Sie nur wenige Server im gesamten Unternehmen haben, können Sie Ansible in einem einfachen Modus starten. Aktualisieren Sie die globalen Administratoren und globalen Einstellungen auf allen Servern gleichzeitig.
Bei großen Installationen verwenden Unternehmen normalerweise Puppet, Chef.
Konzept
Um die globalen Einstellungen auf lokalen Befehlsservern in einer großen Infrastruktur zu ändern, schlage ich einen Git-Submodul-Mechanismus vor.
Das Repository mit lokalen Einstellungen verwendet Git-Submodule mit globalen Einstellungen.
Unten finden Sie ein schematisches Diagramm zum Verbinden eines privaten Repositorys mit globalen Einstellungen mit lokalen Befehlsrepositorys.
Sie können das Konzept der Aktualisierung globaler Einstellungen mithilfe des Git-Submoduls in der Infrastruktur mit Puppet, Chef, Salt verwenden. Der Artikel enthält jedoch ein Beispiel für Ansible.
Installieren Sie beispielsweise tomcat, mysql, nginx und wenden Sie globale Einstellungen in einem Team namens team an.
In gitlab gibt es eine allgemeine Gruppe, die allgemeine Einstellungen enthält.
In der allgemeinen Gruppe gibt es ein Basis-Bootstrap-Projekt, das Administratoren, Sysctl-Einstellungen usw. enthält.
Normalerweise gibt es in einem Unternehmen mehrere Entwicklungsabteilungen - häufiger werden sie als Teams bezeichnet.
Erstellen Sie in gitlab eine Teamgruppe (Sie haben Ihren eigenen Teamnamen).
In der Teamgruppe erstellen wir Projekte: Anwendung, Datenbank, Loadbalancer.
Screenshot von Base-Bootstrap, Anwendung, Datenbank, Loadbalancer:
Das Basis-Bootstrap-Repository ist als Git-Submodul im Anwendungs-, Datenbank- und Loadbalancer-Repository enthalten.
Jedes Mal, wenn die Anwendung, die Datenbank und der Loadbalancer im Repository mit der Aktualisierung des Basis-Bootstrap-Submoduls beginnen.
Danach werden Ansible-Playbook von Base-Bootstrap und Ansible-Playbook von Base-Bootstrap auf Anwendungs-, Datenbank- und Loadbalancer-Server angewendet.
Wenn Sie dem Basis-Bootstrap einen neuen Administrator hinzufügen oder die Systemeinstellungen im Basis-Bootstrap ändern, werden mit Anwendung, Datenbank, Loadbalancer die neuen Einstellungen vom Basis-Bootstrap auf Anwendung, Datenbank und Loadbalancer angewendet.
Vorbereitung
Sie sollten Artikel über Ansible für Anfänger lesen:
# Ansible, wo ich anfangen soll
# Ansible Guide
Sie müssen Gitlab und Gitlab-Runner mit installiertem Docker bereitgestellt haben.
Der Docker-Executor wird hier als Beispiel verwendet - Sie können den Shell-Executor verwenden.
So stellen Sie Gitlab und Gitlab-Runner bereit:
# Southbridge Gitlab-CI Artikel
# Kontinuierliche Integration und Bereitstellung von Docker in GitLab CI
Sie sollten 3 Server haben (zum Beispiel auf Ubuntu): Anwendung, Datenbank, Loadbalancer.
Anwendung, Datenbank, Loadbalancer sind gebräuchliche Namen.
Alle Beispiele können erweitert, verbessert und von anderer Software verwendet werden - der Artikel zeigt das allgemeine Prinzip.
Wie zu implementieren
Die Repositorys und der gesamte Code für den Test können hier abgerufen werden: https://github.com/patsevanton/ansible-gitlab-habr
Wenn Sie mit dem Benutzernamen / Passwort zum Server gehen, erstellen Sie in der erforderlichen Gruppe (in diesem Fall Team) die Benutzerkennwortvariable (wenn Sie sie ändern, müssen Sie auch die Variable im Code ändern) und geben Sie dort das Passwort an (das Passwort wird im Code verwendet).
Vergessen Sie nicht, den erforderlichen Benutzer mit den Sudo-Rechten auf den Endservern zu erstellen (der Benutzercode wird im Code verwendet).
Für diejenigen, die mit SSH-Schlüsseln zum Server gehen, müssen Sie die Variable SSH_PRIVATE_KEY in der Teamgruppe erstellen und den privaten Schlüssel des Benutzers hinzufügen, der eine Verbindung zum Server herstellen soll.
Dies ist ein einfaches Beispiel für die Verbindung zu Servern, sodass Sicherheitsprobleme in diesem Artikel nicht behandelt werden.
Erstellen Sie in jedem Repository (Anwendung, Datenbank, Loadbalancer) ein Git-Submodul:
git submodule add git@gitlab.example.com:common/base-bootstrap.git git submodule add git@gitlab.example.com:team/team-users.git
Für den Zugriff auf das gemeinsam genutzte private Repository wird ein Submodul benötigt.
In unserem Fall ist dies das Repository mit den allgemeinen Einstellungen von Base-Bootstrap und dem Benutzer-Repository des Team-Benutzer-Teams.
Wobei gitlab.example.com Ihr gitlab-Server ist.
Dann ändern wir in .gitmodules den Pfad zum Repository in relative
Ein Beispiel:
[submodule "team-users"] path = team-users url = ../team-users.git [submodule "base-bootstrap"] path = base-bootstrap url = ../../common/base-bootstrap.git
In jedem Repository in Hosts ändern wir die IP in unsere eigene, in ansible.cfg ändern wir remote_user in unseren Benutzer.
Wenn Sie in den letzten Stunden / Tagen keine Commits hatten und neue allgemeine Änderungen an den Servern vornehmen müssen (z. B. müssen Sie einen neuen Administrator hinzufügen), besteht in solchen Situationen ein Ansible-Pull.
Richten Sie ansible-pull ein, um das Common / Base-Bootstrap-Repository herunterzuladen.
Fügen Sie dazu das Bereitstellungstoken-Repository hinzu.
Wechseln Sie zum allgemeinen / base-bootstrap-Repository und dann zu settings / repository / Deploy Tokens.
Erstellen Sie ein Token. Der resultierende Benutzername und das Passwort werden in base-bootstrap / vars / cron.yml aufgezeichnet.
Nachdem Sie überprüft haben, ob alles richtig funktioniert, sollten Sie die Startzeit von Ansible-Pull von "alle 2 Minuten" auf die für Sie geeignete ändern.
Wenn ansible-pull gesunken ist, bedeutet dies, dass das CI dieses Dienstes gelöscht wird. Dies wird jedes Mal gestartet, wenn Sie sich für dieses Dienst-Repository verpflichten (sagen wir, der Dienst heißt Anwendung).
Überprüfen Sie
Erstellen Sie einen neuen Administrator.
Fügen Sie unter https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/users.yml einen neuen Administrator hinzu
Sysctl ändern
Versuchen Sie, Sysctl-Einstellungen unter https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/sysctl.yml hinzuzufügen / zu ändern
Hinzufügen von Einträgen zu cron
Versuchen Sie, Cron-Einträge zu https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/cron.yml hinzuzufügen
Erweitern oder Installieren Ihrer Anwendungen
Zuerst müssen Sie eine Rolle finden, um Ihre Anwendungen zu installieren.
Gehen Sie zu https://galaxy.ansible.com/ und suchen Sie die Rolle für die Installation Ihrer Anwendung.
Versuchen Sie, Ihre Anwendung mithilfe der Rolle von der Konsole auf Ihren Servern zu installieren. In der Regel enthalten alle Rollen Anweisungen in den Beschreibungen.
Versuchen Sie beispielsweise, Java neben Tomcat zu installieren. Installieren Sie zuerst die Rolle geerlingguy.java
ansible-galaxy install geerlingguy.java
Erstellen Sie die Standard-Datei ansible.cfg genauso wie die Repositorys.
Erstellen Sie ein Inventar:
[java] java ansible_host=IP-
Erstellen Sie ein Playbook java.yml
- hosts: java become: yes vars_files: - vars/main.yml roles: - { role: geerlingguy.java }
Führen Sie ansible-playbook java.yml aus
Wenn alles erfolgreich gelaufen ist, fügen Sie es dem gewünschten Projekt hinzu (in diesem Fall Anwendung)
Die Rolle von geerlingguy.java wird nach der Rolle von robertdebock.tomcat https://github.com/patsevanton/ansible-gitlab-habr/blob/master/team/application/tomcat-app.yml#L11 hinzugefügt
Gleiches gilt für alle anderen Anwendungen, die Sie auf dem Server installieren müssen.
Playbook-Tests und Sicherheit
Um den Artikel zu vereinfachen, wird das Problem der Kennwortspeicherung und -prüfung nicht behandelt.
Es gibt Artikel zum Testen des Spielbuchs:
# Ansible: Testen von Playbooks (Teil 1)
# Testen und kontinuierliche Integration für Ansible-Rollen mit Molecule und Jenkins
Antworten auf Fragen
1) Mentat: Und warum ist es schließlich nicht so, wie es im Ansible Dock mit den Umgebungen geschrieben ist? Von der ersten Lesung an scheint es ein Versuch zu sein, alles noch einmal neu zu erfinden. Dort ist es sehr praktisch, dies alles wie ansible-playbook -i env / teamA personalAPlaybook.yml anzuwenden
Antwort: Mit diesem Schema können globale Einstellungen geändert werden. In der Frage wird beschrieben, wie die lokalen Einstellungen der Befehle geändert werden.
PS Möglicherweise ist die gleiche Funktionalität in Ansible Tower implementiert. Aber dazu kann ich nichts sagen - ich habe nicht mit Ansible Tower gearbeitet.