tech.guitarrapc.cóm

Technical updates

PowerShell DSC Advent Calendar 2014 : Day 2 なぜ Configuration Management が必要なのか

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

1日目は、以下の2点を説明しました。

  • DSC は データセンターのあらゆる機器の Configuration Management(CM => 構成管理) Platform となることを志向していること *1
  • ただ構成管理ツールではなく、他の 構成管理ツール が呼び出すことにも使えるツールよりも広範なプラットフォームを目指していること

次に出てくるのが、そもそもなぜ構成管理が求められるのか だと思います。

そこで二日目は、構成管理(以下CM) が果たす役割 => DSC でやるべきことについて考えてみましょう。

目次

めんどくさい

極論はこれです。作ったインスタンスを本番環境で使えるようにするまでの手順は「めんどくさい」のです。CMツールを使うことでこのめんどくささが劇的に軽減されます。

Windows / Linux に関わらずですが、インスタンスを作ってから本番にいれて.... これ本当にやりたいですか?

  • 必要なソフトウェアや処理をする
  • 準備ができたら本番に投入する
  • 本番投入後異常があったら自動復旧されるように監視、処理をする

Webサーバーを例にさくっと表に書きだしてみましょう。表にないこともたくさんありますが、サンプルということで。

設定 維持
ソフトウェア(Windowsの機能追加) インストール ソフトウェが存在し続けること
レジストリ チューニング、設定後の再起動 値が維持されること
サービス(Daemon) 設定、開始されている エラーで一時停止しても開始されること
Webサイト Webサイトが存在すること 存在が保証され、開始し続けていること
ユーザー 適切なユーザー名/パスワードで存在していること ユーザーの存在を維持すること
Access Control List(ACL) セキュリティ規則が適切に設定されていること セキュリティ規則が維持されていること
NTP 正しいNTPサーバーを参照 NTPが常に参照、ntpdが開始していること

どうですか?やりたいですか?

やりたい人はお疲れ様でした、DSC や Chef を含めてCMツールを用いる必要がないほど洗練されているんだと思います。できれば教えてください(懇願)

やりたくない人、アナタワタシノトモダチね!一緒に楽をできるようにしましょう。

どうめんどくさいの

めんどくさいは大事です。では何がどうめんどくさいのか考えます。

設定がめんどくさい

例えば、WorkGroup 環境にユーザーを追加することを考えてみましょう。

スクリプトでの記述

スクリプトを書いてユーザーを追加しますか?さくっと走り書きしてみました。

実行時は、この程度でいいですか?

New-OSUser -Credential (Get-Credential -Credentail hoge) -Groups Administrators

スクリプトを書いた当人はそれでもいいかもしれません。が、仮にユーザーがすでに存在した時に、このスクリプトが繰り返し実行されて問題ない保証を考えると面倒ですね...。

「コードをみればいい」というのは事実ですが、繰り返し実行してもインスタンスの状態に影響しない(これを冪等性*2と呼びます) ことを前提にした仕組みの方が安心ですし、目先のコードや仕組みを考えるよりもっと本当にやりたいことに集中できると思いませんか?

DSC での記述

CM ツールの例として、DSC で「ユーザーが存在していてほしい」ことを書くとこのようになります。*3

大体Chef も似たような記述になります。

スクリプト同様に、CMツールは クックブック(Chef)/リソース(DSC) /プレイブック(Ansible)といわれるロジックは公開されており流用も作成もできます。

実際に利用するときに書くのは、レシピ(Chef)/コンフィグレーション(DSC)/yml (Ansible) と呼ばれる、「どう構成したいか」の設定だけです。

やりたいことに集中できるのは、大事、です。と思います。

維持がめんどくさい

先ほどのユーザー作成ですが、運用中必要なユーザーは途中で削除されたり設定が変わるのは望ましくないですよね?設定したように維持されていてほしいでしょう。

スクリプトの場合

先ほどのユーザー設定を適用するには、実行を自分でトリガーする必要がありました。多くの場合は、リモート先で実行する仕組みも準備する必要があります。

リモートからssh? PSRemoting? あるいは valentia を使いますか?できないことはないですね。ローカルで、シェルスクリプトやバッチ、PowerShellを回しますか?

でも、定期的に、確実に実行されるとなると面倒でしょう。cron や スケジュールタスクを使いますか?監視は.... ふむ。

もし構成の維持をやったことがない方は、思った以上に面倒なことに気づかれると思います。やはり仕組みとして、あるべき状態(Desired State) に自動的に構成 (Configuration) してくれるほうが楽です。

DSC での記述

CM ツールの例として先ほどのユーザー作成を考えてみましょう。

先ほど、ユーザーが作成されたのは、「ユーザーが存在していてほしい」時に、存在していなかった場合のみです。もし、すでにユーザーが存在していたら存在テストのみ行って設定はスキップされます。

CMツールの多くは、放っておくだけで、定期的に「あるべき状態を維持する」ように実行する仕組みを持っています。考えなくてよくて仕組みに乗っかるだけ。いいですね。

CM ツールはあるべき状態を維持する

CMツールは、自動化ツールのように一見みえますが、実際は 「あるべき状態を維持」するのが本質です。

そのため、状態を維持するために繰り返し実行を試みます。繰り返し実行しても影響がないように、冪等性をある程度念頭に置かれています。*4

設定と維持を分けて考えることがなく、自動的に状態が担保される。もし手元のバッチやスクリプト、シェルスクリプトでなんちゃって Infrastructure as Code *5をしているなら、めんどくささから大幅に解放してくれる可能性が大いにあります。

CMツールは、めんどくさがり屋の味方なのです。

あとは、DSC や Chef、Ansible など自分の使いやすいものを使えばいいでしょう。

CM ツールの選択

私の勤務している謎社は、IaaS としては、Windows Server 2012 R2 : Amazon Linux が 9:1 で構成されています。

Linux で、Chefを使っていて辛い目にあった人が多いので、残念ながら Chef はちょっと.... という() 状況でした。

しかし、Windows 環境をベースに運用をするにあたり、C# と PowerShell をメインに使っていることもあり、DSC に関してはスムーズに導入されました。

DSC の不足な機能は、valentia を使うことで補いやすくなることもあって、現在多くのバグや地雷を踏み抜きながらも安定して運用しています。*6

すでに Linux で Chef サーバーを運用しているなら、そのまま Chef を使えばいいでしょう。Windows インスタンスにChefを適用するときは、DSC クックブックを使うと楽でしょう。

環境によっては、Ansible もマッチしていることがあります。yml が、レシピやコンフィグレーションよりシンプルにかけることは多く、構成もシンプルなので 状況に合わせて選べばいいと思います。

Windows を使っているからといって Chef が向いていないというわけではなく、Windows のCMにはDSCを使ったり、DSC をChef から呼び出したりする方が楽なシーンが多いと思います。実際、頑張ってChefだけで書くより楽ですから、ね。

Disposable な環境と CMツール

実感としてCMツールが特に威力を発揮するのが、 Disposable な環境です。

Disposable な環境とは、サーバーをいつでも捨てて再構成できる環境といい替えれます。つまり、そこにあったサーバーが10秒後には破棄して、新しいインスタンスに差し変わっているような環境です。

Disposable な環境では、何か1台だけサーバーがおかしいなと監視結果からわかると、エラーの修復に頑張るよりさっさと破棄して新しい環境をすぐに用意できます。運用で最も手間がかかる障害対応が迅速に完了でき、常にフレッシュな環境が展開できるので、設定がサーバーによって異なることもありません。

しかしDisposable ということは、インスタンスを何度も何度も作ることになります。台数も容易に変更がかけれます、かかります、かけます。その度に、インストール、維持を構築しますか?今、どのサーバーが起動しているかいちいち把握しますか?

CMツールを使うことで、その環境が「あるべき状態」に勝手に維持されます。インスタンスを起動したら、自動的にソフトウェアやチューニング、サービスのインストール、維持がされます。圧倒的に楽で放置プレイ万歳です。

Disposable な環境なので、「1回だけ設定されれば?」というのもあるでしょう。が、まぁ状態が維持されるのもうれしいものです。仮想環境におけるNTPとか、ね。

でも、そんなに頑張る必要がないなら、Chef や DSC ではなく Ansible を使うのはいい選択でしょう。

Docker と CMツール

Docker などコンテナ型などの流行を受けても、まだ本当にCMツールが必要なのかというと、あるべきだと思います。

Docker イメージがあるべき状態に構成されたことを保証し、あとは Docker Hub からデプロイするだけでアプリの動作が保証されたコンテナが展開されるわけですから。

Windows版Docker はよ(迫真)

コンテナ型とか Disposable であっても、状態が維持されることの重要性は変わらないのです。

まとめ

CMツールはめんどくさがりやの仲間。です。*7

*1:真に OSや機器に制約されない クロスプラットフォーム、というにはまだまだほど遠いです。

*2:べきとうせい

*3:これ動作させるには証明書などを使わないといけないのですが、まぁ大体こんな感じということで。

*4:絶対ではありません。環境によってはクリーンイメージから構成して、1回だけ適用されればいいというケースもあります。

*5:MSはConfig as Codeと呼んでますね

*6:Configurationを新たに書くことなんて普段ありません。新しく何かしたい時だけです。普段はサーバーの状態は完全に自動化されています

*7:BootStrap/Configuration Management/Orchestration/Node Management について書くつもりでしたが飽きたのでやめます。