PRESENTACIÓN DE BOSHpor VMware

DOCUMENTO TÉCNICO: AGOSTO DE 2017

Contenido

¿Qué es BOSH? ..................................................................................................................... 3

Descripción de BOSH ................................................................................................................3

¿Qué problemas soluciona BOSH? .....................................................................................4

Casos de uso de BOSH .............................................................................................................6

Implementación de BOSH ................................................................................................8

Arquitectura de BOSH...............................................................................................................8

Referencias de BOSH .................................................................................................................8

Guía paso a paso: Cómo implementar «Kubo» en vSphere ................................9

Pasos para implementar BOSH (en Mac OSX): ...........................................................9

Pasos para implementar Kubo en BOSH ...................................................................... 10

PRESENTACIÓN DE BOSH

D O C U M E N TO T É C N I C O | 2

¿Qué es BOSH?Descripción de BOSHBOSH es una herramienta de código abierto que habilita la implementación y la gestión del ciclo de vida de sistemas distribuidos. Es el principal método utilizado para implementar Cloud Foundry y recibe contribuciones de muchos de los miembros principales de la Cloud Foundry Foundation, como Google, Pivotal y VMware. Permite realizar implementaciones en muchos proveedores de IaaS distintos. Algunos de estos proveedores son:

• VMware vSphere

• Google Compute Platform

• Amazon Web Services EC2

• Microsoft Azure

• OpenStack

D O C U M E N TO T É C N I C O | 3

Figura 1: Descripción de BOSH

BOSH realiza las implementaciones creando varios objetos de desvinculación principales con los que la implementación de sistemas complejos es sencilla y repetible. En referencia a la figura anterior, estos objetos incluyen:

1. CPI: la interfaz de proveedor de cloud (CPI) es la biblioteca ejecutable que BOSH utiliza para interactuar con cualquier IaaS especificado. Hay una CPI disponible para cada IaaS compatible con BOSH y, al implementar las instancias de BOSH, puede definir cuáles utilizará. En la imagen de arriba se muestra una CPI de vSphere. Permite a BOSH realizar todas las acciones de IaaS necesarias, como crear una máquina virtual o una instancia, así como otras primitivas de instancia, red y almacenamiento necesarias para crear una instancia de una implementación.

Manifiesto deimplementación

de BOSH

CPI-vSphere

BOSH

Redes Redes

Implementación de BOSH en ejecución

MV detrabajo

MV detrabajo

MV detrabajo

MV detrabajo

MV detrabajo

vSphere

1

4

5

Versión de BOSH Célula madre de BOSH

3

2

PRESENTACIÓN DE BOSH

2. Célula madre de BOSH: una célula madre («stemcell») es una imagen del sistema operativo base con diversas versiones que se crea para cada CPI compatible con BOSH. Se suele basar en la distribución Ubuntu de Canonical, pero también está disponible en RHEL e incluso en puertos de imágenes de Windows. Generalmente, la «célula madre» es una imagen de SO base reforzada con un agente de BOSH preimplementado. BOSH utilizará este agente para, por ejemplo, instalar y gestionar el ciclo de vida del software en esa máquina virtual.

3. Versión de BOSH: una versión de BOSH es un tarball con distintas versiones que contiene el código fuente completo y las definiciones de trabajo que se necesitan para describir a BOSH cómo se debe implementar esa versión de software en una máquina virtual o una instancia distribuida desde una célula madre. Un ejemplo es la versión de Kubo, que incluye todos los paquetes y detalles necesarios para permitir que BOSH implemente un clúster de Kubernetes totalmente funcional.

4. Manifiesto de implementación de BOSH: Para implementar algo, BOSH debe recibir alguna información declarativa. Esta información la proporciona un operador a través de un manifiesto. Un manifiesto define una o varias versiones y células madre que se usarán en una implementación, y proporciona algunas variables principales, como las de información de IPstack, recuento de instancias y configuración avanzada de las versiones especificadas que desea implementar. Este manifiesto se suele escribir en formato YAML.

5. Implementación de BOSH: Antes de implementar cualquier componente, BOSH necesita cierta información contrastada. Esta información la proporciona un operador a través de un manifiesto de implementación (deployment-manifest) y un manifiesto de configuración de cloud (cloud-config manifest). Estos manifiestos se suelen escribir en formato YAML.

– cloud-config manifest: este archivo en formato YAML es específico de cada IaaS y se define con las propiedades disponibles en su CPI. Proporciona definiciones para aspectos como las redes, el tamaño de las máquinas virtuales, la ubicación del almacenamiento y la asignación de zonas de disponibilidad. Este manifiesto es global, lo que significa que solo puede haber una instancia por BOSH, y que varios manifiestos de implementación pueden hacer referencia a este manifiesto.

– deployment-manifest: este manifiesto hace referencia a objetos de la configuración de cloud y se centra en propiedades asociadas a las versiones. El manifiesto define una o varias versiones y células madre que se usarán en una implementación, y proporciona algunas variables principales, como las de recuento de instancias y configuración avanzada de las versiones especificadas que desea implementar. Esto permite que los manifiestos de implementación sean portátiles de una CPI a otra.

¿Qué problemas soluciona BOSH?Con BOSH, los desarrolladores1 de versiones pueden gestionar versiones de software y empaquetarlo e implementarlo de un modo fácil y reproducible. Los operadores pueden consumir versiones de BOSH con la garantía de que las implementaciones son repetibles con resultados predecibles en los distintos entornos. Para ello, BOSH permite que los desarrolladores de versiones se centren en ofrecer prestaciones importantes cuando generan una versión:

• Capacidad de identificación Un operador debe poder documentar la implementación de software y sus versiones. Por su diseño, una versión de BOSH requiere que el desarrollador declare y empaquete todo en la versión. También se pueden crear versiones de la versión. Esto permite a un operador comprender plenamente lo que se implementa, y pasar de manera uniforme a versiones superiores o inferiores del software en una versión.

1 Un desarrollador de versiones es un desarrollador que empaqueta software que se implementará con BOSH.

PRESENTACIÓN DE BOSH

D O C U M E N TO T É C N I C O | 4

Ejemplo: En la figura 2, un operador que define una implementación puede hacer referencia a una o varias versiones con distintas ediciones en un manifiesto de implementación. Esto permite identificar las versiones de software usadas. En la imagen anterior, BOSH tiene dos versiones de la versión de Kubo disponibles: la 0.0.5 y la 0.0.6. El operador ha definido el uso de la versión 0.0.5 de la versión en el manifiesto de implementación, lo que forzará el uso de Kubernetes versión 1.6.6 en la implementación llamada «mykubo-deployment».

Figura 2: Identificabilidad de BOSH

* ReproducibilidadOtro aspecto clave del lanzamiento de software abordado por BOSH es la reproducibilidad. Para un operador, esto significa que el software debe implementarse exactamente de la misma manera en múltiples entornos, a fin de garantizar la estabilidad operativa.

Ejemplo: En la figura 3 de la página siguiente, un solo manifiesto puede implementar Kubernetes de forma coherente, garantizando la misma implementación funcional con las mismas versiones en varios entornos. Estos entornos incluso pueden utilizar varios proveedores de IaaS mediante la desvinculación de CPI. El manifiesto simplificado y de implementación parcial de la imagen declara la célula madre de BOSH, la versión de BOSH y las propiedades de configuración que se deben usar para implementar clústeres de Kubernetes funcionalmente idénticos en dos entornos distintos.

Versión de BOSH: kubo-versionesVersión : 0.0.5

Paquetes : kubernetes: kubernetes-1.6.6/*

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

Versión de BOSH: kubo-releaseVersión: 0.0.6

Paquetes : kubernetes: kubernetes-1.7.1/*

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

Manifiesto de implementación

de BOSH

CPI-vSphere

BOSH

Redes

Implementación de BOSH en ejecución

MV KBS

V1.6.6

vSphere

MV KBS

V1.6.6

MV KBS

V1.6.6

Nombre: mykubo-deployment Versión: - Nombre: kubo-release Versión: 0.0.5 - Nombre: docker Versión: 28.0.1

mykubo-deployment

D O C U M E N TO T É C N I C O | 5

PRESENTACIÓN DE BOSH

Figura 3: Reproducibilidad de BOSH

• CoherenciaBOSH también aplica la coherencia en el desarrollo de versiones de BOSH a fin de garantizar que cualquier software se pueda empaquetar, cambiar de versión e implementar usando un patrón similar. También proporciona estabilidad operativa.

Casos de uso de BOSHEl valor principal de BOSH es la simplificación de la implementación y la gestión del ciclo de vida posterior de sistemas complejos. Se desarrolló principalmente para implementar Cloud Foundry, pero los desarrolladores lo han ampliado para implementar muchos otros entornos, tanto simples como complejos. Los sistemas en los que BOSH se puede implementar se encuentran en dos ubicaciones principales. La primera es Pivotal Network, donde Pivotal elabora versiones BOSH comerciales de Pivotal Cloud Foundry, así como servicios de Pivotal que suelen estar controlados por Pivotal Operations Manager y BOSH. La segunda ubicación es BOSH.io, que aloja un repositorio de la comunidad de software libre con varios sistemas que se pueden implementar.

Un excelente ejemplo de caso de uso de BOSH es Kubernetes con tecnología de BOSH (es decir, Kubo).

La figura 4 de la página siguiente muestra las principales ventajas que BOSH aporta al operador.

1. Repetibilidad: en un entorno de desarrollo nativo de cloud, el operador puede generar dos o más manifiestos de implementación similares para implementar dos o más implementaciones únicas pero funcionalmente idénticas de Kubernetes para satisfacer las necesidades de varios consumidores desarrolladores.

PRESENTACIÓN DE BOSH

D O C U M E N TO T É C N I C O | 6

Nombre: mykubo-deployment Versión: - Nombre: kubo-release Versión: 0.0.5 - Nombre: docker Versión: 28.0.1 - Nombre: kubo-etcd Versión: 2 stemcells: - alias: trusty os: ubuntu-trusty Versión: latest instance_groups: - Nombre: etcd Instancias: 2 Redes: alpha azs: [az1] Trabajos: alpha - Nombre: etcd Versión: kubo-etcd Propiedades: [ ] stemcell: trusty - Nombre: master Instancias: 2 - Nombre: worker Instancias: 3

Manifiesto de implementación

de BOSH

CPI-AWS

BOSH A nombre de red vpc = alpha

etcd etcd master

vSphere

master worker worker worker

CPI-vSphere

nombre de grupo de puertos de vSphere = alpha

etcd etcd master

vSphere

master worker worker worker

BOSH B

Implementación deBOSH en ejecuciónmykubo-deployment

Implementación de BOSH en ejecuciónmykubo-deployment

Figura 4: Casos de uso de BOSH. Kubo

2. Operaciones posteriores: la gestión del ciclo de vida de BOSH facilita mantener en buen estado todas las implementaciones de Kubernetes.

– Mantener el estado: cada máquina virtual o instancia implementada por BOSH también implementa un agente que comunica el estado a BOSH. Si un nodo de Kubo no está en buen estado, BOSH probará a repararlo o regenerarlo automáticamente. Esto aumentará el tiempo de actividad.

– Aumentar el tiempo de actividad: cada tipo de instancia de trabajo de versión puede tener varias máquinas virtuales o instancias distribuidas en zonas de disponibilidad para garantizar que los servicios proporcionados no se vean afectados por los fallos físicos de una zona de disponibilidad determinada. Las zonas de disponibilidad solo se admiten en algunas CPI, como la CPI de vSphere, en la que las zonas de disponibilidad se corresponden con clústeres de vCenter.

– Aplicación de parches: como BOSH usa versiones con versiones, el operador puede actualizar la versión Kubo de Kubernetes y aplicársela fácilmente a todas las implementaciones en ejecución con una breve interrupción del servicio o ninguna en absoluto. BOSH actualizará cada implementación y mantendrá su estado de la siguiente manera: (1) desconectando los discos persistentes, (2) regenerando las máquinas virtuales o instancias afectadas y (3) reconectando los discos persistentes.

CPI-vSphere

BOSH

mykubo-deployment-2

worker 1

etcd 1

master 1

worker 2

etcd 2

Zona de disponibilidad 1 Zona de disponibilidad 2 Zona de disponibilidad 2

worker 0

master- haproxy

0

master 0

etcd 0 Age

nte

de B

OS

H

Equipo de desarrollo B

Desarrollador

mykubo-deployment-1

worker 1

etcd 1

master 1

worker 2

etcd 2

Zona de disponibilidad 1 Zona de disponibilidad 2 Zona de disponibilidad 3

worker 0

master- haproxy

0

master 0

etcd 0 Age

nte

de B

OS

H

Equipo de desarrollo A

Desarrollador

Supervisor de estado

Operador de plataforma

mykubo-deployment-2Equipo de desarrollo B

mykubo-deployment-1Equipo de desarrollo A

= persistent_disk

D O C U M E N TO T É C N I C O | 7

PRESENTACIÓN DE BOSH

Implementación de BOSHArquitectura de BOSH

BOSH se suele implementar como una sola máquina virtual o instancia. Esa máquina virtual o instancia tiene muchos componentes que desempeñan funciones esenciales para que BOSH pueda gestionar las implementaciones según las necesidades:

• NATS: proporciona un bus de mensaje a través del cual los distintos servicios de BOSH pueden interactuar.

• POSTGRESQL: BOSH escribe toda su información de estado en una base de datos. Generalmente, la base de datos es interna para una única implementación de BOSH de máquina virtual, y la proporciona Postgres. Sin embargo, esto se puede modificar para usar un origen de datos externo, de forma que la máquina virtual de BOSH pueda reconstruirse y volver a conectarse con la base de datos, para volver a cargar su estado persistente.

• BLOBSTORE: cada célula madre y versión cargada en BOSH se almacena en una blobstore. Las implementaciones predeterminadas de BOSH usan un almacén interno (webdav) pero, al igual que con la base de datos Postgresql, esto se puede externalizar.

• Director: la API principal con la que la CLI de BOSH interactuará para permitir que un operador cree y gestione implementaciones de BOSH.

• Supervisor de estado: BOSH requiere que cada máquina virtual que implementa tenga un agente con el que se pueda comunicar para asignar e implementar trabajos de versiones de BOSH que están definidos en un manifiesto de implementación. También mantendrá el estado de cada máquina virtual o instancia que haya implementado. El agente notificará los datos de estado a BOSH y, en caso de error en los servicios o la máquina virtual, o si no hay contacto con el agente, el supervisor de estado puede usar complementos para reiniciar servicios e incluso regenerar la máquina virtual o instancia.

• CPI: la CPI es un archivo binario ejecutable específico de IaaS que BOSH utiliza para interactuar con la IaaS especificada en su archivo YAML de implementación.

• UAA: proporciona acceso a usuarios y autenticación que permite a BOSH autenticar operadores a través de los back-end SAML o LDAP.

• CREDHUB: gestiona credenciales como contraseñas, certificados, entidades de certificación, claves SSH, claves RSA y valores arbitrarios (cadenas y blobs JSON). BOSH utilizará credhub para crear y almacenar credenciales de claves para implementaciones, como claves y certificados públicos.

D O C U M E N TO T É C N I C O | 8

PRESENTACIÓN DE BOSH

Figura 5: Arquitectura de BOSH

Referencias de BOSHEncontrará referencia completa sobre BOSH aquí: BOSH.io

BOSH

worker 1

etcd 1

master 1

worker 2

etcd 2

Zona de disponibilidad 1 Zona de disponibilidad 2 Zona de disponibilidad 3

worker 0

master- haproxy

0

master 0

etcd 0

Implementación de Kubo en vSphere

NATS

POSTGRESQL

BLOBSTSORE

DIRECTOR

SUPERVISOR DE ESTADO

CPI

UAA

CREDHUB

Agente de BOSH

Guía paso a paso: Cómo implementar «Kubo» en vSphereBOSH se implementa a través de la CLI de BOSH, pasando los argumentos de línea de comandos correctos o almacenándolos como datos de variables en archivos YAML adicionales para definir cómo se implementará BOSH. Esta sección de «guía paso a paso» resume los pasos necesarios para implementar BOSH, y ofrece orientación para una implementación básica de Kubo.

Entre los requisitos, se incluyen:

• vSphere vCenter 6.x

• 1 almacén de datos de vSphere con un espacio adecuado para la implementación

• 1 depósito de recursos de vCenter para la implementación de Kubo

Pasos para implementar BOSH (en Mac OSX): Las instrucciones de instalación específicas del sistema operativo para la CLI se documentan aquí.

Obtener BOSH CLI• En esta guía paso a paso se usa la versión 2 de la CLI de BOSH. Es un archivo binario

compilado de código Go, pero tiene algunas dependencias del sistema operativo.

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

Preparar los requisitos de MAC OS, como Ruby• Encontrará otras instrucciones específicas del SO aquí.

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

Usar el cliente de GIT para clonar el repositorio de implementación de BOSH• En esta guía paso a paso se supone que ya tiene el cliente de git instalado. Este repositorio

contiene todo lo que necesita para implementar una instancia de BOSH.

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

Implementar BOSH• El comando de CLI siguiente implementará la instancia de BOSH. Las marcas -o indican uno o

varios archivos YAML que se unen para formar un solo manifiesto. Las marcas -v indican las variables que asignamos a marcadores de variables en cada archivo YAML. El comando int (o «interpolate») de BOSH compone el manifiesto a partir del código auxiliar YAML y las 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]] \

D O C U M E N TO T É C N I C O | 9

PRESENTACIÓN DE 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

Pasos para implementar Kubo en BOSH Usar el cliente de GIT para clonar el repositorio de implementación de BOSH• En esta guía paso a paso se supone que ya tiene el cliente de git instalado. Este repositorio

contiene todo lo que necesita para implementar Kubo con la instancia de BOSH.

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

Generar el manifiesto cloud-config de BOSH y actualizarlo• Un manifiesto cloud-config es específico de cada CPI, y asignará las estructuras de BOSH

(como las zonas de disponibilidad) a las de vSphere. Un manifiesto de implementación hará referencia a estructuras del manifiesto 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

D O C U M E N TO T É C N I C O | 1 0

PRESENTACIÓN DE BOSH

Generar el manifiesto de implementación de 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

Cargar célula madre de BOSH más reciente

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

Cargar la versión de Kubo de 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

Implementar Kubo. :)

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

Encontrará la versión más reciente de este documento aquí.

Acerca de VMware VMware ofrece tecnologías de infraestructura que permiten a los desarrolladores y al departamento de TI crear, ejecutar y gestionar aplicaciones nativas de cloud para aumentar la agilidad empresarial, la seguridad y la eficiencia.

Visite www.vmware.com/es/solutions/cloudnative.html para obtener más información.

Enlace de Twitter: https://twitter.com/cloudnativeapps

Enlace del blog https://blogs.vmware.com/cloudnative/

D O C U M E N TO T É C N I C O | 1 1

PRESENTACIÓN DE BOSH

VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com C/ Rafael Botí, 26 - 2.ª planta, 28023 Madrid, España. Tel. +34 914125000 Fax +34 914125001 www.vmware.com/esCopyright © 2017-2018 VMware, Inc. Todos los derechos reservados. Este producto está protegido por las leyes de derechos de autor y de propiedad intelectual de Estados Unidos e internacionales. Los productos de VMware están cubiertos por una o varias de las patentes enumeradas en http://www.vmware.com/go/patents. VMware es una marca comercial o marca registrada de VMware Inc. en Estados Unidos o en otras jurisdicciones. Las demás marcas y nombres mencionados en este documento pueden ser marcas comerciales de sus respectivas empresas. N.º artículo: VMW_17Q3_WP_Introduction-to-BOSH_FINAL_080817 08/17