課題
これらの3つの展開シナリオを見ると、それぞれのケースでPostgreSQLを使用するアプリケーションが、独自の名前と内容を持つ個別のシークレットを認識する必要があることがわかります。組み込み型シナリオでは公式のPostgreSQL Helmチャートにより提供される値とシークレットを使用しますが、OSBAシナリオではベンダー固有の属性名でシークレットを使用し、外部シナリオではシークレットの名前と内容を自由に定義できます。
1つの展開シナリオで作業するだけなら問題ありませんが、通常はそうとは限りません。例えば、開発段階で組み込み型の展開を使用しても、その後の実稼働ではクラウドプロバイダーのマネージドサービスを使用する必要があり、OSBAの展開が必要になることがあります。したがって、データベースの展開方法や場所に関係なく、アプリケーションが同じ方法でデータベースにアクセスできるようにする必要があることがわかります。そこで、抽象化が必要になります。
解決策
Talendが選択した解決策では、アプリケーションが場所を限定されずにデータベースに接続するために必要な、抽象化層を提供する「ジェネリックシークレット」を使用します。
シークレットには、機密データを扱うリソースとなる以外にも、ポッドの起動を同期する手段にもなるといったメリットがあります。シークレットファイルに依存するポッドがある場合や、何らかの環境変数がシークレットに依存する場合、シークレットが利用可能になってからでないとポッドは起動すらできません。
以下は、PostgreSQLのクラスターとデータベースにアクセスするために作成するジェネリックシークレットの例です。
| シークレットキー | シークレットの値の説明 |
|---|---|
| postgresql.database | データベースの名前 |
| postgresql.host | クラスターのホスト名（IPアドレスまたはKubernetesサービス名） |
| ostgresql.password | マスターのパスワード |
| postgresql.port | クラスターのポート（通常は5432） |
| postgresql.user | マスターユーザー |
上記の各展開シナリオにおいて、このジェネリックシークレットを作成するには、以下に説明する通り、異なるメカニズムを使用します。
組み込み型展開シナリオ
ジェネリックシークレットは、Kubernetesジョブによってvalues.yamlファイルから作成され、PostgreSQLシークレットは公式PostgreSQLチャートによって作成されます。ジョブの環境変数を使用して、組み込まれたPostgreSQLシークレットが作成されるのを待ちます。例についてはこちらを参照してください。
OSBA展開シナリオ
OSBAプロビジョニングプロセスには、2つのKubernetesリソース、サービスインスタンス、およびサービスバインディングが含まれます。サービスバインディングは、プロビジョニングの実行が成功した後に作成されるシークレットの名前を記述します。このため、組み込みシナリオと同様に、Kubernetesジョブを使用してOSBAシークレットが作成されるのを待ち、そこからジェネリックシークレットを作成します。例についてはこちらを参照してください。
外部展開シナリオ
このシナリオは、外部から取得したクレデンシャルデータをHelmのインストールプロセスで指定できるため、最も簡単なシナリオです。したがって、単純なシークレットテンプレートだけでジェネリックシークレットを作成できます。例についてはこちらを参照してください。
新しいレベルの接続管理
Kubernetesは、コンテナ化されたアプリケーションのオーケストレーションを別のレベルに移せるため、ソフトウェアベンダーによる開発、QA、実稼働の環境間で発生するギャップを埋めるうえで役立ちます。それと同時に、サードパーティのリソース/サービスのオプションが大幅に増加しており、ソフトウェアベンダーは、ローカルで管理されるサービスとクラウドベースのサービスの間で柔軟に切り替えることが可能なアプリケーションの構築という課題にも直面しています。
今回は、KubernetesとHelmを活用して、KubernetesアプリケーションからPostgreSQLデータベースへの接続を管理する例を紹介しました。これは、クラスター内のアプリケーションとともに展開することも、クラウド環境にオンデマンドで展開することも、またはクラスター外で事前に展開することも可能です。ここではHelmチャートを使用して、アプリケーションとデータベースの間に抽象化層を提供する単一のジェネリックシークレットを作成しました。この方法を採れば、アプリケーションはデータベースの展開場所を意識したりデータベースへの接続方法を変更したりすることがありません。
このアプローチで作成された関連のHelmチャートは、こちらをご覧ください。
