Airskiff を用いた Airship 1.7 のデプロイを試してみた

#はじめに
OpenStack のデプロイを自動的に実施するためのシステムは世の中に沢山ありますが、大きなクラスタを維持・管理するためには様々な Day 2 Operation を実施していく必要があるため、時間の経過とともに いわゆる Snow Flake Server になっていく問題が良く起こります。

問題への対応方法としては kolla-ansible のようなコンテナベースのデプロイシステムを使うことが挙げられますが、Airship を使えばライフサイクル管理の全てについて人間の作業を排除して機械に自動操縦させることができます。

Airship は OpenStack Fundation 傘下のプロジェクトになっており、主に AT&T がリーダーシップを取って開発が進められています。

本ドキュメントでは、開発者向けの Airship クラスタのデプロイツール (Airskiff) を用いて実際に OpenStack クラスタを構築してみることで、(私が)理解できた内容についてまとめていきます。

#Airship のアーキテクチャ
Airship は非常に沢山のコンポーネントにて構成されているため理解するのが大変ですが、ユーザ(Admin) の視点で見ると操作方法はシンプルです。
デプロイの大まかな流れとしては、Treasuremap と呼ばれるリポジトリで提供されているサイト設定例を参考に設定ドキュメント(yaml)を作成し、統合されたファイルを生成した上で commit するだけになります。

なお、Airship では設定ドキュメントが宣言的(Declarative)になっており、管理者が設定を commit すると、記載内容に従って差分を埋める形で変更が適用できます。
Declarative であることのメリットとしては、例えば git で管理された設定ドキュメントについて、どの revision についても、確実に正しくクラスタの設定を遷移させることができます。

- [Airship Treasuremap Documentation](https://airship-treasuremap.readthedocs.io/en/latest/#airship-treasuremap)

Airship の主要コンポーネントは、次のようになります。

- Shipyard
  - デプロイのワークフローを管理するためのツール
- Drydock
  - Baremetal サーバの管理ツール
- Deckhand
  - 設定ドキュメントの生成・保管ツール
- Armada
  - 複数の Helm chart を一元的にまとめてデプロイするためのツール
- Kubernetes (k8s)
  - Under-Cloud, Over-Cloud で稼働する各コンテナプロセスが稼働する場所
- Promenade
  - Kubernetes のデプロイツール
- Helm
  - k8s のパッケージマネージャ
- openstack-helm
  - OpenStack の Pod をデプロイするための Helm パッケージ集
- Divingbell
  - Baremetal サーバ用の、特定の設定を実施するためのツール

#デプロイ手順
実際に Airship のデプロイを実施して、各コンポーネントがどのように動作しているのかを確認していきます。
次のドキュメントを参考にして、Airskiff を用いて Airship のデプロイを実施します。

-[Airskiff: Lightweight Airship for Dev](https://airship-treasuremap.readthedocs.io/en/latest/airskiff.html)

##OSパッケージを最新版に更新
今回の検証では、Host OS に ubuntu18(bionic) を使用しました。

```bash
sudo apt update
sudo apt install -y python-pip
```

##treasuremap のダウンロード
はじめに、treasuremap のリポジトリをダウンロードします。
下記の例では tag の指定をしておりませんが、2019年1月の最新版 (v1.7相当) を使用しております。

```bash
git clone https://opendev.org/airship/treasuremap.git
cd treasuremap
```

##依存レポジトリのダウンロード
Airship のデプロイに必要な、依存パッケージのダウンロードを実施します。

```bash
./tools/deployment/airskiff/developer/000-clone-dependencies.sh
```

##minikueのデプロイ
Airskiff では k8s のインフラとして、minikube を使用します。
次のコマンドを実行すると、自動的に minikube のデプロイが完了します。

```bash
./tools/deployment/airskiff/developer/010-deploy-k8s.sh

# group の設定変更を反映させるために、再度サーバにログインします
# exit; ssh login
kubectl get nodes
cd treasuremap
```

##Openstack Client パッケージのインストール
次に、OpenStack Client のパッケージをインストールしておきます。
次のコマンドを実行すると、自動的に必要なパッケージが host OS 上にインストールされます。

```bash
./tools/deployment/airskiff/developer/020-setup-client.sh
```

##Airship 各種コンポーネントのデプロイ
次のコマンドを実行することで、Airship の各種コンポーネントのデプロイが実施されます。

```bash
./tools/deployment/airskiff/developer/030-armada-bootstrap.sh
```

##OpenStack のデプロイ
次に、overcloud 側の OpenStack についてデプロイを実施します。

私の環境ではデフォルト設定だと qemu の設定に問題があり nova の instance が起動できなかったので、次のように libvirt の設定を変更しました。

```bash
vi type/skiff/charts/osh/openstack-compute-kit/nova.yaml

----
diff --git a/type/skiff/charts/osh/openstack-compute-kit/nova.yaml b/type/skiff/charts/osh/openstack-compute-kit/nova.yaml
index 55e4522..e791765 100644
--- a/type/skiff/charts/osh/openstack-compute-kit/nova.yaml
+++ b/type/skiff/charts/osh/openstack-compute-kit/nova.yaml
@@ -38,6 +38,7 @@ data:
       nova:
         libvirt:
           virt_type: qemu
+          cpu_mode: none
     pod:
       replicas:
         api_metadata: 1
----
```

次のコマンドを実行すると、OpenStack (overcloud) クラスタのデプロイが実施されます。

```bash
./tools/deployment/airskiff/developer/100-deploy-osh.sh
```

上記コマンドを実行すると、次のような出力が得られます。

```bash
./tools/deployment/airskiff/developer/100-deploy-osh.sh
+ : ./tools/airship
+ : './tools/airship pegleg'
+ : './tools/airship shipyard'
+ : airskiff
+ . tools/deployment/airskiff/common/os-env.sh
+++ grep -m 1 project_domain_name /etc/openstack/clouds.yaml
+++ cut -d \' -f 2
++ export OS_PROJECT_DOMAIN_NAME=default
++ OS_PROJECT_DOMAIN_NAME=default
+++ grep -m 1 user_domain_name /etc/openstack/clouds.yaml
+++ cut -d \' -f 2
++ export OS_USER_DOMAIN_NAME=default
++ OS_USER_DOMAIN_NAME=default
+++ grep -m 1 project_name /etc/openstack/clouds.yaml
+++ cut -d \' -f 2
++ export OS_PROJECT_NAME=admin
++ OS_PROJECT_NAME=admin
+++ grep -m 1 username /etc/openstack/clouds.yaml
+++ cut -d \' -f 2
++ export OS_USERNAME=admin
++ OS_USERNAME=admin
+++ grep -m 1 password /etc/openstack/clouds.yaml
+++ cut -d \' -f 2
++ export OS_PASSWORD=password123
++ OS_PASSWORD=password123
+++ grep -m 1 auth_url /etc/openstack/clouds.yaml
+++ cut -d \' -f 2
++ export OS_AUTH_URL=http://keystone-api.ucp.svc.cluster.local:5000/v3
++ OS_AUTH_URL=http://keystone-api.ucp.svc.cluster.local:5000/v3
+ ./tools/airship pegleg site -r . lint airskiff -x P001 -x P009
+ : peggles
+ mkdir -p peggles
+ TERM_OPTS='-l info'
+ ./tools/airship pegleg site -r . collect airskiff -s peggles
+ ./tools/airship shipyard create configdocs airskiff-design --replace --directory=peggles
Unable to find image 'quay.io/airshipit/shipyard:72ca47e5c9ae8b7b1dcccd7742be6499f0411650-ubuntu_xenial' locally
72ca47e5c9ae8b7b1dcccd7742be6499f0411650-ubuntu_xenial: Pulling from airshipit/shipyard
e80174c8b43b: Already exists
d1072db285cc: Already exists
858453671e67: Already exists
3d07b1124f98: Already exists
9546e3da564e: Already exists
726a803d4fb9: Already exists
715f0d303278: Already exists
1b3529dec8d8: Already exists
62db00689dc5: Already exists
0e030d0c79cf: Already exists
4089ea48533c: Already exists
bb126cc76c84: Already exists
b40abecbfc2b: Already exists
Digest: sha256:517f81a43f3cda652cf1df898bf858230d1718131637bcd94dd4531ceae8c0c7
Status: Downloaded newer image for quay.io/airshipit/shipyard:72ca47e5c9ae8b7b1dcccd7742be6499f0411650-ubuntu_xenial
Configuration documents added.
Status: Validations succeeded
Reason: Validation

####  Errors: 0, Warnings: 0, Infos: 0, Other: 0  ####
+ ./tools/airship shipyard commit configdocs
Configuration documents committed.
Status: Validations succeeded
Reason: Validation
- Info: DeploymentStrategyNotSpecified
        Message: A deployment strategy document was not specified in the deployment configuration. Because of this, the strategy used will be all-at-once.
        Diagnostic: Message generated by Shipyard.
        Document: shipyard/DeploymentConfiguration/v1 - deployment-configuration

####  Errors: 0, Warnings: 0, Infos: 1, Other: 0  ####
+ ./tools/airship shipyard create action update_software --allow-intermediate-commits
Name                   Action                                   Lifecycle        Execution Time             Step Succ/Fail/Oth        Footnotes
update_software        action/01DYPHTBZQ2E3XNG9D2AN7AT00        None             2020-01-16T00:00:01        0/0/0
```
OpenStack クラスタのデプロイ状況を確認するには、次のように 'shipyard get actions' コマンドを実行します。

```bash
./tools/airship shipyard get actions
Name                   Action                                   Lifecycle         Execution Time             Step Succ/Fail/Oth        Footnotes
update_software        action/01DYPHTBZQ2E3XNG9D2AN7AT00        Processing        2020-01-16T00:00:01        8/0/8                     (1)

Action Footnotes        Note
(1)                     > action metadata:01DYPHTBZQ2E3XNG9D2AN7AT00(2020-01-16 00:01:02.239545+00:00): Configdoc revision 1
```

1-2時間程度待つとデプロイワークフローが完了します。action に含まれている各 step の実行結果を確認する場合は、次のように 'shipyard describe action/...' コマンドを実行します。

```bash
./tools/airship shipyard describe action/01DYPHTBZQ2E3XNG9D2AN7AT00
Name:                  update_software
Action:                action/01DYPHTBZQ2E3XNG9D2AN7AT00
Lifecycle:             Complete
Parameters:            {}
Datetime:              2020-01-16 00:01:02.824431+00:00
Dag Status:            success
Context Marker:        a062329c-09e2-4918-8a36-4995efa8a1d3
User:                  admin

Steps                                                                Index        State                  Footnotes
step/01DYPHTBZQ2E3XNG9D2AN7AT00/dag_concurrency_check                1            success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/action_xcom                          2            success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/deployment_configuration             3            success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/validate_site_design                 4            success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/armada_build                         5            failed
step/01DYPHTBZQ2E3XNG9D2AN7AT00/decide_airflow_upgrade               6            upstream_failed
step/01DYPHTBZQ2E3XNG9D2AN7AT00/armada_get_status                    7            success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/upgrade_airflow                      8            upstream_failed
step/01DYPHTBZQ2E3XNG9D2AN7AT00/skip_upgrade_airflow                 9            upstream_failed
step/01DYPHTBZQ2E3XNG9D2AN7AT00/armada_post_apply                    10           failed
step/01DYPHTBZQ2E3XNG9D2AN7AT00/create_action_tag                    11           success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/deployment_status                    12           success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/deckhand_validate_site_design        13           success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/armada_validate_site_design          14           success
step/01DYPHTBZQ2E3XNG9D2AN7AT00/armada_get_releases                  15           upstream_failed
step/01DYPHTBZQ2E3XNG9D2AN7AT00/final_deployment_status              16           success



Commands        User         Datetime
invoke          admin        2020-01-16 00:01:30.283434+00:00

Validations: None

Action Notes:
> action metadata:01DYPHTBZQ2E3XNG9D2AN7AT00(2020-01-16 00:01:02.239545+00:00): Configdoc revision 1
```

#Under Cloud Platform (UCP) の動作テスト
前記の作業で OpenStack のデプロイについては完了しました。引き続いて、Under cloud (UCP) の稼働状況を確認していきます。
UCP についても overcloud と同様に OpenStack のコンポーネント(keystone, barbican)が使用されているので、環境変数(OS_CLOUD) を変更することで overcloud / ucp を切り替えることができます。

```bash
export OS_CLOUD=airship
openstack endpoint list
```

ucp では、次のコンポーネントが稼働しています。

```bash
$ openstack endpoint list
+----------------------------------+-----------+--------------+--------------+---------+-----------+---------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                                                     |
+----------------------------------+-----------+--------------+--------------+---------+-----------+---------------------------------------------------------+
| 0a499766d9c448999b965882a4ba5d75 | RegionOne | armada       | armada       | True    | internal  | http://armada-api.ucp.svc.cluster.local:8000/api/v1.0   |
| 1baee8dd9db842a197ffe736a6f06a8d | RegionOne | shipyard     | shipyard     | True    | internal  | http://shipyard-int.ucp.svc.cluster.local:9000/api/v1.0 |
| 1ebfeda7bf6045a9b0418cba07c866b7 | RegionOne | barbican     | key-manager  | True    | internal  | http://barbican-api.ucp.svc.cluster.local:9311/v1       |
| 1f1d9ec9c15d4fb194b9710fb645852a | RegionOne | deckhand     | deckhand     | True    | admin     | http://deckhand-int.ucp.svc.cluster.local:9000/api/v1.0 |
| 2d451bd360464b7f8f20dc508a710394 | RegionOne | deckhand     | deckhand     | True    | public    | http://deckhand-api.ucp.svc.cluster.local/api/v1.0      |
| 31350fa47e764a91a2474b4047f9b617 | RegionOne | keystone     | identity     | True    | internal  | http://keystone-api.ucp.svc.cluster.local:5000/v3       |
| 3b936e8e8cc8490da184282da3f26c4a | RegionOne | keystone     | identity     | True    | public    | http://keystone.ucp.svc.cluster.local/v3                |
| 416d52135d194b7f874f5c7354db3947 | RegionOne | keystone     | identity     | True    | admin     | http://keystone.ucp.svc.cluster.local/v3                |
| 4d06858dbc59429fa8e6c1bb9406a749 | RegionOne | barbican     | key-manager  | True    | public    | http://barbican.ucp.svc.cluster.local/v1                |
| 511701f7f3a34fa6b7c5cd743ef17ae2 | RegionOne | shipyard     | shipyard     | True    | public    | http://shipyard-api.ucp.svc.cluster.local/api/v1.0      |
| 756171e845ae4b12bc2e58c1ebd476ea | RegionOne | deckhand     | deckhand     | True    | internal  | http://deckhand-int.ucp.svc.cluster.local:9000/api/v1.0 |
| 853b488454024650b0a4208a88da1a5e | RegionOne | armada       | armada       | True    | admin     | http://armada-api.ucp.svc.cluster.local:8000/api/v1.0   |
| acccaaa0f7f8474d950aa2ea95fb7be0 | RegionOne | shipyard     | shipyard     | True    | admin     | http://shipyard-int.ucp.svc.cluster.local:9000/api/v1.0 |
| c528f19a6de945d086494ae013caf94b | RegionOne | barbican     | key-manager  | True    | admin     | http://barbican-api.ucp.svc.cluster.local:9311/v1       |
| d3d1228ded854c1eaa37cdf0ee578d92 | RegionOne | armada       | armada       | True    | public    | http://armada.ucp.svc.cluster.local:8000/api/v1.0       |
+----------------------------------+-----------+--------------+--------------+---------+-----------+---------------------------------------------------------+
```

#OpenStack(overcloud) の動作テスト
続いて、overcloud側の稼働状況を確認します。環境変数(OS_CLOUD) を 'openstack' に変更した上で、openstack cli の各種コマンドを実行します。

```bash
export OS_CLOUD=openstack
openstack endpoint list
openstack image list
openstack token issue
```

overcloud では、次のコンポーネントが稼働しています。

```bash
$ openstack endpoint list
+----------------------------------+-----------+--------------+--------------+---------+-----------+---------------------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                                                                 |
+----------------------------------+-----------+--------------+--------------+---------+-----------+---------------------------------------------------------------------+
| 016af849da8e4904b4f5025a3a3aa813 | RegionOne | glance       | image        | True    | public    | http://glance.openstack.svc.cluster.local/                          |
| 0bbdfe2755134b0fb34a4f08d86c525c | RegionOne | nova         | compute      | True    | admin     | http://nova-api.openstack.svc.cluster.local:8774/v2.1/%(tenant_id)s |
| 10c7b5a640d14d80ac043e6eed3be643 | RegionOne | keystone     | identity     | True    | public    | http://keystone.openstack.svc.cluster.local/v3                      |
| 2df81fe57e21487892960fb6d12ebc58 | RegionOne | placement    | placement    | True    | public    | http://placement.openstack.svc.cluster.local/                       |
| 4cf60570d8cc45948c6c0d6d14c25fab | RegionOne | keystone     | identity     | True    | internal  | http://keystone-api.openstack.svc.cluster.local:5000/v3             |
| 866a177317244dc882666983fa99f763 | RegionOne | neutron      | network      | True    | admin     | http://neutron-server.openstack.svc.cluster.local:9696/             |
| 86f0af974f7f4ba1b4c562b2a8d90d6c | RegionOne | placement    | placement    | True    | admin     | http://placement-api.openstack.svc.cluster.local:8778/              |
| ad5d2a13881640d18163e48c44c8a67b | RegionOne | glance       | image        | True    | admin     | http://glance-api.openstack.svc.cluster.local:9292/                 |
| aee6d5a65bbd474eb403b25a2f2e3750 | RegionOne | neutron      | network      | True    | public    | http://neutron.openstack.svc.cluster.local/                         |
| b8c3611408dc47379cbf5c2349be5f8d | RegionOne | glance       | image        | True    | internal  | http://glance-api.openstack.svc.cluster.local:9292/                 |
| c44088634a504b13bc95fad231f5941b | RegionOne | nova         | compute      | True    | internal  | http://nova-api.openstack.svc.cluster.local:8774/v2.1/%(tenant_id)s |
| d350d53374674e74bf0355c515d7596c | RegionOne | neutron      | network      | True    | internal  | http://neutron-server.openstack.svc.cluster.local:9696/             |
| d92744936a2d4ff4bba643a3f19ff624 | RegionOne | keystone     | identity     | True    | admin     | http://keystone.openstack.svc.cluster.local/v3                      |
| debced5dc02d409383cbffc61ead7068 | RegionOne | nova         | compute      | True    | public    | http://nova.openstack.svc.cluster.local/v2.1/%(tenant_id)s          |
| f8419a39b83748f1a06c2d781923f7ad | RegionOne | placement    | placement    | True    | internal  | http://placement-api.openstack.svc.cluster.local:8778/              |
+----------------------------------+-----------+--------------+--------------+---------+-----------+---------------------------------------------------------------------+

# 初期に登録されているイメージはありません
$ openstack image list

# 問題なく keystone token を取得できました
$ openstack token issue
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field      | Value                                                                                                                                                                                   |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| expires    | 2020-01-16T20:12:30+0000                                                                                                                                                                |
| id         | gAAAAABeIBruPEObrS0aMOmU6pQYqD7nCOmrfhxyDW0tE3EJ4Nvjz8yOAKG8IGammbfxRHzR80MRGG7oprtknmz5hYuAxzsg0EG2TSPqmXbdjAvKDO_ZH4pIjY2N7H6x8tCDfwI2P1_g-XQ6iysG-Ug4LcMSmTSGsIIasKhjfasR7JGc6p-FgDQ |
| project_id | 805b7df0c6e64210919b215bf79d744c                                                                                                                                                        |
| user_id    | cd73162d330b4fb1967fa65dd75da2c7                                                                                                                                                        |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
```

## Day-2 Operation の実施方法
例えば運用を開始した後に Nova の設定を変更したくなった場合など、OpenStack クラスタの設定を変更する必要が出た場合の作業方法についてまとめます。
作業手順自体はとても簡単で、設定ドキュメントを修正した上で "commit configdocs" -> "create action update_software" を実行するだけになります。

例えば、virt_type を kvm に変更するような場合であれば、openstack-helm chart の設定を変更した上で、shipyard コマンドを実行します。

```bash
# nova の設定を変更します
vi type/skiff/charts/osh/openstack-compute-kit/nova.yaml

----
diff --git a/type/skiff/charts/osh/openstack-compute-kit/nova.yaml b/type/skiff/charts/osh/openstack-compute-kit/nova.yaml
index 55e4522..e791765 100644
--- a/type/skiff/charts/osh/openstack-compute-kit/nova.yaml
+++ b/type/skiff/charts/osh/openstack-compute-kit/nova.yaml
@@ -38,6 +38,7 @@ data:
       nova:
         libvirt:
+          virt_type: kvm
     pod:
       replicas:
         api_metadata: 1
----

# pegleg コマンドを実行して、Armada で適用するための yaml ファイルを生成します
mkdir peggles_2
TERM_OPTS="-l info" ./tools/airship pegleg site -r . collect airskiff -s peggles_2

# pegleg コマンドにて生成された yaml ファイルを、deckhand のリポジトリに登録します
./tools/airship shipyard create configdocs airskiff-design --replace --directory=peggles_2

# コンフィグドキュメントの変更内容を commit コマンドにて確定させます
./tools/airship shipyard commit configdocs

# update_software actionを作成することで、commit 済みの設定がクラスタに適用されます
./tools/airship shipyard create action update_software --allow-intermediate-commits
```

#Nova 動作テスト
最後に、nova の動作テストを実施します。
下記のようなコマンド系列を実行して、実際にインスタンスに ssh login ができることを確認します。

```bash
IMAGE=cirros-0.4.0-x86_64-disk.img
curl -L -o ${IMAGE} http://download.cirros-cloud.net/0.4.0/${IMAGE}
openstack image create --disk-format qcow2 --container-format bare --public --property os_type=linux --file ${IMAGE} cirros
openstack network create demo-net
openstack subnet create --subnet-range 10.0.0.0/24 --network demo-net --gateway 10.0.0.1 --dns-nameserver 8.8.8.8 demo-subnet
openstack router create demo-router
openstack router add subnet demo-router demo-subnet

sudo apt-get install -y jq
openstack security group list -f json | jq -r '.[].ID' | xargs -I {} openstack security group rule create {} --protocol tcp --ingress --dst-port 22
openstack security group list -f json | jq -r '.[].ID' | xargs -I {} openstack security group rule create {} --protocol icmp

openstack keypair create --public-key ~/.ssh/id_rsa.pub demo-key

openstack server create  --flavor m1.tiny --key-name demo-key --image cirros --network demo-net test01
```

#Airship の中身を覗いてみる
Airship の中身を知りたいのであれば実際に稼働状況を確認してみるのが一番手っ取り早い、ということで k8s から見た UCP の稼働状況を確認しました。

UCP では、postgresql, mariadb, rabbitmq が稼働しており、Persistent Volume まで使っているので ウルトラヘビー級ボクサーのように重いシステムであることが伺えます。

Airskiff では Baremetal サーバの管理が不要なため Drydock は稼働しておりません。また、Airskiff では pv provisioner として nfs が使用されているため、UCP 側では Ceph クラスタが稼働しておりません。

このため、実際のプロダクション環境でフル装備の Airship を運用するとなると、 UCP の運用管理だけでお腹がいっぱいになりそうな予感がします。

```bash
# Airship の各コンポーネントは API を持っているため、裏方システムにもかかわらず常にリソースを消費します
# RDBMS だけでも mysql と postgresql の 2つが稼働しているのが辛い..
$ kubectl -n ucp get pod -o wide | grep Running
airflow-scheduler-7c55fd5b47-bgfgf                         1/1     Running     0          8d      192.168.0.28   minikube   <none>           <none>
airflow-worker-0                                           3/3     Running     0          8d      192.168.0.38   minikube   <none>           <none>
airship-ucp-keystone-memcached-memcached-66cf59785-bf24v   1/1     Running     0          8d      192.168.0.17   minikube   <none>           <none>
airship-ucp-rabbitmq-rabbitmq-0                            1/1     Running     0          8d      192.168.0.12   minikube   <none>           <none>
airship-ucp-rabbitmq-rabbitmq-exporter-785b846d5b-jjdzb    1/1     Running     0          8d      192.168.0.10   minikube   <none>           <none>
armada-api-764db66f78-5bgvb                                2/2     Running     0          8d      192.168.0.41   minikube   <none>           <none>
barbican-api-679d54fcdb-6lc4x                              1/1     Running     0          8d      192.168.0.54   minikube   <none>           <none>
deckhand-api-7fd4649b78-vthk4                              1/1     Running     0          8d      192.168.0.46   minikube   <none>           <none>
ingress-76b5cd44f6-zmkgh                                   1/1     Running     0          8d      192.168.0.7    minikube   <none>           <none>
ingress-error-pages-7565db89f4-tpbql                       1/1     Running     0          8d      192.168.0.6    minikube   <none>           <none>
keystone-api-77f49f69df-rxsf6                              1/1     Running     2          8d      192.168.0.20   minikube   <none>           <none>
mariadb-ingress-error-pages-69c8db547d-9fx4n               1/1     Running     0          8d      192.168.0.8    minikube   <none>           <none>
mariadb-ingress-fcc5cff54-k56wv                            1/1     Running     0          8d      192.168.0.11   minikube   <none>           <none>
mariadb-server-0                                           1/1     Running     0          8d      192.168.0.13   minikube   <none>           <none>
postgresql-0                                               1/1     Running     0          8d      192.168.0.14   minikube   <none>           <none>
shipyard-api-68dc886ccf-6l4v7                              2/2     Running     1          8d      192.168.0.29   minikube   <none>           <none>

#UCPでも persistent volume が必要なため、プロダクション環境であれば controler node でも専用の Ceph クラスタを稼働させる必要があります (容量について小さくて大丈夫です)
$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                           STORAGECLASS   REASON   AGE
pvc-606c4fc0-382f-11ea-8e10-fa163e849846   2Gi        RWO            Delete           Bound    openstack/glance-images                                         general                 8d
pvc-6cce377f-382e-11ea-8e10-fa163e849846   256Mi      RWO            Delete           Bound    openstack/rabbitmq-data-airship-openstack-rabbitmq-rabbitmq-0   general                 8d
pvc-cc9c075e-382c-11ea-8e10-fa163e849846   5Gi        RWO            Delete           Bound    openstack/mysql-data-mariadb-server-0                           general                 8d
pvc-f560feda-3825-11ea-8e10-fa163e849846   256Mi      RWO            Delete           Bound    ucp/rabbitmq-data-airship-ucp-rabbitmq-rabbitmq-0               general                 8d
pvc-f5deb23e-3825-11ea-8e10-fa163e849846   5Gi        RWO            Delete           Bound    ucp/mysql-data-mariadb-server-0                                 general                 8d
pvc-f7fcfcc9-3825-11ea-8e10-fa163e849846   5Gi        RWO            Delete           Bound    ucp/postgresql-data-postgresql-0                                general                 8d
pvc-feef561a-3828-11ea-8e10-fa163e849846   5Gi        RWO            Delete           Bound    ucp/airflow-logs-airflow-worker-0                               general                 8d

# 最も負荷の小さいシングル構成にもかかわらず、Load が 13 まで達してます
$ uptime
07:22:35 up 8 days,  2:44,  1 user,  load average: 13.86, 10.22, 10.01

# 検証環境は、8-vCPU 構成になります
$ lscpu | head
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              8
On-line CPU(s) list: 0-7
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           8
NUMA node(s):        1
Vendor ID:           GenuineIntel

# メモリの消費量については、16GB あれば大丈夫そうです
$ free -m
             total        used        free      shared  buff/cache   available
Mem:          16039        9536         529         789        5974        5413
Swap:             0           0           0
```

#さいごに - Airship2.0に向けて
今回の Airship 検証では、Airskiff の稼働状況を軽く覗いてみましたが、正直なところあまりにもヘビーすぎるため、プロダクション環境でも使いたい気持ちが1ビットも湧きませんでした :p

実際のところ Open Design Summit の発表内容を見る限りでは、SK Telecom での Airship の使われ方は Armada のみを選択的に使用している、とのことだったので現実的な使い方をされているように見受けられます。
ただし、公式 blog を読んだ限りでは、Airship がウルトラヘビー級なことが課題である点については開発コミュニティでもキッチリと認識されている模様で、次期メジャーリリースの Airship 2.0 では UCP の軽量化が一気に進みそうです。

- [Airship Blog Series 1 - Evolution Towards 2.0](https://www.airshipit.org/blog/airship-blog-series-1-evolution-towards-2.0.html)
- [Airship Blog Series 2 - An Educated Evolution](https://www.airshipit.org/blog/airship-blog-series-2-an-educated-evolution.html)
- [Airship Blog Series 3 - Airship 2.0 Architecture High Level](https://www.airshipit.org/blog/airship-blog-series-3-airship-2.0-architecture-high-level.html)
- [Airship Blog Series 4 - Shipyard - an Evolution of the Front Door](https://www.airshipit.org/blog/airship-blog-series-4-shipyard-an-evolution-of-the-front-door.html)
- [Airship Blog Series 5 - Drydock and Its Relationship to Cluster API](https://www.airshipit.org/blog/airship-blog-series-5-drydock-and-its-relationship-to-cluster-api.html)

MaaS の代わりに cluster-api + metal.io が使えるようになったり、airflow が Argo workflow に置き換えられたりと、2.0 では仕様自体が大きく変わるみたいですが、とても現実的な進化を遂げることが期待できそうです。