Onur Yilmaz

Trendyol Tech のプラットフォーム チームとして、我々の目標の 1 つはアプリケーション構成と秘密管理を動的かつ信頼できるものにし、アプリケーションから抽象化できるようにすることです。 私たちは長い間 Kubernetes ConfigMaps と Secrets を使用してきましたが、これらは私たちの要件を完全に満たすものではありません。 例えば、ConfigMap上の設定を変更した場合、その変更を反映させるためにアプリケーションポッドを再起動する必要があります。 すべてのアプリケーション・インスタンスに変更が反映されるまで、数分かかることもある。 もうひとつの問題は、Kubernetesのシークレットが十分にセキュアでないことです。

私たちの主な要件は次のとおりです。

• アプリケーション プロセスを再起動せずに、アプリケーションの設定を動的に変更できること。 4444>
• アプリケーションの秘密は安全で監査可能でなければなりません。 また、秘密に対するロールベースのアクセス制御を提供したい。
• アプリケーションから構成管理を抽象化する必要がある。 言い換えれば、アプリケーションは、秘密と構成がどこに、どのように保管され、提供されているかを知るべきではありません。
• 構成と秘密の管理システムは、高可用性とスケーラビリティを備えていなければなりません。 Vault は私たちの要件をすべて満たしており、動的な秘密のような機能も備えているため、将来的に有用になるかもしれません。 また、Vault のストレージ バックエンドとして Consul を使用することもできます。

  Consul は、サービスの検出と設定のための分散型、高可用性、およびスケーラブルなツールです。 私たちのケースでは、Consul の key-value ストア機能を使用して、秘密でない設定を保持するだけです。

  3 番目の要件であるアプリケーションからの設定管理の抽象化については、主に envconsul または consul-template を使用することができました。

  Envconsul は Consul と Vault から取得した環境変数でサブプロセスを起動する方法を提供します。

  Consul-template は Consul と Vault からファイル システムに値を取得し、デーモン モードで作業している間は値の同期を維持します。 しかし、Envconsul (または環境変数) の問題は、プロセスを再起動しないとその環境変数を変更できないことです。 これは、私たちの最初の要件に反しています。 私たちは、アプリケーション・プロセスを再起動することなく、設定を変更できるようにしたいのです。 898>

  

  consul-template では設定ファイルのレンダリングのためにテンプレートファイルを使用することが可能です。 これにより、大きな柔軟性を得ることができます。 以下はテンプレートファイルの例です。

  Consul-template はこのテンプレートを読み込み、”key” キーワードを使用した場合は Consul から、”with secret” キーワードを使用した場合は Vault からの値でプレースホルダーを置き換えます。 テンプレート言語については、こちらで詳しく説明しています。 レンダリングされた出力ファイルは次のようになります;