Verwaltung von SUSE Linux Paketen mit Katello

Katello-Logo

Katello erweitert Foreman um Content-Management oder da es mir primär um Linux-Pakete geht bevorzuge ich den Ausdruck Software-Management. Über Lifecycle-Environments und Content-Views werden hier Snapshots der Repositories erstellt und den verschiedenen Stages nacheinander präsentiert, damit in Produktion auch tatsächlich die Updates landen, die auch vorher getestet wurden. Doch darüber habe ich bereits vor einer Weile geschrieben. Seitdem hat sich zwar einiges weiterentwickelt, insbesondere ist die Unterstützung für Debian dazugekommen. Aber darüber möchte ich berichten wenn auch noch der Support für Errata-Management für Debian soweit ist.

Stattdessen möchte ich auf die Unterstützung für SUSE eingehen. Diese wurde von ATIX entwickelt und als Foreman-Plugin “ForemanSccManager” veröffentlicht. Wer die “Red Hat”-Unterstützung von Katello kennt, wird die Funktionalität recht schnell wieder erkennen. Das Plugin fügt einen neuen Menüpunkt hinzu, der es erlaubt Accounts für den Zugriff auf das SUSE Customer Center anzugeben und die damit verknüpften Softwareprodukte einfach zur Synchronisation auszuwählen. Dies finde ich besonders hilfreich, da SUSE zur Authentifizierung nicht nur mit Benutzer und Passwort sondern auch einem Token in der URL arbeitet, welches das manuelle Handling hier leider erschwert.

Wenn jemand ein paar Screenshots sehen möchte, möchte ich ihn auf die Orcharhino-Dokumentation (einem Produkt auf Basis von Katello) verweisen, denn das Plugin befindet sich schon eine Weile bei ATIX und ihren Orcharhino-Kunden im Praxis-Einsatz. Wer also auf SUSE angewiesen ist und noch eine Lösung für das Softwaremanagement sucht, kann mit Katello und dem ForemanSccManager auf eine modernere Plattform als Spacewalk oder den darauf basierenden SUSE-Manager setzen. Wer bereits auf Katello setzt und SUSE nutzt, dem kann ich nur empfehlen seinen Workflow auf das Plugin umzustellen.

Dirk Götz
Dirk Götz
Senior 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.

Config Management Camp Ghent 2019

Ich habe dieses Jahr die erste Gelegenheit bekommen, mich mit meinen Kollegen und meinem Chef am Configuration Management Camp im Ghent zwischen 4. und 6. Februar zu beteiligen. Wir sind am 3. Februar am Abend in Ghent angekommen und durch die Stadt spazieren gegangen. Ghent hat uns sehr beeindruckt: Nicht nur die Sauberkeit der Straßen, sondern auch die Verbindung von alten und neuen Gebäuden haben Ghent besonders schön wirken lassen.

DevOps und Konfigurationsmanagement

Aber der Höhepunkt war das Camp: Es gab fast 1000 Teilnehmer aus der ganzen Welt. Die Vorträge waren sehr informativ und gingen hauptsächlich um DevOps und Konfigurationsmanagement ( Puppet, Ansible, Chef, Foreman). Viele Referenten haben sowohl ihre Erfahrungen sowie zuletzt aufgekommene und gelöste Probleme in ihrer Firma geteilt, als auch neue Features im Automation- und Konfigurationsmanagement-Feld vorgestellt. Am dritten Tag nahm ich mit meinem Kollegen und Ausbilder auf dem Foreman Construction Day Workshop teil. Wir haben uns in Gruppen praktisch mit “Foreman” beschäftigt. Am Ende des Tages haben einige Foreman-Entwickler und Teilnehmer über Wünsche, Verbesserungen und kommende Features gesprochen.

Ich empfehle jedem, der Interesse am Konfigurationsmanagement hat, das nächste Camp zu besuchen und belgische Waffeln und Bier auf jeden Fall zu probieren. Die sind sehr, sehr lecker.

 

 

 

 

 

 

 

Afeef Ghannam
Afeef Ghannam
Junior Consultant

Afeef macht seit September 2017 eine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS. Nachdem der gebürtige Syrer erfolgreich Deutsch gelernt hat, stellt er sich jetzt der Herausforderung Programmiersprache. Neben der IT schätzt er vielfältiges Essen. Sein Motto lautet يد واحدة لا تصفق لوحدها , was so viel bedeutet wie „Eine Hand wird nie allein klatschen“.

GitLab CI + Docker + Traefik = ❤️

So wie vermutlich einige, bin auch ich zur Zeit sehr von GitLab und dessen CI/CD Features angetan. Vor einigen Monaten habe ich angefangen, für meine privaten Webprojekte eine Template .gitlab-ci.yml zu erstellen, welche für jeden Commit, auf jedem Branch, automatisch Docker Images baut und diese in meiner Docker-Umgebung mit zum Branch/Projekt passender Subdomain und SSL-Zertifikat bereitstellt.

Um zu funktionieren benötigt das ganze eine erreichbare Docker-API, ein darauf laufendes Traefik, ein Docker-Netzwerk namens Proxy (Traefik muss dieses auch nutzen) und einen Account + Repository auf hub.docker.com. Das ganze kann aber recht einfach umgeschrieben werden, falls man seine eigene Registry verwenden möchte.

Ablauf beim Commit:

  1. Bauen und Pushes des Images (Tag => Branch + Commit-Hash)
  2. Umbenennen des alten Containers, falls vorhanden (Suffix ‘-old’ wird angehangen)
  3. Erstellen des neuen Containers (Name => Deployment Domain bsp. master.dev.domain.tld)
  4. Löschen des alten Containers
  5. (Optional) Löschen & neu erstellen des Produktionscontainers, falls der Commit auf dem Masterbranch stattgefunden hat (Muss durch Button ausgelöst werden und läuft wie Schritte 2 bis 4 ab)
  6. Neue Container stehen unter den Deployment-Domains zur Verfügung

Pipeline eines Commits auf Master/andere Branches (Deploy auf Produktion kann durch “Play”-Button ausgelöst werden):

Pipeline eines Commits auf andere Branches:

Für jeden Branch wird auch ein Environment erstellt, welches über Operations/Environments in GitLab verwaltet werden kann.
Hier können Deployments angesehen, gelöscht, in Produktion ausgerollt und auf einen früheren Stand zurückgesetzt werden:

Zur Nutzung des Templates in einem Projekt wird ein Dockerfile im Repository, ein paar CI/CD-Variablen, und das Template selber benötigt.

Benötigte CI/CD-Variablen:

CI_DEV_URL_SUFFIX (Domain-Suffix der Development-Umgebungen): dev.domain.tld
CI_PRODUCTION_URL (Domain der Produktionsumgeben): domain.tld
CI_DOCKER_HOST (Adresse & Port der Docker-API): docker.domain.tld
CI_REGISTRY_IMAGE (Image-Name auf hub.docker.com): supertolleruser/supertollesoftware
CI_REGISTRY_USER (Docker-Hub Benutzer): supertolleruser
CI_REGISTRY_PASSWORD (Passwort des Docker-Hub Benutzers): supertollespasswort
CI_TRAEFIK_PORT (Port der Webanwendung im Container): 8080

Da das ganze Projekt bis jetzt nur Images baut und Container bereitstellt, könnten hier natürlich noch Tests eingebaut werden um das ganze abzurunden.

Zur Zeit arbeite ich an einer Umstellung auf Kubernetes und werde, sobald abgeschlossen, auch davon berichten.

Noah Hilverling
Noah Hilverling
Junior Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

NoCode, Security by Design

NoPicture

Bei Netways sind wir immer am Puls der Zeit und probieren für euch den neuesten heißen Sch**ß aus. Heute möchte ich euch deswegen NoCode vorstellen. Wenn man NoCode noch nicht kennt; es kann als logische Fortsetzung aller aktuellen Cloud Technologien und Everything as Code Initiativen gesehen werden. So konnte sich NoCode innerhalb kurzer Zeit einen zentralen Platz auf der CloudNative Landscape sichern
Am Anfang steht die Lochkarte. Auf dieser sind Programme binär abgespeichert und werden von damaligen Großrechnern ausgeführt. Leider enthält der Code dieser Anwendungen einige wenige Bugs, was allgemein Verunsericherung führte. Lochkarten werden nach kurzer Zeit wieder abgeschafft.

Weiter geht es mit solide programmierten Unix und Windows Serveranwendungen, die innerhalb von vielen Unternehmen hervorragende Dienste leisteten. Da mit zunehmender Vernetzung die Probleme dieser Lösungen offensichtlicher wurden und man nicht schnell genug hinterher kam einen Fehler immer wieder durch zwei neue zu ersetzen, schaffte man vielerorts diese Insellösungen wieder ab und setzte auf Standards. Das Glück für die schon beinahe von Arbeitslosigkeit bedrohten Admins, es gibt derlei sehr viele.
Mittlerweile haben wir Virtualisierung und können mit P(roblem)aaS, I(nsecure)aaS und S(anduhr)aaS fast alle Kundenwünsche im keim … erfüllen. Ab diesem Zeitpunkt, wo man dank DevOps und dezentralen verbindungslosen Orchestrierungstools seine Bugfixes auf tausende Container gleichzeitig deployen kann, wird es Zeit sich von diesen noch beinah beherrschbaren Problem Factories zu verabschieden.
Jetzt können papierlos, hardwareless, connectionless und configurationless einpacken. Wir machen serverless und führen Funktionen ‘direkt in der Cloud’ aus.
Da wir alles vom Strom, über das Netzwerk bis zum Server abschaffen, fehlt nur noch der Code.
Genau hier springt NoCode ein. Mit wenigen Zeilen NoCode kann man sich fast alle Anwendungsfälle moderner Applikationen vorstellen. Das beste an NoCode, es enthält niemals Bugs und kann für die verschiedensten Einsatzzwecke genutzt werden. Als erste Enterprise Monitoring Lösung hat auch icinga2 die NoCode notation eingeführt. Jedes in NoCode geschriebene config file wird klaglos von der Syntax Prüfung akzeptiert. Ein Kollege arbeitet gerade daran ein neues Backend Feature in NoCode zu implementieren. Ich habe noch keine Details gesehen, aber es rennt wie Sau.

Schaut euch unbedingt das NoCode github Repo von Kelsey Hightower, dem verantwortlichen google Hacker, an. Hier könnt ihr das Projekt auschecken und mit docker testen.

Wer jetzt heiß ist und mal eine Anwendung im live Betrieb sehen möchte. Die vom führenden Crypto Anbieter ROT26 angeboteny Crpyto API ist gerüchteweise in NoCode implementiert. Probiert es direkt aus

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Open Source Camp: Hurry up to get on stage!

You know how to automate things with Ansible? You enjoy sharing your knowledge with your fellows? Then hurry up to get on stage and become a speaker at OSCAMP!

Call for papers runs until February 2019! Submit your paper here.

Open Source Camp is a series of events giving Open Source projects a platform to present themselves to the community. Its third edition on Ansible takes place right after OSDC‘s lecture program on May 16 in Berlin.

 

#OSCAMP | May 16, 2019 | Berlin

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Meine ersten eigenen Projekte

Das letzte Mal das ich einen Blogpost geschrieben habe ist jetzt schon ein Weilchen her und das Thema hat sich wenig mit meiner Arbeit beschäftigt – Teamwochenende.

Doch in den letzten Wochen habe ich meine ersten eigenständigen Projekte bekommen. Zunächst hat mir Markus die Aufgabe gegeben eine Backup-Lösung für unsere Notebooks zu finden. Vorgabe hierzu war es, sowohl Disaster Recovery und normale Datensicherung zu bewerkstelligen. Dies habe ich mittels Relax and Recover und DejaDub gelöst.

Natürlich hatte die Aufgabe ihre Tücke, wenn man noch keine Erfahrung mit dem Thema hat, aber zum Einstieg war das genau richtig. Vor Allem hat mir die Aufgabe die Möglichkeit gegeben nicht nur Erfahrung sondern auch Selbstvertrauen zu sammeln.

Danach bekam ich das Stichwort “Puppetized Graphing” zugeworfen, dahinter verbirgt sich dass ich Grafana und Graphite via Puppet installieren sollte. Ziel war es auch das Graphite und Grafana miteinander kommunizieren und alles was dazu gehört, sprich Datenbank und ähnliches. Ich durfte bei Netways auch schon einige Schulungen absolvieren und habe über entsprechende Grundlagenkenntnisse von Puppet verfügt, genauso wie Graphite und Grafana, und hatte auch Unterlagen, sowie Referenzen, aber einige Fallstricke kamen bei dem Thema trotz alledem auf mich zu.

In dem Zeitraum habe ich dutzende Versuche gestartet und bin oft hingefallen und hab Dinge gelernt, die ich ursprünglich gar nicht mit dem Thema in Verbindung gebracht hätte. Zu keinem Zeitpunkt hab ich mich allein gefühlt in meiner Aufgabe, denn auch wenn mal ein Kollege grinsend an der gigantischen Fehlerausgabe vorbei lief, wurde oft genug gefragt ob man mir den helfen könnte und auch umgekehrt, hat mich keiner abgewunken, wenn ich mal Hilfe brauchte.

 

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.