x

Menü

Chef Workflow: Part 3 - Cookbooks In Produktion

veröffentlicht in: Configuration Management Datum: 01.12.2017
Miriam Grainer, Junior IT-Consultant

Über die Autorin

Miriam Grainer ist eine Junior IT-Beraterin für Infralovers und Commandemy. Miriam liebt es neue Technologien und Programmiersprachen zu lernen und damit zu experimentieren. Derzeit studiert sie Informationsmanagement an der FH Joanneum Graz. Twitter LinkedIn

Alle Artikel von diesem Autor sehen

Cookbooks in Produktion

In diesem Abschnitt erfahren Sie, was Sie nach der Fertigstellung von Cookbooks tun können.

Phase 1 - Upload

Wir betrachten ein Cookbook als beendet, wenn alle Tests erfolgreich waren. Ein Cookbook ohne Tests gilt nicht als beendet. Wenn die Tests existieren, führt der Ersteller einen Merge-Request von seinem Fork an das Upstream-Git-Repository durch, aus dem er geforkt hat. Das Git-Repository ist durch ein Continuous Integration System (CI) (z.B. Jenkins) zugänglich. Der einzige manuelle Schritt, der benötigt wird, ist der Upload vom Entwickler. Der Rest wird automatisch ausgeführt.

Die CI führt die Tests erneut durch und analysiert das Cookbook auf häufige Fehler oder Inkonsistenzen (Foodcritic, Rubocop). Wenn dies gelingt, wird die CI GitLab darüber informieren, dass die Tests erfolgreich verlaufen sind. In der Regel wird dies mit “+1” gemacht, wenn die Tests erfolgreich sind, und mit “-1”, wenn sie fehlschlagen. Der Verlauf der Merge-Request in GitLab zeigt diese Antwort von Jenkins. Darüber hinaus könnte ein ChatOps-Tool auch benachrichtigt werden. Nachdem Jenkins GitLab einen +1 gegeben hat, weiß der Administrator des Repositorys jetzt, dass alles zu funktionieren scheint. Er prüft dann den Code selbst, und wenn er alles zu seiner Zufriedenheit findet, akzeptiert er den Merge-Request. Das Update vom Benutzer wird nun offiziell akzeptiert.

Wenn dies gelingt, wird die CI die Versionsnummer des Cookbooks auf eine ungerade Zahl schieben, wo die letzte Nummer ungerade gemacht werden sollte (z.B. 0.2.3). Die ungerade Zahl sagt uns, dass dies ein vollständig getestetes Cookbook ist, aber nur in einer Staging-Umgebung verwendet werden darf. Es wird dann von der CI auf einen Staging-Chef-Server hochgeladen. Das Cookbook ist nur produktionsbereit, wenn es eine gerade Versionsnummer hat (z. B. 0.2.4).

Phase 2 - Dependencies

Wenn das neue Cookbook von einem anderen Cookbook im System abhängig ist, werden diese Cookbooks ebenfalls getestet. Sie verwenden die ungerade Versionsnummer des Cookbooks vom Staging-Chef-Server mit ihrer neuesten Produktionsversion. Die CI führt den Test und das Linting erneut mit allen abhängigen Cookbooks durch. Phase 2 wird vollständig automatisch ausgeführt und wird auch von einem Continuous Integration System (CI) (z.B. Jenkins) ausgelöst.

Phase 3 - Building

Wenn alle Cookbooks aus dem Phase-2-Build erfolgreich sind, erhält das Cookbook eine gerade Versionsnummer, die in eine QA-Umgebung hochgeladen wird. In der QA-Umgebung werden echte Menschen echte Arbeit mit echter Infrastruktur leisten. Wenn die Betreiber entscheiden, dass alles stabil ist, können sie einen Knopf drücken und die Cookbooks werden zur Produktion befördert.

Wollen Sie mehr über Chef erfahren? Dann sehen Sie sich unsere Chef Trainings an.