Die ver­gan­gene Dekade ver­zeich­net einen sehr deut­li­chen Trend in der IT-Bran­che: Cloud Com­pu­ting. Das pay-as-you-go Modell und das auto­ma­ti­sierte Ska­lie­ren von Anwen­dun­gen, ange­passt an die Bedürf­nisse des Nut­zers, haben viele Unter­neh­men über­zeugt Teile ihrer IT-Infrastruktur in die Cloud zu migrieren.

Unglück­li­cher­weise eig­nen sich die oft mono­li­thi­schen Code­struk­tu­ren der bestehen­den Anwen­dun­gen nicht ohne wei­te­res für den Betrieb in der Cloud. Um die Vor­teile der Cloud voll aus­zu­nut­zen, kön­nen sol­che Soft­ware­pa­kete in klei­nere, unter­ein­an­der kom­mu­ni­zie­rende, Micro­ser­vices auf­ge­bro­chen werden.

Dies erzeugt aller­dings auch wei­tere Her­aus­for­de­run­gen für die Ent­wick­ler: Auch nach erfolg­rei­chen Inte­gra­ti­ons­tests offen­ba­ren sich feh­ler­hafte Kom­mu­ni­ka­tio­nen zwi­schen den Micro­ser­vices unter Umstän­den erst nach dem Deploy­ment. Das macht ein kon­ti­nu­ier­li­ches Deploy­ment unum­gäng­lich, wenn Feh­ler früh erkannt und beho­ben wer­den sol­len. Aller­dings kann das Deploy­ment vie­ler kom­mu­ni­zie­ren­der Micro­ser­vices schnell an Kom­ple­xi­tät gewinnen.

Auto­ma­ti­sierte Con­ti­nuous Integration/Continuous Deploy­ment (CI/CD) Lösun­gen ent­las­ten die Ent­wick­ler bei der Auf­gabe den Code zu ver­wal­ten, zu tes­ten und zu deployen. Natür­lich soll­ten auch diese CI/CD Lösun­gen auto­ma­tisch mit der Größe des Pro­jekts ska­lie­ren, mehr dazu in unse­rem Blog­bei­trag „Spin­ning Up an Ela­s­tic CI-Pipe­line using Jenk­ins and Kuber­netes“. Der Ein­satz die­ser eta­blier­ten Tools erlaubt zwar voll­stän­dige Kon­trolle über die CI/CD Pipe­line, erhöht aller­dings auch den Auf­wand diese auf­zu­set­zen und zu administrieren.

Aus die­sem Grund bie­tet Ama­zon eine Reihe Cloud-nati­ver Deve­lo­p­ment Tools an, die das Auf­set­zen einer voll­stän­di­gen CI/CD Pipe­line erleich­tern (siehe Abbil­dung 1). Dabei ist es dem Ent­wick­ler über­las­sen, wie­viel der Admi­nis­tra­tion einer sol­chen CI/CD Pipe­line er selbst über­neh­men will und wie­viel er dem Auto­ma­tis­mus über­las­sen will. Im Fol­gen­den stel­len wir die AWS Ser­vices für die CI/CD Pipe­line kurz vor und erläu­tern ihre Zusammenhänge.

AWS Code­Com­mit

AWS Code­Com­mit ist ein auf Git basie­ren­des Codere­po­si­tory. Es inte­griert mit ande­ren Ser­vices der AWS Cloud, zum Bei­spiel AWS IAM für das Manage­ment der Benut­zer oder AWS Cloud­Watch für das Über­wa­chen des Repo­si­tory. Cross-Account Zugänge kön­nen Nut­zern außer­halb des über­ge­ord­ne­ten AWS Accounts den Zugriff auf das Repo­si­tory erlau­ben. Ama­zon stellt die Hard­ware bereit und ska­liert sie auto­ma­tisch mit der Größe des Pro­jekts. Alle Daten wer­den mit­hilfe des AWS KMS Diens­tes auto­ma­tisch ver­schlüs­selt. Events kön­nen kon­fi­gu­riert wer­den, damit Ent­wick­ler oder andere Ser­vices über AWS SNS und AWS Lambda auto­ma­tisch benach­rich­tigt wer­den, wenn zum Bei­spiel Code gepusht oder Pull Requests erstellt wer­den. Diese Events erlau­ben auch das Aus­lö­sen der auto­ma­ti­sier­ten CI/CD Pipeline.

AWS Code­Build

AWS Code­Build erlaubt das voll­au­to­ma­ti­sierte Kom­pi­lie­ren und Tes­ten des Codes. Dazu star­tet der Dienst Docker Con­tai­ner, die ent­we­der von Ama­zon bereit­ge­stellt oder selbst ver­wal­tet sind. AWS Code­Com­mit, Git­Hub, Bit­bu­cket oder AWS S3 stel­len den Code bereit. Auch AWS Code­Build nutzt die übli­chen Vor­teile der AWS Cloud: Die von AWS bereit­ge­stellte Hard­ware ska­liert auto­ma­tisch mit der Anzahl an ange­for­der­ten Builds, Ver­schlüs­se­lung der Daten erfolgt unter der Nut­zung von AWS KMS und AWS IAM ver­wal­tet die Berech­ti­gun­gen der Nut­zer. AWS Cloud­Watch hilft bei der Über­wa­chung des Ser­vice und sam­melt die Logs der Build­pro­zesse. Selbst­kon­fi­gu­rierte Events lei­ten wei­tere CI/CD Schritte ein oder sen­den wich­tige Infor­ma­tio­nen an Ent­wick­ler.
Ein wich­ti­ger Teil von AWS Code­Build ist die Kon­fi­gu­ra­tion des Build­pro­zes­ses in Form der buildspec.yml Datei, die im Root­ver­zeich­nis des Pro­jekts liegt. Hier kön­nen genaue Anwei­sun­gen für das Auf­set­zen der Build­um­ge­bung, das Kom­pi­lie­ren und das Tes­ten des Codes ange­ge­ben werden.

AWS Code­De­ploy

AWS Code­De­ploy hilft bei dem Deploy­ment der Anwen­dun­gen auf EC2 oder On-Premises Instan­zen sowie in AWS Lambda Funk­tio­nen. Die appspec.yml Datei ent­hält dabei die genauen Anwei­sun­gen für das Stop­pen vor­he­ri­ger Anwen­dungs­ver­sio­nen, das Kon­fi­gu­rie­ren der Anwen­dungs­um­ge­bung und das Star­ten der neuen Anwen­dungs­ver­sion. Unter­schied­li­che Deploy­ment­stra­te­gien, wie zum Bei­spiel Canary oder Blue/Green Deploy­ments, erlau­ben eine Test­pe­ri­ode der Anwen­dung inner­halb einer voll­stän­di­gen Pro­duk­ti­ons­um­ge­bung. Soll­ten an die­ser Stelle Kom­pli­ka­tio­nen auf­tau­chen, sor­gen auto­ma­ti­sche Roll­backs für das Deploy­ment der letz­ten funk­ti­ons­tüch­ti­gen Ver­sion. Auch hier kön­nen Events kon­fi­gu­riert wer­den, um die Ent­wick­ler über Ablauf und even­tu­elle Kom­pli­ka­tio­nen des Deploy­ments auf dem Lau­fen­den zu halten.

AWS Cloud­For­ma­tion

AWS Cloud­For­ma­tion über­nimmt die Auf­gabe der Res­sour­cen­be­reit­stel­lung für die Anwen­dungs­um­ge­bung. Dies beschränkt sich nicht nur auf Deploy­ments selbst­ent­wi­ckel­ter Anwen­dun­gen, son­dern schließt auch gene­relle Clou­dar­chi­tek­tu­ren mit ein. Daher gehört AWS Cloud­For­ma­tion nicht direkt zum AWS Deve­lo­p­ment Tool­stack. In einem Cloud­For­ma­tion-Tem­p­late ist eine kom­plette Cloud-Infrastruktur in Form von YML oder JSON Code defi­niert. Hier kön­nen alle AWS-Res­sour­cen voll­stän­dig kon­fi­gu­riert wer­den. Para­me­ter erlau­ben das Gene­ra­li­sie­ren sol­cher Infra­struk­tu­ren, zum Bei­spiel für Deve­lo­p­ment und Pro­duc­tion Umge­bun­gen. Out­puts geben Infor­ma­tio­nen aus, die auch von wei­te­ren Cloud­For­ma­tion Tem­pla­tes refe­ren­ziert wer­den kön­nen. Dies erlaubt das Wie­der­ver­wen­den gene­rel­ler Buil­ding Blocks in kom­pli­zier­ten Infrastrukturen.

AWS Ela­s­tic Beanstalk

AWS Ela­s­tic Bean­stalk erstellt voll­au­to­ma­ti­siert voll­stän­dige Deploy­ment­um­ge­bun­gen. Dabei nutzt es impli­zit AWS Cloud­For­ma­tion zur Res­sour­cen­be­reit­stel­lung und AWS Code­De­ploy für das Deploy­ment der Anwen­dung inner­halb der erstell­ten Infrastruktur. Dem Ent­wick­ler wird damit die Auf­gabe abge­nom­men, selbst ein Cloud­For­ma­tion Tem­p­late für die Res­sour­cen­be­reit­stel­lung zu erstel­len. Zudem wird die Inte­gra­tion von Code­De­ploy auto­ma­ti­siert. Der Nach­teil ist die gerin­gere Fle­xi­bi­li­tät bei der Archi­tek­tur der Cloud-Infrastruktur.

AWS Code­Pipe­line

AWS Code­Pipe­line orches­triert den kom­plet­ten CI/CD Work­flow. Code­Pipe­line defi­niert soge­nannte Stages, die die ein­zel­nen Schritte des CI/CD Work­flows reprä­sen­tie­ren (siehe Abbil­dung 2). Begin­nend mit einem Codere­po­si­tory (Code­Com­mit, Git­Hub oder S3) ver­folgt Code­Pipe­line auto­ma­ti­siert Events, die den Build­pro­zess star­ten. Im Falle eines sol­chen Events gibt Code­Pipe­line den Quell­code aus dem Codere­po­si­tory als Arti­facts über S3 an die Build-Stage wei­ter. Hier über­neh­men Build Tools wie Jenk­ins oder AWS Code­Build das Buil­ding und Test­ing ent­spre­chend der Spe­zi­fi­ka­tio­nen der Ent­wick­ler. Etwa­ige Build­ar­ti­facts, wie zum Bei­spiel Bina­ries, wer­den wie­derum an die Deploy­ment-Stage wei­ter­ge­ge­ben. AWS Ela­s­tic Bean­stalk, AWS Cloud­for­ma­tion oder AWS Code­De­ploy prä­sen­tie­ren Optio­nen, um die fer­tige Anwen­dung zu deployen. Es kön­nen zusätz­li­che Stages hin­zu­ge­fügt wer­den, zum Bei­spiel um manu­elle Bestä­ti­gun­gen durch Pro­jekt­lei­ter ein­zu­füh­ren. Sollte eine der Stages fehl­schla­gen bricht der CI/CD Work­flow sofort ab.

AWS Code­Star

AWS Code­Star ist ein Ser­vice, der alle bis­her genann­ten Ser­vices nutzt, um eine voll­stän­dige CI/CD Pipe­line zu erstel­len. In nur weni­gen Hand­grif­fen inner­halb der AWS Con­sole wird eine voll­stän­dige AWS Code­Pipe­line auf­ge­setzt, inklu­sive zuge­hö­ri­gem Codere­po­si­tory und AWS Code­Build Tool. Die Deploy­ment-Stage nutzt, je nach ver­wen­de­tem Pro­jekt­tem­p­late (für eine Über­sicht siehe Abbil­dung 3), AWS Code­De­ploy, AWS Cloud­For­ma­tion, oder AWS Ela­s­tic Bean­stalk. Das Tem­p­late stellt eben­falls bereits buildspec.yml und, falls erfor­der­lich, appspec.yml Dateien bereit. Cloud­Watch ist auto­ma­tisch inte­griert und lie­fert Usa­ge­re­ports in Form eines Dash­boards inner­halb der AWS Con­sole. Unter­lie­gende Kon­fi­gu­ra­tio­nen, wie Code­Pipe­line Stages oder Build­an­wei­sun­gen inner­halb der buildspec.yml, kön­nen nach­träg­lich vari­iert wer­den. Somit ist AWS Code­Star ein idea­ler Start­punkt für neue Pro­jekte. Der Nach­teil hier ist eben­falls, dass man durch die vor­han­de­nen Pro­jekt­tem­pla­tes auf wenige Pro­jekt­ar­ten beschränkt ist.

Fazit

Mit einer Reihe grund­le­gen­der Ser­vices bie­tet AWS alle Tools für eine kom­plette CI/CD Pipe­line. Alle Ser­vices ska­lie­ren auto­ma­tisch mit der Größe des Pro­jekts und arbei­ten nach dem pay-as-you-go Modell. Durch über­ge­ord­nete Orchestra­tion Ser­vices wie AWS Code­Pipe­line und AWS Code­Star bie­tet AWS die Mög­lich­keit die Last der Kon­zep­tion und Admi­nis­tra­tion einer CI/CD Pipe­line von den Ent­wick­lern zu neh­men. Durch die unter­schied­li­chen Levels an Orchestra­tion, gege­ben durch diese bei­den Ser­vices und durch AWS Ela­s­tic Bean­stalk, kön­nen Ent­wick­ler selbst bestim­men, wie fein­gra­nu­liert sie Ihre CI/CD Pipe­line kon­trol­lie­ren wol­len und sich damit bes­ser auf das Wesent­li­che kon­zen­trie­ren – das Ent­wi­ckeln ihrer Anwendung.