WHITE PAPER – AUGUST 2017
EINFÜHRUNG IN BOSH Von VMware EINFÜHRUNG IN BOSH
Inhalt
Was ist BOSH?...... 3 Übersicht über BOSH...... 3 Welche Probleme löst BOSH?...... 4 BOSH-Anwendungsbereiche...... 6
Bereitstellen von BOSH...... 8 BOSH-Architektur...... 8 Informationen zu BOSH...... 8
Anleitung: Bereitstellen von „Kubo“ auf vSphere...... 9 Schritte zum Bereitstellen von BOSH (für Mac OSX): ...... 9 Schritte zum Bereitstellen von Kubo auf BOSH ...... 10
WHITE PAPER | 2 EINFÜHRUNG IN BOSH
Was ist BOSH? Übersicht über BOSH BOSH ist ein Open Source-Tool, das die Bereitstellung und das Lebenszyklusmanagement von verteilten Systemen ermöglicht. Es ist die primäre Methode zum Bereitstellen von Cloud Foundry und wird von vielen wichtigen Mitgliedern der Cloud Foundry Foundation, wie z.B. Google, Pivotal und VMware, unterstützt. BOSH kann Bereitstellungen auf vielen verschiedenen IaaS-Anbietern unterstützen. Dazu gehören: • VMware vSphere • Google Cloud Platform • Amazon Web Services EC2 • Microsoft Azure
• OpenStack
4
BOSH-Bereitstellungsmanifest
3 Netzwerk(e) Network(s) BOSH-Release 1 vSphere-CPI Job Job Job Job Job BOSH-Stemcell VM VM VM VM VM 2 BOSH vSphere
Ausgeführte BOSH-Bereitstellung 5
Abbildung 1: Übersicht über BOSH
BOSH ermöglicht Bereitstellungen, indem mehrere größere Abstraktionsobjekte erstellt werden, mit denen das Bereitstellen komplexer Systeme einfach und wiederholbar wird. Bezugnehmend auf die Abbildung oben, zählen dazu folgende Objekte:
1. CPI: Die Cloud-Anbieterschnittstelle (Cloud Provider Interface, CPI) ist die ausführbare Bibliothek, die BOSH für die Interaktion mit allen IaaS verwendet. Für jede von BOSH unterstützte IaaS ist eine CPI verfügbar. Wenn Sie die BOSH- Instanz(en) bereitstellen, können Sie festlegen, welche diese verwendet. In der Abbildung oben ist eine vSphere-CPI dargestellt. Sie ermöglicht BOSH, alle erforderlichen IaaS-Aktionen durchzuführen, z.B. das Erstellen von VMs oder Instanzen sowie weiterer Instanz-, Netzwerk- und Storage-Primitiven, die zur Instanziierung einer Bereitstellung erforderlich sind.
WHITE PAPER | 3 EINFÜHRUNG IN BOSH
2. BOSH-Stemcell: Eine Stemcell ist ein versioniertes Basis-Betriebssystem-Image für jede CPI, die von BOSH unterstützt wird. Sie basiert meist auf der Ubuntu-Distribution von Canonical, ist aber auch in RHEL und sogar Windows-Image-Ports verfügbar. Die Stemcell ist in der Regel ein gehärtetes Basis-OS-Image mit einem vorab bereitgestellten BOSH-Agenten. BOSH verwendet diesen Agenten beispielsweise zum Installieren und Verwalten des Lebenszyklus einer Software auf einer VM.
3. BOSH-Release: Ein BOSH-Release ist ein versioniertes Tarball. Es enthält den kompletten Quellcode und die Jobdefinitionen, die BOSH eine Beschreibung liefern, wie das jeweilige Software-Release auf einer VM oder Instanz bereitgestellt werden sollte, die über eine Stemcell zur Verfügung gestellt wurde. Ein Beispiel hierfür ist das Kubo-Release, das alle Pakete und Details enthält, mit deren Hilfe BOSH einen voll funktionsfähigen Kubernetes-Cluster bereitstellen kann.
4. BOSH-Bereitstellungsmanifest: BOSH muss bestimmte deklarative Informationen erhalten, um etwas bereitstellen zu können. Diese werden von einem Operator über ein Manifest zur Verfügung gestellt. Ein Manifest definiert die in einer Bereitstellung zu verwendenden Releases und Stemcells und enthält einige wichtige Variablen wie IP-Stack-Informationen, Instanzanzahl und erweiterte Konfigurationseinstellungen der jeweiligen Releases, die Sie bereitstellen möchten. Dieses Manifest ist normalerweise im YAML-Format geschrieben.
5. BOSH-Bereitstellung: BOSH benötigt bestimmte deklarative Informationen, um etwas bereitstellen zu können. Diese werden von einem Operator über ein Bereitstellungsmanifest und ein Cloud-Konfigurationsmanifest zur Verfügung gestellt. Diese Manifeste sind normalerweise im YAML-Format geschrieben. ––Cloud-Konfigurationsmanifest: Dieses YAML ist spezifisch für eine IaaS, wie durch die in ihrer CPI zur Verfügung gestellten Eigenschaften definiert. Es enthält beispielsweise Informationen für Netzwerke, VM-Größen, Speicherorte und Verfügbarkeitszonen-Zuordnungen. Dieses Manifest ist global (d.h., es kann nur eine Instanz pro BOSH geben) und mehrere Bereitstellungsmanifeste können darauf verweisen. ––Bereitstellungsmanifest: Dieses Manifest bezieht sich auf Objekte in der Cloud-Konfiguration und konzentriert sich auf die Eigenschaften der Releases. Die Manifeste definieren die in einer Bereitstellung zu verwendenden Releases und Stemcells und enthalten einige wichtige Variablen wie Instanzanzahl und erweiterte Konfigurationseinstellungen der bereitzustellenden Releases. Dadurch sind Bereitstellungsmanifeste über verschiedene CPIs hinweg portierbar.
Welche Probleme löst BOSH? Mithilfe von BOSH können Release-Entwickler1 Software auf einfache und reproduzierbare Weise versionieren, paketieren und bereitstellen. Operatoren können BOSH-Releases nutzen und davon profitieren, dass Bereitstellungen wiederholbar sind und vorhersagbare Ergebnisse für alle Umgebungen bieten. Um dies zu erreichen, müssen Release-Entwickler beim Erstellen eines Releases einige wichtige Fähigkeiten im Auge behalten:
• Identifizierbarkeit Ein Operator muss in der Lage sein, die Bereitstellung einer Software und ihrer Versionen zu dokumentieren. Bei einem BOSH-Release muss der Entwickler grundsätzlich alle Elemente in dem Release deklarieren und paketieren. Das Release selbst muss auch versioniert werden. So kann ein Operator vollständig verstehen, was bereitgestellt wird, und regelmäßig Upgrades oder Downgrades der Softwareversionen in einem Release durchführen.
1 Ein Release-Entwickler ist ein Entwickler, der von BOSH bereitzustellende Software paketiert.
WHITE PAPER | 4 EINFÜHRUNG IN BOSH
Beispiel: In Abbildung 2 kann ein Operator, der eine Bereitstellung definiert, auf ein oder mehrere versionierte Releases in einem Bereitstellungsmanifest verweisen. Dies ermöglicht die Identifizierung der verwendeten Softwareversionen. In der Abbildung unten stellt BOSH zwei Versionen des Kubo-Releases zur Verfügung: Version 0.0.5 und Version 0.0.6. Der Operator hat im Bereitstellungsmanifest die Verwendung von Version 0.0.5 des Releases festgelegt. Dadurch wird die Verwendung der Kubernetes- Version 1.6.6 in der gesamten Bereitstellung namens „mykubo-deployment“ erzwungen.
Name: mykubo-deployment releases: BOSH-Bereitstellungsmanifest - name: kubo-release version: 0.0.5 - name: docker version: 28.0.1 BOSH Release: kubo-release Version: 0.0.5 Package(s): kubernetes: kubernetes-1.6.6/* nginx: nginx/ Netzwerk(e) nginx-release-1.11.4.tar.gz
vSphere-CPI VM VM VM BOSH-Release: kubo-release KBS KBS KBS Version: 0.0.6 V1.6.6 V1.6.6 V1.6.6 BOSH Package(s): kubernetes: kubernetes-1.7.1/* vSphere nginx: nginx/nginx-release-1.11.4.tar.gz
Ausgeführte BOSH-Bereitstellung mykubo-deployment
Abbildung 2: BOSH-Identifizierbarkeit
* Reproduzierbarkeit Ein weiterer wichtiger Aspekt beim Veröffentlichen von Software, der von BOSH berücksichtigt wird, ist Reproduzierbarkeit. Für einen Operator bedeutet das, dass Software in verschiedenen Umgebungen auf die gleiche Weise bereitgestellt werden sollte, um betriebliche Stabilität zu gewährleisten.
Beispiel: In Abbildung 3 auf der folgenden Seite kann ein einziges Manifest Kubernetes auf einheitliche Weise bereitstellen. Dabei wird die gleiche funktionsfähige Bereitstellung mit den gleichen Releases in mehreren Umgebungen erzielt. Diese Umgebungen können sich dank der CPI-Abstraktion sogar über mehrere IaaS- Anbieter erstrecken. Das vereinfachte und unvollständige Bereitstellungsmanifest in der Abbildung unten deklariert, welche BOSH-Stemcell, welches BOSH-Release und welche Konfigurationseigenschaften verwendet werden müssen, um funktionell identische Kubernetes-Cluster in zwei verschiedenen Umgebungen bereitzustellen.
WHITE PAPER | 5 EINFÜHRUNG IN BOSH
Ausgeführte BOSH- Bereitstellung mykubo-deployment Name: mykubo-deployment releases: - name: kubo-release version: 0.0.5 BOSH A VPC-Netzwerkname = alpha - name: docker version: 28.0.1 CPI-AWS - name: kubo-etcd etcd etcd master master worker worker worker version: 2 stemcells: vSphere - alias: trusty os: ubuntu-trusty BOSH-Bereit- version: latest stellungsmanifest instance_groups: - name: etcd instances: 2 network: alpha vSphere-Portgruppenname = alpha azs: [az1] jobs: alpha vSphere-CPI - name: etcd etcd etcd master master worker worker worker release: kubo-etcd properties: [ ] BOSH B vSphere stemcell: trusty - name: master instances: 2 - name: worker Ausgeführte instances: 3 BOSH-Bereitstellung mykubo-deployment
Abbildung 3: BOSH-Reproduzierbarkeit
• Konsistenz BOSH erzwingt außerdem Konsistenz bei der BOSH-Release-Entwicklung. Damit wird sichergestellt, dass praktisch jede Software nach einem ähnlichen Muster paketiert, versioniert und bereitgestellt werden kann. Dies sorgt zudem für betriebliche Stabilität.
BOSH-Anwendungsbereiche Der Hauptvorteil von BOSH besteht darin, dass die Bereitstellung von komplexen Systemen und das Lebenszyklusmanagement ab Tag 2 vereinfacht wird. BOSH wurde primär zur Bereitstellung von Cloud Foundry entwickelt. Inzwischen wurde das Tool jedoch von Entwicklern erweitert, sodass nun auch viele weitere, sowohl einfache als auch komplexe Umgebungen bereitgestellt werden können. Systeme, auf denen BOSH bereitstellen kann, sind an zwei primären Orten zu finden. Erstens imPivotal-Netzwerk . Hier verwaltet Pivotal kommerzielle BOSH-Releases von Pivotal Cloud Foundry sowie Pivotal-Services, die in der Regel von Pivotal Operations Manager zusammen mit BOSH gesteuert werden. Zweitens BOSH.io. Hier wird ein OSS-Community-Repository von verschiedenen Systemen gehostet, die bereitgestellt werden können.
Ein gutes BOSH-Anwendungsbeispiel ist Kubernetes auf Basis von BOSH, auch als Kubo bezeichnet.
Abbildung 4 auf der folgenden Seite verdeutlicht die wichtigsten Vorteile, die BOSH dem Operator bietet.
1. Wiederholbarkeit: In einer cloudnativen Entwicklungsumgebung kann der Operator zwei oder mehr gleiche Bereitstellungsmanifeste erzeugen, um zwei oder mehr individuelle, aber funktionell identische Kubernetes-Bereitstellungen zu ermöglichen. So können die Anforderungen verschiedener Entwickler-Kunden erfüllt werden.
WHITE PAPER | 6 EINFÜHRUNG IN BOSH
master- Entwickler haproxy 0 Entwicklerteam A
Plattformbediener master 0 master 1 mykubo-deployment-1 mykubo-deployment-2 Entwicklerteam A Entwicklerteam B
BOSH-Agent etcd 0 etcd 1 etcd 2
worker 0 worker 1 worker 2
Verfügbarkeitszone 1 Verfügbarkeitszone 2 Verfügbarkeitszone 3
mykubo-deployment-1 vSphere-CPI
Health Monitor BOSH Entwickler master- haproxy 0 Entwicklerteam B
master 0 master 1 Agent
BOSH etcd 0 etcd 1 etcd 2
worker 0 worker 1 worker 2
= persistent_disk Verfügbarkeitszone 1 Verfügbarkeitszone 2 Verfügbarkeitszone 3
mykubo-deployment-2
Abbildung 4: BOSH-Anwendungsbeispiel: Kubo
2. „Tag 2“-Betrieb: Das Lebenszyklusmanagement von BOSH ermöglicht es, auf einfache Weise für einen einwandfreien Zustand aller Kubernetes-Bereitstellungen zu sorgen.
––Aufrechterhaltung des Systemzustands: Jede von BOSH bereitgestellte VM bzw. Instanz stellt auch einen Agenten bereit, der BOSH Informationen über den Systemzustand liefert. Wenn der Zustand eines Kubo-Knotens nicht einwandfrei ist, versucht BOSH automatisch, den betroffenen Knoten zu reparieren oder neu zu erstellen. Auf diese Weise wird die Betriebszeit verbessert.
––Optimierung der Betriebszeit: Jeder Instanztyp eines Release-Jobs kann mehrere VMs oder Instanzen haben, die über mehrere Verfügbarkeitszonen verteilt sind. So wird sichergestellt, dass die zur Verfügung gestellten Services nicht von physischen Ausfällen in einer Verfügbarkeitszone betroffen sind. Verfügbarkeitszonen werden nur auf bestimmten CPIs unterstützt, z.B. der vSphere-CPI. Hier sind Verfügbarkeitszonen vCenter-Clustern zugeordnet.
––Patching: Da BOSH versionierte Releases verwendet, können Operatoren das Kubo-Release von Kubernetes auf einfache Weise aktualisieren und auf alle ausgeführten Bereitstellungen anwenden, mit nur geringen oder sogar ganz ohne Serviceunterbrechungen. BOSH sorgt folgendermaßen für die Aktualisierung jeder Bereitstellung und Aufrechterhaltung ihres Zustands: (1) Abhängen persistenter Festplatten, (2) Neuerstellen der betroffenen VMs bzw. Instanzen und (3) Wiederanhängen persistenter Festplatten.
WHITE PAPER | 7 EINFÜHRUNG IN BOSH
Bereitstellen von BOSH BOSH-Architektur
BOSH wird in der Regel als einzelne VM bzw. Instanz bereitgestellt. Diese VM/Instanz hat viele Komponenten, die eine wichtige Voraussetzung dafür sind, dass BOSH skalierbare Bereitstellungen verwalten kann: • NATS: Stellt einen Message Bus bereit, über den verschiedene Services von BOSH miteinander interagieren können. • POSTGRESQL: BOSH schreibt seinen gesamten Zustand in eine Datenbank. Im Allgemeinen ist diese Datenbank in eine BOSH-Bereitstellung mit nur einer VM integriert und wird von Postgres zur Verfügung gestellt. Es ist jedoch auch möglich, eine externe Datenquelle zu verwenden, sodass die BOSH-VM neu erstellt und wieder mit der Datenbank verbunden werden kann, um ihren persistenten Zustand neu zu laden. • BLOBSTORE: Alle in BOSH hochgeladenen Stemcells und Releases werden in einem Blobstore gespeichert. Standardbereitstellungen von BOSH nutzen einen internen Speicher (WebDAV), der jedoch wie die PostgreSQL-Datenbank externalisiert werden kann. • Director: Die Haupt-API, zu der die BOSH-CLI eine Verbindung herstellt, um Operatoren das Erstellen und Verwalten von BOSH-Bereitstellungen zu ermöglichen. • Health Monitor: Jede von BOSH bereitgestellte VM muss einen Agenten haben, mit dem BOSH kommunizieren kann, um in einem Bereitstellungsmanifest definierte Jobs von BOSH-Releases zuzuweisen und bereitzustellen. BOSH hält auch den ordnungsgemäßen Zustand jeder bereitgestellten VM bzw. Instanz aufrecht. Der Agent meldet BOSH wichtige Ereignisse. Wenn Services in der VM fehlerhaft ausgeführt werden oder der Agent unerreichbar ist, kann der Health Monitor Services mithilfe von Plug-ins neu starten und die VM bzw. Instanz sogar neu erstellen. • CPI: Die CPI ist die IaaS-spezifische ausführbare Binärdatei, mit deren Hilfe BOSH mit der definierten IaaS in seiner Bereitstellungs-YAML interagiert. • UAA: Bietet Anwenderzugriff und -authentifizierung und ermöglicht BOSH, Operatoren über SAML oder LDAP-Back-Ends zu authentifizieren. • CREDHUB: Verwaltet Anmeldeinformationen wie Passwörter, Zertifikate, Zertifizierungsstellen, SSH-Schlüssel, RSA-Schlüssel und beliebige Werte (Strings und JSON-Blobs). BOSH erstellt und speichert mithilfe von CredHub wichtige Anmeldeinformationen wie öffentliche Zertifikate und Schlüssel.
NATS master- haproxy 0 POSTGRESQL
BLOBSTORE master 0 master 1 DIRECTOR
HEALTH MONITOR
CPI BOSH Agent etcd 0 etcd 1 etcd 2 UAA
CREDHUB worker 0 worker 1 worker 2
Verfügbarkeitszone 1 Verfügbarkeitszone 2 Verfügbarkeitszone 3
BOSH Kubo-Bereitstellung auf vSphere
Abbildung 5: BOSH-Architektur
Informationen zu BOSH Ausführliche Informationen über BOSH finden Sie hier:BOSH.io
WHITE PAPER | 8 EINFÜHRUNG IN BOSH
Anleitung: Bereitstellen von „Kubo“ auf vSphere BOSH wird mithilfe der BOSH-CLI bereitgestellt, indem die korrekten Befehlszeilenargumente übergeben werden. Alternativ werden die Argumente als variable Daten in zusätzlichen YAML- Dateien gespeichert, um zu definieren, wie BOSH bereitgestellt wird. Diese Anleitung enthält die erforderlichen Schritte zum Bereitstellen von BOSH und bietet Unterstützung für eine grundlegende Kubo-Bereitstellung. Voraussetzungen: • vSphere vCenter 6.x • 1 vSphere-Datastore mit ausreichend Speicherplatz für die Bereitstellung • 1 vCenter-Ressourcenpool für die Kubo-Bereitstellung
Schritte zum Bereitstellen von BOSH (für Mac OSX): Betriebssystemspezifische Installationsanweisungen für CLI finden Siehier .
Herunterladen der BOSH-CLI • In dieser Anleitung wird Version 2 der BOSH-CLI verwendet. Dabei handelt es sich um eine in Go kompilierte Binärdatei, die jedoch bestimmte Betriebssystemabhängigkeiten aufweist.
1. sudo wget -O /usr/local/bin/bosh https://s3.amazonaws.com/bosh-cli-artifacts/bosh-cli-2.0.28-darwin-amd64 && sudo chmod 755 /usr/local/bin/bosh
Erfüllen der MAC-Betriebssystemanforderungen, wie Ruby • Weitere betriebssystemspezifische Anweisungen finden Siehier und hier.
2. gem update --system 3. xcode-select --install 4. brew install openssl
Klonen des BOSH-Bereitstellungs-Repositorys mithilfe des Git-Clients • In dieser Anleitung wird die Installation des Git-Clients vorausgesetzt. Dieses Repository enthält alle Elemente, die Sie zum Bereitstellen einer BOSH-Instanz benötigen.
5. git clone https://github.com/cloudfoundry/bosh-deployment 6. cd bosh-deployment
Bereitstellen von BOSH • Mit dem CLI-Einzelbefehl unten wird die BOSH-Instanz bereitgestellt. -o-Flags sind eine oder mehrere YAML-Dateien, die zusammen ein einziges Manifest bilden. -v-Flags sind die Variablen, die variablen Markern in jeder YAML zugewiesen werden. Mit dem Befehl „bosh int“ (Interpolationsbefehl) wird das Manifest aus den YAML-Stubs und den Variablen erstellt.
7. /usr/local/bin/bosh create-env bosh.yml \ --state=mystate.json \ --vars-store=mycreds.yml \ -o vsphere/cpi.yml \ -o uaa.yml \ -o misc/powerdns.yml \ -o credhub.yml \ -v director_name=kubobosh \ -v internal_cidr=[[CIDR-OF-NETWORK-FOR-BOSH-VM]] \ -v internal_gw=[[GATEWAY-OF-NETWORK-FOR-BOSH-VM]] \
WHITE PAPER | 9 EINFÜHRUNG IN BOSH
-v internal_ip=[[IP-OF-NETWORK-FOR-BOSH-VM]] \ -v network_name=[[VCENTER-PG-NAME-NETWORK-FOR-BOSH-VM]] \ -v vcenter_dc=[[VCENTER-DC-NAME]] \ -v vcenter_ds=[[VCENTER-DATASTORE-NAME]] \ -v vcenter_ip=[[VCENTER-IP]] \ -v vcenter_user=[[VCENTER-USER]] \ -v vcenter_password=[[VCENTER-PASSWD]] \ -v vcenter_templates=kubobosh-templates \ -v vcenter_vms=kubobosh-vms \ -v vcenter_disks=kubobosh-disks \ -v vcenter_cluster=[[VCENTER-CLUSTER]] \ -v dns_recursor_ip=[[YOUR-NETWORK-DNS]]
8. /usr/local/bin/bosh alias-env kubobosh -e [[IP-OF-NETWORK-FOR-BOSH-VM]] --ca-cert <(/usr/local/bin/bosh int ./mycreds.yml --path /director_ssl/ca) 9. export BOSH_CLIENT=admin 10. export BOSH_CLIENT_SECRET=$(/usr/local/bin/bosh int ./mycreds.yml --path /admin_password) 11. /usr/local/bin/bosh -e kubobosh env
Schritte zum Bereitstellen von Kubo auf BOSH Klonen des BOSH-Bereitstellungs-Repositorys mithilfe des Git-Clients • In dieser Anleitung wird die Installation des Git-Clients vorausgesetzt. Dieses Repository enthält alle Elemente, die Sie zum Bereitstellen von Kubo mit der BOSH-Instanz benötigen.
1. git clone https://github.com/cloudfoundry-incubator/kubo-deployment 2. cd kubo-deployment
Generieren und Aktualisieren des Cloud-Konfigurationsmanifests für BOSH • Cloud-Konfigurationsmanifeste sind spezifisch für die jeweiligen CPIs und ordnen BOSH- Konstrukte (wie Verfügbarkeitszonen) vSphere-Konstrukten zu. Ein Bereitstellungsmanifest verweist auf Konstrukte aus der Cloud-Konfiguration.
3. /usr/local/bin/bosh int configurations/vsphere/cloud-config.yml \ -o manifests/ops-files/k8s_master_static_ip_vsphere.yml \ -v director_name=bosh \ -v internal_cidr=[[CIDR-OF-NETWORK-FOR-KUBO-CAN-BE-SAME-AS-BOSH]] \ -v internal_gw=[[GATEWAY-OF-NETWORK-FOR-KUBO-CAN-BE-SAME-AS-BOSH]] \ -v internal_ip=[[DNS-OF-NETWORK-FOR-KUBO-CAN-BE-SAME-AS-BOSH]] \ -v kubernetes_master_host=[[IP-FOR-KUBO-MASTER-VIP]] \ -v reserved_ips=[[IP-RANGE-YOU-DONT-WANT-BOSH-TO-USE ex: 192.168.100.10-192.168.100.20]] \ -v network_name=[[VCENTER-PG-NAME-NETWORK-FOR-KUBO-CAN-BE-SAME-AS- BOSH]] \ -v deployments_network=[[VCENTER-PG-NAME-NETWORK-FOR-KUBO-CAN-BE-SAME- AS-BOSH]] \ -v vcenter_cluster=[[VCENTER-CLUSTER-FOR-KUBO]] \ -v vcenter_rp=”[[VCENTER-RESOURCE-POOL-FOR-KUBO]]” > mycloudconfig.yml 4. bosh -e kubobosh update-cloud-config mycloudconfig.yml
WHITE PAPER | 10 EINFÜHRUNG IN BOSH
Generieren des Kubo-Bereitstellungsmanifests
5. /usr/local/bin/bosh int manifests/kubo.yml \ -o manifests/ops-files/master-haproxy-vsphere.yml \ -o manifests/ops-files/worker-haproxy.yml \ -v deployments_network=[[VCENTER-PG-NAME-NETWORK-FOR-KUBO-CAN-BE-SAME- AS-BOSH]] \ -v kubo-admin-password=”mykubopasswd” \ -v kubelet-password=”mykubopasswd” \ -v kubernetes_master_port=443 \ -v kubernetes_master_host=[[IP-FOR-KUBO-MASTER-VIP]] \ -v deployment_name=mykubocluster \ -v worker_haproxy_tcp_frontend_port=1234 \ -v worker_haproxy_tcp_backend_port=4231 > mykubo.yml
Hochladen der aktuellen BOSH-Stemcell
6. /usr/local/bin/bosh -e kubobosh upload-stemcell https://s3.amazonaws. com/bosh-core-stemcells/vsphere/bosh-stemcell-3421.11-vsphere-esxi-ubuntu- trusty-go_agent.tgz
Hochladen des Kubo-Releases für BOSH
7. wget https://github.com/cloudfoundry-incubator/kubo-release/releases/ download/v0.0.5/kubo-release-0.0.5.tgz 8. /usr/local/bin/bosh -e kubobosh upload-release kubo-release-0.0.5.tgz
Bereitstellen von Kubo
9. /usr/local/bin/bosh -e kubobosh -d mykubocluster deploy ~/kubo- deployment/mykubo.yml
Die neueste Version dieses Dokuments finden Sie hier.
Über VMware VMware stellt Infrastrukturtechnologien bereit, die der IT und Entwicklern das Erstellen, Ausführen und Verwalten cloudnativer Anwendungen ermöglichen, um geschäftliche Agilität, Sicherheit und Effizienz zu verbessern.
Weitere Informationen finden Sie unterwww.vmware.com/de/solutions/cloudnative.html .
Link zu Twitter: https://twitter.com/cloudnativeapps
Link zum Blog: https://blogs.vmware.com/cloudnative/
WHITE PAPER | 11 VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com Zweigniederlassung Deutschland Willy-Brandt-Platz 2, 81829 München Telefon: +49 89 370 617 000 Fax: +49 89 370 617 333 www.vmware.com/de Copyright © 2017 – 2018 VMware, Inc. Alle Rechte vorbehalten. Dieses Produkt ist durch US-amerikanisches und internationales Copyright sowie durch Gesetze zum Schutz des geistigen Eigentums geschützt. Produkte von VMware sind durch ein oder mehrere Patente geschützt, die auf der folgenden Webseite aufgeführt sind: http://www.vmware.com/go/patents. VMware ist eine eingetragene Marke oder Marke der VMware, Inc. in den USA und/oder anderen Ländern. Alle anderen in diesem Dokument erwähnten Bezeichnungen und Namen sind unter Umständen markenrechtlich geschützt. Artikelnr.: VMW_17Q3_WP_Introduction-to-BOSH_FINAL_080817 08/17