Seite wählen

NETWAYS Blog

Konzeption oder Proof of Concept? So wird dein IT-Projekt zum Erfolg

von | Apr 13, 2023 |

Wenn man als Open Source Dienstleister langfristig Erfolg haben will, muss man mit der Zeit gehen und die eigene Arbeitsweise in regelmäßigen Abständen hinterfragen. War bis vor einigen Jahren das Erarbeiten eines Konzepts zur Veranschaulichung einer möglichen Umsetzung der Quasi-Standard im IT-Consulting, gibt es mittlerweile valide Alternativen. Besonders beliebt und erprobt ist das Proof of Concept

Unser Manager Consulting Thilo hat sich die Zeit genommen, beide Vorgehensweisen einmal kurz vorzustellen und beantwortet die Frage, was sich besser für dein IT-Projekt eignet: Konzept oder Proof of Concept?

Konzept

Jedes Projekt steht bzw. fällt mit dem zugrundeliegenden Konzept. Erst mit diesem können wir für dichals unsere:n Kund:in ein spezifisches Angebot mit genauen Arbeitspaketen und Abfolgen erstellen.

Um ein gutes Grobkonzept zu erstellen, sammeln wir Informationen wie Ziele, Wünsche oder bestehende Probleme für die neue Umgebung. Dazu sammeln wir mit dirzusammen Eckdaten und definieren Ziele in einem gemeinsamen Onboarding Workshop.

Was ist das Ziel der neuen Umgebung?

  • Benachrichtigen im Fehlerfall?
  • Metriken sammeln und Trends erkennen?
  • Automatisierte Installation?
  • SLAs für Kunden bereitstellen?

Wer ist die Zielgruppe?

  • Kollegen aus dem Nachbarbüro
  • Kund:innen mit SLA Vereinbarungen
  • Zentrale Ansicht für ein Incident Management Team
  • Verteilte Teams die Tool as a Service nutzen

Handelt es sich um eine Migration von Icinga oder einem anderen Tool, ist es besonders wichtig Probleme in der aktuellen IT-Umgebung zu identifizieren. Dazu zählen Ausfälle des Systems, Performance Probleme, Schwierigkeiten bei der Handhabung, beim Update oder bei der Erweiterung der Umgebung.

Mit diesen Informationen wird das bereits angesprochene Grobkonzept erstellt. Es enthält eine Analyse des aktuellen Stands, Herausforderungen mit der bestehenden Umgebung und die gemeinsam definierten Ziele. Um das Projekt für dichtransparent und mit klaren Arbeitspaketen zu gestalten, werden alle definierten Tools und Lösungsansätze umfangreich beschrieben.

Um dir einen Überblick über den zeitlichen Rahmen des Projekts zu geben, kalkulieren wir um NETWAYS IT Consulting den zeitlichen Aufwand der definierten Arbeitspakete.

Proof Of Concept

Ein Proof of Concept (POC) hilft bei der Projektplanung dabei eine Lösung zu simulieren, Probleme in der Benutzung zu finden oder technische Möglichkeiten aufzuzeigen. Bevor ein POC umgesetzt wird, muss festgelegt werden, was genau simuliert oder dargestellt werden soll. Diese Ziele und ein zeitlicher Rahmen werden in einem gemeinsamen Termin zwischen dirund deinem persönlichen Consultant besprochen und festgelegt.

Im Anschluss wird die Vorgehensweise des Proof of Concept festgelegt. Im Icinga Umfeld kann zum Beispiel eine in deiner Infrastruktur gestartete Virtuelle Maschine aufgesetzt werden. Diese kann vom dir und deinem Team umfangreich getestet und weiteren Kolleg:innen bzw. dem Management vorgeführt werden. Des Weiteren kann können wir individuelle Lösungen auch in einer lokalen Entwicklungsumgebung testen, falls Freigaben oder Vorbereitungen kurzfristig nicht umgesetzt werden können.

Im Falle von Icinga können meine Kolleg:innen oder ich mit Hilfe von Automatisierungslösungen wie Ansible oder Puppet schnell eine Umgebung aufsetzen. Dadurch sparen wir uns wertvolle Zeit, um gemeinsam weitere Lösungen für die individuellen Herausforderungen Deines Unternehmens zu evaluieren.

Konzept vs POC

Je nach Anforderungen und Projekt ist ein Konzept oder ein POC sinnvoll. Grundsätzlich kann ein Proof of Concept Deine Wünsche schneller abbilden, eine Umgebung visualisieren sowie Vorteile und Nachteile einer Lösung hervorheben. Ein Konzept hingegen ist lediglich die theoretische Planung eines Projekts und kann wenig über die Funktionalität der Lösung aussagen. Daher ist hier die Expertise und Erfahrung des Consultants wichtig.
Bei größeren Projekten mit neuen Herausforderungen werden häufig beide Varianten gemeinsam eingesetzt, um die Komplexität des Projekts bestmöglich abzubilden. Ein POC, welches dir und deinem Team die spezielle Lösung visuell demonstrieren und simulieren kann. Im Anschluss wird die endgültige Lösung in einem Konzept festgehalten um einen zeitlichen Projektrahmen zu schaffen. Zudem werden für das Projekt Voraussetzungen, Arbeitspakete und Sizing definiert.

Die Umsetzung des Projekts ist bei allen Unternehmen individuell gestaltet. Mein Team und ich können, wenn ein Zugriff gegeben ist, die Umgebung kundenunabhängig aufbauen und im Anschluss eine technische Dokumentation der Arbeitsschritte bzw. der Umgebung liefern. Hierbei arbeiten deine NETWAYS Consultants mit einer Vielzahl von Tools wie Citrix, AnyDesk oder VPN.

In anderen Fällen ist kein direkter Zugriff auf den Server vorhanden oder du willst direkt bei der Umsetzung dabei sein, um gleichzeitig vom Workshop als direkte Schulung zu profitieren. Dabei werden Fragen zu Handling und Aufbau direkt beantwortet.

Wissen für alle

Nach erfolgreicher Umsetzung des Projekts muss schließlich noch ein Wissenstransfer stattfinden. Dieser ist je nach Projekt, Tool und Umgebung verschieden. Nach Projekten in enger Zusammenarbeit sind während des Workshops bereits viele grundsätzliche Fragen geklärt und meist ist der Kunde im Handling mit der Umgebung sicher. In solchen Fällen ist eine technische Dokumentation des Projekts ausreichend.

Falls ein Projekt unabhängig vom Kunden durchgeführt wurde, sollte idealerweise noch ein Wissenstransfer in Form eines extra Workshops oder gar einer Schulung stattfinden. Abhängig von der Anzahl der Mitarbeiter, welche die Umgebung bedienen, ist es sinnvoll eine Schulung für das gesamte Team durchzuführen. Bei einer kleineren Anzahl an Benutzern kann bereits ein Hands-On Workshops von ein paar Stunden ausreichen, um dem Kunden den Umgang und die Konfiguration der neuen Umgebung nahe zu bringen.

Falls du nun Neugierig geworden bist und aktuell sowieso auf der Suche nach einem erfahrenen Open Source IT-Dienstleister mit Herz bist, dann melde dich gerne bei uns! Ich und meine Kolleg:innen führen gerne eine individuelle Betrachtung zu deiner IT-Umgebung und ihren Anforderungen durch. Im Rahmen eines ersten Consultingtermins sprechen wir gemeinsam gerne über deine Vorstellungen und Wünsche für deine IT-Infrastruktur. Ich bin mir sicher, gemeinsam finden wir die beste Lösung!

Thilo Wening
Thilo Wening
Manager Consulting
Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.
Lies mehr von Thilo und triff unser Team

Ausbildung 2022 – Unser neues Konzept

von | Okt 21, 2022 |

Hi zusammen,

wir, die neuen Azubis bei NETWAYS, wurden bereits in einem anderen Blogpost vorgestellt. Ich habe mich dazu entschieden, Euch heute das neue Ausbildungskonzept von NETWAYS zu präsentieren. In der Vergangenheit war es bisher so, dass die einzelnen Azubis in ihre Abteilungen gesteckt wurden und dort dann primär deren Ausbildung stattfand. Bei uns sieht dies nun etwas anders aus:

 

Unser neues Ausbildungskonzept

Wir, die sechs technischen Azubis, verbringen das ganze erste Lehrjahr zusammen. Das dient vor allem dazu, dass alle auf demselben Wissensstand sind und eine gute Grundausbildung bekommen. Hierzu haben wir immer abwechselnd verschiedene Schulungen mit anschließender Projektphase und Berufsschule.

Die Projektphase nach den einzelnen Schulungen dient zur Vertiefung des gelernten Wissens. Die einzelnen Schulungen und Themen werden von unserem Ausbilder Dirk geplant. Die Schulungen selber übernehmen je nach Thema unterschiedliche Abteilungen von NETWAYS. Während ich das hier schreibe, habe ich gerade eine Netzwerkgrundlagen Schulung und nächste Woche geht es mit OpenStack weiter. Die jetzige Schulung hält Michael von NETWAYS Managed Services. Zuvor hatten wir ein Linux Training bei unserem Ausbilder Dirk von NETWAYS Professional Services.

 

Unsere erste Schulung – Linux!

Wie gerade schon erwähnt, hatten wir zuvor eine Linux-Schulung. Diese war unsere erste Schulung und sollte Grundlagen für die kommenden Jahre schaffen. Zuerst ging es um die Basics: Was ist Linux überhaupt? Wie bedient man Linux? Danach haben wir gelernt: Was ist ein Paketmanager, wie funktioniert ein Dateisystem, wofür benötigt man eine SSH-Verbindung. Natürlich haben wir noch viel mehr gemacht, aber dies würde einen eigenen Blogpost benötigen.

 

Anschließend hat dann unsere erste Projektphase begonnen. Wir hatten die Aufgabe, einen eigenen Webserver auf einer virtuellen Maschine laufen zu lassen. Auf dieser sollte unsere erste eigene Webseite gehostet werden. Mir persönlich hat dieses Projekt sehr gut getaugt, da es noch nicht so anspruchsvoll war und mir einen guten Einstieg geboten hat.

 

Persönlich finde ich das neue Ausbildungskonzept bis jetzt sehr gut gelungen. Dadurch, dass wir insgesamt sechs technische Azubis sind, gib es eine regen Austausch von Informationen und man kann sich gegenseitig gut unterstützen. Vor allem für mich, der zuvor wenig bis gar nichts mit der IT am Hut hatte, ist dies sehr vorteilhaft. Auch super finde ich die Projektphasen nach den Schulungen, da diese mir erst so richtig die Möglichkeit bieten, das gelernte Wissen zu vertiefen. Ich bin auf jeden Fall gespannt, wie es weiter geht und ob alle einen ähnlichen Wissensstand nach dem ersten Lehrjahr haben werden.

Bis zum nächsten Mal,
Leander

Leander Müller-Osten
Leander Müller-Osten
Junior Consultant
Leander hat 2022 seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services begonnen. Zuvor hat er Wirtschaftswissenschaften an der FAU in Nürnberg studiert. Nun freut er sich darauf, mit seinen Kollegen zusammen zu arbeiten und einen neuen Weg einzuschlagen. Seine Freizeit verbringt er am liebsten mit seinen Freunden. Ob Zocken, Bouldern, Spikeball oder Kochen - irgendetwas ist immer los.
Lies mehr von Leander und triff unser Team

Logstash-Konfiguration im Team

von | Jan 18, 2019 | , ,

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier „sich häufig ändernde und nicht immer klar strukturierte Logformate“)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig „dreinpfuschen“
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
Thomas Widhalm
Thomas Widhalm
Manager Operations
Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...
Lies mehr von Thomas und triff unser Team

Things done wrong: Custom Packages

von | Jun 12, 2015 | ,

Homer Simpson
Als Consultant begegne ich öfter Konzepten jeglicher Art, sei es das ich sie erstellen darf oder mich bei der Umsetzung an diese halten muss. Besonders wenn letztere unkommentiert als Firmenrichtlinie hinzunehmen sind, komme ich oft nicht mehr aus dem Kopfschütteln raus. In diesem Blogpost will ich nun anfangen mit solchen Konzepten abzurechnen und werde wohl immer wieder neue Themen folgen lassen. Ich werde hierbei keine Kundenbeispiele direkt übernehmen sondern Beispiele mischen um es noch weiter zu überspitzen. Auch soll sich natürlich niemand angegriffen fühlen, wenn sein Konzept ähnlich aussieht, denn meist lässt es sich mit historisch gewachsen begründen. Aber vor allem will ich Probleme aufzeigen, die durch die Konzepte erstehen und dazu anregen solche veralteten Konzepte auf den Prüfstand zu stellen.
Das erste Thema, das ich aufgreifen möchte, ist das Thema Softwareinstallation. Die meisten Projekte und Administratoren haben mittlerweile eingesehen, dass lokale Installation aus dem Quelltext-Archiv nicht mehr zeitgemäß ist. Darum liefern Projekte oftmals auch direkt Pakete aus oder stellen zumindest die dazu nötigen SPEC-Files bereit. Die Gründe hierfür sind meist Nachvollziehbarkeit, geringerer Aufwand, kein Kompiler auf dem System, kein mühsames Ermitteln von Abhängigkeiten, etc. Daher existieren viele Konzepte für das Paketieren von Software, welche nicht vom Distributor ausgeliefert wird. Genau mit diesen möchte ich mich beschäftigen.
Nun auf welche Vorgaben trifft man häufig?
* Selbst paketierte Software soll in ein bestimmtes Verzeichnis installiert werden
* Die Software soll einem speziellen eigenem Benutzer gehören
* Alles soll aus einem einzelnen Paket kommen
* Das Paket soll schon die fertige Konfiguration enthalten
* Pakete müssen parametrierbar sein, da je nach Umgebung andere Pfade, Benutzer, etc. verwendet werden sollen.
Mit diesen Vorgaben möchte ich mich nun im Folgenden auseinandersetzen.
Das Argument selbst paketierte Software in ein eigenes Verzeichnis zu installieren ist üblicherweise Sicherheit. Dieser Mythos hält sich erstaunlicherweise und ich suche den Sicherheitsgewinn ähnlich verzweifelt wie den Yeti oder Nessie. Vielleicht lässt sich hier noch entsprechend argumentieren wenn das Verzeichnis mit speziellen Mount-Optionen als separate Partition eingehängt ist. Aber die Optionen, die einen wirklichen Sicherheitsgewinn bieten wie ACLs oder das Abschalten gewisser Optionen wie das Ausführen von Dateien, Uid-Flags, Devices, werden hier meist nicht genutzt. Zudem könnten diese meist besser und gezielter eingesetzt werden, wenn das Paket in Standardpfaden installiert ist und nur gewisse Verzeichnisse ausgehängt werden, zum Beispiel für temporäre Daten.
Gefährlich wird dies meist in Kombination mit der Vorgabe alles einem bestimmten Benutzer zu übereignen. Eigentlich ist ein Benutzername völlig egal. Benutzer unter denen ein Dienst läuft sollten sich aber üblicherweise nicht am System anmelden können und auch nicht auf schreibend auf ihre Konfiguration oder gar Binärdateien zugreifen können. Die Vorgabe kommt meist daher, dass der Benutzer dann allerdings zur Administration verwendet wird statt administratives und Dienstkonto zu trennen. Kann der Dienst nun seine Konfiguration schreiben, eröffnet dies viele Möglichkeiten für Exploits, denn es hat meist seinen Grund warum ein Dienst mit einem unpriviligierten Benutzer läuft. Noch besser wird es wenn der Benutzer den Dienst mittels sudo als root starten darf und Startskript, in dieses eingebundene Dateien oder Binärdateien verändern kann, damit sind in Sekunden die Rechte ausgeweitet, also genau das Gegenteil vom Ziel der Vorgabe erreicht.
Auch andere Sicherheitskonzepte wie SELinux werden durch die verbogenen Pfade schnell unwirksam, denn ohne die entsprechenden Dateikontexte greift die Policy nicht mehr. Der Aufwand Pakete so umzubiegen und dann weiterzupflegen, insbesondere wenn auch Python-, Perl- oder ähnliche Pfade umgebogen werden, ist dann üblicherweise auch so groß, dass Updates seltener gemacht werden als wenn die Software ohne weiteren Aufwand bezogen werden könnte. Auch dies setzt die Sicherheit weiter herunter.
Natürlich gibt es auch Konzepte, die den Aufwand gering halten, wie die von Red Hat eingeführten Software Collections, trotzdem muss immer noch selbst Aufwand betrieben werden. Der Aufwand ist dann besser darin investiert ein Konzept zu erstellen, welches dem Administrator der Zusatzsoftware erlaubt entsprechende Befehle mit sudo aufzurufen und Konfigurationsdateien über ACLs zu editieren, Logdateien zu lesen, …
Die Vorgaben zusätzliche Dateien oder angepasste Konfigurationen schon mit dem Paket mitzuliefern sind zwar machbar, erhöhen aber die Komplexität weiter und es lässt sich schwerer nachvollziehen woher Dateien ursprünglich kommen. Zusätzliche Dateien sollten also in eigene Pakete, Konfigurationen wenn man nicht auf eine Konfigurationsmanagementlösung setzen möchte in ein eigenes Konfigurationspaket. Über Befehle wie rpm -qf lässt sich dann nachprüfen aus welchem Paket eine Datei kommt, mit rpm -qi erhält man Informationen wie die Bezugsquelle und rpm -qV zeigt welche Dateien nachträglich verändert wurden.
Die Anforderung Pakete parametrierbar zu machen finde ich besonders seltsam, da es beim Paketieren nicht nur darum geht Software nicht auf dem System zu übersetzen, sondern auch Nachvollziehbarkeit in allen Aspekten zu schaffen. Da sich nie ausschließen lässt, dass ein anders gesetzter Parameter die ausgeführte Software beeinflusst, geht hierdurch für mich viel Nachvollziehbarkeit verloren. Diese möchte man besonders beim Updaten haben um Probleme auszuschließen.
Ich hoffe zum Nachdenken angeregt zu haben und Argumentationsgrundlagen für entsprechende Konzepte geliefert zu haben. Die nächsten Konzepte, die ich bei Gelegenheit betrachten möchte, sind das Benutzer- und Softwaremanagement und danach fällt mir bestimmt noch weiteres ein, wenn Interesse besteht. Und wer sein Konzept von mir zerpflückt haben möchte oder eins geschrieben braucht, ich bin natürlich ebenso käuflich wie die Kollegen. 😉

Dirk Götz
Dirk Götz
Principal Consultant
Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.
Lies mehr von Dirk und triff unser Team

Neu im NETWAYS Portfolio – Puppet Starterpaket

von | Jun 18, 2013 | , , , , , , , , ,

Puppet_LogoBei Puppet handelt es sich um ein OpenSource Konfigurationsmanagement System, welches vom amerikanischen Unternehmen PuppetLabs entwickelt wird.
Puppet bietet den Vorteil, Administratoren bei z.B. regelmäßigen Aufgaben wie Paketinstallation, Serverinstallationen oder Konfigurationsänderungen zu entlasten.
Das gesuchte Stichwort heißt: Automatisierung.
Um Unternehmen beim Einstieg in die Puppet-Welt zu unterstützen, bieten wir seit einiger Zeit das Puppet Starterpaket in zwei Varianten an:
Puppet Starterpaket Standard
Dieses Paket besteht aus einem 4-Tages-Workshop mit einem unserer Puppet-Consultants, welcher eine Evaluierung einer vorhanden IT-Umgebung vornimmt und anschließend eine mögliche Konzeptionierung aufzeigt, um Puppet erfolgreich zu implementieren. Anschließend wird der Puppet-Master sowie ein Versionskontrollsystem (z.B. SVN, Git, etc.) installiert, um Änderungen an den Puppet-Modulen nachzuvollziehen. Für einen noch besseren Einstieg, werden zusätzlich einige Beispielmodule erstellt, welche im späteren Verlauf natürlich weiter angepasst werden können.
Puppet Starterpaket Premium
Für komplette Einsteiger im Puppet-Bereich, die bisher noch keine persönlichen Berührungspunkte hatten, bieten wir im Premium-Starterpaket zusätzlich zu den 4 Workshop-Tagen noch 3 Tage Vor-Ort Schulung für 3 Teilnehmer an (weitere Teilnehmer gegen Aufpreis möglich).
Die Schulungsinhalte werden 1:1 von unserer Puppet Fundamentals-Schulung übernommen, inkl. Schulungsnotebooks, Schulungsunterlagen sowie ein Teilnehmerzeugnis.
Je nachdem wie komplex die Umgebung und die jeweiligen Anforderungen an das Puppet-System sind, können folgende Themen im Rahmen des Workshops noch mit aufgenommen werden:

  • Einrichtung von Foreman
  • Einrichtung der PuppetDB
  • Anbindung von externen Datenquellen

Selbstverständlich unterstützen wir auch bei individuellen Anfragen zum Thema Puppet oder beim Betrieb einer bereits vorhanden Puppet-Umgebung, auf Basis unserer Supportverträge oder von Consulting-Dienstleistungen.
Für einen persönlichen Kontakt stehen wir ebenfalls sehr gerne zur Verfügung – weitere Details für eine Kontaktaufnahme sind in unserem Kontaktformular zu finden!

Christian Stein
Christian Stein
Manager Sales
Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".
Lies mehr von Christian und triff unser Team

Trainings

Web Services

Events