| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546 |
- ---
- format: markdown
- categories: Netz-Infrastruktur, Backbone, Supernodes
- title: Server-Automatisierung
- ...
- # Automatisierung der Supernodes und anderer Server
- ## Motivation
- Aktuell werden Supernodes und andere Server durch klonen von VM-Images und viele händische Eingriffe erzeugt. Die
- Vergangenheit hat zwar gezeigt, dass dies grundsätzlich funktioniert, aber zukünftig wird dieser Ansatz vermehrt
- Probleme bereiten. Zu diesen Problem gehören:
- * Skalierbarkeit
- * Reproduzierbarkeit
- * Nachvollziehbarkeit
- Dazu erhält man mit einer vernünftigen Automatisierung auch einige weitere positive Nebeneffekte
- * Einfaches Setup für Testumgebungen
- * Einfacherer Start für neue Communities
- ## Mögliche Tools
- Es gibt verschiedene Automatisierungstools am Markt. Einige bekannte sind:
- * [Puppet](https://puppetlabs.com/)
- * [Chef](https://www.chef.io/)
- * [Ansible](http://www.ansible.com/home)
- Alle diese Tools haben verschiedene Vor- und Nachteile. Aus der aktuellen Diskussion scheint sich aber eine Präferenz
- für Ansible anzuzeichnen.
- ## Aktueller Stand
- Es gibt bereits erste Ansätze eine Community (Supernodes + Map Server) in Ansible zu beschreiben. Das Playbook kann
- [hier](https://github.com/dereulenspiegel/ffdo-ansible) gefunden werden. Auf Basis dieses Playbook wurden einige Rollen
- als eigenständige Rollen ausgegliedert und in eigene Repositories abgespalten
- * [Alfred](https://github.com/dereulenspiegel/ansible-alfred)
- * [Alfred-json](https://github.com/dereulenspiegel/ansible-alfred-json)
- * [fastd](https://github.com/dereulenspiegel/ansible-fastd)
- Diese Rollen können eigenständig benutzt werden und sollten keine bzw. wenige Abhängigkeiten zu anderen Rollen haben.
- Diese Rollen werden auch im oben genannten Playbook wiederverwendet.
|
