原文はこちら
最近のOracle Cloud Infrastructureはいろいろと進歩してます！Autonomous Databaseにサーバレスファンクション、AIが組み込まれたアプリケーション、などなど他にも盛りだくさんです。そして、こうした大物たちも派手ではあるんですが、実のところOracle Cloudのよいところはそのディティールにあります。そうしたディティールのひとつが、最近リリースされたOCI Service Broker for Kubernetesです。リリース1.2.0では、Oracle Cloud InfrastructureのコンソールあるいはCLIで作成した既存サービスのインスタンスとのサービスバインディングをService Brokerを使って作成できるようにサポートを拡張しました。
Service Brokerは何をしてくれるのか？
Service Brokerについては詳しくないんだよね、という方のために説明しておくと、それがやってくれるのは以下のようなアクションです：
- あなたのアプリケーションが必要とする、例えばObject StorageバケットやAutonomous Transaction Processing Databaseのような、Oracle Cloud Infrastructureのサービスのインスタンスを作成する
- Service Brokerによって作成されたそれらのサービスへのバインディングを作成する
ということで、そうしたサービスを使うアプリケーションをデプロイすることができるわけです。
サービスをアンデプロイしたあとには、Service Brokerを使って以下のアクションを行えます：
- 作成したサービスバインディングの削除
- 作成したサービスの削除
こうしたことを行うことで、アプリケーションの依存対象をアプリケーションとともにカプセル化することができ、したがってそれら全てのデプロイやアンデプロイをひとつの単位として扱うことができるようになります。さらに、これらを単一のツール、kubectlで行うことができます。コンテナで稼働するアプリケーションは稼働環境として必要なものを揃えられますが、コンテナ外部に存在している依存対象であるクラウドサービスについてはそうではありませんでした。Service Brokerはこれらもリンクできるので、これによりアプリケーションの移植性が高められます。
Service Broker 1.2.0まで
理屈のうえでは、アプリケーションはどれも自身が依存するクラウドサービスの専有のセットを持っている、と言えます。しかし実践では、多くのアプリケーションが他のマイクロサービスとひとつのクラウドサービスインスタンスを共有していたり、あるいはその環境にもともとあったクラウドサービスインスタンスを使いまわしたりしています。例えば、多くのマイクロサービスアーキテクチャではパブリッシュ／サブスクライブメッセージングを非同期実行のために使っています。あるマイクロサービスが与えられたストリーム、あるいはメッセージングエンドポイントに対してリッスンしている場合、メッセージをパブリッシュするアプリケーションはどこにパブリッシュするべきかを知らなければなりません。もうひとつ例を挙げると、リレーショナル・データベースです。多くの場合、Dev-Testのようなシナリオでさえ、既に存在しているデータベースに事前にテストデータが積まれており、アプリケーションをテストするための準備が完了しています。こうしたケースではマイクロサービスは専有のデータベースを必要とせず、むしろ既存のデータベースに接続することが必要になります。
この点がService Brokerのデザインとマイクロサービスのユースケースとに少々ミスマッチが起こっていたところでした。つまり、サービスのライフサイクルはService Brokerが管理することが想定されており、そしてService Brokerは自身で管理しているサービスのみにサービスバインディングを作成できる、というわけです。あなたのアプリケーションが外部のプロセスによって作成された既存のサービスインスタンスに接続することを必要としている場合、Service Brokerはそのためのサービスバインディングを作成できませんでした。
Service Broker 1.2.0で解決！
リリースされたこのバージョンでは、DevOpsチームはKubernetes環境にアプリケーションをデプロイする際に、既存のOracle Cloud Infrastructureサービスインスタンス（Autonomous Transaction Processing、Autonomous Data Warehouse、Object StorageおよびStreaming）を活用することができます。
Service Brokerを既存のサービスインスタンスと使うワークフローは、通常のService Brokerパターンと同様です：
- サービスインスタンスの作成: そうですね、このケースでは実のところサービスインスタンスを作成するのではなく、既存のサービスインスタンスをService Brokerに対して登録しなければなりません。Service Brokerがサービスバインディングを作成できるのは、Service Brokerが作成したか、あるいは認識しているサービスに対してのみです。というわけでサービスバインディングを作成できるようにするためには、既存のサービスインスタンスをService Brokerに教えてやらなければなりません。なお、このように登録した既存サービスインスタンスについては、Service Brokerはライフサイクルを管理しないという点にはご留意ください。Service Brokerを使って既存サービスインスタンスのパラメーターを更新することはできません。
- サービスバインディングの作成: このステップはService Brokerが作成したクラウドサービスインスタンスへの場合と同じです。
- アプリケーションのデプロイ: いつもと同じ。
- アプリケーションのアンデプロイ: いつもと同じ。
- サービスバインディングの削除: このステップはService Brokerが作成したクラウドサービスインスタンスへの場合と同じです。
- サービスインスタンスの削除: 登録した既存サービスインスタンスの場合にはこのステップはちょっと異なってきます。Service Brokerが削除するのは自身で作成したサービスだけです。登録したサービスについては、Service Brokerが削除するのはその登録だけです。
Autonomous Transaction Processingのワークロードタイプの既存Autonomous Databaseインスタンスを使って詳細を見ていきましょう。ここでの例では、わたしはOracle Cloud Infrastructureコンソールから作成したAutonomous Transaction Processingインスタンスを所持しています。
ここでわたしが既存のインスタンスを使うマイクロサービスをデプロイしたいとすると、以下で説明するようなステップを行うことになります。
これらのステップは、あなたがOracle Container Engine for Kubernetesクラスターに既にOCI Service Brokerをインストールしていることを前提としています。
このポストで使用している見本のYAMLファイルはhttps://github.com/oracle/oci-service-broker/tree/master/charts/oci-service-broker/samplesのサンプルを使っています。
前提の準備：データベースパスワードのKubernetesシークレットを作成
パスワード管理のベストプラクティスとして、Kubernetesシークレットを作成してデータベースパスワードとOracle Walletパスワードを格納しmしょう。暗号化を強く推奨します。
シナリオを通して、データベースのADMINパスワードとサービスバインディングでのOracle Wallet作成の際に使うパスワードが必要になります。なので、passwordとwalletPasswordの値をbase64エンコードされたかたちでシークレットを作成します。
echo '{ "password" : "yourPassword1@here"}' | base64
echo '{ "walletPassword" : "yourWalletPwd2@here"}' | base64結果、YAMLファイルは以下のようになります：
以下のコマンドでシークレットを作成してください：
kubectl create -f /Users/path/atp-demo-secret-2.yamlStep 1: OCI Service Brokerへの既存インスタンスの登録
シークレットを作成したら、既存Autonomous Transaction ProcessingインスタンスをService Brokerに登録しましょう。この登録はService Brokerにどこにインスタンスがあるのかを教えてあげるためのプロビジョニングのいち手順です。以下のパラメーターが必要になります：
- name: インスタンスの表示名
- ocid: インスタンスのOCID
- compartmentId: インスタンスをプロビジョンしたコンパートメントのOCID
- provisioning: プロビジョニングフラグ、falseをセット
注意：Oracle Cloud Infrastructureの各サービスは登録を作成するために個別のパラメーターを持っています。詳細はドキュメントを参照ください。
インスタンスのYAMLファイルは以下のようになります：
以下のコマンドでインスタンスを登録してください：
kubectl create -f /Users/path/atp-existing-instance.yamlsvcat get instancesを実行すると、他のインスタンスとともにこのインスタンスが表示されます。例：
NAME NAMESPACE CLASS PLAN STATUS +------------------+-----------+----------------------+----------+-------+
osb-atp-demo-1 default atp-service standard Ready
osb-demo-pre-exist default atp-service standard Ready
testbucket default object-store-service standard Ready
testbucket2 default object-store-service standard Ready このようにして登録した既存サービスのインスタンスについてはOCI Service Brokerはライフサイクルを管理しないということは覚えておいてください。既存サービスインスタンスのパラメーターをService Brokerを使って更新することはできません。
Step 2: 既存インスタンスへのサービスバインディングの作成
Service Brokerに既存サービスを登録したら、残りのシナリオはService Brokerでインスタンスをプロビジョニングした場合と一緒です。そのインスタンスへのサービスバインディングを作成するには、WalletパスワードをパラメーターとするYAMLファイルが必要です。WalletパスワードはKubernetesシークレットにしておいたので、ここでのYAMLファイルはそのシークレットを参照します。
以下のコマンドでバインディングを作成してください：
kubectl create -f /Users/path/atp-binding-existing.yamlサービスバインディングが作成されたことを確認するには、svcat get bindingsを実行します。以下が実行結果の例です：
NAME NAMESPACE INSTANCE STATUS
+----------------------------+-----------+--------------------+--------+
atp-demo-binding default osb-atp-demo-1 Ready
osb-demo-pre-exist-binding default osb-demo-pre-exist Ready
test-bucket-binding default testbucket Ready Step 3: アプリケーションのデプロイ
OCI Service Brokerソースコードに含まれるサンプルにはデプロイメントYAMLファイルが含まれており、これはinitコンテナを使ってAutonomous Transaction Processingサービスバインディングに含まれる値を取り出すやり方、およびそれらの値を環境変数やボリュームマウントに格納するやり方を説明しています。そのあとには、あなたのアプリケーションはそれらの値を使ってデータベースに接続することができます。
Steps 4–6: アンデプロイ、バインディングの削除、インスタンスの削除
これらのステップの詳細は通常のService Brokerユースケースと同一です。
ただし、Service Brokerによってプロビジョニングされたわけではないサービスインスタンスの削除では、実際にインスタンスが削除されるわけではないということを思い出してくださいね。この際に削除されるのはインスタンスの登録だけです。Service Brokerは自身で作成したサービスインスタンスについてのみ、ライフサイクルを管理できます。
参考情報
OCI Service Broker for Kubernetesの紹介は以下のブログポストを参照ください：
もっと詳しく知りたい、あるいはOCI Service Brokerを試してみたい場合は、OCI Service Broker page on GitHubを見に行ってみてください。
Oracle Cloud Infrastructureサービスの登録やバインディングについて詳細を知りたいなら、ドキュメントを参照ください。