お久しぶりです。森 (@mosuke5) です。
最近、韓国・中国と行く予定があり、世界のおもしろ体験をいろいろしてきました。
中でも中国の未来コンセプトのホテル(Flyzoo)やスーパーマーケット(Hema)などなど。こちらは話すと長くなってしまうので別の機会に。。
さて、本題ですが、会社のとあるハンズオンにてOpenShiftへのアプリケーションのデプロイをopenshift-applierというツールを使っているのを見かけたので気になって調べてみましたので軽くご紹介です。
openshift-applierとはなにか
openshift-applierは、OpenShiftのオブジェクトをクラスタにデプロイするためのAnsibleのRoleです。
Ansibleを使ってOpenShiftやKubernetesクラスタにリソースをデプロイするには、k8sモジュールというのがもともと用意されており、こちらを使ってもできます。こちらについては以前に検証したことがありましたので下記参考にしてください。
openshift-applierでは、OpenShiftのテンプレート機能を使ってデプロイできる点やマニュフェストの適応の前後に任意の処理を入れられるなどがユニークなポイントです。OpenShiftを使ったことある方ならご存知かと思いますが、テンプレートという機能を使って、マニュフェストの一部のパラメータを変数化したり、複数のオブジェクトをまとめたりすることができます。（公式ドキュメントはこちら）
すごく簡単な例を示します。
Namesoaceを作るテンプレートです。Namespace名やそのDescriotionを変数化しています。
apiVersion: v1 kind: Template labels: template: projectrequest-template message: 'Project/Namespace has been created: ${NAMESPACE}' metadata: annotations: description: ProjectRequest Template creationTimestamp: null name: projectrequest-template objects: - apiVersion: v1 description: ${NAMESPACE_DESCRIPTION} displayName: ${NAMESPACE_DISPLAY_NAME} kind: ProjectRequest metadata: name: ${NAMESPACE} parameters: - description: Name displayName: Name name: NAMESPACE required: true - description: DisplayName displayName: DisplayName name: NAMESPACE_DISPLAY_NAME required: true - description: Description displayName: Description name: NAMESPACE_DESCRIPTION
いくつかの項目が変数化されており、oc processコマンド実行時にパラメータを渡すことで、マニュフェストを生成してくれます。
これをそのままクラスタにデプロイしたい場合は oc process xxxxxxx | oc apply -f - で引き渡すことも可能です。OpenShiftのドキュメントやチュートリアルなどを読んでいるとよく出てくるパターンですね。
$ oc process --local -f templates/project/project.yml -p NAMESPACE=hoge -p NAMESPACE_DISPLAY_NAME=hoge
{
"kind": "List",
"apiVersion": "v1",
"metadata": {},
"items": [
{
"apiVersion": "project.openshift.io/v1",
"description": "",
"displayName": "hoge",
"kind": "ProjectRequest",
"metadata": {
"labels": {
"template": "projectrequest-template"
},
"name": "hoge"
}
}
]
}
$ oc process --local -f templates/project/project.yml -p NAMESPACE=hoge -p NAMESPACE_DISPLAY_NAME=hoge | oc apply -f -
なにがいいか
話が少しそれてしまいましたが、openshift-applierではこのOpenShiftのテンプレート機能などの展開が可能になりますが、このツールを使うとどんなメリットがあるかもう少し詳しく考えてみます。
1. テンプレート処理が利用できる
まずはなんと言ってもOpenShiftのテンプレートの機能が使いやすいことでしょう。
OpenShiftでは、デフォルトでもいくつかのテンプレートを用意していて活用する場面はただあります。
テンプレートの処理がフレームワーク化されているのは便利と感じます。
また、OpenShiftのテンプレート機能に加えて、Ansibleで採用しているjinja2のテンプレートエンジンも併用して利用できます。
OpenShiftのテンプレート機能で表現しきれない部分をjinja2でテンプレート化することもできます。
2. 生成するリソースの順番を意識できる
Kubernetesのリソースの扱いの中で、リソースの作成の順番を気にしたいケースがあります。
例えば、Namespaceは先に作っておいてほしいや、DBはアプリより先にデプロイしてほしいなどです。
openshift-applierではオブジェクトの順番を意識して記述することが可能です。
また、"pre/post steps"という機能もあり、特定のリソースの適応の前後に任意の処理を入れ込むことができます。 次のようなユースケースで有効です。
- 次の処理に行く前にリソースが立ち上がるまで待ちたい
- アプリケーションのデプロイ後に、サンプルデータや特定のデータを投入したい
- Deploymentにラベルや環境変数など追加の情報を適応したい
openshift-applier/README.md at master · redhat-cop/openshift-applier · GitHub
3. ansible-vaultが利用できる
そして、ansible-vaultと組み合わせて利用できること、これは便利と感じます。
Secretオブジェクトの中身のデータなどをansible-vaultで暗号化して管理しておき、デプロイ時に復号化して渡すことが可能です。
以下は、 Secretを作るときのサンプルですが、passwordという変数はansible-vaultで暗号化しておくことが可能です。
apiVersion: v1
data:
password: {{ password | b64encode }}
kind: Secret
metadata:
creationTimestamp: null
name: mysecret
実際に試す方法
さて、実際に少し試してみようかなと思ったわけですが、なんとkatacodaで気軽に試せる環境を用意してくれています。 そのため、このブログでは手順などは割愛します。
次世代のopenshift-applier
現在、openshift-applierはバージョン2なのですが、バージョン3では大きな変更を検討しているようです。
”Dash”というプロジェクトネームで検討しているようですが、その設計方針で個人的に注目したポイントは下記です。
※設計方針の案なので確定しているわけではありません。
- Golang実装にしてCLI的に動かせるように
- kustomizeやhelmに対応
詳しいことが書かれているわけではないのですが、Golang実装にしてCLI的に利用できるようにしたいそうです。 また、テンプレート処理もOpenShiftのテンプレート機能とJinja2に加えて、kustomizeやHelmに対応していきたいとのことです。
Kubernetesを運用していくと、マニュフェストのテンプレートエンジン化が必要になってくることが多いです。
個人的にkustomizeというツールが使い勝手がよいと感じていてOpenShiftへの適応も試したりしていました。このあたりは興味深いポイントでした。
余談ですが、kustomizeについてはこちらを是非参考にしてください。
Kustomizeで環境ごとに異なるマニフェストを作る | Goldstine研究所
さいごに
たまたまハンズオンで見かけたOSSのツールではありましたが、調べてみるといろいろと面白い発見がありました。
Kubernetes上でのアプリケーションの運用では、マニュフェストのテンプレートエンジン化とデプロイ制御について課題も感じていたところでした。
このあたりについてまた知見などたまれば投稿していきたいと思います。
