Open Service Broker for さくらのクラウド
Cloud Foundryやkubernetes-incubatorのservice catalogでおなじみ?のOpen Service Broker APIをさくらのクラウド向けに実装しましたのでご紹介させていただきます。
Open Service Broker APIってなに？
Open Service Broker APIとは、Cloud Foundry由来のService Brokerの仕組みをkubernetesなどのCloud Foundry以外の環境でも利用できるようにHTTP APIの仕様を定めたものです。
その前にService Brokerってなに？
Service Broker(サービスブローカー)とは、プラットフォーム(Cloud FoundryやKubernetes)が外部のサービスやコンポーネントを使いやすくするための仕組み、、、です。
と言われてもこれではよくわかりませんね、、、ということで具体的な例を見ながらService Brokerとは何かを追っていきます。
例えばkubernetesでデータベースを使うには？
DockerやKubernetesなどを利用する場合、データベースやKVS、ストレージなどのステートフルなリソースの扱いは悩みどころです。
Kubernetesではこのようなステートフルな運用のためにStateful Setsというものが用意されていますが、通常のステートレスなコンテナと比べると若干デプロイや運用が面倒です。
ということで、無理にKubernetes内で動かさずにRDSなどの外部のサービスの利用をすることも多いかと思います。
RDSなどの外部のサービスを利用する場合
データベースをk8s内で運用せず外部のサービスを利用する場合、概ね以下のような作業が必要となります。
- 利用するサービスの有効化(プロビジョニング)
- 払い出されたログイン情報などをKubernetes上のSecretsなどに登録
- ログイン情報を環境変数などでPodに渡す
この辺の作業はスクリプトなどである程度自動化することも可能ですが、利用するサービスごとに手順が異なったりしてなかなか大変です。
サービスごとに手順手順が異なるといった煩雑さに対し、統一したインターフェースを提供し手軽に扱えるようにすることがService Brokerの役割(のひとつ)です。
次にService Brokerがこれらの問題をどう解決するのか見ていきます。
Service Broker = 外部のサービスなどを仲介してくれる仲買人
イメージとしてはこんな感じです。
利用者と外部サービスとの間にブローカー(仲買人)が入ることで、利用者はブローカーにお願いするだけで済みます。
ブローカーも役割分担することで実装が簡単に
さらに、ブローカーは利用者からの依頼を管理する部分と実際のサービスの調達を行う部分に役割分担されています。
役割分担することで、サービスが増えても追加となったサービスの分だけを実装すればよく、多様なサービスに柔軟に対応できるようになります。
ここでもう一度: Open Service Broker APIとは?
そして、利用者からの依頼を管理する部分と実際のサービスの調達を行う部分についてのインターフェースを仕様として定めたものがOpen Service Broker APIです。
元々はCloud Foundryから始まった仕組みらしいのですが、Service Brokerが非常に便利な仕組みだったために
Kubernetesなど他のプラットフォームでも利用できるようにCF依存でないオープンな仕様としてOpen Service Broker APIが策定されたようです。
(Cloud Foundry周りにあまり詳しくないのでこの辺は後述の参考サイトなどを参照ください…)
Open Service Broker APIの策定はCloud Foundry Foundation (CFF)によってホストされており、現在のAPIバージョンは2.13となっています。
このCFFにはFujitsu, Google, IBM, Pivotal, RedHat, SAPといったメンバーが参加しているとのことです。
ここには載っていませんが、Microsoft(Azure)についてもOpen Service Broker for Azure(OSBA)が活発に開発されています。
KubernetesとOpen Service Broker APIの関係は？
KubernetesにおいてもOpen Service Broker APIを利用するための仕組みが開発されています。
それがkubernetes-incubatorのService Catalogというものです。
Service Catalogは先ほどの図で言うと、利用者からの依頼を受け付ける仲介者の役割を担っています。
具体的にはService CatalogはKubernetesのカスタムリソースとしてServiceInstanceとServiceBindingを追加し、それらを管理するコントローラー+APIサーバを提供してくれます。
つまり、Kubernetes利用者からは以下のようにkubectlコマンドでリソースを追加することで、外部のサービスを利用できるようになります。
# こんな感じのyamlを用意(この例ではAzure上のMySQLを利用)
$ cat example_service.yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: example-mysql-instance
namespace: default
spec:
clusterServiceClassExternalName: azure-mysql
clusterServicePlanExternalName: basic50
parameters:
location: eastus
resourceGroup: demo
firewallRules:
- startIPAddress: "0.0.0.0"
endIPAddress: "255.255.255.255"
name: "AllowAll"
# kubectlで投入
$ kubectl create -f example_service.yaml
これでAzure上のMySQL(Azure Database for MySQL)のインスタンスが作成されます。
このMySQLを各Podなどから利用できるようにするためのクレデンシャルの発行を以下のように行うことができます。
(なお、このインスタンス作成のことをProvisioning、クレデンシャルの発行(仕様上は以外も出来ますが)をBindingと呼びます)
# Azure Database for MySQLへのアクセス用クレデンシャル発行 & Kubernetesのsecretに格納
$ cat example_binding.yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: example-mysql-binding
namespace: default
spec:
instanceRef:
name: example-mysql-instance # 先ほど作成したインスタンスを指定
secretName: example-mysql-secret # クレデンシャルの格納先となるsecret名を指定
# こちらもkubectl経由で投入
$ kubectl create -f example_binding.yaml
各PodではSecretを参照することでデータベースのホスト名/データベース名/ユーザー名/パスワードなどを知ることができます。
kubernetes上で完結できるので、例えばHelm chartとしてきちんと永続化したいデータを持つアプリなどの配布を行う際に非常に便利に使えます。
本題: Open Service Broker for さくらのクラウド
そして今回実装したのがService Catalogから依頼を受けて実際にサービスを調達する部分です。
これを利用することでkubernetesからさくらのクラウド上のマネージドなサービスを利用することが容易になります。
先ほどのAzureの例のように、kubectlコマンドからさくらのクラウド上のマネージドDBであるデータベースアプライアンスを作成できます。
ということで早速使い方を紹介します。
Open Service Broker for さくらのクラウドの使い方
準備
まずはさくらのクラウド上のVPC内にKubernetesクラスタを構築する必要があります。
なぜVPC内にKubernetesクラスタが必要かと言うと、さくらのクラウドのデータベースアプライアンスがVPC内(正確にはスイッチさえ繋げばOK)に置く必要があるためです。
Kubernetes(内のPod)から繋ぎたいため、必然的にVPC内にクラスタを置く必要があります。
クラスタを持っていない方はDocker for WindowsまたはDocker for MacでもOKです。
その場合、L2TP/IPSecなどでVPCルータに対してVPN接続を行っておきましょう。
インストール
Helmのインストール
まずはKubernetesのパッケージ管理ツールであるHelmをインストールします。
macOSの場合はhomebrew、Windowsの場合はChocolateyでインストール可能です
# macの例 $ brew install kubernetes-helm
インストールしたらhelm initを実行しておきます。
$ helm init
Service Catalogのインストール
続いてHelmでService Catalogのインストールを行います。
# HelmにService Catalog用のリポジトリを追加 $ helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com $ Service Catalogのインストール(ネームスペースは"catalog"としておく) helm install svc-cat/catalog --name catalog --namespace catalog
(オプション) Service Catalog CLIのインストール
必須ではないですが、Service Catalog専用のCLI(svcat)をインストールしておくと詳細な情報が参照できて便利です。
CLIを試してみたい方はドキュメントを参考にインストールしてみてください。
Open Service Broker for さくらのクラウドのインストール
続いてHelmでOpen Service Broker for さくらのクラウドのインストールを行います。
さくらのクラウドのAPIキーが必要となりますので、発行していない方はコントロールパネルなどから発行しておいてください。
APIキーは以下のように環境変数に設定しておきます(インストール時の入力を楽にするためです)。
$ export SAKURACLOUD_ACCESS_TOKEN=<your-api-token> $ export SAKURACLOUD_ACCESS_TOKEN_SECRET=<your-api-secret> $ export SAKURACLOUD_ZONE=<your-zone>
続いてHelmでインストールを行います。
# HelmにOpen Service Broker for さくらのクラウド用のリポジトリを追加 $ helm repo add sacloud https://sacloud.github.io/helm-charts/ # Open Service Broker for さくらのクラウドのインストール(ネームスペースは"osbs"としておく) $ helm install sacloud/open-service-broker-sacloud --name osbs --namespace osbs \ --set sacloud.accessToken=$SAKURACLOUD_ACCESS_TOKEN \ --set sacloud.accessTokenSecret=$SAKURACLOUD_ACCESS_TOKEN_SECRET \ --set sacloud.zone=$SAKURACLOUD_ZONE
インストール後はkubectl get pod --namespace=osbsを実行して動いているか確認しましょう。
# STATUSがRUNNING、かつREADYが1/1になっていることを確認しておく $ kubectl get pod --namespace=osbs NAME READY STATUS RESTARTS AGE osbs-open-service-broker-sacloud-xxxxxxxx-xxxxx 1/1 Running 0 7h
kubectlコマンドでデータベースアプライアンスを作成してみる
それでは早速データベースアプライアンスを作成してみましょう。
現時点では以下2種類をサポートしています。
- MariaDB 10.2
- PostgreSQL 9.6
今回は例としてMariaDBを作成してみます。
まず以下のようなyamlファイルを用意します。
apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceInstance metadata: name: my-mariadb-instance namespace: default spec: clusterServiceClassExternalName: sacloud-mariadb clusterServicePlanExternalName: db-10g parameters: switchID: <VPC内のスイッチのID> ipaddress: "<データベースに割り当てるIPアドレス>" maskLen: <データベースのネットワークマスク長> defaultRoute: "<データベースのデフォルトルートIPアドレス>"
さくらのクラウド上のスイッチのIDとデータベースに割り当てるIPアドレス関連の記入が必要です。
記入したらkubectlコマンドを実行します。
kubectl create -f <作成したyamlファイル>
うまくいきましたね？
しばらく待つとさくらのクラウド上に新しいデータベースアプライアンスが作成されているはずです。
数分かかりますので気長に待ちましょう。
svcatコマンドをインストールしている場合は以下のコマンドで作成状況を確認できます。
$ svcat get instances
作成したデータベース上にアカウントを作成してみる
次に、Podなどから利用できるようにデータベース上に新たなアカウントを発行し、Kubernetesのsecretにクレデンシャルを登録します。
こちらも先ほどと同じくyamlファイルを作成してkubectlコマンドを実行することで行えます。
apiVersion: servicecatalog.k8s.io/v1beta1 kind: ServiceBinding metadata: name: my-mariadb-binding namespace: default spec: instanceRef: name: my-mariadb-instance secretName: my-mariadb-secret
$ kubectl create -f <作成したyamlファイル>
kubectlを実行すると、my-mariadb-secretという名前でデータベースへのログイン情報(クレデンシャル)が登録されているはずです。
# secretに登録されたクレデンシャルの確認 $ kubectl get secret my-mariadb-secret
なおsecretはBASE64エンコードされていますので、復号して生データを見たい場合は以下のコマンドを実行しましょう。
$ echo <BASE64エンコードされた文字列> | base64 -D
あとは各Podからsecretの値を参照すればOKです。マネージドなデータベースがこれだけで使えるようになるのは便利ですよね！！！
応用: 作成したデータベースを利用する例
応用例としてService Broker for さくらのクラウドを利用するhelm chartを作成してみました。
イケてるデータ可視化ツールであるMetabaseをインストールする例となっています。
Metabaseのバックエンドとしてさくらのクラウドのデータベースアプライアンスを利用、データベースアプライアンスはOpen Service Broker for さくらのクラウドが管理します。
# 応用例のインストール
$ helm install --name my-release sacloud/metabase \
--set database.switchID=<your-switch-id> \
--set database.ipaddress=<your-db-ip> \
--set database.maskLen=<your-db-network-mask-len> \
--set database.defaultRoute=<your-db-default-route-ip>
詳細はChartの内容をみていただければと思いますが、ちゃんと永続化したいデータを伴う構成でもHelmで手軽に配布できるようになっています。
終わりに
ということで今回はOpen Service Broker for さくらのクラウドについて紹介しました。
Open Service Broker/Service Catalogは非常に便利ですのでぜひ使ってみてください！！
以上です。
参考記事
この記事を書くのに以下の記事/スライドを大いに参考にさせていただきました。
Service Brokerの仕組みについてはこちらの資料を読むのがおすすめです。
