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,...

GitLab Training v2.5.0 released

We have released v2.5.0 of our GitLab training today. Based on the feedback from previous trainings, and many things learned together with the students, we aim for the next classes already.

Dive deep into Git rebase, merge, squash, cherry-pick, get to know real-life development workflows and explore the possibilities of CI/CD pipelines and even more fancy GitLab features. Check our training schedule and register now!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Monthly Snap November


 
Remember one month ago? The first talks were about to start soon, you had your first coffee, enjoyed the rich Holiday Inn breakfast, took your journal, in which you had your plan for the day scetched, you were happy to meet an old friend in the hallway on your way to Saal Jacobi, where Bernd Erk was preparing to kick-off OSMC. …
OSMC – good times! Take some of its spirit with you into the cold and dark december days and let it warm your heart like a cup of hot Christkindlesmarkt mullet wine.

Form OSMC to Open Infrastructure

How? Make yourself a cup of hot wine and read through OSMC 2018 – Day 1 and OSMC 2018 – Day 2 by Dirk, or OSMC 2018 – or: The Thirteen-Star Conference, in which our attendees share their experiences. Read Michi’s Hackathon stories and Dirk’s report about OSCAMP on Puppet. You’re more of a visual type?  Browse through our OSMC Archive and find all the videos, pics and slides.
Right after OSMC our NWS-Team hit the road to Berlin for OpenStack Summit. Check out their managed Open Infrastructure service at nws.netways.de – now with MyEngineer support!

Icinga Seminar & Berlin Camp

Lennart Betz continues his blogpost-seminar Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile and Teil 10: Profile Part II. Join the Icinga community in 2019: Icinga Camp Berlin: Call for Papers is running until Decemeber 31! Find all November Icinga updates here.

For the tech hearts

Achim tell you to Get your RadosGW metrics into Ceilometer. Loei explains the use and functionality of RFID & NFC. Niko shares Neuheiten beim IntelliJ-Update. Tim knows Ceph Mimic | Using loop devices as OSD
In git gud! Henrik tells the story of: How I Learned to Stop Worrying and Love my Code. Noah introduces you with GitKraken to a nearly perfect Git-Client, while Johannes shares another useful tool: PDF manipulieren mit pdftk.

Presents

In November Silke announced Black Friday mal ganz in Orange – Es darf gespart werden und Die neue Generation der SMSEagle NXS-97xx Linie stellt sich vor. It‘s always a good idea to check our Shop for special offers. Especially if you are looking for Christmas presents. In that sense: Entschleunigung vom Weihnachtsstress bei Netways!
Have a wonderful December and Christmas season! Stay tuned!

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.

Neuheiten beim IntelliJ-Update

Ob Java12, Kotlin 1.3 oder Neuerungen für Git oder Editor-Features wie mehrzeilige To-do-Kommentare. Das alles erwartet einen in dem neuen großen Update der Entwicklungsumgebung: IntelliJ Idea.

Die Publisher von Jetbrains haben mit der neuesten Version 2018.3 das nächste große Update von Intellji Idea eingeleitet. Mit der Erneuerung kommen neben der Unterstützung von Programmiersprachenversionen noch viele andere Features, die folgende Inhalte liefern.

Neue Features für Java 12 und Kotlin 1.3

IntelliJ unterstützt jetzt das Preview-Feature für die Raw-String-Literale. (Bild: Jetbrains)
(Prewiew-Feature für die Raw-String-Literale)
Intellij Idea beinhaltet zukünftig mit der Version 2018.3 die Unterstützung der kommenden Java-12-Features. Eine Vorschau für die neue Raw-String-Literale kommt mit der im März 2019 neu erscheinenden Version der Programmiersprache. Die neue Anpassung der Java-IDE unterstützt die Funktion bereits auch mit entsprechenden Quick-Fixes, sprich ein Stück Code der durch diese Fix-Funktion markiert wird und entsprechende Lösungen vorschlägt. Doppelter und somit redundanter Code kann ab sofort auch in komplizierten Situationen erkannt werden. Solche Duplikate sind dann im Diff-Viewer einsehbar.
Redundante Bedingungen werden jetzt noch besser erkannt. (Bild: Jetbrains)
(Redundante Bedingungen werden jetzt noch besser erkannt.)
Jetbrains hat einige weitere Quick-Fix-Optionen ergänzt um redundanten Code zu beheben. Unter anderem zählt dazu der überflüssige Sortieraufruf bei einer darauffolgenden Nutzung der Min-Funktion, bei der der Java-Stream-API genauso wie die Erkennung bei vorangegangenen überflüssigen Bedingungen, die bereits durch eine darauffolgende verknüpfte Bedingung abgedeckt ist. Zudem erkennt Intellij mit der neuen Version die redundante Verwendung von Annotations für unterdrückte Inspektionen.
IntelliJ bietet bei einigen Code-Stellen eine automatische Migration zum neuen Kotlin 1.3. (Screenshot: Jetbrains)
(IntelliJ bietet bei einigen Code-Stellen eine automatische Migration zum neuen Kotlin 1.3.)
Zu den Java-Neuerungen hinzu kommt auch noch die Unterstützung von Kotlin 1.3. Damit die Migration des Projekts zur neuen Version vereinfacht werden kann, greift Intellij einem unter die Arme. Zum Beispiel kann man Imports und Kotlin-Dependencies automatisch anpassen lassen. Ebenso gibt es auch für Kotlin Inspektions- und Quick-Fix-Optionen sowie eine verbesserte Unterstützung für Multiplattformprojekte.

Verbesserung der Editor-Funktionen und Git-Integration

Der Editor selbst hat auch einige neue Neuerungen mitgebracht, z.B mehrzeilige To-do-Kommentare(siehe Bild/GIF) oder dass in der Statusbar die verwendete Anzahl an Leerzeichen für Einrückungen angezeigt wird. Falls die Einrückung nicht mit der Projekteinstellung übereinstimmt, wird dies entsprechend markiert und eine Lösung vorgeschlagen. Zusätzlich kommt Ihr über das Pop-up direkt zu den Editor-Config-Dateien für die jetzt auch Syntax-Highlighting sowie Code-Vervollständigung unterstützt wird.

Auch mehrzeilige To-Do-Kommentare sind mit der aktuellen IntelliJ-Version kein Problem mehr. (Bild: Jetbrains)
Bei Git hat sich auch einiges geändert wie zum Beispiel, dass Intellij jetzt Github-Pull-Requests unterstützt und die Funktion „History up to Here“ die gesamte Historie aufzeigt. Auch nützlich dürfte die Funktion sein, die es erlaubt, eine Datei aus einem anderem Branch zu kopieren. Einfach ein Rechtsklick auf die ausgewählte Datei und schon gelangt man ins Compare-Branches-Fenster.(siehe Bild)
Mit wenigen Mausklicks kann jetzt eine Datei von einem anderen Branch kopiert werden. (Screenshot: Jetbrains)
Neben der überarbeiteten Funktion zum Durchsuchen des gesamten Projekts hat Jetbrains einige weitere kleinere Neuerungen zur Verfügung gestellt. Das betrifft Kubernetes, Javascript und Maven. Alle Neuerungen diesbezüglich findet Ihr auf der Internetseite von Jetbrains unter diesem Blog.

Niko Martini
Niko Martini
Junior Developer

Egal ob zu Hause oder bei NETWAYS, Niko hockt gern vor dem PC. Ab und zu fährt er auch mal mit seinem Dad auf eine Fahrradtour quer durch Deutschland. Nach seinen ersten Tagen bei uns, in denen er NETWAYS, die Kollegen und Tools näher kennengelernt hat, freut er sich besonders auf die kommenden Jahre.

git gud! or: How I Learned to Stop Worrying and Love my Code

(…and I’m only 13 years late to the party…)
First of all, I have a confession to make. I’m code shy. At least that’s what I thought I was.
One of the fresh-faced young trainees this year here at NETWAYS, I’m not entirely “new” to the scene. Having gone to university (with varied success) I never was bestowed with the confidence to actually contribute to anything. In terms of feedback, my lecturers and I only looked at what I was doing wrong – yes, admittedly, to get me to stop what I was doing wrong, but approaching code like this made me feel like I was always doing something wrong.
Again, admittedly, I probably was always doing something wrong, but I felt like I shouldn’t contribute, I mustn’t contribute, the only thing I would add to an open source project would be bugs, I would mess things up more than I would be helpful to anybody. I’ve written some small stuff for myself at home, but.. why would anybody rely on my code?
It was an awful feeling. So I never did contribute. And that’s how I became code shy.
Three months into my stint at NETWAYS, and it all changed massively. Apart from my wonderful colleagues, git helped in a big way to give me more confidence, to be more active in my participation, to instill a kind of pride in my work I haven’t felt before – to stop worrying and love my code.
 

So – why write the millionth paragraph about git?

This won’t be a technical introduction, but rather a little recollection of my thoughts and emotions while getting introduced to git and using it at work – because my mind has been thoroughly blown.
 

What’s git?

Well, let’s take a look at good ol’ Wikipedia:

Git (/ɡɪt/) is a version-control system for tracking changes in computer files and coordinating work on those files among multiple people.

Version-control? Now, what’s that supposed to mean? Is that like back in the days when I sent my source code files to my professor via mail, so he could check over them and see if I did my stuff?
Well, in a way, that could be some sort of version control system as well – just not a very automated and effective one. Version control is about the general management of files, code, data – it keeps track of changes, who did what, when (and if you’re lucky, you’ll even find a hint or two explaining why), and it allows for reversion of changes and modifications people have made.
My ears perked up when I heard this.
I can go around and mess things up and nobody would get mad at me? I won’t break stuff from the get go? I was amazed.
 

But how does git do it?

At work we have remote repositories hosted on GitLab, from which I could pull all of the files of the project onto my local machine. So now I have my own copy of the project, in which I could move, delete, add or modify files to my liking – and I wouldn’t break anything doing so, because the remote repository on GitLab would be completely unchanged.
In a way, it’s a sandbox for me, where I can go ahead and code, take care of issues, fix bugs, or add features, test them – until I feel safe to share the work I’ve done with other people. You can see how that is a comforting feeling to have – you can code without worries.
 

So – what happens behind the scenes?

Git takes snapshots of my work. A snapshot is the way git keeps track of all of the files belonging to a project. Git will checksum them, generate a SHA-1 hash. These hashes are the way git knows about the changes to the code inside the files. After I’ve staged my modified files, I can commit the changes I’ve made. Committing will checksum all of the project directories and store them in the repository – and it will store a pointer to the commit that came before it. This is awesome! So now I can have multiple points to revert the project back to, just in case. But… how would I go about doing that?
Well, let’s talk about branches. Branches are pointers to these commits, the default one being the master branch. There is a master branch on my local machine as well as on GitLab – which made me immediately nervous again. But luckily, I can just branch off of my local master, give it a meaningful name, and even push and store the commits belonging to that branch to GitLab, with the master being untouched. Again, another safe environment for me to go about my work, be more assertive in sharing it, all in a peaceful state of mind.
So – thanks to git, I feel safe in being much more creative and independent when going about contributing to our projects here at NETWAYS – and thanks to the awesome work environment here, I do have space and time to try to add to these projects in a constructive way. My colleagues can look at my code, give me tips and hints, and neither them nor me have to worry about me being a nuisance messing things up.
But what if I’ve finally fixed a bug, or added an awesome feature to one of our projects? Then it’s time to make a merge request. On GitLab, I pick a branch of mine, write a little bit about the new functions or which bugs I (hopefully) fixed, and request for these changes to be added into the master. From there, my fate lies in the hands of the project maintainers…
A successful merge request might just be the greatest feeling of all.
I know that there are a million new ways I could break things if I use git wrongly. So, getting good at git is something I must and will learn at NETWAYS. And – bursting with pride and with a newfound confidence – I look forward to learning more every day.

Henrik Triem
Henrik Triem
Junior Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

GitKraken – Der nahezu perfekte Git-Client


Heute möchte ich euch GitKraken vorstellen, ein Git-GUI-Client welcher sich nun seit fast 3 Jahren bei mir im täglichen Einsatz findet und mir die Arbeit mit Git an einigen Tagen sehr vereinfacht.
Wieso ein GUI-Client, wenn man CLI haben kann?
Ich habe schon einige Male von Kollegen gesagt bekommen, dass ich GitKraken doch nur nutze, weil ich mit der CLI nicht zurecht komme. Der wahre Grund ist für mich einfach die viel bessere Übersicht über Changes, History und anderen Branches, schnelleres Auschecken und Resetten von Braches und auch manchmal, die Undo- und Redofunktionen.
Einfacheres Aufteilen in Commits
Jeder der oft viel schreibt und erst nach Stunden anfängt seine Arbeit in einzelne Commits aufzuteilen, weiß wie aufwendig es ist mit git add-p zu arbeiten. Diese Arbeit wird einem von GitKraken sehr vereinfacht und geht dadurch um einiges schneller. Hier können direkt einzelne Zeilen oder Hunks zum Stagen ausgewählt werden.
Was kostet der Spaß?
GitKraken kostet je nach Projekt zwischen 0€ und 99€/Jahr. Dies hängt von der Art des Projekts ab, an dem man mit GitKraken arbeitet. Möchte man mit dem Projekt Geld verdienen und es ist nicht Open-Source, dann muss man dafür mindestens 49€ im Jahr blechen. Wer jedoch ausschließlich an privaten und/oder Open-Source-Projekten arbeitet, kann GitKraken komplett kostenlos nutzen.
Nur nahezu perfekt
Auch wenn GitKraken einwandfrei funktioniert und sehr viele gut implementierte Funktionen bieten, hat es auch so einige kleine Macken. Um GitKraken nutzen zu können benötig man einen Account, GitKraken ist Closed-Source und kostet sogar Geld, wenn man es kommerziell nutzen möchte. Diese Aspekte treffen in der Open-Source-Community oft auf wenig Unterstützung.
Download
GitKraken ist für Windows, MacOS und Ubuntu/Debian erhältlich und kann hier heruntergeladen werden.

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,...