Zusammenfassung

Das Ansible soll genutzt werden, um unsere Infrastruktur einheitlich zu gestalten und um spezielle Spezialkonfigurationen zu vermeiden. Der Zielzustand ist, dass man eine VM neuinstallieren kann und nach einem Ansible-Run wieder alle Dienste installiert und konfiguriert sind.

Disclaimer

Die folgenden TODOs sind nicht fest. Es darf und soll darüber diskutiert werden, was sinnvoll bzw. nicht sinnvoll ist und warum.

Generelles

Paketinstallationen
- Im "alten" Ansible hatten wir Paket-Listen, die auf allen Servern installiert wurden. Das würde ich so beibehalten. Solche Listen können bei Bedarf auch für andere Hostgruppen (z.B. mail-servers, webservers,…) angelegt werden. Diese müssen dann im jeweiligen YAML-File referenziert werden.
Passwörter in Konfigurationsdateien
- In einigen Konfigurationsdateien die per Ansible ausgerollt werden (sollen) müssen Passwörter für Datenbanken etc. angegeben werden. Hier sollten wir Möglichkeiten prüfen, diese aus dem Passwordstore zu ziehen. s. https://docs.ansible.com/ansible/latest/collections/community/general/passwordstore_lookup.html
Monitoring
- Aktuell wird bei der Neuinstallation eines Hosts das icinga2-agent.sh-Skript aus dem Icinga-Director kopiert und manuell auf dem Host ausgeführt. Das soll durch das Ansible abgelöst werden. Dazu wird das Skript als Template genutzt und das Agent-Ticket per API-Request aus dem Icinga-Director geholt.

Anwendungen

Anwendungen können generell mehrmals in unserer Infrastruktur betrieben werden. Wir sollten daher möglichst alles soweit generalisieren, dass es auf einem neuen Server laufen kann und Anwendungen immer für ganze Hostgruppen ausrollen. Ob in der Hostgruppe dann nur ein Server ist, ist ja erstmal egal.

GitLab-Runner
- GitLab-Runner sind nicht wirklich kompliziert zu installieren. Die Paketquellen von GitLab werden im Playbook eingebunden und die Config per Template mit einem Passwort aus dem Passwordstore generiert.
Prometheus/Grafana
- Die Konfigurationsdateien für Prometheus und Grafana sind bereits im Repo. Die Config von Prometheus soll aber noch so angepasst werden, dass nicht jeder Host einzeln reingeschrieben werden muss, sondern die Exporter anhand von Hostgruppen im Template eingetragen werden.
Kubernetes-Worker
- Kubernetes-Worker sollten komplett automatisch installiert werden und dem Cluster joinen
Firewalls
- HAProxy
  - dehydrated
  - Front- und Backends
- keepalived
- shorewall
- Netzwerkkonfig

# Zusammenfassung Das Ansible soll genutzt werden, um unsere Infrastruktur einheitlich zu gestalten und um spezielle Spezialkonfigurationen zu vermeiden. Der Zielzustand ist, dass man eine VM neuinstallieren kann und nach einem Ansible-Run wieder alle Dienste installiert und konfiguriert sind. # Disclaimer Die folgenden TODOs sind nicht fest. Es darf und soll darüber diskutiert werden, was sinnvoll bzw. nicht sinnvoll ist und warum. # Generelles - [x] Paketinstallationen - Im "alten" Ansible hatten wir Paket-Listen, die auf allen Servern installiert wurden. Das würde ich so beibehalten. Solche Listen können bei Bedarf auch für andere Hostgruppen (z.B. mail-servers, webservers,…) angelegt werden. Diese müssen dann im jeweiligen YAML-File referenziert werden. - [x] Passwörter in Konfigurationsdateien - In einigen Konfigurationsdateien die per Ansible ausgerollt werden (sollen) müssen Passwörter für Datenbanken etc. angegeben werden. Hier sollten wir Möglichkeiten prüfen, diese aus dem Passwordstore zu ziehen. s. https://docs.ansible.com/ansible/latest/collections/community/general/passwordstore_lookup.html - [x] Monitoring - Aktuell wird bei der Neuinstallation eines Hosts das icinga2-agent.sh-Skript aus dem Icinga-Director kopiert und manuell auf dem Host ausgeführt. Das soll durch das Ansible abgelöst werden. Dazu wird das Skript als Template genutzt und das Agent-Ticket per API-Request aus dem Icinga-Director geholt. # Anwendungen Anwendungen können generell mehrmals in unserer Infrastruktur betrieben werden. Wir sollten daher möglichst alles soweit generalisieren, dass es auf einem neuen Server laufen kann und Anwendungen immer für ganze Hostgruppen ausrollen. Ob in der Hostgruppe dann nur ein Server ist, ist ja erstmal egal. - [x] GitLab-Runner - GitLab-Runner sind nicht wirklich kompliziert zu installieren. Die Paketquellen von GitLab werden im Playbook eingebunden und die Config per Template mit einem Passwort aus dem Passwordstore generiert. - [x] Prometheus/Grafana - Die Konfigurationsdateien für Prometheus und Grafana sind bereits im Repo. Die Config von Prometheus soll aber noch so angepasst werden, dass nicht jeder Host einzeln reingeschrieben werden muss, sondern die Exporter anhand von Hostgruppen im Template eingetragen werden. - [ ] Kubernetes-Worker - Kubernetes-Worker sollten komplett automatisch installiert werden und dem Cluster joinen - [x] Firewalls - [x] HAProxy - [x] dehydrated - [x] Front- und Backends - [x] keepalived - [x] shorewall - [x] Netzwerkkonfig

tteichler commented

2021-04-07 00:03:10 +02:00

Author

Owner

added 1 commit

975ddc6c - Rewrite Teckids sysadmin-ansible

Rows
Columns

Rewrite Teckids sysadmin-ansible #20

Zusammenfassung

Disclaimer

Generelles

Anwendungen