BOSH CLI 部署流程

0x00 Intro

本文档翻译的内容来自官方文档 描述BOSH Client部署环境的流程,包括安装CPI、创建VM、创建disk、挂载disk等操作。

  • 0x01. 验证配置文件manifest、版本发布release和镜像stemcell
    部署流程的第一步就是验证。CLI首先将检查manifestreleasestemcell是否有变化。如果文件没有变化,CLI检查之后即会退出并发出Skipping deploy消息。
    随后,CLI会验证manifest中的属性(properties)并解析部署的配置信息。CLI会将配置文件解析成两部分:部署配置信息(deployment manifest)和CPI配置信息(CPI config)。
    部署配置信息被用在一个单独的VM中的任意releases上。一个release是一个版本集合,包括配置属性、模板、启动脚本、源码和其他一切能够保证可以以可重复(reproducible)的方式构建(build)和部署(deploy)上层应用的内容。由于面前CLI只创建了一个VM,上面只能指定一个release job。
    CPI配置信息被用来本地安装和配置CPI。在manifest中的cloud_provider部分来指定。

    在BOSH CLI v2中,部署配置信息manifest被定义如下加个部分:

    • Deployment Identification: 包含部署的名称和uuid。
    • Releases Block: 部署中每个release的名称和版本。
    • Stemcells Block: 部署中每个stemcell的名称和版本。
    • Update Block: 定义BOSH更新实例时行为
    • Instance Groups Block: 指定jobs和instance groups的映射关系。
    • Properties Block: 描述全局属性。
    • Variables Block: 变量的配置(比如creds)。
    • Tags Block: key-value形式的标签。

    以前IaaS相关的配置信息(比如网络,磁盘类型)被独立称为cloud-config的配置信息。在我们将这些配置信息生成为一个YAML文件后就可以使用bosh deploy命令来部署应用。验证配置文件步骤就在这里进行。BOSH CLI会显性将配置更新的部分提示给用户(如下图)。

    bosh_deploy

  • 0x02. 安装CPI Release
    CPI Release直接在BOSH CLI的机器上编译,因为BOSH CLI需要在本地运行CPI命令与IaS层交互。
    CPI release必须包含cloud_provider.template.job。在CPI安装期间,CPI job相关的packages都将被编译,其templates都会被渲染。CPI job templates获取相关的属性值,这些属性值在manifest的cloud_provider -> properties部分。
    这些packages和templates存放在~/.bosh/<installation_id>目录下。

  • 0x03. 上传Stemcell
    在CPI本地安装后,CLI会调用CPI方法create_stemcellstemcellmanifest指定。

  • 0x04. 启动Registry
    在创建VM前,CLI会先启动RegistryRegistry被CPI用来存储易变数据,这些数据之后会被运行在VM上的Agent使用。所以Registry是用来存储可变数据的服务,而基础架构元数据服务(infrastructure's metadata service)存储不变的数据。直到CPI创建完VM,这些数据是预先不可知的。例如,在BOSH VM创建之后,Agent需要从Registry获得挂载持久化硬盘的信息数据。
    CPI会在基础架构元数据服务存储Registry的URL。部署在VM上的Agent会从URL中获取registry配置信息。

  • 0x05. 删除已存在的VM
    如果VM已经部署过,CLI会尝试与VM上Agent建立连接。如果。我们可以在create-env通过option:--state director-state.json获得相关状态信息。如果其上的Agent有响应,CLI会停止VM上的服务,并卸载硬盘。最终,CLI会删除VM并更新部署的状态信息(删除VM CID)。

  • 0x06. 创建新VM
    接下来,CLI会发送create_vm的命令给CPI。此外,VM CID被记录在状态信息文件。

  • 0x07. 启动SSH tunnel
    CLI创建一个与VM反向SSH tunnel。tunnel的信息也由manifest提供。Tunnel帮助VM上的Agent获取Registry

  • 0x08. 等待Agent
    一旦SSH tunnel启动,CLI会使用提供的mbus URL向VM上的Agent发出ping请求。一旦Agent准备好,就会响应ping请求。

  • 0x09. 创建硬盘
    CLIL接着给VM创建和挂载硬盘。这些信息也由manifest文件提供。这里有两种方法指定硬盘。一种是添加persistent_disk_pool属性,一种是添加persistent_disk属性。如果manifest上有这些信息,CLI会向CPI调用create_disk方法。成功后,disk CID会记录在状态文件中。

  • 0x10. 挂载硬盘
    成功创建硬盘后,CLI会调用CPIattach_disk方法。当硬盘成功挂载后,CLI会向Agent发出mount_disk请求。

  • 0x11. 发送stop信息
    一旦Agent成功监听mbus URL,CLI会向Agent发送stop信息。Agent会使用monit命令来管理VM上的jobs。暂停的目的是为了更新jobs数据。

  • 0x12. 发送apply信息
    接着CLI会发送apply信息,并随之发送需要安装到VM上的packagesjobsAgent会在<mbus URL>/blobs端点(endpoint)提供二进制文件(blobstore)。
    由每个job模板(templates)所指定,CLI从blobstore下载相应的job模板,并从manifest中获得响应的属性并渲染模板。一旦所有的模板都被渲染,CLI会将所有模板的archive上传到blobstore。apply信息包含这些packages,release job中spec文件(指定模板属性),manifest指定的网络配置信息和作为job模板文件摘要(digest)的hash值。

  • 0x13. 发送start信息
    一旦apply任务(task)完成,CLI会向Agent发送start信息。Agent收到后会开始执行安装好的jobs

本文简介BOSH部署的工作流程,接下来会依据BOSH log和CPI的log进一步介绍部署的交互流程。