4. 設定

すべてのアプリケーションには設定が必要です。データベースの認証情報、APIキー、フィーチャーフラグ、環境固有の設定などです。Build.ioは設定をコードから分離して管理するため、変更なしに同じコードベースを異なる環境にデプロイできます。

このセクションでは、環境変数、アプリ設定、シークレットを安全に保つためのベストプラクティスを通じてアプリの設定を管理する方法を説明します。

4.1 環境変数（Config Var）

Config VarはBuildアプリケーションを設定するための主要な手段です。実行時に環境変数としてアプリに公開され、機密データをコードベースから切り離し、再デプロイなしに設定を変更できます。

Config Varの仕組み

アプリが起動すると、BuildはすべてのConfig Varを環境に注入します。コードは他の環境変数と同様に読み取ります。

Ruby:

database_url = ENV['DATABASE_URL']

Node.js:

const apiKey = process.env.API_KEY;

Python:

import os
stripe_key = os.environ.get('STRIPE_SECRET_KEY')

Config Varはすべてのプロセスタイプ（web、workerなど）で利用可能で、デプロイや再起動後も保持されます。

Config Varの設定

ダッシュボードから、アプリのSettingsタブに移動し、Config Varsセクションを見つけます。「Reveal Environment」をクリックして既存の値を表示し、必要に応じて追加・編集します。

CLIから：

$ bld config:set STRIPE_KEY=sk_live_xxx123 -a my-app

複数の変数を一度に設定できます：

$ bld config:set API_URL=https://api.example.com RETRY_COUNT=3 -a my-app

現在の設定を表示するには：

$ bld config:list -a my-app

変数を削除するには：

$ bld config:unset OLD_API_KEY -a my-app

Config Varが変更されたとき

Config Varを更新すると、アプリのダイノが再起動されます。新しい値はすぐに有効になります。再デプロイは不要です。関連する複数の変数を更新する場合は、複数回の再起動を避けるために1つのコマンドですべて設定することを検討してください。

4.2 アプリ設定

Config Varに加えて、アプリにはBuildがどのようにデプロイ・実行するかを制御するいくつかの設定があります。これらはダッシュボードのアプリのSettingsタブで確認できます。

スタック

スタックはアプリのビルド方法を決定します。ほとんどのアプリでは、最新のセキュリティパッチが適用されたCloud Native Buildpackを使用するデフォルト設定のままにしてください。アプリにDockerfileが含まれていてそれを使用したい場合は、スタックを「dockerfile」に設定します。

ビルドパック

ビルドパックはソースコードを実行可能なアプリケーションに変換します。通常はアプリのテックスタックに合ったビルドパックを追加します。必要なアプリには複数のビルドパックを追加できます（例：アセットコンパイルにNode.jsが必要なRubyアプリ）。順序が重要で、ビルドパックは順番に実行され、それぞれが後続のビルドパックに実行可能ファイルを提供できます。

リージョン

アプリのリージョンによって、ダイノが実行される場所が決まります。最良のパフォーマンスのために、ユーザーやデータベースに近いリージョンを選択してください。設定後にリージョンを変更することは可能ですが、影響があるため、最初から最適なものを選んでください。

アプリポリシー

いくつかのポリシーがアプリの実行動作とセキュリティを制御します。アプリのSettingsタブの「Policies」セクションで確認できます。

WebSocketを許可 — アプリのWebSocket接続を有効または無効にします。

一時証明書のプロビジョニング — ACM（自動証明書管理）証明書が発行される前に自己署名証明書を生成します。新しいデプロイのセットアップ時に、ドメインのDNSが解決され、実際の証明書がプロビジョニングされるのを待つ間、アプリに動作するHTTPSエンドポイントを提供する際に便利です。

レスポンスタイムアウト — Buildがリクエストを終了するまでのリクエスト所要時間。長時間のリクエストを処理するアプリではこれを増やしますが、長いタイムアウトはダイノのリソースを占有することに注意してください。

Webアプリケーションファイアウォール（WAF） — ほぼ回線速度で、すべての受信トラフィックを透過的にプロキシする組み込みファイアウォールを有効にします。WAFはOWASP Core Rule Setを使用してSQLインジェクションやクロスサイトスクリプティングなどの一般的なWebアタックをブロックします。TLSパススルーが有効な場合、WAFはトラフィックを検査できません。

TLSパススルー — ルーティング層でBuildが終端する代わりに、アプリが直接SSL/TLS終端を処理できるようにします。カスタム証明書の検証や独自のTLS終端が必要なサービスでのみ使用してください。これを有効にすると、ルーティング層がトラフィックを読み取れなくなるため、WAFやその他のHTTPレベルの検査が無効になります。

プロセスネームスペースの共有 — 同じダイノ上のコンテナ間でプロセスネームスペースを共有します。これにより、Buildの組み込みプロセスマネージャーが、親プロセスが残した孤立プロセスを積極的にクリーンアップできます。

侵食耐性 — エラーが発生したかどうかに関わらず、プロセスが自動的に再起動されるまでの時間制限を設定します。これは、時間の経過とともにプロセスが応答不能になるメモリリークやその他の漸進的な劣化に対するセーフガードとして機能します。

ビルドキャッシュ — 後続のビルドを高速化するために以前のビルド結果をキャッシュします。大きな依存ツリーやコンパイルが遅いプロジェクトに特に有効です。古いキャッシュによるビルド問題が発生した場合は、一時的にこれを無効にしてクリーンビルドを強制できます。

4.3 シークレット管理

Config VarはAPIキー、データベースパスワード、暗号化キーなどのシークレットを保存する適切な場所です。BuildはConfig Varを保存・転送時に暗号化し、ビルドログやアプリのソースコードには絶対に公開されません。

コードからシークレットを排除する

プライベートリポジトリであっても、シークレットをリポジトリにコミットしないでください。代わりにConfig Varを使用してください。誤ってシークレットをコミットした場合は、すぐにローテーションしてください。Gitの履歴は永続的であり、シークレットは侵害されたとみなすべきです。

ローカル開発では、.envファイルを使用して.gitignoreに追加します。dotenv（ほとんどの言語で利用可能）などのツールは、開発中にこれらの値を環境に読み込み、本番環境でのConfig Varの動作を模倣します。

シークレットのローテーション

定期的にシークレットをローテーションすることで、漏洩した場合の被害を限定できます。自分が管理する認証情報（自分のAPIキーなど）の場合は、Config Varを新しい値で更新します：

$ bld config:set API_KEY=new_key_value -a my-app

アプリは新しい値で再起動します。外部サービスについては、複数のアクティブなキーを同時にサポートしているか確認してください。これにより、新しいキーを追加し、デプロイして動作確認をした後、ダウンタイムなしに古いキーを失効させることができます。