MAAS デプロイ全体でプロキシを追跡する
MAAS におけるイメージのダウンロード、インストーラーのトラフィック、デプロイ済みパッケージへのアクセス、その後のアプリケーション要求を区別します。
MAAS のブートイメージのダウンロードが成功すれば、コントローラーの経路が証明されます。インストール済みのマシンが後からパッケージを取得できない場合は、その段階のコンシューマーを調べます:
| 段階 | 調査するコンシューマー |
|---|---|
| イメージ/プロビジョニングのダウンロード | 担当のコントローラーサービス |
| コミッショニングまたはインストール | 一時的なタスク環境 |
| インストール済み OS パッケージ | パッケージマネージャーと生成された設定 |
| その後の charm、スクリプト、アプリケーションのダウンロード | その要求を行うクライアント |
稼働中の MAAS バージョンがサポートする制御を使用してください。文書化されている enable_http_proxy は、プロビジョニングとパッケージアクセスに組み込みまたは指定のプロキシを使う場合を対象とします。http_proxy は外部サービスを識別します。ピアプロキシモードでは、デプロイ済みのマシンが MAAS の組み込みプロキシを利用でき、そのプロキシは当該外部サービスを親として使います。公開外部親の許可された利用では、HTTP プロキシ一覧から HTTP の候補を選んでください。ピアプロキシモードでは、ノード上の MAAS ローカルのエンドポイントを変更しないでください。
したがって、ノード上の MAAS ローカルのエンドポイントが必ずしも古いわけではありません。外部アドレスに置き換える前に、その親をたどってください。ノードにプロキシ設定を渡さなかったリリースの古い preseed 回避策は、現在のすべてのデプロイを説明するものではありません。
失敗している段階では、生成されたパッケージ設定、エンドポイントへの到達性、認証 ID をインストーラー環境と比較してください。ホームディレクトリや変数を共有している必要はありません。APT を使う Ubuntu ノードでは、APT 自身のプロキシオプションを調べてください。ローカルのメタデータアクセスは公開リポジトリと分けてください。内部のプロビジョニング URL を外部親へ送ると、公開ダウンロードが機能していても失敗することがあります。
コントローラーのシェルやブラウザーも別のコンシューマーであり、設定されたパッケージマネージャーがその後のすべてのランタイムを設定するわけではありません。管理変更の後は、影響を受けた既存のワークロードが実際に何を受け取ったかを確認し、設定がすぐに再読み込みされたと決めつけないでください。