これは、アドベントカレンダー4日目の記事です。
3日目に、DSCの用語をChefと照らし合わせながら説明しました。
Chefが、CMツールとして備える基本的な機能をDSCも備えていることが何となく見えましたか？
さて4日目は、当初予定していたDSCのエンジンの説明ではなく、DSCが備える2つの動作モードについて説明します。
動作モード
2つのモードがあります。
1つは PUSH、もう1つが PULL です。
2つのモードの違いは、構成開始の起点が「DSCサーバー」か「対象となるサーバー(以下ノードと呼称)」にあります。*1
余談ですが、英語ではPUSHモード / PULLモードより、PUSHシナリオ / PULLシナリオということが多いです
順に概要を見ていきましょう。
PUSH
DSCの記事でよく見るのが PUSH モードです。*2
PUSHは、「DSCサーバーがノードに対して、任意のタイミングであるべき状態に収束させる」モードです。
DSCサーバーが起点ということですね。↓の図をイメージするといいでしょう。
ChefでいうとChef-soloですね。
PUSHの流れ
DSCサーバーが能動的に動作します。*3
- DSCサーバーで、あるべき状態をコンフィグレーションとして記述してコンパイル
- コンパイルした構成をノードに適用
- ノードをあるべき状態へ収束
シンプルです。
PUSH ではあるべき状態の維持を行いにくい
2日目にこういいました。
仕組みとして、あるべき状態(Desired State) に自動的に構成 (Configuration) してくれるほうが楽です。
PUSHが構成されるきっかけは「任意」。ということは、ノードが自動的に「あるべき状態」へ収束されるわけではありません。「あるべき状態になってね」とDSCサーバーがキックしてあげないといけないため、ノードの状態を維持したい場合、定期的なPUSH実行は別途行う必要があります。
本番環境では「あるべき状態を維持したい」ことが多いため、 PUSHは適さないケースがあります。
いつPUSH を使うの？
ではいつ使うのか。実際に私はDSCを本番環境で利用していますが大きく3つの用途があります。
- PUSH/PULLモード切り替え
- DSCサーバー自身の構成
- 自動テスト環境
- 練習
それぞれをさらっと見ていきましょう。
PUSH/PULLモード切り替え
PUSHとPULLの動作を切り変える時には、Set-DSCLocalConfigurationManager Cmdletを使います。
このCmdletの動作はPUSHと同じ挙動/仕組みです。Windowsはデフォルトが PUSHモードなので、PULLに変更するときは必ず1回実行することになりますね。
DSC サーバー自身の構成
私が所属する謎社のサービスはAWS上で運用しており、提供するサービスごとにネットワーク(アカウントレベル)を分離させています。つまり、サービスごとにそれぞれ独立したサーバー群があるとイメージしてください。
このサーバー群で一番先に立ち上げるのがDSCサーバー です。
DSCサーバー が一番先に起動するということは、DSCサーバー自身の構成を担保してくれるサーバーはいないということです。
そのため、DSCサーバーが自分自身をノードとしてあるべき状態に構成する必要があります。
この時PUSHを使って、↓の図のようにノードである自分自身をあるべき状態にします。
自動テスト環境
CMツールのテストとは何でしょうか？ 何をテストするのかというと↓かと思います。
ノードが「あるべき状態」に構成されたのかをテストする
せっかくCMツールを使っても、リソースに書かれたどう構成するかのロジックや、コンフィグレーションに書いたあるべき状態の宣言が「正確にノードに適用」されなくては意味がありません。そのため、ノードがあるべき状態になったかのテストは重要です。
ServerSpecを使うことでChefやPuppetのテストを行うのは一般的に行われています。DSCには当初決定版といえるテストツールがありませんでしたが、最近はPesterを使ってテストをすることが広まりつつあります。
Pesterの詳細はアドベントカレンダー後半あたりで具体的に紹介しますが、BDDスタイルのテストを行えるPowerShellモジュールです。
サーバーのテストは、構成やリソースをGitHubにプッシュしたら自動的に実施される必要があります。そこで、次のような自動テストフローを行っています。
- GitHubへのプッシュ
- まっさらなインスタンスの起動を
- 「あるべき状態」を記述したコンフィグレーションとリソースをCIからDSCサーバーにデプロイ
- PUSHでノードをあるべき状態へ
- Pesterでノードの状態をテスト
- テスト結果の通知
- インスタンスの削除
テストは一度だけ実行すればよく、また任意のキックタイミングが取れるPUSHは相性がいいでしょう。
練習
PUSHの最も楽な点は、 ExecutionPolicyが許可され、WinRMのListnerがつながればすぐに使えることです。「SSHで繋いでさくっとテスト」に似た簡便さがあります。*4
いざPULLで構成しよう！ と思っても、コンフィグレーションの書き方や、MOFファイルがどのように作用するのかなど、何もしらないところから始めるのは大変です。
PUSHで「コンフィグレーショの書き方」「リソースのインポートと実施」「ノードとの疎通」「DSC実行結果のログ確認」など練習をするといいでしょう。
ちなみにPUSHはCIMセッションを使っていますが、PULLではSMBとHTTP/HTTPSで通信することになります。*5
PULL
謎社で実際に「本番環境」にて利用しているのが PULL モードです。
PULLは、「ノードが自分からDSCサーバーに問い合わせて、自身をあるべき状態に収束する」モードです。
ノードが起点ということですね。
ノードの動作モード
PULLでは、ノードが「あるべき状態を適用後、どのように動くのか」を3つの基準から1つ選べます
ふつーは、ApplyAndAutoCorrectで自動復旧を可能にしますね。
| 設定 | 概要 |
|---|---|
| ApplyAndAutoCorrect | 対象サーバーが自分で継続的にDSCサーバーへ構成のずれを確認しに行き、ずれが生じていた場合自分を構成する。 |
| ApplyAndMonitor | 対象サーバーが一度だけDSCサーバーから構成を取得して適用。以降は定期的に自分があるべき状態とずれてないか監視するが、ずれがあっても勝手に復旧しない。 |
| Apply | 対象サーバーが一度だけDSCサーバーを構成を取得して適用します。以降は差異がないか確認もしない。 |
PULLの動作モードは↓の図を参考にどうぞ。
PULLの流れ
PUSHの逆で、ノードが能動的に動作します。
- ノード自身が勝手に自分のDSCサーバーにあるべき状態をしめした構成を問い合わせ
- 取得した構成を自分に適用して、自身の状態をあるべき状態に収束
- 構成の変化を監視
- 自分の構成が変化したとき、1-3を繰り返してあるべき状態へ収束、維持
- もし、DSCサーバーで「あるべき状態」を更新すると、ノードが構成をとりにきて自身をあるべき状態に収束
PULLの際にDSCサーバーが行うこと
ノードの逆で、受動的に動作します。
- あるべき状態の定義(コンフィグレーション)を書く
- ノードのロール用に構成適用ファイル(MOFファイル)を生成
- ノードが参照できる所定のパスに配置
- 3以降は、あるべき状態の変更がない限り対象のサーバーが勝手に取りに来るのを待つだけ
いつPULLを使うの？
PULLサーバーは、PUSHと違って「あるべき状態に自立的に収束する」ため、一度構成したら完全放置プレイができます。
このため、本番環境のように自動化が求められるシーンではPULLが適しています。
- 動的にサーバーの台数が変化
- デプロイなどのたびにサーバーをすてて新しいサーバーを作るImmutable Infrastructureな環境 *6
- エラーがあってもあるべき状態に自動復旧してほしい本番環境
誤解がないように
PULLは「ノードが起点となって定期的にあるべき状態に収束」されます。
が、「DSCサーバーから、ノードに対して(任意のタイミングで)最新の構成を取得してあるべき状態に収束してね」と指示することもできます。
とはいえ、任意のタイミングでしか構成する必要がないならPUSHを使うほうが素直でしょう。*7
まとめ
ぜひ、読まれてるアナタの環境が、PUSH と PULL のどちらに向いているのか考えてみてください。
明日は、「DSCのエンジン的な役割を果たす」Local Configuration Managerについて説明します。
LCMが、PUSHやPULLの挙動を決めているので、まずPUSHやPULLって何？ という説明が必要だったのでした。
