PRÉSENTATION DE BOSHpar VMware

LIVRE BLANC – AOÛT 2017

Sommaire

Qu’est-ce que BOSH ? ........................................................................................................ 3

Présentation de BOSH...............................................................................................................3

Quels problèmes BOSH permet-il de résoudre ? .........................................................4

Cas d’usage de BOSH ................................................................................................................6

Déploiement de BOSH .......................................................................................................8

Architecture de BOSH ...............................................................................................................8

Informations de référence sur BOSH .................................................................................8

Instructions : Comment déployer Kubo sur vSphere .............................................9

Procédure de déploiement de BOSH (pour Mac OSX) ...........................................9

Procédure de déploiement de Kubo sur BOSH ......................................................... 10

PRÉSENTATION DE BOSH

L I V R E B L A N C | 2

Qu’est-ce que BOSH ?Présentation de BOSHBOSH est un outil Open Source qui permet d’assurer le déploiement et de gérer le cycle de vie des systèmes distribués. Principale méthode de déploiement de Cloud Foundry, BOSH bénéficie de la contribution de nombreux membres éminents de la Cloud Foundry Foundation, dont Google, Pivotal et VMware. Cet outil prend en charge les déploiements de nombreux fournisseurs IaaS, parmi lesquels :

• VMware vSphere

• Google Cloud Platform

• Amazon Web Services EC2

• Microsoft Azure

• OpenStack

L I V R E B L A N C | 3

Figure 1 : Présentation de BOSH

BOSH réalise les déploiements en créant plusieurs grandes abstractions qui permettent de gérer le déploiement de systèmes complexes de manière simple et reproductible (voir la figure ci-dessus) :

1. CPI : L’interface de fournisseur de Cloud, ou CPI, est la bibliothèque d’exécutables que BOSH utilise pour interagir avec une infrastructure IaaS déterminée. Il existe une CPI pour chaque infrastructure IaaS prise en charge par BOSH, et vous pouvez spécifier la ou les CPI qui seront utilisées par la ou les instances de BOSH lors du déploiement de ces instances. Dans l’illustration ci-dessus, c’est une CPI vSphere qui est représentée. Celle-ci permet à BOSH d’effectuer toutes les actions IaaS requises, telles que la création d’une VM ou d’une instance, ainsi que des diverses primitives d’instance, de réseau ou de stockage nécessaires pour instancier un déploiement.

Manifeste dedéploiement

BOSH

CPI-vSphere

BOSH

Réseau(x) Réseau(x)

DéploiementBOSH actif

VM detravail

vSphere

1

4

5

Release BOSH

Stemcell BOSH

3

2

VM detravail

VM detravail

VM detravail

VM detravail

PRÉSENTATION DE BOSH

2. Stemcell BOSH : Une stemcell est une image de système d’exploitation de base versionnée. Une stemcell est générée pour chaque CPI prise en charge par BOSH. Généralement basée sur la distribution Ubuntu de Canonical, elle est également disponible en tant que portage d’image RHEL ou même Windows. La stemcell est le plus souvent une image de système d’exploitation de base renforcée comportant un agent BOSH prédéployé. BOSH a notamment recours à cet agent pour l’installation de logiciels sur la VM concernée et la gestion de leur cycle de vie.

3. Release BOSH : Une release BOSH correspond à un fichier tarball versionné qui contient la totalité du code source et des définitions de travaux nécessaires pour indiquer à BOSH comment la release concernée du logiciel doit être déployée sur une VM ou une instance provisionnée à partir d’une stemcell. À titre d’exemple, la release Kubo comprend l’ensemble des packages et des détails dont BOSH a besoin pour déployer un cluster Kubernetes entièrement fonctionnel.

4. Manifeste de déploiement BOSH : BOSH ne peut effectuer un déploiement qu’après avoir reçu certaines informations déclaratives. Celles-ci lui sont fournies par un opérateur via un manifeste. Un manifeste définit la ou les releases et stemcells à utiliser dans un déploiement, et fournit un ensemble de variables clés telles que les informations sur la pile IP, le nombre d’instances et les paramètres de configuration avancée de la ou des releases à déployer. Ce manifeste présente généralement le format YAML.

5. Déploiement BOSH : BOSH a besoin de certaines informations déclaratives pour effectuer un déploiement. Celles-ci lui sont fournies par un opérateur via un manifeste de déploiement et un manifeste cloud-config. Ces manifestes présentent généralement le format YAML.

– Manifeste cloud-config : Ce fichier YAML est propre à une infrastructure IaaS déterminée, définie par les propriétés mises à disposition dans sa CPI. Il fournit la définition de divers éléments, tels que les réseaux, les tailles de VM, les emplacements de stockage et les mappages de zone de disponibilité. Ce manifeste est de type global, ce qui signifie qu’il ne peut y en avoir qu’une seule instance par système BOSH, et que plusieurs manifestes de déploiement peuvent y faire référence.

– Manifeste de déploiement : Ce manifeste fait référence aux objets définis dans le manifeste cloud-config en s’attachant aux propriétés associées aux releases. Les manifestes définissent la ou les releases et stemcells à utiliser dans un déploiement, et fournissent un ensemble de variables clés telles que le nombre d’instances et les paramètres de configuration avancée de la ou des releases à déployer. Cela permet le portage des manifestes de déploiement d’une CPI à une autre.

Quels problèmes BOSH permet-il de résoudre ?BOSH permet aux développeurs de releases1 d’assurer le suivi des versions, le packaging et le déploiement des logiciels d’une manière simple et reproductible. Les opérateurs ont la possibilité de consommer des releases BOSH avec la garantie de pouvoir reproduire les déploiements avec des résultats prévisibles dans différents environnements. À cette fin, BOSH permet aux développeurs de releases de se concentrer sur la fourniture de plusieurs fonctionnalités clés lors de la génération d’une release :

• Caractère identifiable L’opérateur doit avoir la possibilité de documenter le déploiement du logiciel et de ses versions. Par nature, une release BOSH impose au développeur de déclarer et packager tous les éléments qu’elle contient. La release elle-même doit également être versionnée. L’opérateur a ainsi une parfaite connaissance des éléments déployés, et la possibilité de mettre à niveau ou déclasser les logiciels contenus dans une release de manière cohérente.

1 Un développeur de releases est un développeur chargé de packager les logiciels destinés à être déployés par BOSH.

PRÉSENTATION DE BOSH

L I V R E B L A N C | 4

Exemple : Dans la Figure 2, l’opérateur qui définit un déploiement peut se référer à plusieurs releases BOSH versionnées spécifiées dans un manifeste de déploiement. Il est ainsi en mesure d’identifier les versions logicielles utilisées. Dans cette image, BOSH met à disposition deux versions de la release Kubo : la version 0.0.5 et la version 0.0.6. L’opérateur a opté pour la version 0.0.5 de la release indiquée dans le manifeste de déploiement, ce qui entraînera l’utilisation de Kubernetes version 1.6.6 à l’échelle du déploiement nommé « mykubo-deployment ».

Figure 2 : Caractère identifiable garanti par BOSH

* ReproductibilitéAutre aspect fondamental de la production logicielle pris en charge par BOSH : la reproductibilité. Du point de vue de l’opérateur, les logiciels doivent être déployés de la même manière dans tous les environnements pour garantir la stabilité opérationnelle.

Exemple : Dans la Figure 3 (page suivante), un manifeste unique permet de déployer Kubernetes de manière homogène, c’est-à-dire d’assurer le même déploiement fonctionnel avec les mêmes releases dans différents environnements. En utilisant l’abstraction CPI, il est même possible de cibler les environnements de différents fournisseurs IaaS. Le manifeste de déploiement simplifié et partiel illustré dans cette image indique quelle stemcell BOSH, quelle release BOSH et quelles propriétés de configuration doivent être utilisées pour déployer des clusters Kubernetes fonctionnellement identiques dans deux environnements différents.

Release BOSH: kubo-releaseVersion: 0.0.5

Package(s): kubernetes: kubernetes-1.6.6/*

nginx: nginx/ nginx-release-1.11.4.tar.gz

Release BOSH: kubo-releaseVersion: 0.0.6

Package(s): kubernetes: kubernetes-1.7.1/*

nginx: nginx/nginx-release-1.11.4.tar.gz

Manifeste dedéploiement

BOSH

CPI-vSphere

BOSH

Réseau(x)

DéploiementBOSH actif

VM KBS

V1.6.6

vSphere

VM KBS

V1.6.6

VM KBS

V1.6.6

Nom: mykubo-deployment releases: - Nom: kubo-release version: 0.0.5 - Nom: docker version: 28.0.1

mykubo-deployment

L I V R E B L A N C | 5

PRÉSENTATION DE BOSH

Figure 3 : Reproductibilité garantie par BOSH

• CohérenceBOSH assure également la cohérence du développement de releases BOSH afin de garantir que pratiquement tous les logiciels peuvent être packagés, versionnés et déployés selon un schéma identique. Cette cohérence est également un facteur de stabilité opérationnelle.

Cas d’usage de BOSHLe principal apport de BOSH est de simplifier le déploiement et les opérations de gestion du cycle de vie du jour 2 dans le cadre de systèmes complexes. Cet outil a initialement été développé pour le déploiement de Cloud Foundry, mais les extensions dont il a bénéficié de la part des développeurs lui permettent désormais d’assurer des déploiements dans d’autres environnements, simples ou complexes. Les systèmes vers lesquels BOSH est capable d’effectuer des déploiements sont principalement répertoriés sur deux sites. Le premier est le site Pivotal Network, sur lequel Pivotal maintient la liste des releases BOSH commerciales de Pivotal Cloud Foundry ainsi que des services Pivotal, qui sont en principe pilotés conjointement par Pivotal Operations Manager et BOSH. Le second est le site BOSH.io, qui héberge un référentiel communautaire OSS recensant des différents systèmes pouvant être déployés.

Le projet Kubernetes basé sur BOSH, ou Kubo, constitue un excellent exemple de cas d’usage de BOSH.

La Figure 4 (page suivante) présente les principaux avantages que BOSH apporte à l’opérateur.

1. Reproductibilité : Dans un environnement de développement natif Cloud, l’opérateur a la possibilité de générer plusieurs manifestes de déploiement en vue de réaliser des déploiements Kubernetes distincts mais fonctionnellement identiques pour répondre aux besoins des différents développeurs appelés à consommer ces déploiements.

PRÉSENTATION DE BOSH

L I V R E B L A N C | 6

Nom: mykubo-deployment releases: - Nom: kubo-release version: 0.0.5 - Nom: docker version: 28.0.1 - Nom: kubo-etcd version: 2 stemcells: - alias: trusty os: ubuntu-trusty version: latest instance_groups: - Nom: etcd instances: 2 network: alpha azs: [az1] jobs: alpha - Nom: etcd release: kubo-etcd properties: [ ] stemcell: trusty - Nom: master instances: 2 - Nom: worker instances: 3

Manifeste dedéploiement

BOSH

CPI-AWS

BOSH A nom du réseau vpc = alpha

etcd etcd master

vSphere

master worker worker worker

CPI-vSphere

nom du groupe de ports vSphere = alpha

etcd etcd master

vSphere

master worker worker worker

BOSH B

mykubo-deployment

DéploiementBOSH actif

mykubo-deployment

DéploiementBOSH actif

Figure 4 : Cas d’usage de BOSH : Kubo

2. Opérations du jour 2 : La fonctionnalité BOSH de gestion du cycle de vie facilite le maintien de l’intégrité de tous les déploiements Kubernetes.

– Maintenir l’intégrité : Chaque VM ou instance déployée par BOSH déploie également un agent qui retransmet les données d’intégrité à BOSH. Si un nœud présente un problème d’intégrité, BOSH tente automatiquement de la réparer ou de le régénérer, ce qui permet d’améliorer le temps disponible.

– Augmenter le temps disponible : Chaque type d’instance de travail issu d’une release peut être associé à plusieurs VM ou instances distribuées entre différentes zones de disponibilité, afin que les services fournis ne puissent pas être affectés par les défaillances physiques propres à une zone de disponibilité. Les zones de disponibilité ne sont prises en charge que par certaines CPI, telles que la CPI vSphere. Dans cette dernière, les zones de disponibilité sont mappées aux clusters vCenter.

– Application de correctifs : Dans la mesure où BOSH utilise des releases versionnées, l’opérateur peut aisément mettre à niveau la release Kubo de Kubernetes et l’appliquer à l’ensemble des déploiements actifs pratiquement sans interruption de service. BOSH procède comme suit pour assurer la mise à jour avec maintien d’état de chaque déploiement : (1) il détache les disques persistants ; (2) il régénère les VM ou instances affectées ; puis (3) il rattache les disques persistants.

CPI-vSphere

BOSH

mykubo-deployment-2

worker 1

etcd 1

master 1

worker 2

etcd 2

Zone de disponibilité 1 Zone de disponibilité 2 Zone de disponibilité 2

worker 0

master- haproxy

0

master 0

etcd 0 Age

nt B

OS

H

Équipe de développement B

Développeur

mykubo-deployment-1

worker 1

etcd 1

master 1

worker 2

etcd 2

worker 0

master- haproxy

0

master 0

etcd 0 Age

nt B

OS

H

Équipe de développement A

Développeur

Health Monitor

Opérateur deplate-forme

mykubo-deployment-2Équipe de

développement B

mykubo-deployment-1Équipe de

développement A

= disque persistant

Zone de disponibilité 1 Zone de disponibilité 2 Zone de disponibilité 3

L I V R E B L A N C | 7

PRÉSENTATION DE BOSH

Déploiement de BOSHArchitecture de BOSHBOSH est généralement déployé sous la forme d’une VM ou d’une instance unique. Cette VM/instance présente de nombreux composants qui jouent un rôle crucial dans la capacité de BOSH à gérer les déploiements à grande échelle :

• NATS : Fournit un bus de messages pour les interactions entre les différents services de BOSH.

• POSTGRESQL : BOSH enregistre l’ensemble de ses informations d’état dans une base de données, qui est généralement hébergée à l’intérieur d’un unique déploiement BOSH sur VM, et fournie par Postgres. Il est toutefois possible de modifier cette situation en utilisant une source de données externe, ce qui permet de régénérer la VM BOSH et de la reconnecter à la base de données pour recharger son état persistant.

• BLOBSTORE : Chacune des stemcells et des releases chargées dans BOSH est stockée dans un magasin d’objets blob. Les déploiements par défaut de BOSH utilisent un référentiel interne (webdav), mais, à l’instar de la base de données Postgresql, ce référentiel peut également être externalisé.

• Director : Il s’agit de la principale API avec laquelle l’interface de ligne de commande BOSH doit s’articuler pour permettre à un opérateur de créer et gérer des déploiements BOSH.

• Health Monitor : Sur chaque VM qu’il déploie, BOSH requiert la présence d’un agent avec lequel il peut communiquer pour affecter et déployer des travaux à partir des releases BOSH définies dans un manifeste de déploiement. BOSH maintient également l’intégrité de chacune des VM ou instances qu’il a déployées. L’agent assure la remontée des données d’intégrité auprès de BOSH et, en cas de défaillance des services de la VM ou d’inaccessibilité de l’agent, le composant Health Monitor peut utiliser des plug-ins pour redémarrer ces services ou même régénérer la VM ou l’instance.

• CPI : La CPI est un fichier binaire exécutable propre à un fournisseur IaaS déterminé qui permet à BOSH d’interagir avec l’infrastructure IaaS définie dans son fichier de déploiement YAML.

• UAA : Fournit des fonctionnalités d’accès et d’authentification utilisateur permettant à BOSH d’authentifier les opérateurs via des systèmes back-end SAML ou LDAP.

• CREDHUB : Gère les informations d’authentification telles que mots de passe, certificats, autorités de certification, clés de protocole SSH, clés RSA et autres valeurs (chaînes et blobs JSON). BOSH exploite le composant credhub pour créer et stocker les principales informations d’authentification nécessaires aux déploiements, telles que les certificats et clés publics.

L I V R E B L A N C | 8

PRÉSENTATION DE BOSH

Figure 5 : Architecture de BOSH

Informations de référence sur BOSHDes informations de référence complètes relatives à BOSH sont disponibles sur le site : BOSH.io

BOSH

worker 1

etcd 1

master 1

worker 2

etcd 2

Zone de disponibilité 1 Zone de disponibilité 2 Zone de disponibilité 3

worker 0

master- haproxy

0

master 0

etcd 0

Déploiement de Kubo sur vSphere

NATS

POSTGRESQL

BLOBSTSORE

DIRECTOR

HEALTH MONITOR

CPI

UAA

CREDHUB

Agent BOSH

Instructions : Comment déployer Kubo sur vSpherePour déployer BOSH, vous pouvez utiliser l’interface BOSH CLI, transmettre les arguments de ligne de commande appropriés, ou stocker ces arguments en tant que données variables dans des fichiers YAML supplémentaires définissant les modalités de déploiement de l’outil BOSH proprement dit. La présente section décrit la procédure de déploiement de BOSH et donne quelques conseils pour un déploiement Kubo de base.

Conditions requises :

• vSphere vCenter 6.x

• 1 banque de données vSphere avec suffisamment d’espace pour le déploiement

• 1 pool de ressources vCenter pour votre déploiement Kubo

Procédure de déploiement de BOSH (pour Mac OSX) : Vous trouverez ici les instructions d’installation propres au système d’exploitation pour l’interface CLI.

Se procurer l’interface BOSH CLI • Les présentes instructions se réfèrent à la version 2 de l’interface BOSH CLI. Il s’agit d’un

binaire compilé avec Go, qui présente néanmoins certaines dépendances vis-à-vis du système d’exploitation.

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

Préparer les composants requis pour MAC OS, tels que Ruby• D’autres instructions propres au système d’exploitation sont disponibles ici.

2. gem update --system 3. xcode-select --install 4. brew install openssl

Utiliser le client GIT pour cloner le référentiel de déploiement de BOSH • Les présentes instructions supposent que le client GIT est déjà installé. Ce référentiel contient

tout ce dont vous avez besoin pour déployer une instance BOSH.

5. git clone https://github.com/cloudfoundry/bosh-deployment 6. cd bosh-deployment

Déployer BOSH• La commande CLI ci-après suffit à déployer l’instance BOSH. Les indicateurs -o désignent un

ou plusieurs fichiers YAML assemblés pour constituer un manifeste unique. Les indicateurs -v correspondent aux variables que nous affectons aux marqueurs variables présents dans chaque fichier YAML. La commande BOSH int, ou interpolate, lance la composition du manifeste à partir des stubs YAML et des variables.

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]] \ -v internal_ip=[[IP-OF-NETWORK-FOR-BOSH-VM]] \

L I V R E B L A N C | 9

PRÉSENTATION DE BOSH

-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

Procédure de déploiement de Kubo sur BOSH Utiliser le client GIT pour cloner le référentiel de déploiement de BOSH• Les présentes instructions supposent que le client GIT est déjà installé. Ce référentiel contient

tout ce dont vous avez besoin pour déployer Kubo sur votre instance BOSH.

1. git clone https://github.com/cloudfoundry-incubator/kubo-deployment 2. cd kubo-deployment

Générer et mettre à jour le manifeste BOSH cloud-config• Chaque manifeste cloud-config est propre à une CPI déterminée et permet le mappage des

structures BOSH (telles que les zones de disponibilité) aux structures vSphere. Un manifeste de déploiement fait référence aux structures du manifeste cloud-config.

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

L I V R E B L A N C | 1 0

PRÉSENTATION DE BOSH

Générer le manifeste de déploiement Kubo

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

Charger la stemcell BOSH la plus récente

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

Charger la release BOSH Kubo

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

Déployer Kubo :)

9. /usr/local/bin/bosh -e kubobosh -d mykubocluster deploy ~/kubo-deployment/mykubo.yml

La version la plus récente de ce document est disponible ici.

À propos de VMware VMware fournit des technologies d’infrastructure qui permettent aux développeurs et aux départements informatiques de créer, d’exécuter et de gérer des applications Cloud de façon à améliorer l’agilité, la sécurité et l’efficacité.

Pour plus d’informations, consultez le site www.vmware.com/fr/solutions/cloudnative.html.

Lien Twitter : https://twitter.com/cloudnativeapps

Lien du blog : https://blogs.vmware.com/cloudnative/

L I V R E B L A N C | 1 1

PRÉSENTATION DE BOSH

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com VMware Global Inc. Tour Franklin 100-101 Terrasse Boieldieu 92042 Paris La Défense 8 Cedex France Tél. +33 1 47 62 79 00 www.vmware.com/frCopyright © 2017-2018 VMware, Inc. Tous droits réservés. Ce produit est protégé par les lois des États-Unis et internationales sur le copyright et la propriété intellectuelle. Les produits VMware et ceux de ses filiales sont couverts par un ou plusieurs brevets répertoriés à l’adresse http://www.vmware.com/go/patents. VMware est une marque déposée ou une marque commerciale de VMware, Inc. ou de ses filiales, aux États-Unis et/ou dans d’autres juridictions. Les autres marques et noms mentionnés sont des marques de leurs propriétaires respectifs. Référence : VMW_17Q3_WP_Introduction-to-BOSH_FINAL_080817 08/17