Enterprise レベルに含めるもの
initialize、maintenance、knowledge の各セクションが同じように適用されます。
| ユースケース | Enterprise | Org-wide | Repo-level |
|---|---|---|---|
| VPN / ネットワークアクセス | ✓ | ||
| CA 証明書 | ✓ | ||
| プロキシ設定 | ✓ | ||
| DNS オーバーライド | ✓ | ||
| GPG commit 署名 | ✓ | ||
| 共有 language runtimes | ✓ | ||
| Org-wide CLI ツール | ✓ | ||
| 非公開 registry 認証 | ✓ | ||
| repo の dependencies | ✓ | ||
| repo 固有の test/lint | ✓ |
Enterprise レベルの設定では repositories をクローンできません。リポジトリのクローンには org レベルのアクセスが必要です。Enterprise 設定は共有インフラストラクチャ (VPN、証明書、ツール) にのみ利用してください。repo のクローンは org レベルで自動的に処理されます。
Enterprise の権限
| 操作 | 必要なロール |
|---|---|
| Enterprise 設定の閲覧 / 編集 | Enterprise Admin |
| org 設定の閲覧 / 編集 | Org Admin または Enterprise Admin |
| repo 設定の閲覧 | 任意の org メンバー |
| repo 設定の編集 | ManageOrgSnapshots 権限を持つメンバー |
ビルドの連鎖
- すべての 組織で新しいビルドがトリガーされます
- 各組織のビルドには、Enterprise の設定 → 組織の設定 → すべての repo の設定が含まれます
- ビルドは組織ごとに独立して実行されるため、ある組織の失敗が他の組織に影響することはありません
- 各組織には専用のマシンイメージが割り当てられます
Enterprise の
initialize ステップでは順序が重要です。 最初に VPN (内部ホストに到達できるようにするため) 、次に DNS (名前解決できるようにするため) 、その次に証明書 (HTTPS を機能させるため) 、次にプロキシ (トラフィックを正しくルーティングするため) 、最後に内部ソースからダウンロードするツールを配置する必要があります。複数組織の管理
- まず Enterprise 設定 — 共有インフラストラクチャ (VPN、証明書、プロキシ) を設定します
- 次にorg-wide 設定 — 各 org の管理者が共有ツールとレジストリへのアクセスを設定します
- 最後にリポジトリ固有の設定 — 各チームがそれぞれのリポジトリを設定します
Enterprise の移行
- まず Enterprise レベルの YAML を設定します — VPN、証明書、プロキシ設定などの共有インフラストラクチャを対象とします。
- org は 1 つずつ移行します。 各 org にはそれぞれ「レガシーのマシンスナップショットを利用する」トグルがあるため、ほかのチームに影響を与えずに段階的に移行できます。
- テスト用 org を検討します。 大規模な Enterprise では、本番 org に展開する前に宣言型構成を検証するため、専用のテスト組織を作成してください。
- 大規模展開には Devin を利用します。 Devin は並列セッションで repo を設定できます。repo ごとに 1 つのセッションを起動すると、Devin が設定案を自動生成します。これは 10〜100 以上の repo を導入する場合に適しています。
次のステップ
- Enterprise の使用例 — VPN、CA 証明書、プロキシ、DNS、GPG 署名など
- 環境設定 — 設定を記述するためのメインガイド
- VPN 設定 — VPN の詳細な設定手順