VMware Tanzu Application Platform (以降 TAP ）は Kubernetes が中心となるプラットフォームですが、Kubernetes 以外のクラウドのサービスも管理することが可能です。この回で紹介するの Services Toolkit です。Kubernetes も含めたクラウドの全てのサービスを TAP らしく開発者視点で管理していく、面白い世界を紹介します！
Kubernetes だけでは完結しない、システムでのクラウドサービス利用
VMware では、Kubernetes が今後のアプリケーション展開の中心になることを確信していますが、Kubernetes だけでシステムが完結するケースは少ないと思っています。その最たる例が、ステートフル、いわゆるデータをもったサービスです。認めざるを得ない点として、 Kubernetes はステートフルなサービスを管理するのは苦手です。そのため、多くの現場で検討されているパターンが、ステートレスなアプリケーションを Kubernetes でホストし、ステートフルなサービスは Kubernetes の外部サービス(e.g. Amazon RDS ) を利用するパターンです。
さて、この際に、開発者の要求は「早くデータベースがほしい」と「細かい設計は気にしたくない」です。対して、プラットフォーム管理者はこれらの要求をうけいれつつも、ガバナンスを効かせることが重要になってきます。しかし、これまで登場してきた多くの製品や OSS は開発者もしくプラットフォーム管理者、片方の思いに応えるようなものばかりであり、両者の要求を同時に答えるのは難しかったです。
そこで登場するのが TAP です。開発者の自由を尊重しながら、プラットフォーム担当者がもとめる秩序を提供する、これは TAP が最も得意としている分野です。Kubernetes 内外のサービスの管理、そしてそれを開発者に抽象化して提供する Services Toolkit を深堀していきましょう。
Kubernetes の Persistent Volume がヒントに 〜「管理者」と「利用者」を明確にする Services Toolkit
Services Toolkit とは、TAP が提供する一機能として VMware が開発したものです。以下の専用のマニュアルも用意されています。
Services Tookit の面白い特徴が Kubernetes では一般的に使われている機能である Persistent Volume から着想をえている点です。Persistent Volume のどこから着想をえたのかというと、”Claim (要求)” という発想です。ここから紹介するのは Services Toolkit ではなく、一般的に Kubernetes でコンテナが参照する永続ストレージを管理する Persistent Volume についてです。Persistent Volume を利用する際は二段階の操作があります。
- 「管理者」が PersistentVolume を作成し、ストレージ領域をプール化する
- 「利用者」が PersistentVolumeClaim を作成し、要求に対しプールからストレージが割り当てられる
Kubernetes を触ったことのある方々は、この機能に新鮮さを感じた方も多いかと思います。これまでのストレージを抽象化する IaaS 製品の多くは払い出し、拡張、削除などの操作を自動化するものがほとんどでした。しかし、 Kubernetes では管理者と利用者の間にもう１ステップ “Claim” という操作を含め、「管理者」と「利用者」の明確な役割分担をあたえました。
このモデルに着想をえて作ったのが Services Toolkit です。ここからは Services Toolkit の説明ですが、この機能は Persistent Volume の代わりに Kubernetes 内外のサービスを対象にします。「サービス」という抽象的な言葉を使っていますが、例として、Kubernetes上の PostgreSQL のインスタンスも、Amazon RDS クラウド上のクラウドのマネージドRDBも全て Services Toolkit のサービスとして扱えます。そしてこれらのサービスを以下のように開発者に提供することができます。
- 「管理者」がサービスを作成し、プール化する
- 「開発者」がサービスに対するClaimを作成し、要求に対しプールからサービスが割り当てられる
※前図とほぼ一緒ですが、Persistent Volume が Service に置き換わっています。
まさに、PersistentVolume をそのままサービスに置き換えているものです。結果として、以下のメリットが生まれます。
- 「管理者」と「利用者」の間に明確な役割の分担ができる
- サービスがプール化されることで、開発者がリソースを利用できるスピードを早めることできる
- Claim が排他処理として働き、複数のアプリが同一のリソースを奪い合うことを避けられる
なお、Persistent Volume の一機能である Storage Class に相当する機能も今後開発される予定です。Storage Class とは、”Claim” だけで実態のストレージ領域も切り出す機能です。Services Toolkit でも “Claim” だけで、サービスを直接払い出す機能が想定されています。まさに Persistent Volume の発想をそのまま継承している形です。
その他、外部 Kubernetes のリソースを管理する Dedicated Service Clusters 機能（執筆時点では Experimental ) など追加で様々な機能も実装されています。
Services Toolkit を使い Amazon RDS をサービス化
説明だけではわかりにくいと思うので、実機を見てみたいと思います。以下図示したようなシナリオを実行したいと思います。「管理者」が複数 Amazon RDS のインスタンスをプール化、そして「開発者」がそれを利用していきます。
まずは「管理者」の操作です。最小に行う操作がサービスの種類、 Class を作成していきます。今回は、開発用と本番用を二つの Class を作成します。
以下が開発用の定義です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: services.apps.tanzu.vmware.com/v1alpha1 kind: ClusterInstanceClass metadata: name: rds-postgres-dev spec: description: short: AWS RDS Postgresql Development pool: kind: Secret labelSelector: matchLabels: services.apps.tanzu.vmware.com/class: rds-postgres-dev fieldSelector: type=servicebinding.io/postgres |
以下が開発用の定義です。ほぼ同じですが、”-dev”が”-prod”に置き換わっています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
apiVersion: services.apps.tanzu.vmware.com/v1alpha1 kind: ClusterInstanceClass metadata: name: rds-postgres-prod spec: description: short: AWS RDS Postgresql Production pool: kind: Secret labelSelector: matchLabels: services.apps.tanzu.vmware.com/class: rds-postgres-prod fieldSelector: type=servicebinding.io/postgres |
二つのYaml適用後、Tanzu CLI で Class 一覧を取得すると、先ほどつくったものが見えてきます。
|
1 2 3 4 5 |
% tanzu service class list NAME DESCRIPTION rds-postgres-dev AWS RDS Postgresql Development rds-postgres-prod AWS RDS Postgresql Production |
さて、現段階では、ただ Class を定義しただけなので、開発者に Claim として渡すことのできるリソースである “Claimable(要求可能)” はどちらも空の状態です。
|
1 2 3 4 5 6 7 |
% tanzu service claimable list --class rds-postgres-dev No claimable service instances found. % tanzu service claimable list --class rds-postgres-prod No claimable service instances found. |
では、次に “Claimable” なサービスを作成していきます。まず、Kubernetes の操作外で、以下のように Amazon RDS 上に２つDB インスタンスを作成しておきました。
これの認証情報 / Secret を登録していきます。まず pdb-1 です。ここでは、 pdb-1 は開発用と仮定して、さきほどの Class を指定した rds-postgres-dev のラベル(赤字)を指定します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: v1 kind: Secret metadata: name: pdb-1<span style="color: #993300;"> labels: services.apps.tanzu.vmware.com/class: rds-postgres-dev</span> type: servicebinding.io/postgres stringData: type: postgres host: XXXXX port: "5432" username: postgres password: XXXXX database: posgtes |
おなじく pdb-2 の認証情報も作成してきます。pdb-2 は開発用と仮定して、さきほどの Class を指定した rds-postgres-prod のラベル(赤字)を指定します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: v1 kind: Secret metadata: name: pdb-2<span style="color: #993300;"> labels: services.apps.tanzu.vmware.com/class: rds-postgres-prod</span> type: servicebinding.io/postgres stringData: type: postgres host: XXXXX port: "5432" username: postgres password: XXXXX database: posgtes |
なお、 pdb-1 も pdb-2 の認証情報の値ですが、Spring Cloud Bindings のフォーマットにあわせておくことが推奨です。この回で紹介した Service Bindings の機能の恩恵を受けることができます。
この二つの Secret を登録すると以下のように Tanzu CLI で Claimable として見えてきます。事前に定義した Class で識別されている状態になっています。
|
1 2 3 4 5 6 7 8 9 |
% tanzu service claimable list --class rds-postgres-dev NAME NAMESPACE KIND APIVERSION pdb-1 default Secret v1 % tanzu service claimable list --class rds-postgres-prod NAME NAMESPACE KIND APIVERSION pdb-2 default Secret v1 |
では、ここからは「開発者」を演じます。アプリケーションとして、データベースを “Claim(要求)” していきます。Tanzu CLI を使い pdb-1 データベースを使う要求を出してみます。
|
1 |
tanzu services claim create pdb1-claim --resource-name pdb-1 --resource-kind Secret --resource-api-version v1 |
しばらくすると以下のように READY の値が True になります。
|
1 2 3 4 |
% tanzu services claim list NAME READY REASON pdb1-claim True Ready |
さて、ここで実験で、全く同じリソース (pdb-1 )に対し、さらにClaim をしてみたいと思います。一見 Claim が完了したようにみえますが、２つめの Claim が READY のステータス FALSE で、理由として “ResourceAlreadyClaimed” とでてきます。
|
1 2 3 4 5 6 7 8 9 10 |
% tanzu services claim create pdb1-claim-conflict --resource-name pdb-1 --resource-kind Secret --resource-api-version v1 Creating claim 'pdb1-claim-conflict' in namespace 'default'. Please run `tanzu services claims get pdb1-claim-conflict --namespace default` to see the progress of create. % tanzu services claim list NAME READY REASON pdb1-claim True Ready pdb1-claim-conflict False ResourceAlreadyClaimed |
これが、Claim を使う一つのメリットです。今までは、こういったサービスの排他制御が困難でしたが、 Claim という抽象化されたリソースをつかうことで実現ができています。
最後に Claim をつかって実際のワークロードを作ります。この際、”–service-ref”に今回作成した Claim を指定します。このようにすると、 Amazon RDS のDBへの認証情報がアプリケーションに引き渡され、利用可能となります。（なお繰り返しですが、この仕組みはこの回で紹介した Service Bindings の機能をあわせてご参照ください。）
|
1 2 3 4 5 6 7 8 9 |
% tanzu apps workload create my-workload \ --git-repo https://github.com/sample-accelerators/spring-petclinic \ --git-branch main \ --git-tag tap-1.2 \ --type web \ --env SPRING_PROFILES_ACTIVE=postgres \ --app my-workload \ <span style="color: #993300;">--service-ref db=services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:pdb1-claim</span> |
以上 Services Toolkit を使った紹介でした。なお、この回で紹介したのはServices Toolkit の中でも一番ベーシックなものです。マニュアルには以下のようなパターンも紹介されていますのでぜひ試してみて下さい。
- Secret ではなく RabbitMQ Operator 経由で Claim を行う方法
- Amazon RDS の払い出しまでをも自動化した方法
- サービス専用のクラスタ (Dedicated Service Cluster) をつかった方法（Experimental)
Services Toolkit は TAP 1.2 でもまだ新しい機能です。今後の更なる機能拡張が期待されます。
まとめ
Services Toolkit を使いサービスをプール化して、ユーザーに公開する手段を紹介しました。VMware ブログで引き続きTAPの新機能を続々と紹介させていただきます。
