前回もご紹介したのですが、ご縁があって書かせていただいた @IT Windows Server Insider様のDesired State Configuration (DSC) の超入門記事が完結したので記事にしてみます。
記事の目的、意図したことなどを、ほげもげ。
記事の目的
DSCにまず触ってもらうこと。です。
学習初期の情報が乏しい
自分自身がDSCを導入するにあたって、学習初期にいくつも問題と遭遇しました。
- そもそもなぜ DSCが必要なのかわからない - 何から手を付ければいいのか、初めの一歩がわからない - 初めの一歩やサンプルConfigurationがあっても、構築の流れが網羅されていない - Pushの例は多いけど、Pullをどうやるのかわからない - そもそもLCMってなに
今回の記事は、PowerShellやChefを使ったりしているけど、DSC使うのわからない方がDSCでPush/Pull構成を作れるまでを理解していただくことを最終的な目的としています。
この記事を見て、手元の環境を作ることでPush / Pullの環境がコードでさくっと作れるはず。です。*1
基礎的な知識の充足
今回の記事では、DSCの構成から、Local Configuration Managerのパラメータまで基本的な知識を抑えてあります。これらの知識は、さらにDSCを使いこなそうとするときに必須となるものです。
記事を通して環境を作ってみたり、パラメータを変えることで、より理解が進むことでしょう。
さらに DSCを学びたい人へ
PowerShell TeamもPowerShell.orgも他のMVPの方々の記事も素晴らしいので、進む際に是非見てみてください。
私も、ブログなどで記事を書いて紹介していきます。
Windows で Infrastructure as Code は一般的なのか
詳細の中編/後編を記事にするまでに、勉強会やde:codeでセッションをする機会をいただいたりしました。ありがとうございます。
セッションを通して感じたのは、PowerShell DSCを実際に環境で使うにまでの流れ、Infrastructure as Codeが想像以上にWindowsな環境では一般的でないのかということです。
もちろんやっている方も大勢なのでしょうが、少なくともLinuxで行われるようなコードベースの展開よりも、「System Centerを使ったり、GUIでぽちぽちする」というご意見をよく目にしました。
Infrastructure as code を主眼に
そこで記事では、意図的に Infrastructure as Code を主体にしました。
WindowsはGUIともマッチしているのがいい。というのはメリットの一面ですが、GUIの操作に依らないコードだけの方が、Chefと単純に比べたり理解が進むと考えたためです。 実際にコードを触る方が楽しい人は多いと信じていますが、そうじゃない方にとっては楽しくないです。 それでも、少しでもみなさんの学習の助けになれば幸いです。
DSC クロスプラットフォーム対応なのか
DSCは、CIM / MOFをベースにしているため、 Linux (omiとwsmanが有効になっていれば) に対してもPushが可能です。
現在はCTPリリースですがGitHubリポジトリもあるので興味のある方はぜひ。
一言いうなら、Pullはよ。
Windows は DSC でないといけないのか。
いいえ。ChefやPuppetもDSCを呼び出すことができます。Chefの方がクックブックレベルで統合されていますが。
DSCは、PowerShell TeamとChefエンジニアが密接な交流を経て生まれたプラットフォームです。
CMツールではなくプラットフォームなので、Chefのようにすべての面倒を見てくれるわけではありません。その代り、外部サービスがDSCを利用したり、他のCMツールがDSCを利用することが容易になっています。
事実、Chefもdsc cookbookを使うことで、Windowsに対してはDSC Resource/Configurationを利用できます。
GitHubリポジトリとスーパーマーケットにcookbookが公開されているのでぜひ遊んでみてください。
DSCにこだわる必要もないのです。ChefでもDSCでも使いやすい方を使えばいいです。
DSCがツールじゃないといって、できない。というわけではありません。初めから容易されていない部分を作る必要があるといっても、ちょっとした手助けで済みます。
最後に
これを機にWindowsでもInfrastructure as Codeをして幸せになれる方が増えることを祈っています。
Infrastructure as Codeは、Windowsでも現実のものなのです。テスト周りもいずれ記事にします。
余談 : 当初の予定
全2回の予定でした。内容も、もう少し簡素というか絞ってさっくりでした。
第1回を書き終えた後、前回の記事を読んだ担当編集様から、「文字数気にしないでいいのでもっと書いていいのよ」とやさしいお言葉を頂戴したのがターニングポイントでした。
セッションを通じて、簡素に書いても伝わらないと認識したため加筆しました。
第2回を書きおわったら、8000文字予定が24000文字になっていました。編集様ごめんなさい。
編集様のお心遣いで第2回を急きょ中編/後編に分割、前中後の3部構成にしていただいたという経緯があります。
改めて担当していただいた「U様、ありがとうございました」
*1:きっと。たぶん。手元で全コード動かして環境作ってます。
