Windows 向け「はじめに」シリーズ第 3 回へようこそ。
前回の投稿では、Ansible と Ansible Tower を使用して Active Directory 環境を管理する方法を取り上げました。今回は、このようなマシンをドメインで設定する方法を説明します。この記事では、大部分を割いて特定のモジュールについて説明します。Ansible には、こちらに示すように非常に多くの Windows モジュールがあります。時間は無限ではないので、今このすべてを説明することはできません。そこで、よく使われる少数のモジュールに限定します。
MSI と win_package モジュール
ドメインを準備し、マシンを追加したので、今度はマシンにインストールする段階です。先に進む前に、ここで説明するモジュールについての注意事項がいくつかあります。モジュール win_msi は廃止され、Ansible 2.8 では削除されます (本記事の投稿時点では 2.5)。その代りに win_package を使用でき、この投稿ではこちらを使用します。
では、インストールの説明に戻りましょう。win_package モジュールがその処理を行います。具体的には、インストールまたはアンインストールが必要な .msi および .exe ファイルに使用されます。これらのファイルはローカルで、または URL やネットワークリソースから取得できます
モジュール内のパラメーターにより、柔軟性が大幅に向上します。Ansible 2.5 では、引数のリストを使用できるようになり、必要に応じてモジュールが引数をエスケープします。ただし、MSI パッケージを処理する場合は、MsiExec 固有のエスケープの問題があるため、文字列の使用を推奨します。
以下に、win_package モジュールの使用例を示します。最初の例は、Visual C++ をインストールし、引数をリストする方法を示しています。
- name: Install Visual C thingy with list of arguments instead of a string
win_package:
path:
http://download.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-B699-5E9B7962F9AE/VSU_4/vcredist_x64.exe
product_id: '{CF2BEA3C-26EA-32F8-AA9B-331F7E34BA97}'
arguments:
- /install
- /passive
- /norestart上の例では、プロダクト ID がリストされています。Ansible は、ローカルならば MSI から ID を抽出することができ、実際に抽出しますが、必要でない場合に MSI をホストで強制的にダウンロードさせたくありません。プロダクト ID を指定すると、Ansible はパッケージがインストール済みかどうかをすばやくチェックします。巨大な場合もある MSI をインターネットから前もってダウンロードする必要はありません。プロダクト ID がなくてもインストールできます。この例を以下に示します。
- name: Install Remote Desktop Connection Manager locally omitting the product_id
win_package:
path: C:\temp\rdcman.msi
state: present前述したように、ネットワーク共有からダウンロードして、この共有へのアクセスに必要な資格情報を指定することもできます。以下の例はその方法を示すもので、ネットワークリソースから 7-zip をインストールします。
- name: Install 7zip from a network share specifying the credentials
win_package:
path: \\domain\programs\7z.exe
product_id: 7-Zip
arguments: /S
state: present
user_name: DOMAIN\User
user_password: PasswordWindows パッケージ管理と Chocolatey
ほとんどの Linux ディストリビューションとは異なり、Windows には組み込みのパッケージマネージャーはありません。Windows には Windows App Store がありますが、これらの多数の製品がデータセンターを構成するようになるとは考えられません。
しかし、Chocolatey と呼ばれるコミュニティプロジェクトがあり、Windows ユーザー向けに完全なパッケージ管理を提供します。カスタマイズされていない setup.exe や .msi ファイルの管理に伴う不便さがいくらか解消されます。そしてご想像のとおり、このためのモジュールがあります。
モジュールの詳細に踏み込む前に、Chocolatey についてもう少し説明しましょう。例えるなら、Chocolatey は Mac ユーザーにとっての Homebrew と言えます。Chocolatey は、Windows ソフトウェア (インストーラー、zip アーカイブ、ランタイムバイナリ、内部およびサードパーティのソフトウェア) のあらゆる処理を、バージョン管理と依存関係の両方の要件を満たすパッケージフレームワークを使用して、容易に実行できるように設計されています。
Chocolatey モジュールは使用方法において Unix 系の対応するモジュールと同じく、シンプルかつ強力です。バージョンに関してはソフト要件もあります。ソフト要件とは、実行するには v. 0.10.5 が必要だが、Chocolatey でそのバージョンが認識されない場合、自動的にアップデートされるという意味です。さらに便利な機能として、Chocolatey がマシン上にない場合は、モジュールが、割り当てられたタスクを実行する前に Chocolatey を自動的にインストールしてくれます。
モジュールを使い始める最も簡単な方法は、軽量の CLI ツールをインストールすることです。どの方法でもワークフローは同じなので、Git を使いましょう。
- name: Install git
win_chocolatey:
name: git
state: presentともかく、Git のインストールはこんなに簡単です。何かの特定のバージョンが必要なら、そのバージョンも同じくらい簡単にインストールできます。たとえば、Notepad++ バージョン 6.6 が必要だとします。コードは以下のようになります。
- name: Install notepadplusplus version 6.6
win_chocolatey:
name: notepadplusplus
version: '6.6'バージョンを指定する場合は、文字列として入力するということが重要です (6.6 がシングルクォートで囲まれていることに注意してください)。その理由は、文字列として入力しないと YAML の`float`と解釈されてしまうからです。有効なバージョン番号の多くは `float` に適切に変換されず、同じ結果が生成されます (例：ほとんどのバージョン管理方式では '6.10' != '6.1' だが、`float` としての 6.10 は 6.1 になる)。そのため、常にバージョン番号をクォートで囲んで、再フォーマットされないようにすることを推奨します。
一部のパッケージでは、インストールに対話的なユーザーログオンが必要となることがあります。正しい権限情報を渡すため、become を使用して実行することができます。以下の例では、become を使う必要があるパッケージのインストールを示しています。become: System を指定できますが、この場合はパスワードを指定する必要はありません。
- name: Install a package that requires 'become'
win_chocolatey:
name: officepro2013
become: yes
become_user: Administrator
become_method: runaswin_chocolatey モジュールは強力でパワフルですが、become がなければ機能しない事例もあります。パッケージに become が必要かどうか簡単に見極める方法はないので、become を使わずに試してみて、うまくいかなければ使うという方法をお勧めします。
Windows 自動化におけるパッケージと中身
このブログ投稿では、Windows 環境でパッケージのインストールを自動化する 2 つの方法を説明しました。Chocolatey を使用する場合でも、何らかのパッケージをインストールする必要がある場合でも、Ansible にはそのすべての処理をシンプルで可読性の高い形式で実行し、さらにそれ以上の機能があります。
次回の投稿は Windows 自動化の「はじめに」シリーズの締めくくりとして、Ansible を使用した Windows でのセキュリティとアップデートについて紹介します。
