環境変数を保存するにはどうすればよいですか？

これは、環境変数/構造に関するメソッドとアドバイスに関する非常に幅広い質問です。しかし、最終的には「環境変数をどのように保存すればよいですか？」という非常に具体的な質問に対する答えを探しています。

まず、いくつかの説明：

• 私にとっての環境は3〜10台のサーバーであり、特定の顧客のインフラストラクチャを含める方法です。
• 各環境内にはいくつかの変数があり、それらはほとんどいくつかのキー入力（名前、サイズなど）から自動的に生成されます。

現状では、すべての環境変数を次のような構造に格納しています。

<playbook>.yml                   # Various playbooks for deployment
roles/windows                    # Ansible role for Ubuntu
roles/ubuntu                     # Ansible role for Ubuntu
config/hosts/<name>.yml          # Ansible inventory
config/hosts/vars/<name>.json    # Environment specific variables 

現在、構成は上記のgitリポジトリのサブモジュールとして初期化されています。変数ファイルはかなり頻繁に変更されるため、これによりデータの変更に関する問題が発生し、コミット間で1回、2回、または3回でさえ、変更の追跡がますます困難になります。

個人的にはこれから先を見ますが、すべての顧客変数を一元化された/スケーラブルな方法で保存し、次にansibleを使用して動的なインベントリでそれに接続する必要があります。

Consulのように、必要とされる可能性のある部分を実行しているように見えるいくつかのテクノロジーがあることは理解していますが、それらは、小さなわずかに異なる多数のアプリケーションではなく、1つの大きなアプリケーションを提供する環境で最適に動作するようです。

基本的には、インベントリスクリプトを作成し、すべてのデータを目的外に構築されたデータベースに移動し、何も変更されていないかのように続行する必要があることを理解しています。これはおそらく、現在保存している多くのデータを潜在的に削減する方法であると考えています。おそらく、単にデータを再利用するだけでなく、データを保存するさまざまな方法を検討しています。

1つ、2つ、または3つの巨大な環境ではなく、多くの小規模な環境に対処する必要がある場合、誰かがコードとしてインフラストラクチャを実装した経験があることを願っています。

助言がありますか？

私は、スケーラブルな方法で環境変数を実行することを2回実行しましたが、どちらも完璧ではありませんでした。以下に私の両方の経験の概要を示します。

一般的な要因

• 環境変数は、元のソースコードとは別のリポジトリに格納されます（これらは一緒にサブモジュール化されていますが、依然として個別のリポジトリに基づいています）
• アーティファクトとその変数には、個別の「ビルド」プロセスがあります。
• 環境変数の個別のリリースプロセスはありません。環境変数を変更したい場合は、同じ変更レビューボードと通常の手順を実行する必要があります。

Consul KVペアの使用

環境変数は、アーティファクトリポジトリから読み込まれ（元のgitリポジトリではありません）、名前空間付きのKVペアツリーに読み込まれます。次に例を示します。

/env/dev1/my/application/v1.1.1

上記のdev1は環境の名前、my / applicationはアプリケーションの名前空間、v1.1.1は使用する環境変数のバージョンです。

開発者にとって、これらすべてのものは見えません。実行時に、プラットフォームは現在の領事クラスターに環境が存在することを確認し（問題がなく、エラーが発生している場合）、アプリケーションの名前空間のサブツリーを確認します（これにより、1つのアプリで相互汚染が発生しないようにすることができます別のアプリ変数を参照します）、構成のバージョン番号は、デプロイ可能なアーティファクトに接続されているラベルから取得されます。このラベルを更新することがここで重要なことです。なぜなら、両方の本番データセンターを失った場合、デプロイ可能なアーティファクトからメタデータを読み取り、すべての環境変数をKVストアにロードするだけで、環境を再び立ち上げることができるからです。

このアプローチの問題 開発者は、常に、つまり毎回、アプリケーションの実行方法に大きな影響を与える構成変更を環境に取り込む方法を見つけました。なぜなら、コードの変更よりも構成の変更を承認する方が簡単だからです。

変数が埋め込まれた「デプロイメント」アーティファクトの保存

これにより、アーティファクトの正確なバージョンが構成のバージョンに密接に結び付けられます。構成を変更した場合は、このデプロイメント成果物を再ビルドする必要がありました。

デプロイアーティファクト自体は、本質的に、リリース可能なバイナリへのURLとそれに関連付けられたすべての構成を含むyamlファイルでした。

プラットフォームには、変数を読み取り、起動時にアプリケーションのプロセスツリーに出力するコンポーネントが含まれています。

これまでのところ、はるかに成功しています。これは、履歴を追跡できるアーティファクトがあり、任意のレビューボードまで保持して、「これが私たちが気にする唯一のアーティファクトなので、見る必要がないためです。その他の変更、これに対する変更のみ」（つまり、デプロイするアプリケーションのバージョン、含まれる環境変数など）

これにより、開発者が変数に基づいて動作を変更するロジックをアプリケーションに組み込んで、適切なテストサイクルを実行せずに変更をすり込むことが少し難しくなります。

ボーナスポイント

アプリケーションシークレットを検討します。これに対するこれまでの解決策は、開発チームが拡張Javaキーストアを暗号化するために使用する公開RSAキーを提供することでした（ほとんどすべての言語に、Javaキーストアを読み取ることができるライブラリがあります）。これは、3番目のタイプのアーティファクトのように扱われます。サーバーにプルされ、プラットフォームの秘密キーで復号化され、実行時にアプリケーションに提供されます。

明らかに、秘密管理はそれ自身のワームの缶です。しかし、おそらく検討する価値があります。

お客様の環境が顧客ごとの場合、特定のケースでは、顧客ごとにリポジトリを用意することをお勧めします。（一般に、それは環境ごとのリポジトリです。）このリポジトリは、環境変数、ansible変数、インベントリ、強力に暗号化されたシークレット（アカウントアクセストークン、秘密鍵など）の標準ディレクトリ構造になります。これらのリポジトリにコードをgitサブモジュール化します。私はおそらくそれを複数のリポジトリで行うでしょう。1つはansibleロールとモジュール用、もう1つはメンテナンススクリプトとデプロイメントスクリプト用、1つは環境で実行される主要な各アプリケーション用です。

これで、オプションで実際にコードをフォークしたり、特定のタグでreleaseのサブモジュールを固定したりして、テストしてリリースしない限り、お客様の環境を管理するコードが変更されないようにすることができます。

アーティファクトリポジトリを使用している場合は、アーティファクトが適切にバージョン管理され、それらのバージョンが環境変数で適切に指定されていることを確認してください。

環境変数は可能な限り人間が更新するのではなく、スクリプトによって生成する必要があるため、自動化は重要です。顧客ごとのインベントリに手動の更新がほとんどないことを確認し、開発者はコードリポジトリのみを更新します。構成を変更したい場合は、生成スクリプトの1つに対して行う必要があります。生成スクリプトを実行して変数を生成し、差分をお客様のリポジトリにコミットします。このプロセスの継続的インテグレーションをセットアップすることは価値があります。これがないと、ある時点で、維持するにはリポジトリが多すぎます。