CI/CD-Pipeline mit AWS-Tools, Teil 1

DevOps-Projekte mit AWS CodeStar erstellen

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

Wer im Team arbeitet, darf in CodeStar das Anlegen der zusätzlichen Nutzer nicht vergessen.
Wer im Team arbeitet, darf in CodeStar das Anlegen der zusätzlichen Nutzer nicht vergessen. (Bild: Drilling / AWS Germany GmbH)

Im Jahr 2017 hat AWS den Dienst AWS CodeStar vorgestellt. Dieser soll das Einrichten und Betreiben von Continuous-Integration- und Continuous-Delivery-Pipelines besonders komfortabel machen. Ein solches Szenraio spielen wir hier durch.

Ein CodeStar-Projekt integriert sämtliche Ressourcen einer CI/CD- (sprich Continuous Integration and Continuous Delivery) Pipeline so miteinander, dass das ganze Projekt von einem zentralen Ort sicher erstellt, bearbeitet und verwaltet wird. AWS CodeStar ist aber auch in der Lage, mehrere interne und externe Entwickler auf sichere Weise in ein Entwicklungsprojekt einzubinden.

Konkret integriert CodeStar mehr oder weniger automatisch AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy und AWS Code Pipeline zu einer erprobten CI/CD-Toolchain. Jedes der genannten Tools ist aber natürlich auch für sich einsatzbar ist, verfügt über eine eigene grafische Management Console und lässt sich mit Hilfe eigener CLI/SDK-Calls verwalten und verwenden.

Dementsprechend ist es natürlich ebenso denkbar, jedes der genannten Tools wiederum mit jedem anderen dieser AWS-Tools oder auch mit vielen externen CI/CD-Tools zu integrieren. Nutzer können Ihre CI/CD-Toolchain dann in vielfältiger Weise aufbauen.

Toolchain nach Bedarf

Mit oder ohne CodeStar lassen sich mit AWS-Diensten, externen Cloud-Ressourcen und On-Premises-Tools CI/CD-Toolchains in vielfältiger Weise erstellen. Ein weit verbreiteter Ansatz ist z. B. die Verwendung von ...

  • Github, Gitlab oder Bitbucket als Cloud-basiertes Repository,
  • CodeBuild zum Bauen der Projekte für die unterschiedlichen Umgebungen,
  • CodeDeploy, Elastic Beanstalk oder CloudFormation für die Bereitstellung auf EC2, Lambda oder Physik, während sich
  • ein externer CI-Server wie Jenkins um die „Durchflusssteuerung“ kümmert.

Allerdings ist es dann meist schwieriger, die Schnittstellen/Übergänge von externen Services zu AWS oder On-Premises so zu konfigurieren, dass der Prozessfluss im Sinne von DevOps ohne manuelle Interaktionen, Genehmigungen oder sonstige Feedback-Schleifen durchläuft.

Wir haben jedes der genannten Tools bereits einzeln besprochen, hier wollen wir den Fokus auf das große Ganze, also die CI/CD-Pipeline legen. Verwendet man hierbei ausschließlich AWS-Services und überlässt das Projekt- und User-Management AWS CodeStar, gelingt das Einrichten, Betreiben, Überwachen und Visualisieren besonders elegant. Als Beispiel wollen wir im folgenden Workshop einen auf Python/Django basierenden Web Service auf EC2 ausliefern und betreiben.

Neues CodeStar-Projekt

In unserem Beispiel legen wir CodeStar als IAM-Benutzer an.
In unserem Beispiel legen wir CodeStar als IAM-Benutzer an. (Bild: Drilling / AWS Germany GmbH)

Dazu legen wir zunächst in der AWS CodeStar-Console ein neues CodeStar-Projekt an, wie in unserem allgemeineren CodeStar-Artikel beschrieben. Dazu bedarf es einer CodeStar-Service-Rolle. AWS-Nutzer können AWS CodeStar als IAM-Benutzer, Federation User, Root-User oder im Rahmen einer übernommenen IAM-Rolle verwenden. Wir verwenden CodeStar als IAM-Benutzer.

Der Vorteil ist, dass AWS CodeStar dann bei der Konfiguration des Benutzerzugriffs hilft, indem es die Berechtigungen für den IAM-Nutzer verwaltet. Wurde der IAM-Benutzer bereits einem oder mehreren AWS anderen CodeStar-Projekten hinzugefügt, hat dieser bereits die Richtlinien und Berechtigungen für den Zugriff auf den Service und die Ressourcen für die Projekte, zu denen sie gehören.

Viele AWS CodeStar-Projekte verwenden wie in unserem Fall AWS CodeDeploy oder AWS Elastic Beanstalk zur Bereitstellung (Deployment) von Code auf Amazon EC2-Instanzen. Um im Rahmen des Projektes auf verbundene Amazon EC2-Instances zugreifen zu können ist es sinnvoll, für den verwendeten IAM-Benutzer ein EC2-Schlüsselpaar zu erstellen. Der betreffende IAM-Benutzer muss über Berechtigungen zum Erstellen und Verwalten von Amazon EC2-Schlüsseln verfügen wie z. B: „ec2:CreateKeyPair“ und „ec2:ImportKeyPair“.

Als Projektvorlage verwenden das Projekt-Template „Python (Django)“
Als Projektvorlage verwenden das Projekt-Template „Python (Django)“ (Bild: Drilling / AWS Germany GmbH)

Startpunkt für ein neues Projekt ist die CodeStar-Console in der AWS Management Console. Hier erstellen wir mit einem Klick auf den Button „Start a project“ (beim ersten Besuch des Dienstes) oder „Create a new project“ (sofern bereits andere Projekte bestehen) ein CodeStar-Projekt aus einer Vorlage. Hier wählen wir das Projekt-Template „Python (Django)“ mit dem Applikationstyp „Web application“ und dem Envrionment-Typ „EC2“.

Dann vergibt man einen Projektnamen und eine „Project-ID“. Sofern der Nutzer Letztere nicht selbst bestimmt, leitet CodeStar die Projekt-ID aus dem Projektnamen ab. Das ist wichtig zu wissen, weil die Projekt-ID die Basis zur Ableitung weiterer Meta-Daten für die „beteiligten“ Tools wie Code Commit, CodeBuild usw. ist.

AWS CodeCommit

In den Projektdetails hinterlegen wir beispielhaft AWS CodeCommit als Code-Repository.
In den Projektdetails hinterlegen wir beispielhaft AWS CodeCommit als Code-Repository. (Bild: Drilling / AWS Germany GmbH)

Als Repository verwenden wir AWS CodeCommit, auch wenn CodeStar alternativ GitHub unterstützt. In letzterem Fall benötigt man für das CodeStar-Projekt einen gültigen GitHub-Benutzer-Account. AWS CodeCommit bietet den Vorteil, dass es direkt mit IAM integriert ist und die Daten im Backend auf Basis von AWS S3 sicher, d. h. verschlüsselt abgelegt werden.

Konkret ist AWS CodeCommit ein Version Control Service, der von Amazon Web Services gehostet und betrieben wird. Nutzer können in CodeCommit Komponenten beliebiger Art wie Dokumente, Quellcode und Binärdateien privat in der Cloud speichern und verwalten. Neben der integrierten Sicherheit bietet AWS CodeCommit auch den Vorteil, dass der Dienst in sich hochverfügbar ist und bei Bedarf automatisch skaliert.

Zudem gibt es mit CodeCommit keine Einschränkung hinsichtlich der Größe der Repositories oder der Dateitypen, die gespeichert werden können. Weitere Details zur Integration von CodeStar mit CodeCommit finden sich in unseren CodeCommit-Artikel.

Wird das Projekt auf Amazon EC2 bereitgestellt, lassen sich direkt die Konfigurationsdetails prüfen.
Wird das Projekt auf Amazon EC2 bereitgestellt, lassen sich direkt die Konfigurationsdetails prüfen. (Bild: Drilling / AWS Germany GmbH)

Nach einem Klick auf „Next“ überprüfen wir noch die Ressourcen und Konfigurationsdetails und klicken dazu auf den blauen Link „Edit Amazon EC2 Configuration“ rechts oben. Dieser wir natürlich nur angezeigt, wenn das Projekt wie im Beispiel auf EC2 bereitgestellt wird. Hier könnte man bei Bedarf auch einen anderen Instanz-Typ auswählen.

Interessant ist auch die visuelle Darstellung der Pipeline für das gesamte CodeStar-Projekt im Assistenten. Dieses verwendet offenbar (grau hinterlegt) AWS CodeCommit für den SourceCode-Verwaltung, AWS CodeDeploy für die Bereitstellung des Anwendungs-Codes und AWS CloudWatch für die Überwachung. Als Continuous Integration Service kommen AWS CodeBuild und AWS CodePipeline zum Einsatz. Doch zunächst klicken wir auf „Create Project“, wählen ein EC2-Keypair und bestätigen die Projekt-Erstellung.

Der erste Build läuft direkt nach dem Erstellen des Projektes durch.
Der erste Build läuft direkt nach dem Erstellen des Projektes durch. (Bild: Drilling / AWS Germany GmbH)

Unmittelbar nach Klick auf „Create Project“ beginnt CodeStar, das komplette Projekt zu bauen und bereitzustellen, wie man im CodeStar-Dashboard in der Kachel „Continuous Deployment“ komfortabel verfolgen kann. Danach möchte CodeStar noch wissen, wie und „wo“ der Code letztendlich bearbeiten werden soll.

AWS CodeCommit kann z. B. mit einem handelsüblichen Git-Client lokal geklont werden. Dies setzt vorhandene Git-Credentials voraus, die man für einen beliebigen IAM-User übrigens in der IAM-Console generisch erzeugen kann. Mit einem Klick auf „Command line tools“ erfahren Einsteiger weitere Details, um das CodeCommit-Repository erfolgreich über die unten angezeigte „Clone Repository URL“ wahlweise via SSH oder HTTPS sicher zu replizieren.

Alternativ besteht die Möglichkeit, AWS CodeCommit über die vorhandenen Plugins für Eclipse oder VisualStudio an die lokalen Entwicklungs-Tools des Benutzers anzubinden. Details dazu stehen ebenfalls in unserem Einführungs-Artikel zu CodeStar. Man kann diese Schritte wahlweise direkt hier im Assistenten erledigen oder mit „Skip“ vorerst überspringen und sobald die Anbindung später erledigt ist, im CodeStar Projekt-Dashboard im Abschnitt „IDE“ auf „I have already done this“ klicken. Der Abschnitt „IDE“ verschwindet dann aus dem Dashboard.

Teams erweitern

Wer im Team arbeitet, darf in CodeStar das Anlegen der zusätzlichen Nutzer nicht vergessen.
Wer im Team arbeitet, darf in CodeStar das Anlegen der zusätzlichen Nutzer nicht vergessen. (Bild: Drilling / AWS Germany GmbH)

Exemplarisch erweitern wir jetzt noch das Entwicklungsteam und klicken zu diesem Zweck auf „Setup your team“. Bisher sind nur wir selbst bzw. der assoziierte IAM-User mit der angegeben E-Mail-Adresse und der CodeStar-Rolle „Owner“ Mitglied des Projektes. Mit „Add Team Member“ lassen sich weitere Nutzer hinzufügen.

Dazu ist zunächst im Listenfeld „Select user“ wahlweise ein IAM-User aus dem eigenen Account oder ein CodeStar-User aus einen anderen CodeStar-Projekt auswählbar. Ferner erforderlich sind ein Display-Name, eine E-Mail-Adresse sowie eine „Project-Role“, wie z. B. „Viewer“. Mit einem Häkchen bei „Remote Access“ ist es dem Nutzer erlaubt, von remote auf alle mit dem Projekt im Zusammenhang stehenden Amazon EC2-Linux-Instanzen zuzugreifen.

Die Beziehung zwischen den einzelnen Rollen und einem AWS CodeStar-Projekt.
Die Beziehung zwischen den einzelnen Rollen und einem AWS CodeStar-Projekt. (Bild: AWS Germany GmbH)

Arbeitet das Projekt mit Ressourcen, die außerhalb von AWS liegen (z. B. ein GitHub-Repository oder JIRA), wird der Zugriff auf diese Ressourcen vom Ressourcenanbieter kontrolliert, nicht von AWS CodeStar. Das vorangestellte Diagramm zeigt die Beziehung zwischen den einzelnen Rollen und einem AWS CodeStar-Projekt.

Im zweiten Teil dieser Beitragsreihe werfen wir einen Blick auf die Deployment-Details und schauen, wie sich die Pipeline verhält, wenn wir einen Commit tätigen.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45683273 / CI / CD)