これは、PowerShell DSC Advent Calendar 2014 - Adventar 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 って何？という説明が必要だったのでした。
