DevOps und Cloud-Reifegradmodelle verstehen: Ein Leitfaden zur Verbesserung Ihrer IT-Strategie
Im heutigen schnelllebigen Technologiebereich sind DevOps- und Cloud-Praktiken entscheidend, um die Software-Bereitstellung zu beschleunigen und
In diesem Abschnitt erfahren Sie, was Sie nach der Fertigstellung von Cookbooks tun können.
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).
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.
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.
Sie interessieren sich für unsere Trainings oder haben einfach eine Frage, die beantwortet werden muss? Sie können uns jederzeit kontaktieren! Wir werden unser Bestes tun, um alle Ihre Fragen zu beantworten.
Hier kontaktieren