Cloud Foundry (CF) ist eine OpenSource Platform, welches auf ein gängige IaaS bereitgestellt werden kann, um ein PaaS zu errichten, in dem dann unterschiedliche Applikationen und Services bereitgestellt werden können. Natürlich gibt es verschiedene Anbieter die ein PaaS auf Cloud Foundry basierend anbieten, dazu gehören u.a. Pivotal CF, IBM Bluemix. In dieser Einführung wird CF mit IBM Bluemix vorgestellt.

Übersicht

Mit Cloud Foundry (CF) gibt eine etablierte PaaS Software vor was von verschiedenen Hersteller unterstützt wird. CF ist eine Stack was die Bereitstellung, Verwaltung und Betrieb von eigenen Applikationen in einer Cloud-Umgebung unterstützt. Dieser Stack besteht aus mehreren Komponenten die nachfolgenden kurz erläutert werden.

[caption id="" align="aligncenter" width="589"] Cloud Foundry Stack - https://docs.cloudfoundry.org/concepts/architecture/ - 22.11.2017[/caption]

Jegliche hereinkommenden Anfragen gelangen durch den Router zu dem Cloud Controller oder ein Diego Zelle, welches eine App verwaltet.

Die Information bzgl. des Routing für die vorhandenen Applikationen wird vom Bulletin Board System (BBS) regelmäßig abgefragt.

Deployment Anfragen werden an den Cloud Controller verwiesen, der im Zuge des Deployments eine Diego Zelle für die Ausführung der Applikation beauftragt.

Ein Vorteil einer Cloud Platform ist die Skalierung und die Überwachung der Applikationen mit einem automatischen Neustart einer weiteren Instanz, falls notwendig. Cell Reps überwacht dabei die aktuellen Instanzen gemäß der definierten Anzahl an Instanzen. Nsyncs verarbeitet die Skalierungs-Anfragen und BBS verwaltet die Instanzen um die Skalierungsanforderungen einzuhalten.

Jegliche binäre Dateien (Applikationen, Droplet etc) werden in dem Blob Store zwischengehalten.

Die schon erwähnte Diego Zelle übernimmt die Ausführung der Applikationen und deren Installation. Dabei werden alle Container in dem Garden verwaltet.

Falls die Applikation zusätzliche Services benötigt, werden diese über den Service Broker verwaltet.

Die unzähligen Komponenten in der CF Landschaft kommunizieren über verschiedene Mechanismen:

• BBS für die Daten welche häufig aktualisiert werden, wie jegliche Status-Daten, Heartbeat Messages, Routing-Informationen etc.
• Consul für langlebige Daten wie IP-Adressen oder verteilte Locks
• NATS sorgt für die Broadcast Funktionalität, welche u.a. für das Routing relevant ist.

Um einen guten Überblick über Komponenten zu haben werden die Metriken und Logs einheitlich gesammelt; so finden sich z.B. Deployment-Information im Metrics Collector und jegliche Applikations-Log im Log Aggregator.

Vorbedingung

Um CF zu nutzen, wird eine eigene CF Installation/Plattform benötigt oder man nutzt einen der existierenden CF Provider, wie Pivotal CF oder IBM Bluemix. Im weiteren Verlauf wird auf IBM Bluemix eingegangen.

IBM Bluemix bietet einen kostenlosen Zugang an, der zeitlich nicht begrenzt ist und viele Services und Komponenten frei zugänglich anbietet.

Die Kommunikation mit einer CF Plattform wird mittels CF CLI durchgeführt. Hierfür gibt es für die gängigen Betriebssystemen entsprechende Installationspakete:

https://docs.cloudfoundry.org/cf-cli/install-go-cli.html

Da hier auch IBM Bluemix verwendet wird, wird die Bluemix CLI (bx) benötigt - dafür stehen für die gängigen Betriebssysteme Pakete bereit.

Zu beachten ist, dass seit kurzem im kostenlosen Zugang von IBM Bluemix die Verwendung von Docker nur noch über ein Kubernetes Cluster möglich ist. Dafür muss die Kubernetes-CLI installiert werden. In der kostenpflichtigen Variante kann mittels IBM Bluemix Container-Service verwendet werden, um einzelne und skalierbare Container einzurichten. Tut man dies dennoch mit einem kostenlosen Account, erhält man u.a. folgende Meldung

$ bx ix namespace-set <eigener_namensbereich>
FAILED

{
    "code": "IC5205E", 
    "description": "The free trial for single containers and scalable groups is no longer available. To try out IBM Bluemix Container Service, create a lite Kubernetes cluster instead.", 
    "environment": "prod-lon02", 
    "host_id": "107", 
    "incident_id": "1055-1511201389.681-851514", 
    "name": "Sunset", 
    "rc": "403", 
    "type": "Provisioning"
}

In Cloud Foundry werden Applikationen immer einer Organisations-Einheit zugeordnet, die wiederum in verschiedene Spaces unterteilt werden. Hier stehen einem jegliche Unterteilungsmöglichkeiten, wie z.B. die Unterteilung nach Umgebung (Test, Integration, Produktion) oder eher fachlich (Kundenverwaltung, Produktmanagement etc). Zu beachten ist, dass beim IBM Bluemix eine Organisation und Space konfiguriert wurden. IBM Bluemix hat zusätzlich eine Kategorisierung vorweg, die Region (UK, DE, Sydney, US South).

[caption id="attachment_320" align="aligncenter" width="558"] ] [/caption]

Die IBM Bluemix Region legt fest, an welcher API-URL die CF Anfragen verschickt werden

• UK: api.eu-gb.bluemix.net
• DE: api.eu-de.bluemix.net
• Sydney: api.au-syd.bluemix.net
• US South: api.ng.bluemix.net

Einrichtung

Dieses Kapitel umfasst die Bereitstellung einer Applikation in einem Docker Image. Dafür wird ein eigener Cluster erstellt und hierfür wird Cloud Foundry und IBM Bluemix verwendet. Als Applikation wird das blueprint Projekt verwendet, was im letzten Beitrag vorgestellt wurde.

Diese Applikation kann unter folgende URL erreicht werden: http://169.51.16.35:32531/swagger-ui.html

Erste Schritte

• Anmeldung bei einem Cloud Foundry Provider. Zu beachten ist, dass hier die korrekte API URL verwendet wird. Dabei muss die Region verwendet werden, die in Bluemix konfiguriert wurde. Wenn als Region UK ausgewählt wurde, lautet die URL: https://api.eu-gb.bluemix.net. Ohne die Angabe von ORG und SPACE beim Login wird interaktiv die vorhandenen aufgelistet und zur Auswahl gestellt.

$ cf login [-a API_URL] [-u USERNAME] [-p PASSWORD] [-o ORG] [-s SPACE] 

$ cf login -a https://api.eu-gb.bluemix.net -u USERNAME [-o ORG -s SPACE]

• Eine Anmeldung über die IBM Bluemix CLI ist auch notwendig. Anschließend muss die Cloud Foundry Organisation und Space ausgewählt werden.

$ bx login


$ bx target --cf
...

API-Endpunkt: https://api.eu-gb.bluemix.net (API-Version: 2.92.0) 
Region: eu-gb 
Benutzer: ... 
Konto: (aa...) 
Ressourcengruppe: Default 
Organisation: bm_org 
Bereich: dev

• IBM Bluemix CLI bietet mehre Plugins an um die einzelnen Komponenten in der Bluemix Landschaft einzurichten; eins ist Container Services zur Verwaltung von Cluster. Somit steht dann "bx cs" zur Verfügung.

$ bx plugin install container-service -r Bluemix 


$ bx plugin list
Installierte Plug-ins auflisten...

Plug-in-Name        Version 
container-service   0.1.390

• Für den Einsatz von Docker wird ein Registry benötigt, was auch als Bluemix Plugin (bx cr)  zur Verfügung steht.

$ bx plugin install container-registry -r Bluemix 


$ bx plugin list
Installierte Plug-ins auflisten...

Plug-in-Name         Version   
container-registry   0.1.235   
container-service    0.1.390

• Für den Registry muss ein eindeutiger Namensbereich definiert werden.

$ bx cr namespace-add <mein_namensbereich> 
Namensbereich '...' wird hinzugefügt...

Namensbereich '...' wurde erfolgreich hinzugefügt

OK

Cluster erstellen

• Ein neuer Cluster kann über die bx cs CLI erstellt werden. Dabei muss die Kubernetes Version angegeben werden. Diese muss mit der eigenen Kubernetes(-CLI) Version kompatibel sein. Der Erstellte Cluster ist ein Lite-Cluster und ist bei IBM Bluemix kostenfrei.

$ bx cs kube-versions
OK
Version   
1.5.6   
1.7.4 (default)   
1.8.2   

$ bx cs cluster-create --name myCluster --kube-version 1.7.4
Creating cluster...
Das Flag 'machine-type' wurde nicht angegeben. Daher wird ein Lite-Cluster mit Standardparametern erstellt. Zur Anpassung der Parameter erstellen Sie einen Standardcluster und beziehen Sie alle erforderlichen Flags ein. 
OK

• Die aktuellen Worker im Cluster können angezeigt werden. Der vorhandene besitzt keinen Services/Applikation ist auch nicht öffentlich erreichbar.

$ bx cs workers myCluster
OK
ID                                                 Public IP   Private IP   Machine Type   State               Status                              Version   
kube-par01-pa709d68f58b324f7fae5faa3eb54b1051-w1   - - free provision_pending   Waiting for master to be deployed   1.7.4_1503

Docker Image veröffentlichen

• Um ein Docker Image bereitzustellen, muss dieser zum bereitgestellten Registry veröffentlicht werden. Dabei ist zu beachten, dass eine Anmeldung beim Registry notwendig ist, ansonsten wird die Veröffentlichung abgewiesen.

$ docker build -t registry.eu-gb.bluemix.net/haftech/blueprint:0.1.bm .

$ bx cr login

$ docker push registry.eu-gb.bluemix.net/haftech/blueprint:0.1.bm
The push refers to a repository [registry.eu-gb.bluemix.net/haftech/blueprint]
c8dd4c015ecb: Pushed 
46259359b5ea: Pushed 
...
0.1.bm: digest: sha256:347ed4151d2ca....e1d size: 1375


$ bx cr images
Images werden aufgeführt...

REPOSITORY                                     NAMENSBEREICH   TAG      DIGEST         ERSTELLT        GRÖßE    SCHWACHSTELLENSTATUS   
registry.eu-gb.bluemix.net/haftech/blueprint   haftech         0.1.bm   347ed4151d2c   9 minutes ago   128 MB   Unbekannt   

OK

Applikation veröffentlichen

• Da in dem kostenlosen Zugang von IBM Bluemix Docker Images nur noch mittels Kuebernetes Cluster bereitgestellt werden können, wird das Kuebernetes-CLI benötigt.
• Nach jeder CLI Anmeldung ein die CF Plattform, muss Kubernetes-CLI mit dem Cluster konfiguriert werden. Dafür wird eine Konfigurationsdatei runtergeladen und muss als Umgebungsvariable KUBECONFIG zur Verfügung gestellt werden. Mittels dem Version-Befehl kann überprüft werden, ob die Verbindung zum CF Server erfolgreich aufgebaut werden kann.

$ bx cs cluster-config myCluster
OK
Die Konfiguration für myCluster wurde erfolgreich heruntergeladen. Exportieren Sie die Umgebungsvariablen, um mit der Verwendung von Kubernetes zu beginnen.

export KUBECONFIG=/home/.../.bluemix/plugins/container-service/clusters/myCluster/kube-config-par01-myCluster.yml



$ export KUBECONFIG=/home/.../.bluemix/plugins/container-service/clusters/myCluster/kube-config-par01-myCluster.yml



$ kubectl version --short
Client Version: v1.7.4
Server Version: v1.7.4-1+1540c973d4ff9d

• Zur Bereitstellung der Applikation „blueprint“ für ein POD in Kubernetes, wird erstmal ein Deployment-Artefakt erstellt werden. Dieses kann dann später für weitere Instanzen wiederverwendet werden.

$ kubectl run blueprint --image=registry.eu-gb.bluemix.net/haftech/blueprint:0.1.bm
deployment "blueprint" created

• Das Deployment muss nur veröffentlich werden. Dafür steht das kubernetes expose Befehl bereit. Da wir gerade nur einen Workerknoten im Cluster haben, wird als Typ NodePort verwendet. Zusätzlich werden noch die Ports definiert. Der generierte Port wird sich im Bereich „30000-32767“ bewegen.

$ kubectl expose deployment/blueprint --type=NodePort --port=8099 --name=blueprint-service --target-port=8099 

service "blueprint-service" exposed

• Die öffentliche IP und Port lassen sich aus den Details des Service und Cluster ermitteln. Die Applikation lässt sich über folgende URL erreichen: http://169.51.16.35:32587.

$ kubectl describe service blueprint-service  
Name:			blueprint-service
Namespace:		default
Labels:			run=blueprint
Annotations:		<none>
Selector:		run=blueprint
Type:			NodePort
IP:			172....
Port:			<unset>	8080/TCP
NodePort:		<unset>	32587/TCP
Endpoints:		172...:8080
Session Affinity:	None
Events:			<none>

$ bx cs workers myCluster
OK
ID                                                 Public IP      Private IP      Machine Type   State    Status   Version   
kube-par01-pa709d68f58b324f7fae5faa3eb54b1051-w1   169.51.16.35   10.126.122.25   free           normal   Ready    1.7.4_1503

• Fals der Service, respektive die Applikation, gelöscht werden muss, geht das mit folgendem Befehl

$ kubectl delete service blueprint-service
service "blueprint-service" deleted

Fazit

Mittels Cloud Foundry und Kubernetes-CLI lässt sich mit überschaubarem Aufwand ein Docker Images in einem CF Provider veröffentlichen.; ohne dabei den Docker Container hier entsprechend anzupassen. Run Anywhere somit weiter eingehalten.

Viele der hier aufgeführten Befehle lassen sich bei den CF Providern über entsprechende UI-Konsolen durchführen. Genauso gibt es entsprechende IDE Unterstützung.

In einem späteren Beitrag wird mehr auf Cluster-Fähigkeit und Skalierung eingegangen, genauso wie dieser Prozess der Bereitstellung automisiert werden kann.

Referenzen

• IBM Bluemix und Cloud Foundry: https://console.bluemix.net/docs/overview/cf.html#howwork
• IBM Bluemix CLI (bx): https://console.bluemix.net/docs/cli/reference/bluemixcli/getstarted.html#getting-started
• IBM Bluemix Plugin - Container Service: https://console.bluemix.net/docs/containers/csclidevtools.html
• IBM Bluemix Plugin - Cloud Container Registry : https://console.bluemix.net/docs/cli/plugins/registry/index.html#containerregcli
• Kubernetes CLI: https://kubernetes.io/docs/tasks/tools/install-kubectl/