pantrag_fisi Projekantrag: Implementierung eines Ansible-Automatisierungsservers am Standort Hamburg zur Erstellung von Monitoring Appliances

[Br0nx]

Moin,

ich bitte einmal um Unterstützung bzgl meines Projektantrags.
Schaut bitte einmal und macht Vorschläge.

 

 

1.    Projektbezeichnung

 

Implementierung eines Ansible-Automatisierungsservers am Standort Hamburg zur Erstellung von Monitoring Appliances.

1.1  Kurzform der Aufgabenstellung

 

Die XXX betreibt verschiedene Produkte und Dienstleistungen für Kunden aus allen Branchen. Im Fokus stehen hierbei mittelständisch angesiedelte Kunden. Immer wieder hat sich die Frage herauskristallisiert, wie man speziell verwaltete Dienste, sogenannte Managed Service bei Kunden, überwachen kann. Hat ein Kunde seine Systeme in einem unserer Rechenzentren stehen, werden die Zustände der Server und Dienste überwacht. Sollten diese beim Kunden vor Ort betrieben werden, so benötigt der Kunde zur Überwachung eine separate Appliance.

Für den Standort XX soll eine Automatisierung, basierend auf Ansible implementiert werden, die das Erstellen einer Monitoring Appliances optimiert. Bisher erfolgte dies manuell durch einen Kollegen, in zwei Werktage á acht Stunden.

1.2  Ist-Analyse

 

Im Rechenzentrum in XX betreibt die XXX bereits mehrere Monitoring Appliances, die eigenen Dienste und Server überwacht. Ebenso Kundensystem, die im Rechenzentrum stehen werden durch eine solche Appliance überwacht. Dort wird zum Erstellen bereits eine Automatisierung mit Ansible eingesetzt. Das entsprechende Ansible-Playbook, das die Monitoring Appliances erstellt ist dort auch im Einsatz. Dies auf einem alten Ubuntu 14.04.3 LTS implementiert und für die Ansible Version 1.7 geschrieben worden. Mit dem Ansible-Playbook wird ein MySQL Datenbankserver, ein Apache Webserver, die Monitoring Software Naemon und das Monitoring Webinterface Thruk automatisch installiert und grundkonfiguriert. Anschließend werden die benötigten Checks und Host Dateien manuell übertragen.

2.    Zielsetzung entwickeln / Soll-Konzept

 

2.1  Was soll am Ende des Projekts erreicht sein?

 

Ziel des Projektes ist es einen Ansible Automatisierungsserver am Standort Hamburg zu implementieren, durch den Monitoring Appliances, in Form von virtuellen Maschinen oder als physische Hardware deployed werden können. Dies löst die manuelle Installation, die bislang von einem Kollegen durchgeführt wurde ab. Die Automatisierung optimiert den Prozess und erhöht gleichzeitig die Produktivität, denn das Erstellen erfolgt komplett autonom. Eine Nachkontrolle erfolgt durch einen Kollegen aus der Fachabteilung, der die Appliance freigibt.

2.2  Welche Anforderungen müssen erfüllt sein?

 

Folgende Anforderungen sollen durch die Automatisierung erfüllt werden:

-          Maximale Betriebszeit bei minimalen Kosten

-          Zugriff auf den Server nur durch Mitarbeiter der speziellen Fachabteilung

-          Autonome Installation der benötigen Softwarepakete (MySQL, Apache2, Naemon, Thruk)

-          Autonome Konfiguration der benötigten Softwarepakete

-          Einfacher Aufruf zum Start eines Deployments

-          Ein Testdeployment muss durchführbar sein

2.3  Welche Einschränkungen müssen berücksichtigt werden?

 

Die im Rahmen des Projektes zu erstellende virtuelle Maschine wird auf einem XenServer aufgesetzt, der bereits am Standort vorhanden ist. Dieser findet bereits Einsatz zur Bereitstellung von virtuellen Microsoft SCCM Distribution Points. Daher müssen der virtuellen Maschine fixe Ressourcen zugeteilt werden.

3.    Projektstrukturplan entwickeln

 

3.1  Was ist zur Erfüllung der Zielsetzung erforderlich?

 

Damit die Zielsetzung erfüllt werden kann, muss für die virtuelle Maschine ein Linux Betriebssystem gewählt werden, welches langfristig Unterstützt wird. Das bereits vorhandene Ansible-Playbook muss an das neue Betriebssystem und damit an die neue Ansible Version angepasst werden. Das damit aktualisierte Ansible-Playbook wird in unserem Git versioniert und alle Schritte im Ticketsystem dokumentiert.

3.2  Aufgaben auflisten

 

·         Analyse

 

+ Durchführung einer Ist-Analyse

+ Erstellung eines Soll-Konzeptes

+ Kosten/Nutzen-Analyse erstellen

·         Entwurf

 

+ Erstellung eines Projektablaufplans

·         Durchführung

 

+ Bereitstellen einer virtuellen Maschine

+ Grundinstallation der VM

+ Härtung

       + Firewall installieren

       + SSH Zugang absichern

+ Installation des Ansible Pakets

+ Installation der Abhängigkeiten vom Ansible-Playbook

+ Implementierung des Ansible-Playbooks

·         Testen

+ Testszenario festlegen

+ Testdeployment durchführen

+ Testprotokoll erstellen

·         Abnahme und Übergabe

+ Projektdokumentation erstellen

+ Erstellen eines Benutzer-Handouts für die Fachabteilung

+ Übergabe an die Fachabteilung

 

 

4.    Projektphasen mit Zeitplanung in Stunden

 

Analyse	5 h
·         Durchführung einer Ist-Analyse	1 h
·         Erstellung eines Soll-Konzeptes	2 h
·         Kosten/Nutzen-Analyse erstellen	2 h
Entwurf	3 h
·         Erstellung eines Projektablaufplans	3 h
Durchführung	15 h
·         Bereitstellen einer virtuellen Maschine	1/2 h
·         Grundinstallation der VM	1 h
·         Härtung	3 h
-          Firewall installieren	1 ½ h
-          SSH Zugang absichern	1 ½ h
·         Installation des Ansible Pakets	½ h
·         Installation der Abhängigkeiten vom Ansible-Playbook	3 h
·         Implementierung des Ansible-Playbooks	4 h
Testen	3 h
·         Testszenario festlegen	½ h
·         Testdeployment durchführen	2 h
·         Testprotokoll erstellen	½ h
Abnahme und Übergabe	9 h
·         Projektdokumentation erstellen	7 h
·         Erstellen eines Benutzer-Handouts für die Fachabteilung	1 h
·         Übergabe an die Fachabteilung	1 h

 

 

[Gast halcyon]

Wenn man es genau nimmt, dann handelt es sich bei dem Projekt um eine Migration eines bestehenden Systems auf einen neuen Versionsstand. Welche eigenen (wirtschaftlichen) Entscheidungen triffst du?

 

 

 

[Colamann]

Sehe ich nicht so, es geht um die Automatisierung eines manuellen Prozesses. Allerdings verwirrt mich die Erwähnung eines bestehenden Ansible-Rezeptes, nachdem vorher immer von einem manuellen Prozess gesprochen wurde.

Ach ja, oben steht "in zweiu Werktage", das muß "Werktagen" heißen.

[mapr]

Irre ich mich, oder fehlt da die Wirtschaftlichkeit?

[Br0nx]

Also vom DIng ist es keine Migration sondern eine neue Installation am Hamburger Standort. Und wir haben bereits ein Ansible Playbook im Einsatz, welches auf einer ältern Version basiert. Dies soll in dem Zug mit upgedatet werden.

[Gast halcyon]

53 minutes ago, Colamann said:

Sehe ich nicht so, es geht um die Automatisierung eines manuellen Prozesses. Allerdings verwirrt mich die Erwähnung eines bestehenden Ansible-Rezeptes, nachdem vorher immer von einem manuellen Prozess gesprochen wurde.

Genau das ist aber der Punkt. Es geht eben nicht um die Automatisierung des Prozesses. Die Automatisierung wurde bereits innerhalb des vorhandenen Ansible-Playbooks implementiert und soll lediglich auf den neuen Produktstand hin angepasst werden.

Würde es hier um die Automatisierung gehen, hätte man in der Wirtschaftlichkeitsbetrachtung erstmal abwägen können, warum man Ansible und nicht Chef oder Puppet nimmt. Die Entscheidung ist hier hingegen schon gefallen.

14 minutes ago, Br0nx said:

Also vom DIng ist es keine Migration sondern eine neue Installation am Hamburger Standort.

Was du tust ist den vorhandenen Provisionierungsprozess auf ein neues System zu migrieren.

Bearbeitet 2. März 2017 von halcyon

[Br0nx]

vor 10 Minuten schrieb halcyon:

Genau das ist aber der Punkt. Es geht eben nicht um die Automatisierung des Prozesses. Die Automatisierung wurde bereits innerhalb des vorhandenen Ansible-Playbooks implementiert und soll lediglich auf den neuen Produktstand hin angepasst werden.

Würde es hier um die Automatisierung gehen, hätte man in der Wirtschaftlichkeitsbetrachtung erstmal abwägen können, warum man Ansible und nicht Chef oder Puppet nimmt. Die Entscheidung ist hier hingegen schon gefallen.

Was du tust ist den vorhandenen Provisionierungsprozess auf ein neues System zu migrieren.

Also wäre es besser Projektbezeichnung umzuschreiben?

 

[Gast halcyon]

Ich finde den Titel und die Projektbeschreibung zumindest irreführend. Wenn man Punkt 2.2 liest dann liest sich dein Projekt so, als würdest du die Automatisierung implementieren, sprich das Playbook schreiben. So schreibst du es ja auch in deine Zeitplanung. Dort schreibst du, du würdest es implementieren. In Wirklichkeit hebst du es auf ggf. auftretende Änderungen von Ansible v1.7 auf v2.2 an.

Von der Zeitplanung her finde ich dein Projekt ansonsten ok. Für die Umstellung sind 35h definitiv nicht unrealistisch. Trotzdem fehlt hier natürlich irgendwie noch der wirtschaftliche Aspekt und das treffen eigener Entscheidungen. Die IHK liegt da halt Wert drauf ...

 

Bearbeitet 2. März 2017 von halcyon