読者です 読者をやめる 読者になる 読者になる

tech.guitarrapc.cóm

C#, PowerShell, Unity, Cloud Platfrom Technical Update and Features

PowerShell DSC Advent Calendar 2014 : Day 4 Pull と Push

PowerShell DSC AdventCalendar

これは、PowerShell DSC Advent Calendar 2014 - Adventar 4日目の記事です。

3日目に、DSC の用語をChefと照らし合わせながら説明しました。

Chef が、CM ツールとして備える基本的な機能を DSC も備えていることが何となく見えましたか?

さて4日目は、当初予定していた DSC のエンジンの説明ではなく、DSC が備える 2つの 動作モードについて説明します。

目次

動作モード

2 つのモードがあります。

1つは PUSH、もう一つが PULL です。

2つのモードの違いは、構成開始の起点が「DSCサーバー」か「対象となるサーバー(以下ノードと呼称)」にあります。*1

余談ですが、英語では PUSH モード / PULL モードより、PUSH シナリオ / PULL シナリオということが多いです

順に概要を見ていきましょう。

PUSH

DSCの記事でよく見るのが PUSH モードです。*2

PUSH は、「DSCサーバーがノードに対して、任意のタイミングであるべき状態に収束させる」モードです。

DSCサーバーが起点ということですね。↓の図をイメージするといいでしょう。

f:id:guitarrapc_tech:20141205002503p:plain

Chef でいうと Chef-solo ですね。

PUSHの流れ

DSCサーバーが能動的に動作します。*3

  • DSCサーバーで、あるべき状態をコンフィグレーションとして記述してコンパイル
  • コンパイルした構成をノードに適用
  • ノードをあるべき状態へ収束

シンプルです。

PUSH ではあるべき状態の維持を行いにくい

2日目にこういいました。

仕組みとして、あるべき状態(Desired State) に自動的に構成 (Configuration) してくれるほうが楽です。

PUSHが構成されるきっかけは「任意」。ということは、ノードが自動的に「あるべき状態」へ収束されるわけではありません。「あるべき状態になってね」とDSCサーバーがキックしてあげないといけないため、ノードの状態を維持したい場合、定期的なPUSH実行は別途行う必要があります。

本番環境では「あるべき状態を維持したい」ことが多いため、 PUSH は適さないケースがあります。

いつPUSH を使うの?

ではいつ使うのか。実際に私は DSC を本番環境で利用していますが 大きく3つの用途があります。

  1. PUSH/PULLモード切り替え
  2. DSC サーバー自身の構成
  3. 自動テスト環境
  4. 練習

それぞれをさらっと見ていきましょう。

PUSH/PULLモード切り替え

PUSH と PULL の動作を切り変える時には、Set-DSCLocalConfigurationManager Cmdlet を使います。

このCmdlet の動作はPUSH と同じ挙動/仕組みです。Windows はデフォルトが PUSHモードなので、PULLに変更するときは必ず1回実行することになりますね。

DSC サーバー自身の構成

私が所属する謎社のサービスはAWS 上で運用しており、提供するサービスごとにネットワーク(アカウントレベル)を分離させています。つまり、サービスごとにそれぞれ独立したサーバー群があるとイメージしてください。

このサーバー群で一番先に立ち上げるのがDSCサーバー です。

DSCサーバー が一番先に起動するということは、DSCサーバー自身の構成を担保してくれるサーバーはいないということです。

そのため、DSCサーバーが自分自身をノードとしてあるべき状態に構成する必要があります。

この時 PUSH を使って、↓の図のようにノードである自分自身をあるべき状態にします。

f:id:guitarrapc_tech:20141205003136p:plain

自動テスト環境

CM ツールのテストとは何でしょうか?何をテストするのかというと↓かと思います。

ノードが「あるべき状態」に構成されたのかをテストする

せっかくCMツールを使っても、リソースに書かれたどう構成するかのロジックや、コンフィグレーションに書いた あるべき状態の宣言が「正確にノードに適用」されなくては意味がありません。そのため、ノードがあるべき状態になったかのテストは重要です。

ServerSpec を使うことで Chef や Puppet のテストを行うのは一般的に行われています。DSC には当初決定版といえるテストツールがありませんでしたが、最近は Pester を使ってテストをすることが広まりつつあります。

Pester の詳細はアドベントカレンダー後半あたりで具体的に紹介しますが、BDD スタイルのテストを行える PowerShell モジュールです。

サーバーのテストは、構成やリソースをGithub にプッシュしたら自動的に実施される必要があります。そこで、次のような自動テストフローを行っています。

  1. GitHub へのプッシュ
  2. まっさらなインスタンスの起動を
  3. 「あるべき状態」を記述したコンフィグレーションとリソースをCIからDSCサーバーにデプロイ
  4. PUSH でノードをあるべき状態へ
  5. Pester でノードの状態をテスト
  6. テスト結果の通知
  7. インスタンスの削除

テストは 一度だけ実行すればよく、また任意のキックタイミングが取れる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の動作モードは↓の図を参考にどうぞ。

f:id:guitarrapc_tech:20141205010147p:plain

PULLの流れ

PUSHの逆で、ノードが能動的に動作します。

  1. ノード自身が勝手に自分のDSCサーバーにあるべき状態をしめした構成を問い合わせ
  2. 取得した構成を自分に適用して、自身の状態をあるべき状態に収束
  3. 構成の変化を監視
  4. 自分の構成が変化したとき、1-3を繰り返してあるべき状態へ収束、維持
  5. もし、DSCサーバーで「あるべき状態」を更新すると、ノードが構成をとりにきて自身をあるべき状態に収束
PULLの際にDSCサーバーが行うこと

ノードの逆で、受動的に動作します。

  1. あるべき状態の定義(コンフィグレーション)を書く
  2. ノードのロール用に構成適用ファイル(MOFファイル)を生成
  3. ノードが参照できる所定のパスに配置
  4. 3以降は、あるべき状態の変更がない限り対象のサーバーが勝手に取りに来るのを待つだけ
いつPULLを使うの?

PULLサーバーは、PUSHと違って「あるべき状態に自立的に収束する」ため、一度構成したら完全放置プレイができます。

このため、本番環境のように自動化が求められるシーンでは PULL が適しています。

  1. 動的にサーバーの台数が変化
  2. デプロイなどのたびにサーバーをすてて新しいサーバーを作る Immutable Infrastructureな環境 *6
  3. エラーがあってもあるべき状態に自動復旧してほしい本番環境
誤解がないように

PULLは「ノードが起点となって定期的にあるべき状態に収束」されます。

が、「DSCサーバーから、ノードに対して(任意のタイミングで)最新の構成を取得してあるべき状態に収束してね」と指示することもできます。

とはいえ、任意のタイミングでしか構成する必要がないなら PUSH を使うほうが素直でしょう。*7

まとめ

ぜひ、読まれてるアナタの環境が、PUSHPULL のどちらに向いているのか考えてみてください。

明日は、「DSC のエンジン的な役割を果たす」 Local Configuration Manager について説明します。

LCM が、PUSH や PULL の挙動を決めているので、まず PUSH や PULL って何?という説明が必要だったのでした。

*1:通信方法なども違いますがいったん置いておきます

*2:というか、PULLの記事が少ない

*3:むしろノードは待ち受けるだけ

*4:楽とは言っていない

*5:PSRemoting と CIMセッションは違うのですが、PSRemotingを有効にする際にCIMセッションも有効になるので詳細は省きます

*6:サーバーが捨てられる(Disposable Component)環境といい替えてもいいでしょう

*7:PULLから指示するには、いくつか問題となる理由があります。これは後日説明します