使って、仮想マシンをプロビジョンするところまでの方法をシェアしてみたいと思います。含めたインフラストラクチャの構成をコード化するのに便利です。統一できると便利かもしれません。Windowsのどれでも動作して、インストールも簡単なところが素敵です。あるユースケースである、VMをプロビジョンして、Chefをインストールするところまでをコード化してみたいと思います。インストールは大変簡単です。ページから、自分の環境にあったバイナリを落として、ディレクトリにパスを通せば終了です。他に何も必要ありません。ところにある、インストーラーをOS環境に合わせて落としておくとよいでしょう。今回はWindowsで実施しましたが、Macでも同じ手順で可能かと思います。ARMで使う時の認証の手順が一番楽ちんに設定できます。CLIを使います)説明は真壁さんのエントリに譲って、具体的な設定の手順だけシェアします。Directoryに対して、アプリケーションを登録して、アクセス許可を与えます。Code>のところに表示されているコードを入力して、その後ご自分のAzureアカウントでログインしてください。CLIのモードを変えておきます。Managerという新しいモードがありますので、当然新しいモードにしておきます。登録サービスプリンシプルは最初は面倒に感じるのですが、一旦次のオペレーションをすると本当に楽ちんです!最初の一回だけなので、楽しんでいきましょう。Directoryに登録するようなことをします。あなたの持っているブログとか何かのURLで結構です。他の人とかぶりがないものであればよいでしょう。ホームページとか登録とか「なんでやねん」と思いますが、サービスプリンプル認証では、「アプリケーションを登録」することになっているので本当にそのようなケースでは必要になります。Terraformでアクセスしたいだけなので、必須項目として入れる必要があるので入れているという程度の認識で結構です。使って今度は、サービスプリンシパルを作成します。Directoryでは、認証が可能なエンティティはすべて、プリンシパルとして表されます。ユーザやアプリケーションもプリンシパルです。アプリケーションが目的のサービスにアクセスするのに、サービスプリンシパルが使われます。アクセスするための、Terraform用のサービスプリンシプルを作成します。先ほどアプリケーションを登録した時にGetした、アプリケーションのIdを使います。これでサービスプリンシプルができました。OKこれで、Azureへのアクセスをするためのサービスプリンシパルが作成されました。次に、アクセス権を設定するため、ロール(役割)を割り当てます。ここでは、ContributorというAzureのサブスクリプションに対する権限を与えています。Id>にあなたのAzureのサブスクリプションを記入しましょう。listコマンドで、あなたが現在使っているサブスクリプションIDがわかると思います。この後必要なtenant_idを取得するために、次のコマンドを発行しましょう。すると、ご使用のサブスクリプションのIDのところにTenantIdが表示されます。テナントとは、何かを所有する人という意味です。コンフィグレーションファイルを作成します。全体のコードは、Gistにあげておきました。等の名前で保存します。次のように、terraform.tfvarというファイルを作ります。createで指定したパスワードです。この場合、Ubuntuですが、Ubuntuのデフォルトの、sudoユーザの名前のことです。パスワードも同じくですね。tenantId>"Gistにおいた、terraform.tfの中身の解説は、AZURERM_VIRTUAL_MACHINEあたりを読むと理解できると思います。Managerを触っておくと、理解が進みます。Managerの解説としては、次の安納さんのブログのエントリが一番わかりやすくて好きです。使ったプロビジョニングtfファイルとtfvarsのファイルがそろっていることを確認します。tfvarsのファイル名は、terraform.tfvarsである必要があるので注意してください。コマンドterraformの実行計画を作成します。こんな構成で、インフラ作りますというような情報が表示されます。いうファイルが作成されます。ちなみに、連続でプロビジョニングをしたい場合は、次のTipsをご参照ください。はまりどころがありますので整理しておきました。はまりどころとかもありますので、ご注意ください。accountの名前を変えることこれが最大のはまりどころです。applyを再実行すると、ストレージアカウントが作成されなくなります。途中でこのような表示がでて終わりません。これは推測なのですが、ストレージアカウント名は、ARMの時代になっても、リソースグループ単位ではなく、Azureでかぶっているとダメなようです。これを削除しても、その名前がどうやらしばらくは生きている様子です。(多分後でバッチで消える)ですので、削除したストレージアカウントを次の日だと使えるケースもあり、使えないケースもある、、、という雰囲気(私の実験による)という感じなので、ストレージアカウントを削除して再作成したい場合は、違う名前に変更するのが無難です。ストレージアカウントの名前を定義するのが、標準になっています。この件に関しては、TerraformのGitHubのIssueに報告しておきました。それが、destroyでも私が試したときはあかんかったですわ。コマンドが上手く動かないときは、terraform.tfstateとバックアップを削除するterraformのコマンドを実行してもうまく動作しないケースがあります。これは、まだ、ARMのProviderができて間もないこともあります。applyでできる下記のファイルを消せばいい感じで動作するようになります。リソースでは、os_profileの部分と、connectionの部分に、同じ、ユーザとパスワードを指定するため、当初は、connectionの部分は、${self.os_profile.*.admin_password}みたいな感じでデータを共有しようとしましたができませんでした。VMが出来上がってしまうと、そのような参照ができるのでしょうが、この段階ではVMを作成している途中なのでそれらの値が参照できないのでは?と推測しています。次の部分で解説する、varをメカニズムを使うとすっきり書けます。サブスクリプションや、パスワードを一元管理し、外だしするパスワードとか、サブスクリプションは、公開するファイルには書きたくないですよね?その場合は、次のvariablesのメカニズムを使うと便利です。固定なので、違う名前にしないでくださいね!tfファイルは違う名前でもOKです。planでて入力が求められます。Exec等を使う下記の部分ですね。このコマンドは、リモートでシェルを実行するコマンドの場合です。この例では、chefをワンライナーでインストールしています。他にもいろんなプロビジョナーがあるので、ご参照ください。applyを実施して、コマンドプロンプトを見るとこんな感じになります。表示されているラインの間隔があります。この間隔の部分をコピー&ペースとしてみると、実は何らかの文字が出力されています。黒くて見えないだけです。師匠がコメントくださりました。Codeが最近めっきりお気に入りです。両刀使いの私にとって、同じように動くのはうれしいです。あと、軽いのに、コード保管があるのはうれしいです。実際これで書くと、tfファイルを書いていると補完してくれるので楽でした。プロバイダーを使ってVMをブートして、何かをプロビジョニングするというユースケースを試してみました。使えるリソースが少ないとかの問題はありますが、DSLも書きやすいし、ARMのテンプレートまでデプロイできるし、なかなかいい感じです。Templateに軍配が上がると思いますが、今後どんどん便利になってくると思うので要注目です。どこでも安定して動くのは気持ちいですね!以上です。Tsuyoshi@TsuyoshiUshio@githubプログラマ。自分の学習用のブログです。内容は会社とは一切関係ありません。