この記事では、VMware Tanzu Application Platform (以下、TAP ) のアプリケーションの推奨設定を行う Convention Service について紹介します。「推奨設定」ですが、「言うは易し」の世界であり、無数に存在しており、すでに本番で動いているアプリケーションで設定を忘れたら、目も当てられません。Convention Service はこの問題を解決するための機能です。
え、先輩、そんなことも知らないんですか？問題
“Convention” の日本語の意味は “慣例” に近いです。”Convention Service”、エキスパートたちの間で “慣例” 的に設定されている項目を自動的に設定しようという機能です。
さて、Convetion Service の説明の前に以下の問題を考えてみましょう。たとえば、Kubernetes に対して、以下のようにコンテナを起動したとします。
（！非推奨の設定で起動しますので、実際に実行はしないでください！）
kubectl run –image=nginx nginx
kubectl expose pods nginx –port=80 –type=NodePort
たった二つのコマンドで、Kubernetes ホストにポートがアサインされ、そのままブラウザで nginx にアクセスできます。しかし、これを本番環境につかうわけにはいかないです。Kubernetes に詳しい優秀な後輩君が見た場合「え、先輩、そんなことも知らないんですか？」といわれてしまいます。筆者が知っている範囲でもこの起動方法には以下の問題があります。
- http 通信が暗号化一切されず、公開されてしまっている
- NodePort はホスト側にポートを公開するため、ホストが乗っ取られるリスクを生み出している
- 外部公開する場合は、Ingress リソースを作るべきである
- コンテナ内のアプリケーションが root ユーザーで起動してしまっている
- リソース制限が設定されていないので、CPU/メモリが無制限に使われてしまうリスクがある
- 可能な範囲までファイルシステムのマウントを readonly に設定するべきだが一切設定されていない
- そもそも “kubectl run” および “kubectl expose” は非推奨な起動方法であり、YAMLを使った宣言的にデプロイをするべきである
では推奨の設定をいれていくことになるのですが、頭を悩ませるのがこれらの設定を一律に「すべてのコンテナに設定できない」という点です。この場合は “nginx” というアプリケーションの特性を考えながら推奨設定を考慮する必要があります。また、nginx のようなシンプルなアプリケーションならまだしも、特定のフレームワークで開発されているアプリケーションの場合、そのフレームワークで求められる推奨設定も理解する必要があります。
こういった設定を漏らしたまま、環境にデプロイしてしまうと、後で変更することは容易ではありません。特に、これらの設定の漏れによって重大な問題を起こした場合「知らなかった」では済まされないわけです。
こういったアプリケーション特性に基づいた推奨設定をプラットフォームが自動的に設定する仕組みが Convention Service です。
Convention Service の概要
TAP の Convention Service は「 App-Aware Platform = アプリケーション特性を理解したプラットフォーム」を実現するための機能の一つです。Convention Service は、アプリケーションの特性を読み解き、そこの推奨設定を自動的にいれていく仕組みです。開発者からみた特徴として、用意する Kubernetes のマニフェスト（YAML）は、シンプルのままでいいでいう点です。
この Convention Service ですが、VMware が開発したものです。OPA Gatekeeper など機能だけをみると似た OSS はあったのですが、それらは採用されませんでした。その理由は他の OSS は「アプリケーションの理解」が十分ではない、という判断でした。 VMware が重要視したのは、より “App-Aware” であるという点です。Kubernetes 上で稼働するアプリケーションの推奨設定を入れるのは、人手ではなくプラットフォームの仕事であるべきというのが TAP の信念です。プラットフォームが開発言語やフレームワークを自動的に判別して、設定をいれていく、その際開発者はそれを気にしなくて良い、この考え方を実装するには新たなプロジェクトとして立ち上がりました。
さて、この Convention Service が App-Aware である特徴が、Kubernetes のマニフェストの妥当性だけでなく、コンテナイメージそのものもスキャンするという点です。主には、SBoM (Software Bills of Materials) を使っているのですが、実際のアプリケーションの使われているライブラリやそれのバージョンを検索した上で、Convention を設定していきます。これによって、 Kubernetes のマニフェストだけでは読み解けない、アプリケーションの属性も加味した推奨設定をいれることができるようになります。
現在TAP 1.0では、以下の Convention を提供しています。今後はラインナップの拡充のほか、このプロジェクト自体の OSS 化を目的にしています。（※この記事リリース後、Cartographer Convention として OSS 化がされました）
- Developer convention service
- Spring Boot convention service
- Application Live View convention service
Convention Service を体感してみる
今回は Convention Service の中の “Developer convention service” を紹介したいと思います。
Developer Convention Service はアプリケーションのデバッグをよりやりやすくするための設定を追加していきます。ドキュメント上ではこの章で解説されています。
さて、Developer Convention の LiveUpdate 機能をみていきましょう。 LiveUpdate 中は、勝手にアプリケーションがスケールアップもしくは0 にスケールダウンしないことを保証するため、minScale:1 , maxScale:1 にするのが推奨設定です。Covention Service は以下の手順でそれを設定していきます。
- apps.tanzu.vmware.com/live-update=true が設定されているかをチェックをする
- ライブアップデート対象なプロセスが含まれていることを確認
- minScale および maxScale を 1 に設定する
ここでの二番目の「ライブアップデート対象」とは、（執筆時点では）Cloud Native Buildpacks を作成したイメージが Process Reloading を対応しているか、という観点でチェックしています。Convention Service は Cloud Native Buildspacks が作成したイメージ、そのとき生成された SBoM の情報からこの情報をチェックしています。
ここから以下の二つのテストをしてみて Convention Service がどのように動くかを見てみたいと思います。
- Process Reloading に対応済みの Java Buildpacksの挙動
- Process Reloading に未対応の NodeJS Buildpacksの挙動
まず、Cloud Native Buildpacks で Process Reloading 対応済みの Java Buildpacks の挙動を見てみます。以下のコマンドでワークロードを作成してみます。重要なのが ” –live-update=true ” のパラメータです。
tanzu apps workload create tanzu-java-web-app \
–git-repo https://github.com/sample-accelerators/tanzu-java-web-app \
–git-branch main \
–type web \
–live-update=true \
–yes
ワークロード作成後、Kubernetes のマニフェストを確認すると、minScale:1 , maxScale:1 が設定されています。これは Convention Service が期待通り設定されていることを表しています。
次に、Cloud Native Buildpacks で Process Reloading に未対応の NodeJS Buildpacks の挙動を見てみます。以下のコマンドでワークロードを作成してみます。同じく重要なのが ” –live-update=true ” のパラメータです。
tanzu apps workload create tanzu-nodejs-web-app \
–git-repo https://github.com/making/hello-nodejs \
–git-branch master \
–type web \
–live-update=true \
–yes
ワークロード作成後、Kubernetes のマニフェストを確認すると、minScale/maxScale が設定されていないです。apps.tanzu.vmware.com/live-update=true のラベルはありますが、 Convention Service がイメージの SBoM から LiveUpdate が対応していないことを検知しています。よって minScale/maxScale 設定はされていないですが、これも期待通りの動きです。
Convention Service はこのデモのように、Cloud Native Buildpacks を基に作られたイメージであるか、さらには Java/NodeJS かを Convention Service が検知して、推奨の設定をいれます。アプリケーションを理解した推奨設定を開発者からは透過的に設定することができました。
まとめ
今回は、TAP が推奨設定を自動的にいれる Convention Service についてまとめました。VMware Blog ではさらに TAP の様々な機能を紹介していく予定です。
