2 minutes reading time (482 words)

Hybrid Container deployment mit Jenkins

containermanagement

Nachdem wir in unserem ersten Blogartikel (LINK) über die Architektur einer modernen Containerplattform im Allgemeinen geschrieben haben, möchten wir mit diesem Artikel in die Praxis gehen. Wir beschreiben eine technische Lösung, mit der Unternehmen dabei unterstützt werden, die zahlreichen rechtlichen Anforderungen umzusetzen und gleichzeitig flexibel und kostensparend zu arbeiten.

Strenge Anforderungen treffen nicht nur für regulierte Branchen wie z.B. Banken und Versicherungen zu, sondern auch auf Telekommunikationsunternehmen oder andere Branchen. Cloud Lösungen bieten eine enorme Flexibilität und können dabei auch preiswerter sein als On-Premises Lösungen. Beim Thema Datenschutz fällt es vielen Unternehmen allerdings schwer, konforme Cloud Lösungen zu implementieren - stattdessen verzichten sie komplett darauf. Unsere Beispielarchitektur besteht sowohl aus On-Premises als auch Cloud Komponenten, welche je nach Bedarf verschoben werden können. Somit müssen lokal weniger Ressourcen bereitgestellt werden als in reinen On-Premises Szenarien. Gleichzeit können schneller neue Nodes bereitgestellt werden, ohne dass teure Hardware im eigenen Rechenzentrum vorgehalten werden muss. 


Für unsere Demo haben wir eine simple Python Web Applikation geschrieben, welche in unserem Fall in ein Bitbucket Code Repository eingecheckt wird. Anschließend bauen wir mit Jenkins automatisiert ein Container Image aus dem Code, führen Basis Test Cases aus und pushen dieses in unsere private Docker Registry. Zuletzt triggert Jenkins entweder unseren Cloud oder On-Premises Docker Swarm Cluster. Swarm deployed das Image dann auf die entsprechenden Worker-Nodes. 

Verarbeitet die Applikation datenschutzrelevante Daten, wird der Container auf den On-Premises Docker Swarm deployed. Sind die Daten unkritisch, wird der Cloud Docker Swarm Cluster verwendet. Jenkins ist also als eine Art Weiche zu verstehen, die durch zwei simple Buttons in der Jenkins Oberfläche gesteuert wird und entscheidet, wo der Container laufen darf.

In unserem Beispiel haben wir uns dazu entschieden, das Code Repository, die Registry und die Build-Pipeline On-Premises zu deployen. Es wäre natürlich auch möglich, je ein On-Premises und eine Cloud Komponente zu installieren. Aus unserer Sicht erhöht sich dadurch aber nur die Komplexität. Wir haben bewusst zwei getrennte Cluster ausgewählt. Dies dient dazu, aufzuzeigen, dass man sehr einfach über Jenkins entscheiden kann, wohin ein Container Image deployed wird. Zudem haben viele Unternehmen ohnehin mehrere Cluster in Betrieb.

Es wäre natürlich auch möglich ein einzelnes Cluster zu implementieren, der On-Premises Master und Worker-Nodes sowie Cloud Worker-Nodes enthält. Über Flags könnte man dann z.b. verhindern, dass ein datenschutzrelevanter Container in der Cloud laufen wird.

Im Video seht ihr, wie einfach und schnell ein Container gebaut und in den Cloud Swarm deployed werden kann. Anschließend wird er per Knopfdruck auf den On-Premises Cluster umgezogen. 

Im nächsten Artikel werden wir unsere Demo App automatisch skalieren und dynamisch Instanzen deployen oder entfernen. Voraussichtlich werden wir dann auch mit einem Kubernetes Cluster arbeiten, um bewusst Demos mit verschiedenen Orchestrierungswerkzeugen (Swarm, Kubernetes und Open Shift) zu realisieren und dann zu gegebener Zeit die Vor und Nachteile beleuchten. Wie immer könnt ihr auch Wünsche äußern, über welches Thema wir als Nächstes schreiben sollen ????….  

ESAE Serie Teil 3 – Privileged Access Management u...
Container - Wie sieht eine moderne Enterprise Cont...

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Guest
Dienstag, 20. August 2019