Bosh のアーキテクチャについて

まずは、DRY にしたがって、ozzozz さんの BOSH 101 winter 2018 - Speaker Deck に全体的な構成の説明をお任せするとして、自分なりのまとめをここでは記載します。

Bosh の目的

Bosh は、「個人やチームが開発したソフトウェアのバージョニング、パッケージング、デプロイを 簡単に かつ べき等性（いつでも、何度でも）を保って 行える」構成管理システムです。

ここでのポイントは、

冪等性があること
簡単であること

です。デプロイの冪等性については、chef, ansible でも言われていることで、そもそもこれが保たれないのは、構成管理システムの役目を果たしていないでしょう。

そのため、1. は前提条件として、重要なのは 2. です。パッケージ管理やデプロイなど、その管理が面倒なシステムはエンジニアから使われない → 頻繁にデプロイされない → どんどん古くなるようになります。よって、2. は実は構成管理システムにおいて、非常に重要な要素なのです。

デプロイって面倒で難しい

Release engineering という言葉があるように、ソフトウェアのデプロイは多くの場合、事故や問題の元となるくらいに難しいです。実際にソフトウェアを誰かに提供しているエンジニアでは頷かれると思いますが、

メンテナンス時間を設けて、その間に切り替える
問題があったら、手順書に従って順番にコンポーネントをロールバックする

など、リリースに関わる問題は枚挙にいとまがありません。Release Engineering そして Bosh では下記の項目を満たすように設計がされているます。

Identifiability: 一意性。あるリリースを構成するソースコード、環境、ツールが一意に特定できること（多くの場合は deployment manifest や config という形で記述する）
Reproducibility: 再現性。なんどでも、いつでもデプロイして同じ設定や環境が再現できること
Consistency: 一貫性。開発、デプロイ、監視、リリースにて何が起こっているかが把握できること
Agility: 俊敏性（Wikipedia での説明が理解できず省略。言葉の意味から察すると、すばやく簡単にデプロイできること）

まとめると 「簡単に、すばやく、外部に影響されない形で、再現性を保ってデプロイでき、デプロイし終えるまでの状態をトラッキングできること」 が Release Engineering の肝となります。

個人的には、 Release Engineering はビジネスと直結する重要な分野 と思っており、うまくいえば「早く修正し、新しい機能で更新、セキュア」なサービスができますが、下手すると「修正が遅く、機能は古く、更新ができず、脆弱性を突かれる」ことになりかねません。

そう考えると、最近のコンテナ技術の流行りというのは、ビジネス的な合理性も相まってこれほど普及しているのかもしれません。

Bosh で重要なコンポーネント

では、Bosh のアーキテクチャについて、記載していきます。

まず、Bosh とアプリケーション、IaaS の大雑把な関係は、下記の図のようになります。

Bosh が基本的にやることは、

IaaS の API を通じて、VM を作成する (API が提供されていれば、OpenStack でも GCP, AWS, Azure でも大丈夫です)
VM 上にアプリケーションをデプロイする

ということです。しかし、上記の Release Engineering で必要とされることを実現するためには、様々なコンポーネントが連結しあっています。 Bosh の中の詳細の図は下記のようになります。

Bosh における重要なコンポーネントをアプリケーションに近い順で並べると以下のようになります。

Release (bosh release とよく言われます)
Deployment Manifest
bosh-agent
Stemcell
Director
Blobstore
Health Monitor
NATS
CPI

上から順番に説明していきます。

アプリケーションに近いコンポーネント

Release, Deployment Manifest, bosh-agent, Stemcell

Release

Release とはアプリケーションのソースコード、設定、必要なライブラリが同梱された集合体で、Bosh でデプロイできる形に作られたものです。bosh release と言われたりします。

Release を作成するための方法については、Creating a Release - Cloud Foundry BOSH に任せますが、要は Bosh が作成した VM 上で動作させるアプリケーションと設定 という感じです。

Release を作成するときの注意点は、アプリケーションが利用するために必要なもの（バイナリを含め）が原則すべてまとめられている必要があるということです。

なぜかといえば、Release Engineering の Reproducibility を守るためです。つまり、インターネットアクセスがない状態であっても、Release 内で依存が閉じていれば、いついかなるときもアプリケーションがデプロイできるからです。

具体例

Deployment Manifest

Release に同梱する設定はどんな環境でも利用されるものです。でなければ、特定の環境でしか動かない Release ができてしまいます。

では、環境に関係する設定、例えば DB の URL、パスワード、DNS の向き先、などなどはどう設定するのでしょうか？

それを定義するのが、Deployment Manifest です。

Bosh は開発者からアップロードされた Release と、それをデプロイするための環境情報である Deployment Manifest を組み合わせて、アプリケーションを稼働させます。（細かい話をすると、例えば Release で使う DB の VM数を 3 台としたり、ローリングアップデートの設定をしたり、デプロイに関係する設定も Deployment Manifest で行います）

具体例

GitHub - concourse/concourse-bosh-deployment: A toolchain for deploying Concourse with BOSH.

bosh-agent

さて、Bosh で作成された VM には、Release という形でまとめられたアプリケーションが、Deployment Manifest という環境設定情報を読み込んで動作するということがここまでわかりました。

ここで、「Release はどのように VM にインストールされて、どうやってアプリケーションが起動するの？」と思われたかもしれません。

参考

Stemcell

TBD

What is a Stemcell? - Cloud Foundry BOSH

Bosh 固有なもの

Director, Blobstore, Health Monitor, NATS

Director

Bosh のコントローラといえる重要なコンポーネントで、bosh コマンドから送信される様々なコマンドの API となります。

参考

BOSH - The Components - YouTube

Blobstore

Release の定義されたバイナリファイル。

Health Monitor

TBD

NATS

IaaS に近いコンポーネント

CPI

TBD

Bosh のアーキテクチャについて

Bosh の仕組み