PasChic

Vielen Dank für euere schnelle Rückmeldung! Die eigenliche Idee, sprich worauf ich ja den Fokus legen will, ist lediglich eine Zentralisierung, die abteilungsübergreifend zur Verfügung stehen soll, zu integrieren. D.h., dass nicht so wie aktuell nur unsere DevOps in der Lage sind Playbooks auszuführen. Diese sind ja bereits in GitHub alle samt gelagert. Mit der Lösung würde z.B. unsere Abteilung Customer Support in die Lage versetzt, z.B. Playbooks für Bugfix Updates auf unseren Applikationen oder auch Updates einer Customizationarea auszuführen oder aber auch backup Konfigs. auf produktiv Systemen. Ich will wirklich die Idee vermitteln, dass lediglich Transparenz und Zentralisierung gegeben sein soll und durch ein role-based access control Teams/Abteilungen, je nach Berechtigung, gewisse Playbooks launchen können. Ich muss ganz ehrlich sagen, dass ich mich mit dem Projekt schon final festgelegt habe, weshalb mir es wirklich am Herzen liegt dieses durchzuboxen. Somit würde ich mich auch in dieser kurzen Zeit sehr schwer tun ein komplett neues Projekt zu wählen, da die Abstimmung mit meinem Auftraggeber so gut wie flach fällt aufgrund der aktuellen Situation.

Hallo zusammen, mein Antrag wurde leider zum zweiten Mal abgelehnt. Mittlerweile bin ich an einem Punkt angekommen an dem sich bei mir Verzweiflung breit macht und ich nicht mehr weiß was ich hier genau ändern/verbessern kann. Ich würde mich riesig freuen wenn Ihr euch die Zeit nehmen könntet und euch das einmal in Ruhe durchlesen und ggf. mir einige Verbesserungsvorschläge geben könntet. Das war die Begründung der IHK warum der Antrag nicht genehmigt wurde (auch hier frage ich mich warum mir dies nicht beim ersten versuch schon mitgegeben wurde): Ihre Projektidee viele verstreute Ansible-Instanzen durch eine zentrale Prozess-Automatisierung mittels Jenkins, Rundeck oder einem ähnlichen Programm zu ersetzen, halten wir – die Mitglieder Ihres Prüfungsausschusses- für ein sehr gutes und interessantes Projekt. Allerdings entspricht Ihr Antrag leider nicht den Anforderungen an einen genehmigungsfähigen Antrag. Damit Sie Ihre Projektidee im Rahmen Ihrer IHK-Abschlussprüfung im Sommer 2020 umsetzen können, müssen wir Sie leider bitten Ihren Antrag intensiv zu überarbeiten. Gehen Sie dabei insbesondere auf folgende Punkte ein: Erst im Anhang wird klar, dass Sie die verstreuten Ansible-Instanzen durch eine zentrale, in Azure bereitgestellte Ansible Instanz mittels Jenkins, Rundeck oder einem ähnlichen Programm ersetzen wollen. Warum geht diese wesentliche Information nicht aus Ihrem Text hervor? Und was spricht gegen eine On-Premise-Lösung? Warum sollen jetzt Personen, die wenig Erfahrung im Umgang mit komplexen Playbooks haben, diese ausführen (Stichwort: Berechtigungskonzept)? In der Planungsphase fehlt die Aufstellung des Kriterienkatalogs für die Auswahl der zentralen Automatisierungssoftware (Jenkins, Rundeck o. a.) Jenkins, Rundeck oder einem ähnlichen Programm benötigen Sie ein Zertifikat. Welche Klasse muss Ihr Zertifikat entsprechen? Warum nennen Sie nicht die Linux-Distribution oder wollen Sie hierfür ein Kriterienkatalog aufstellen? Wo befinden sich die verstreuten Ansible-Instanzen? Beschreiben Sie diese und geben Sie deren Anzahl und Lage an. Ergänzen Sie dazu Ihren im Anhang befindlichen Netzwerkplan. Dieser muss die projektrelevante Netzwerkinfrastruktur mit eventuell modifizierter IP-Konf. in quasinormgerechter Darstellung (Cisco-Symbole) abbilden.

1 Thema der Projektarbeit Evaluierung und Einführung einer zentralen Deployment Lösung zur Kanalisierung und Vereinheitlichung aktueller Deployment Prozesse zur Steigerung der Transparenz und der Umsetzung der Unternehmensrichtlinien (Compliance) 2 Geplanter Bearbeitungszeitraum Beginn: 23.03.2020 Ende: 11.05.2020 3 Projektbeschreibung 3.1 Einführung: XYZ (hier wurde seitens der IHK nichts angemeckert, daher lasse ich das auch aus Datenschutzgründen weg) 3.2 Kurzform der Aufgabenstellung: Die XYZ GmbH plant eine Evaluierung und Einführung eines zentralen Orchestrierungs-Tools mit grafischer Oberfläche, um interne Prozesse mit einem visuellen Dashboard zu zentralisieren und zu steuern. Die Lösung soll die Ausführung und die damit verbundene Provisionierung von Infrastruktur (IaC) mittels Ansible kanalisieren und eine Ausführung von lokalen Clients (von diversen Standorten und Netzwerken) obsolet machen. Es ist vorgesehen, dass Ansible Playbooks und Inventories zentral verwaltet und Aufträge für die Ausführung über eine Web-GUI geplant werden können. Das Ziel ist es mit Hilfe der zentralen Komponente eine Reduzierung von Fehleranfälligkeiten und Erhöhung der Transparenz durch Reproduktionsmöglichkeiten sicherzustellen, die aktuell aufgrund der Menge an aufgeteilten und dezentralen Ressourcen zustande kommt. Optional besteht das Bestreben, die Lösung als eine Art Self-Service-Portal zugänglich zu machen um einen agilen Arbeitsfluss zu gewährleisten und die Teams damit unabhängig zu machen. Zusammengefasst zielt die Anforderung in erster Linie auf die Provisionierung einer Lösung ab, die für eine klare und effektive Zentralisierung und Vereinheitlichung der dezentralen Teams sorgen soll. Diese Zielanforderung richtet sich zudem konkret auf folgende Konzepte, die durch eine zentrale Transparenz impliziert werden: Verwaltung von zentralem Konfigurationsmanagement, zentrale Anwendungsbereitstellung (Datenbankverwaltung, Netzwerkverwaltung, etc.), vereinfachte Job-Konfigurationen und zentrale Bereitstellung von Push-Button-Deployments. Dies führt dazu, dass die Administration und Organisation für die peripheren Abteilungen und Teams erleichtert und global erreichbar werden. 3.3 Ist-Zustand: Ansible ist bei der XYZ GmbH bereits etabliert. Aufgrund der wachsenden Systemlandschaft haben sich die Anforderungen geändert und erfordern eine Optimierung. Aktuell werden alle Konfigurationen und Installationen, die u.a. die Erstellung neuer virtuellen Maschinen oder Setup der jeweiligen VMs und Installation der von der XYZ GmbH angebotenen Applikationen beinhaltet, lokal durch den einzelnen Engineer ausgeführt (lokaler Ansible Client - lokale Playbooks). Zur Zeit werden die Playbooks in GitHub Repositories bereitgestellt. Diese Playbooks klont sich der jeweilige Engineer auf seine lokale Arbeitsumgebung, um den letzten Stand zu erhalten. Nach erfolgreicher Konfiguration (kundenspezifisch, z.B. URL) werden die Playbooks individuell von der lokalen Arbeitsumgebung, über die Kommandozeile, ausgeführt. Der Zugriff ist somit nur auf eine kleine Gruppe beschränkt und als Folge der dezentralen Ausführung nicht transparent. Die Ausgabe der Log-Dateien bei der Ausführung der Playbooks über die CLI erfolgt lokal auf einer der jeweiligen Maschinen. Einsehbar sind diese nur von demjenigen, der die Ausführung angestoßen hat. Eine zentrale Übersicht und Nachvollziehbarkeit ist nicht gegeben. Bezugnehmend auf den aktuellen Stand der Job-Konfigurationen, werden auszuführende Jobs nur von Administratoren konfiguriert. Es gibt keine zentrale Kontrolle oder Übersicht über geplante und gestartete Jobs und sind somit schwer nachvollziehbar. Eine Berechtigungshierarchie ist nicht vorhanden, da die Playbooks und die damit verbundenen Konfigurationen und Administrationen, nur seitens unserer Fachabteilung dezentral verwaltet und ausgeführt werden. 3.4 Soll-Zustand: Primärziel ist die Bereitstellung einer Lösung, welche eine dezentrale Ausführung aller Playbooks ersetzt bzw. verhindert um Transparenz und Nachvollziehbarkeit zu erlangen. Dies beinhaltet unter anderem die Erstellung von Infrastruktur und Installation der XYZ Komponenten. Um dies zu erreichen müssen alle Playbooks von einem zentralen Knoten angesteuert werden. Folgende Benefits sollen durch diese Lösung erreicht werden: Transparenz, d.h. Nachverfolgen wer wann welche Ressourcen erstellt oder geändert hat (Audit Log), Security (Einschränkung zur Erstellung neuer Ressourcen auf der zentralen Plattform) und optional, Einführung einer User- und Berechtigungshierarchie (Rechte und Rollen), da das Tool abteilungsübergreifend genutzt werden soll. Eine übersichtlichere Darstellung für die entsprechenden User gehört dabei ebenso zur Konzeption wie eine chronologische Historie der ausgeführten Konfigurationen und/oder Installationen. Simultan dazu, sollen diese Informationen zentral zugänglich sein (Audit trail). Statistiken z.B. über erfolgreiche und fehlgeschlagene Jobs, die dann ebenfalls global abrufbar wären, sollen einen zusätzlichen Nutzen bringen (zentrale Traceability). Deployment Informationen sollen zentral verfügbar sein und eine komfortable und schnelle Analyse und Nachvollziehbarkeit von ausgeführten Ansible Playbooks ermöglichen. Zu dem Zweck, dass dann eine Transparenz gegeben ist wenn der betroffene Engineer nicht verfügbar ist. Indem es ermöglicht wird die Ad-Hoc-Befehlsausführung (z.B. Installation und Konfiguration der XYZ GmbH Komponenten) über einfaches Anklicken zentral zu steuern und auszuführen, sollen zukünftig keine komplexen Kommandobefehle (über die CLI) mehr ausgeführt werden, um einen Prozess anzustoßen. User aus anderen Teams würden in die Lage versetzt, entsprechende Funktionen zu bedienen, wobei individuelle Berechtigungen vergeben werden und ein Userkreis definiert wird, der auf bestimmte Bereiche Zugriff erhält (Role-based Access Control). Dies ermöglicht dann im weiteren Verlauf ein vereinfachtes On-Boarding weiterer Teams und einen Self-Service. Letztendlich stimmen sich die Anforderungen dahingehend ab, dass jeder Jobs lokal antriggern kann und über entsprechende Berechtigungen eine Transparenz gegeben ist (Möglichkeit eines zentralen Managements / Steigerung der Transparenz). Zudem soll eine systematisierte und zweckmäßige Einteilung durch eine vereinfachte Ansicht von Automatisierungs-Tasks für Anfänger oder unerfahrene Ansible Anwender festgelegt werden (z.B. für die Mitarbeiter aus den Abteilungen Support und Professional Service). 3.5 Schnittstellen: Die jeweiligen Schnittstellen die mit dem Projekt verbunden sind, schließen als Auftraggeber Herrn AB, aus der Abteilung Technical Operations, ein. Jegliche Änderungen die mit dem Projekt verbunden sind müssen mit dem Auftraggeber abgestimmt und entsprechend genehmigt werden. Herr ABC (DevOps) unterstützt mich bei der Durchführung des Projektes und bildet eine Schnittstelle als Ansprechpartner für die technischen Anforderungen. 4 Projektumfeld Das Projekt wird ausschließlich in den Räumlichkeiten der XYZ GmbH in AA in der XYZ Straße 11 durchgeführt. Zentraler Ansprechpartner und Projektbetreuer ist Herr ABC. Es handelt sich um ein betriebsinternes Projekt. Auftraggeber ist die Fachabteilung ”Technical Operations”. 5 Projektphasen mit Zeitplanung 1. Analyse Phase: (3,0h) 1.1 Abstimmung mit dem Auftraggeber (2,0h) 1.2 Erstellung eines Soll-Konzepts (1,0h) 2. Planungsphase (5,0h) 2.1 Festlegung der Systemumgebung (1,0h) 2.2 Evaluierung geeigneter Tools (2,0h) 2.3 Personalplanung (0,5h) 2.4 Terminplanung (0,5h) 2.5 Ressourcenplanung (0,5h) 2.6 Kostenplanung (0,5h) 3. Realisierungsphase (13,5h) 3.1 Festlegung des passenden Tools (1,0h) 3.2 Server mit einer Linux-Distribution aufsetzen und härten (2,0h) 3.3 Installation des Tools (4,0h) 3.4 Basis-Konfiguration des Tools (3,0h) 3.5 Erweiterte Konfigurationen (3,5h) 4. Projektabschluss (13,5h) 4.1 Tests der Funktionalitäten (2,0h) 4.2 Soll-Ist-Vergleich / Abnahme (2,0h) 4.3 Erstellung der Projektdokumentation (6,0h) 4.4 Erstellung des Administrator Handbuches (1,0h) 4.5 Erstellung des Kunden Handbuches (1,0h) 4.6 Fazit (0,5h) 4.7 Übergabe an die Fachabteilung (1,0h) Gesamtzeit: 35h Netzwerkplan_schematisierteDarstellung.pdf