Anwendungsdeployment
Last updated
Was this helpful?
Last updated
Was this helpful?
In diesem Abschnitt beleuchte ich die verschiedenen Ansätze jegliche Arten von Anwendungen (sehr einfach aber auch sehr komplexe) auf AWS zu betreiben.
Allen gemeinsam ist, dass die Basic-Tools von AWS (EC2, VPC, ALB, Auto-Scaling-Groups, Security-Groups, ...) mehr oder weniger offensichtlich genutzt werden, um so ein komplexes Szenario abzubilden. Je nach LĂśsung hat man entweder weniger oder mehr EinfluĂ.
Man kann sich AWS wie einen Baukasten mit Basis-Komponenten vorstellen. Einige der daraus von AWS zusammengebauten und zur Wiederverwendung bereitgestellten Composite-Komponenten tragen dann spezielle Namen wieAWS Fargate, AWS EKS, ... Enduser werden dann wiederum ihrerseits aus den BaDaneben stehen jedem Nutzer natĂźrlich auch selbst die Basis-Komponenten und Composite-Komponenten zu seine eigenen Custom-Komponenten (= LĂśsung) zusammenbauen. Ist die so allgemein, dass sie fĂźr andere relevant sein kĂśnnte, kann er auch diese wiederum zur Weiterverwendung auf dem Amazon Marketplace anbieten.
Eine Webseite besteht ja nur aus HTML, CSS, Java-Script und passt somit perfekt in ein S3-Filesystem. AWS bietet genau zu diesem Zweck die MĂśglichkeit, einem S3-Bucket als static Website zu konfigurieren ... super einfach, um schnell mal eine Webseite bereitzustellen.
Da moderne Single-Page-Applikationen auch nur aud den oben genannten Komponenten bestehen, handelt es sich hier automatisch um ein Anwendungs-Deployment. So einfach kanns sein.
Hierbei handelt es sich um einen PaaS-Ansatz (vor einigen Jahren hatte ich mal mit der Google App Engine rumgespielt ... sehr ähnlich).
Mit wenigen Konfigurationen (CPU, Memory, Port) stellt AWS eine auto-skalierte Anwendung zur VerfĂźgung. Die Anwendungen mĂźssen dazu als
Source-Code (Docker-basiertes Repo in GitHub)
Docker-Image (private oder public AWS-ECR)
zur VerfĂźgung stehen.
Limitation: ein Job darf nur 15 Minuten dauern
Hierbei handelt es sich um ein AWS-proprietäre Alternative zu Kubernetes.