Jenkins Deployment Dashboard Plugin für Amazon EC2 Umgebungen

Keine Kommentare

Dieser Blog Artikel beschreibt ein neues Jenkins Plugin, welches wir nach dem Feedback zur Continuous Delivery in the Cloud begonnen haben zu entwickeln. In den ursprünglichen Continuous Delivery Blog Artikeln haben wir das Setup und die Konfiguration einer Deployment Pipeline basierend auf Open Source Tools beschrieben. Um eine größere Anzahl an Test- und Produktivumgebungen über ein Dashboard zu verwalten, haben wir ein einfaches Dashboard aus statischem HTML generiert. Wir haben sehr viele Rückfragen zu diesem Dashboard erhalten und ob es ein Jenkins Plugin sei und wie es verwendet werden kann. Dieses Feedback hat uns dazu gebracht, dieses Dashboard als flexibles Jenkins Plugin zu entwickeln, Jenkins EC2 Deployment Dashboard Plugin. Wir denken, dass es jetzt eine ausreichende Stabilität besitzt, um offiziell released zu werden.

Welche Probleme löst das Jenkins Plugin?

Typischerweise haben Unternehmen verschiedene Umgebungen auf denen verschiedene Versionen einer Anwendung getestet werden können, bevor sie auf in die Produktionsumgebung deployed werden. Es sollte mindestens eine Test, Staging und Produktionsumgebung existieren. Testumgebungen werden oft von verschiedenen Entwicklern mit neuen Software Versionen bestückt. Größere Teams verlieren dabei schnell den Überblick welche Version aktuell deployt wurde. Um projektübergreifend Transparenz bzgl. der deployten Versionen zu schaffen, ist ein zentrales Dashboard sehr nützlich. Zusätzlich sollte es für den Product Owner möglich sein mit einem einfachen One-Click Build eine spezielle Software Version auf eine der Umgebungen zu deployen.

Dieses Plugin versucht diese Probleme der Übersichtlichkeit und Transparenz zu lösen.

Welche Vorraussetzungen müssen für die Verwendung des Jenkins EC2 Deployment Dashboards erfüllt sein?

Sie benötigen die folgenden Tools und Server Umgebungen um dieses Plugin verwenden zu können:

  • Amazon EC2 Instanzen für ihre Server Umgebungen (z.B. Produktion/Staging/Test Umgebungen)
  • Artifactory oder Nexus als Artefakt Repository um ihre Software Artefakte zu speichern (z.B. WAR, EAR, RPM, …)
  • Jenkins für das Bauen und Deployment ihrer Software (http://jenkins-ci.org)

Dashboard Ansicht

Hier ist ein Screenshot der Jenkins Deployment Dashboard Ansicht. Auf dem Dashboard sind alle konfigurierten EC2 Instanzen auf einen Blick zu sehen. Es wird der aktuelle Server Status angezeigt, sowie die deployte Software Version, Uptime, Instanz Typ und die aktuelle IP Adresse. Im oberen Bereich werden alle verfügbaren Software Versionen aus dem Artefakt Repository angezeigt. Aktuell unterstützt das PlugijFrog Artifactory und Sonatype Nexus als Artefakt Repository.

1-dashboard

Basic Workflow

  • Ein Continuous Integration Job baut die aktuellste Version der Software und lädt das fertige Artefakt in ein Artefakt Repository
  • Vom Deployment Dashboard aus, kann man alle vorhandenen Artefakt Versionen aus einer Dropdown Liste auswählen und eine Umgebung angeben, wohin die ausgewählte Version deployt werden soll
  • Der Deployment Job bekommt die VERSION und das ENVIRONMENT als Parameter übergeben. In diesem Job können sie ihre eigenen speziellen Deployment konfigurieren, die anhand der Version und der Umgebung das Deployment durchführen. Im Anschluss wird die EC2 Umgebung automatisch mit der VERSION getagged

Jenkins Plugin, Artifact Repository, AmazonEC2 Instances

Plugin Konfiguration

Globale Jenkins Konfiguration

Dieses Plugin ist jetzt über die Jenkins Update Site verfügbar. Das ist der einfachste Weg es zu installieren. In den folgenden Abschnitten wird die Konfiguration Schritt für Schritt beschrieben:

Das konfigurierte Artefakt Repository verwenden wir später für das Deployment Dashboard. Darüber werden alle für ein Deployment verfügbaren Version geladen.

0-jenkins-configuration-artifactory

Globale Amazon Zugangsdaten Konfiguration

Als nächstes müssen die globalen AWS Zugangsdaten eingerichtet werden. Hierfür bitte http://localhost:8080/jenkins/credential-store/ aufrufen

  • Danach Manage Credentials um die Zugangsdaten einzugeben
  • Im Anschluss die Verbindungsdaten testen

Die AWS Zugangsdaten werden benötigt, um die wichtigsten EC2 Umgebungsinformationen abfragen zu können und Label an den EC2 Instanzen aktualisieren zu können. Falls sie noch keine AWS Zugangsdaten in der AWS Konsole eingerichtet haben, finden sie hierzu die Anleitung weiter unten, inkl. einer vollständigen Beschreibung.

0-jenkins-configuration-credentials

Deployment Job Konfiguration

Als nächstes muss ein parametrierbarer Job angelegt werden, der zwei Parameter entgegennimmt. Diesen Job verwenden wir später für das Deployment der Anwendung.

  • Der erste Text Parameter bekommt den Namen VERSION
  • Der zweite Text Parameter den Namen ENVIRONMENT
  • Zum Schluss muss noch der Build Schritt mit dem Namen EC2 Environment und den passenden AWS Zugangsdaten ausgewählt werden

Der EC2 Environment Build Schritt tagged automatisch die EC2 Umgebung mit der übergebenen VERSION. In diesem Deployment Job können sie ihre eigenen Dployment Skripte konfigurieren und die übergebenen Parameter verwenden, um die korrekte VERSION ihrer Software auf das korrekte ENVIRONMENT zu deployen. Stellen sie zudem sicher, dass sie die korrekten AWS Zugangsdaten und AWS Region konfiguriert haben.

3-deployJob

Dashboard Ansicht Konfiguration

Nachdem wir alle Vorbereitungen getroffen haben, kommen wir jetzt zur Konfiguration der Dashboard Ansicht. 

  • Zuerst muss eine neue Ansicht vom Typ Deployment Dashboard angelegt werden, http://localhost:8080/jenkins/newView
  • Als nächstes konfigurieren wir die Ansicht:
    • Mit der Checkbox Display available Releases aktiviert man die Dropdown Liste mit den Artefakt Versionen auf dem Dashboard, sowie einen Deployment Knopf
    • Dazu muss die groupId und artifactId des Artefaktes angegeben werden, für welches die Versionen im Artefakt Repository gesucht werden sollen
    • Als nächstes können sie alle ihre EC2 Umgebungen anlegen, auf die ihre Software deployed werden soll
    • Als Build Job wählen sie bitte den Deploy Job aus, den wir zuvor angelegt hatten
    • Zum Schluss noch die Konfiguration speichern

Hier eine Übersicht, wie ihre Konfiguration aussehen sollte:

5-view-config

Nun sollten sie den Status ihrer EC2 Umgebungen auf dem Dashboard sehen, sowie die Versionen und weitere Details. In der oberen Hälfte des Dashboards ist eine Auswahlbox zu sehen, in der alle Versionen ihres Software Artefaktes angezeigt werden. Die Versionen wurden aus ihrem Artefakt Repository geladen. Wenn sie eine VERSION auswählen und ein ENVIRONMENT können sie mit dem Deploy Knopf den Deployment Job starten.

Fertig 🙂

AWS Sicherheitseinstellungen

Zuerst ein paar generelle Informationen. AWS EC2 Instanzen können mit eigenen Labels getagged werden. Dieses Plugin verwendet Tags um die Umgebungen zu identifizieren und die Versionsnummer an der Umgebung zu speichern. Hier ist ein Screenshot von der AWS Management Konsole. Die EC2 Instanz mit der ID i-294e3b6b wurde mit der Version 1.4.416 getagged.

4-aws-tags

AWS Access Key anlegen

Um einen AWS Access Key mit ausreichend Rechten anzulegen, müssen sie die folgenden Schritte durchführen:

  • AWS Konsole starten https://console.aws.amazon.com/iam/home?#users
  • Neuen IAM User anlegen
  • Danach User Policy auswählen  Custom Policy → Select → Set Policy Name → zum Schluss das folgende Policy Statement setzen 
    • allow User to create tags
    • allow User to delete tags
    • allow User to describe instances

Anstatt jede Policy separat auszuwählen, können sie auch das folgende Statement kopieren.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1412928158000",
      "Effect": "Allow",
      "Action": [
        "ec2:DeleteTags",
        "ec2:DescribeInstances",
        "ec2:CreateTags"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Zusammenfassung

Ich hoffe ihnen hilft das Plugin bei ihren Projekten weiter. Sie können den Source Code auf Github unter https://github.com/jenkinsci/ec2-deployment-dashboard/ forken. Über Anregungen und Rückmeldungen würde ich mich sehr freuen.

 

Marcel Birkner ist seit 2012 als Software Consultant bei der codecentric AG tätig. Er unterstützt seine Kunden insbesondere bei der Umsetzung von Continuous Integration und der Optimierung von Release-Prozessen. Aufgrund seiner langjährigen Erfahrung als Architekt und Entwickler verfügt er über ein umfassendes Wissen über Java und Open-Source-Technologien.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.