Suchen

Amazon Web Services für Entwickler, Teil 6 Entwicklungsumgebung mit AWS CodeBuild bereitstellen

| Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Nach der Planungsphase für AWS CodeBuild befassen wir uns konkret mit der Bereitstellung einer Docker-basierten, auf AWS gehosteten Entwicklungsumgebung. Dieser Vorgang dient allein dem Zweck, einen Build anzustoßen, ohne sich um die Infrastruktur kümmern zu müssen.

Firmen zum Thema

AWS CodeBuild bietet vorgefertigte Build-Umgebungen für die gängigsten Programmiersprachen und Werkzeuge.
AWS CodeBuild bietet vorgefertigte Build-Umgebungen für die gängigsten Programmiersprachen und Werkzeuge.
(Bild: AWS Germany GmbH)

Der erste Schritt der Projektkonfiguration.
Der erste Schritt der Projektkonfiguration.
(Bild: Drilling / AWS)

Zum Erstellen eines Build-Projektes mit AWS CodeBuild wechselt man in der AWS Management Console im Abschnitt „Services / Developer Tools“ zur AWS CodeBuild Console und klickt auf der Willkommensseite auf „Get Started“, bzw. (wenn es bereits andere CodeBuild-Projekte gibt) im Navigationsbereich „Build projects“ auf „Create project“.

Im „Step 1“ des Projekt-Assistenten „Configure your project” gibt man seinem CodeBuild-Projekt zunächst einen Projektnamen. Dabei ist zu beachten, dass Build-Projektnamen in allen AWS-Konten eindeutig sein müssen. Mit „Add description“ lässt sich optional auch eine Beschreibung im entsprechenden Feld „Description“ hinterlegen.

Code Repository auswählen

Beim „Source provider“ hat man die Wahl zwischen Amazon S3, ...
Beim „Source provider“ hat man die Wahl zwischen Amazon S3, ...
(Bild: Drilling / AWS)

Anschließend wählt man bei „Source: What to build“ für „Source provider“ den gewünschten Quellcode-Anbietertyp (Amazon S3, AWS Code Commit, Bitbucket, GitHub oder GitHub Enterprise) aus und führt je nach Wahl einen der im Folgenden beschriebenen Schritte aus.

Bei „Amazon S3“ genügt es, einen Namen für das Bucket anzugeben, das den Quellcode enthält. Dazu gibt man für „S3 object key“ den Namen einer ZIP-Datei ein, die den Quellcode enthält.

... einem AWS CodeCommit Repository, ...
... einem AWS CodeCommit Repository, ...
(Bild: Drilling / AWS)

Im Fall „AWS CodeCommit“ wählt man für „Repository“ den Namen des AWS CodeCommit-Repositories aus. Mit dem Kontrollkästchen „Build Badge“ kann man dafür sorgen, dass der Build-Status des Projekts sichtbar und integrierbar ist. Beispiele dazu finden sich in der Build-Badges-Dokumentation. Mit dem Wert bei „Git clone depth“ ist es möglich, einen „flachen Klon“ mit einem Verlauf zu erstellen, der auf die angegebene Anzahl von Commits gekürzt ist. Zum Erstellen eines vollständigen Klons wählt man den Eintrag „Full“.

... oder auch einem bestehenden GitHub Repository.
... oder auch einem bestehenden GitHub Repository.
(Bild: Drilling / AWS)

Hat man sich für GitHub entschieden, klickt man auf den Button „Connect to GitHub“, meldet sich mit seinem bestehenden Konto an und klickt auf der GitHub-Seite „Authorize application für Organization access“ und wählt mit einem Klick auf „Request access“ neben dem Repository dasjenige aus, auf das AWS CodeBuild zugreifen können soll. Nach der Auswahl von „Authorize application“ kam man dann zurück in der AWS CodeBuild-Konsole bei „Repository“ den Namen des GitHub-Repositories angeben, das den Quellcode enthält.

Für die Einstellungen bei „Git clone depth“ gilt das Gleiche, wie oben für AWS CodeCommit erläutert. Mit dem Kontrollkästchen „Webhook“ lässt sich einstellen, dass AWS CodeBuild den Quellcode jedes Mal neu erstellt, wenn eine Code-Änderung an dieses Repository übergeben wird. Mit dem Kontrollkästchen „Build Badge“ lässt sich wieder der Build-Status des Projekts sichtbar und integrierbar machen.

Für weitere Repository-Einstellungen z. B. für „GitHub Enterprise“ oder „Bitbucket“ verweisen wir auf die umfassende AWS-CodeBuild-Dokumentation.

Amazon Web Services für Entwickler
Bildergalerie mit 7 Bildern

Entwicklungsumgebung bereitstellen

Danach wählt man im Abschnitt „Envrionment: How to build“ für „Environment image“ entweder die Option „Use an image managed by AWS Codebuild“ oder „Specifiy a Docker image“, um die eigentliche Entwicklungsumgebung zur Verfügung zu stellen.

Die von AWS CodeBuild bereitgestellte Entwicklungsumgebung lässt sich flexibel einrichten.
Die von AWS CodeBuild bereitgestellte Entwicklungsumgebung lässt sich flexibel einrichten.
(Bild: Drilling / AWS)

In beiden Fällen erfolgt das Bereitstellen der Entwicklungsumgebung mit Hilfe eines Docker-Abbilds. Möchte der Nutzer ein Docker-Image benutzen, das von AWS CodeBuild verwaltet wird, wählt er die erste Option, gefolgt von den gewünschten Optionen für „Operating system“, „Runtime“ und „Version“.

Möchte er hingegen ein anderes Docker-Image nutzen, wählt er „Specify a Docker image“ und dann bei „Custom image type“ eine der Optionen „Other“ oder „Amazon ECR“. Mit „Other“ lassen sich dann für „Custom image ID“ sowohl Name als auch Tag eines Docker-Images im Format „repository-name/image-name:image-tag“ aus dem Docker-Hub eintragen. Statt über Docker-Hub kann man das gewünschte Image mit Auswahl der entsprechenden Option auch von „Amazon ECR“ beziehen. Hier wählt man dann „Amazon ECR repository“ und „Amazon ECR image“ für ein Docker-Image im jeweiligen AWS-Konto.

Die Build-Befehle lassen sich per Spezifikationsdatei oder auch manuell nach Bedarf definieren.
Die Build-Befehle lassen sich per Spezifikationsdatei oder auch manuell nach Bedarf definieren.
(Bild: Drilling / AWS)

Bei „Build specification“ hat man zwei Optionen: Enthält der o. a. Quellcode bereits eine Build-Spezifikationsdatei, wählt man „Use the buildspec.yml in the source code root directory“. Enthält der Quellcode dagegen keine Build-Spezifikationsdatei oder möchte der Nutzer andere als die in der Spezifikationsdatei „buildspec.yml“ im Root-Verzeichnis des Quellcodes angegebene Build-Befehle ausführen, muss er die Option „Insert build commands“ wählen. Hier gibt er dann für „Build command“ alle Befehle ein, die AWS CodeBuild in der build-Phase ausführen soll, wobei sich mehreren Befehle jeweils mit && unterteilen lassen, wodurch gewährleistet ist, dass der jeweils vorherige Befehl vollständig abgeschlossen ist, bevor der Nächste verarbeitet wird.

Details dazu finden sich in der Dokumentation in der Build Spec Reference.

Ausgabe-Bucket

Weiter geht es im Abschnitt „Artifacts: Where to put the artifacts from this build project“, in dem der Nutzer festlegen kann, ob er möchte, dass Ausgabe-Artifakte des Build-Projekts erstellt und in einem S3-Bucket abgelegt werden, welches er an dieser Stelle spezifizieren muss.

Das Speichern der Build-Ausgaben in einem Amazon S3-Bucket erfordert ein paar zusätzliche Angaben.
Das Speichern der Build-Ausgaben in einem Amazon S3-Bucket erfordert ein paar zusätzliche Angaben.
(Bild: Drilling / AWS)

Entscheidet man sich für das Speichern der Build-Ausgaben in einem Amazon S3-Bucket, sind folgende ergänzenden Schritte erforderlich: den Eintrag bei „Name“ kann man freilassen, wenn man direkt den Projektnamen für die ZIP-Datei oder den Ordner der Build-Ausgabe als Pfad für die Ausgaben verwenden möchten. Optional kann man aber einen Namen eintragen. Soll eine ZIP-Datei mit einer Dateierweiterung ausgegeben werden, muss man die Dateierweiterung an den Namen der ZIP-Datei anfügen.

Schließlich wählt man bei „Bucket name“ den Namen des Ausgabe-Buckets aus. Hat der Anwender allerdings vorher die Option „Insert build commands“ benutzt, muss er für „Output files“ die Speicherorte der Dateien des Builds angeben, die in der ZIP-Datei, bzw. dem Ordner für die Build-Ausgabe enthalten sein sollen, wobei sich mehrere Speicherorte durch ein Komma trennen lassen.

Im nächsten Abschnitt „Cache“ kann man sich bei „Typ“ für das Verwenden eines Cache entscheiden oder nicht (Eintrag „No cache“). Das Verwenden eines Caches kann zu einer erheblichen Zeitersparnis bei der Erstellung führen, weil CodeBuild dann wiederverwendbare Teile der Build-Umgebung im Cache speichert und über Builds hinweg benutzen kann. Möchte der Nutzer einen Cache verwenden, muss er in Amazon S3 ein passendes Bucket konfigurieren, das zum Speichern des Cache verwendet wird. Optional kann der Anwender für „Path prefix“ ein Amazon S3-Pfadpräfix stellen. Dieses kann man sich wie einem Verzeichnisnamen vorstellen. Allerdings muss man dann darauf achten, am Ende des „Path prefix“ keinen „/” anzufügen.

Die letzten Einstellungen sind in den Bereichen „Service role“ sowie „VPC“ vorzunehmen.
Die letzten Einstellungen sind in den Bereichen „Service role“ sowie „VPC“ vorzunehmen.
(Bild: Drilling / AWS)

Schließlich muss der Anwender im Abschnitt „Service role“ eine AWS CodeBuild-Servicerolle angeben oder mit „Create a service role in your account“ einen zu verwendenden Rollen-Namen angeben. In der Standardeinstellung funktioniert diese Rolle ausschließlich mit diesem Projekt. Wer z. B. bereits eine Service-Rolle für AWS CodeBuild-hat, kann mit „Choose an service existing role from your account“ auch diese verwenden. Verwendet man die erstelle Service-Rolle mit einem anderen Build-Projekt, wird sie allerdings von AWS so aktualisiert, dass sie mit dem anderen Build-Projekt funktioniert. Jede Service-Rolle lässt sich bis zu zehn Build-Projekten zuordnen.

Zum Schluss ist noch der Abschnitt „VPC“ zu bearbeiten. Möchte man keine VPC für sein Projekt verwenden, wählt man schlicht „No VPC“. Wird AWS CodeBuild allerdings explizit verwendet, um mit einer vorhanden VPC zusammenzuarbeiten, gibt man im Dialog zunächst die „VPC-ID“ an, wählt dann die Subnetze aus, die die von AWS CodeBuild verwendete Ressourcen enthalten und schließlich die Security Groups, die AWS CodeBuild benutzt, um den Zugriff auf Ressourcen in dieser VPC zu erlauben.

Final kann man noch die gewählten VPC-Einstellungen mit der gleichnamigen Schaltfläche validieren. Im Step des Assistenten hat man dann nach Anzeige der Zusammenfassung die Wahl zwischen „Save“ oder „Save and Build“.

Amazon Web Services für Entwickler
Bildergalerie mit 7 Bildern

(ID:45358320)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist