Ansibleは、基盤となる技術としてPowerShellを使ったWindowsのサポートを追加した。数週間の間にリリースされるAnsible 1.7は、"ベータ"においてWindows統合を特徴にしている。InfoQは、Ansibleの作成者で、開発の詳細を知っているMichael DeHaan氏と話した。
ネイティブOSを管理する機能を使用するAnsibleの哲学に則ると、PowerShellとWindows Remote Management (WinRM)は、AnsibleがWindowsの管理に使用する基礎技術である。どちらとも最新バージョンのWindowsにネイティブに提供されており、それ以前のバージョンにもインストールすることができる。WinRMは、Ansibleのエージェントレスアプローチをを維持することを可能にするSSHと同等のものである。すべてのAnsibleのWindowsモジュールはPowerShellで書かれており、"Windowsユーザーが知っていて使用することができるツールで、みんながモジュールを書くことができる"。
すでに"win"から始まるWindowsを対象にしたいくつかのモジュールが存在している。これらのモジュールは、任意のPowerShellスクリプトの実行や、MSIとWindows機能のインストール、ユーザーの管理などの基本的な機能を提供している。slurp, raw, setupなどWindowsをサポートするいくつかの既存のモジュールも存在する。
AnsibleはLinuxとWindows の管理が可能な限りシームレスになるようにしている。同じAnsible playbookで、Linuxマシンを構成するステップと、Windowsマシンで他のステップを構成することができる。
新しくWindowsをサポートしているにもかかわらず、ドキュメントに書かれているように、Ansibleはまだ、Linux制御マシンを必要としている:
Windows制御マシンからAnsibleを実行するようにすることは、プロジェクトのゴールではありません。将来のメインプロジェクトで使用できる技術、機能、コードが制限されるため、この機能を要求から控えています。Linux制御マシンは、Windowsホストを管理するために必要になります。
追加のセキュリティが必要な場合、インストール時には、Linux制御マシンの必要性に加えて、リモート実行ポリシー、ファイアウォール構成、PowerShellリモーティングのためのHTTPSリスナーのような越えるべきいくつかのハードルがある。フリップ面では、それらのハードルは、PowerShellとWinRMを使用するすべてのシナリオで共通している。
コードはまだ、開発ブランチにあり、Windowsサポートは"アルファレベルであることを考慮するべきだが、かなり使える"。Ansible 1.7のリリース日に関する質問についてMichael氏は答えた:
現時点ではデータセットはありませんが、およそ1ヶ月程度で準備できる予定です。私たちは新モジュールの価格がリーズナブルになり、またさらに簡単なセットアッププロセスのスクリプトを持ってWindowsリリースを'ベータ'ステータスにしたいと考えています。
InfoQ: Microsoftが推奨するPowerShell Desired State Configuration (DSC)を使用しないことを選択したようですがなぜですか？
Michael: 私たちは実際にはDSCのサポートに非常にオープンだが、Ansibleが使うためには"オーケストレーション"と"タスクワークフロー"に関連する様々なことがあります。たとえばあなたがやりたいことは単に"このポリシーを適用する"ではなく"今 X をする"です。DSCは現在、特定のポリシーを適用するにはMOFファイルを経由するが、これらアドホックな管理するのにはフィットしません。
そのため、私たちは多くの管理者が知っているPowerShellをサポートしており、おそらくDSC構成を適用するためのモジュールを持つことになります。
覚えておくべき重要なことは、Ansibleがコンセプトをよりアクセスしやすくするように設計されているため、DSC周りをきちんと学習しなくてもWindowsのモジュールであるため、あなたがAnsibleを使用することができるはずです。
私たちはMicrosoftの様々な人たちと、DSCが将来できるであろうことや段階的なタスクに使うための能力、実装レイヤーとして使用する場合の納得度など、かなり頻繁に話しています。
InfoQ: IT自動化と構成管理をするときにLinux/Unixの世界とWindowsの世界で主な違いは何ですか？
Michael: ある有名なフレーズは"ボンネットが溶接された車を買いますか"ですが、これはLinuxに完全に公平ではありません。Linuxは、あなたがやりたいことをやるための基本的なフレームワークであるべきですが、その結果、(Ansibleのように)それを議論するためのツールのエコシステム全体を作ることになっています。Windowsはもう少し均一的ですが、柔軟性が少なくなっています - 通常、異なる特性を持つ50のオプションを持つのではなく、ひとつの論理的な方法を持っています。
両方を同じ環境で管理したいときに興味深いことがわかるでしょう。WindowsをWindowsのように感じたいと思い、LinuxをLinuxのように感じたいのですが、Ansibleはいずれのケースでも誤って適用しないように設定します。
InfoQ: あなたはPowerShellが時に矛盾を抱えていると言っていましたが、主な矛盾点はどこですか？
Michael: ケーシングやハイフンをどう扱うかと言った些細なことや、ハッシュとそれらに使われているプログラム言語をどのように処理するかと言ったことです。Powershellは非常に有能でアリ、すばらしいことにWindowsの世界の多くの管理者がすでに知っています。
すばらしいことはAnsibleのユーザーは、PowerShellを知っている必要がなく、単にモジュールがどう書かれているかだけでよいことです。ただし、ユーザーがPowerShellモジュールを書きたい、またはwin_scriptモジュールでPowerShellスクリプトをプッシュしたいだけの場合にもよいことです。
InfoQ: この開発を発表したとき、あなたは"クロスプラットフォームにしようとして、まだ提供していない多くの自動化プラットフォームを経験しているたくさんのユーザーと話した"と話していました。これらのプラットフォームは、お互いに共通の弱点を持っていますか？どのようにしてそのトラップを避けていますか？
Michael: ネイティブのPowerShellリモーティングを使うことがその中のひとつです。特別なソフトウェアをインストールしなくてもネイティブなMicrosoftソリューションを使うことができるということは、私たちは自分達のエージェントを維持することでAnsibleを継続することができることを意味します。私たちはすべてのWindows管理者が非常にアクセスしやすいWindowsリモーティング機能を使用しています - 特別なことをすることなく、OSの機能を使用するだけです。
私たちとしては、特別な客としてWindowsを扱うつもりはなく、ansibleの他のOSとしてそれを扱っており、それをするためにLinuxの抽象化を強要したりもしていません。
Microsoftが提供する強力な標準ライブラリであるため、PythonではなくPowerShellでモジュールを書いていることもそのひとつで、Windows管理者は彼らがやりたいことをすべてできる完全なアクセス権を持っている。
Michael氏はまた、コミュニティの貢献を促した: "多くのユーザーがこれに貢献していて、サポートの拡大に興味を持っている人たちは、ansible-developmentメーリングリストに立ち寄ってhi!と言ってください。"