13 Sep 2016, 17:30

Azure Functionsで運用管理サーバレス生活(使用量データ取得編)

背景と動機

Azure Functions使ってますか。「サーバレス」という、ネーミングに突っ込みたい衝動を抑えられないカテゴリに属するため損をしている気もしますが、システムのつくり方を変える可能性がある、潜在能力高めなヤツです。キャッチアップして損はないです。

さて、Azure Functionsを使ってAzureの使用量データを取得、蓄積したいというリクエストを最近いくつかいただきました。いい機会なのでまとめておきます。以下、その背景。

  • 運用管理業務がビジネスの差別化要素であるユーザは少ない。可能な限り省力化したい。運用管理ソフトの導入維持はもちろん、その土台になるサーバの導入、維持は真っ先に無くしたいオーバヘッド。もうパッチ当てとか監視システムの監視とか、やりたくない。
  • Azure自身が持つ運用管理の機能が充実し、また、運用管理SaaS(MS OMS、New Relic、Datadogなど)が魅力的になっており、使い始めている。いつかは運用管理サーバを無くしたい。
  • でも、それら標準的なサービスでカバーされていない、ちょっとした機能が欲しいことがある。
  • Azureリソースの使用量データ取得が一例。Azureでは使用量データをポータルからダウンロードしたり、Power BIで分析できたりするが、元データは自分でコントロールできるようためておきたい。もちろん手作業なし、自動で。
  • ちょっとしたコードを気軽に動かせる仕組みがあるなら、使いたい。インフラエンジニアがさくっと書くレベルで。
  • それAzure Functionsで出来るよ。

方針

  • Azure FunctionsのTimer Triggerを使って、日次で実行
  • Azure Resource Usage APIを使って使用量を取得し、ファイルに書き込み
  • Nodeで書く (C#のサンプルはたくさんあるので)
  • 業務、チームでの運用を考慮して、ブラウザでコード書かずにソース管理ツールと繋げる (Githubを使う)

Quick Start

準備

  • ところでAzure Funtionsって何よ、って人はまずいい資料1いい資料2でざっと把握を
  • AzureのAPIにプログラムからアクセスするため、サービスプリンシパルを作成 (こことかここを参考に)
    • 後ほど環境変数に設定するので、Domain(Tenant ID)、Client ID(App ID)、Client Secret(Password)、Subscription IDを控えておいてください
    • 権限はsubscriptionに対するreaderが妥当でしょう
  • Githubのリポジトリを作成 (VSTSやBitbucketも使えます)
  • 使用量データを貯めるストレージアカウントを作成
    • 後ほど環境変数に設定するので、接続文字列を控えておいてください

デプロイ

  • Function Appを作成
    • ポータル左上”+新規” -> Web + モバイル -> Function App
    • アプリ名は.azurewebsites.net空間でユニークになるように
    • App Seriviceプランは、占有型の”クラシック”か、共有で実行したぶん課金の”動的”かを選べます。今回の使い方だと動的がお得でしょう
    • メモリは128MBあれば十分です
    • 他のパラメータはお好みで
  • 環境変数の設定
    • Function Appへポータルからアクセス -> Function Appの設定 -> アプリケーション設定の構成 -> アプリ設定
    • 先ほど控えた環境変数を設定します(CLIENT_ID、DOMAIN、APPLICATION_SECRET、AZURE_SUBSCRIPTION_ID、azfuncpoc_STORAGE)
  • サンプルコードを取得
  • 準備済みのGithubリポジトリにpush
  • リポジトリとFunction Appを同期
    • Function Appへポータルからアクセス -> Function Appの設定 -> 継続的インテグレーションの構成 -> セットアップ
    • Githubリポジトリとブランチを設定し、同期を待ちます
  • Nodeのモジュールをインストール
    • Function Appへポータルからアクセス -> Function Appの設定 -> kuduに移動 -> site/wwwroot/getUsageData へ移動
    • このディレクトリが、実行する関数、functionの単位です
    • “npm install” を実行 (package.jsonの定義に従ってNodeのモジュールが”node_modules”へインストールされます)
    • deploy.cmd で自動的にインストールするよう変えました

これで、指定ストレージアカウントの”usagedata”コンテナに日次で使用量データファイルができます。

コード解説

3つのファイルをデプロイしました。簡単な順に、ざっと解説します。コードを眺めながら読み進めてください。

package.json

主となるコードファイルは後述の”index.js”ですが、その動作に必要な環境を定義します。依存モジュールのバージョンの違いでトラブらないよう、dependenciesで指定するところがクライマックスです。

function.json

Azure Functionsの特徴である、TriggerとBindingsを定義します。サンプルはTimer Triggerなので、実行タイミングをここに書きます。”schedule”属性に、cron形式({秒}{分}{時}{日}{月}{曜日})で。

“0 0 0 * * *” と指定しているので、毎日0時0分0秒に起動します。UTCです。

index.js

メインロジックです。

  • 先ほど設定した環境変数は、”process.env.HOGE”を通じ実行時に読み込まれます。認証関連情報はハードコードせず、このやり口で。
  • 日付関連処理はUTCの明示を徹底しています。Azure Functions実行環境はUTCですが、ローカルでのテストなど他環境を考えると、指定できるところはしておくのがおすすめです。これはクラウドでグローバル展開する可能性があるコードすべてに言えます。
  • 0時に起動しますが、使用量データ作成遅延の可能性があるので、処理対象は2日前です。お好みで調整してください。詳細仕様はこちら
  • module.export からが主フローです。asyncを使って、Blobコンテナの作成、使用量データ取得&ファイル書き込みを、順次処理しています。後ほど豆知識で補足します。
  • 最後にcontext.done()でFunctionsに対してアプリの終了を伝えます。黙って終わるような行儀の悪い子は嫌いです。
  • ヘルパー関数たちは最後にまとめてあります。ポイントはcontinuationTokenを使ったループ処理です。
    • Resource Usage API は、レスポンスで返すデータが多い場合に、途中で切って「次はこのトークンで続きからアクセスしてちょ」という動きをします。
    • ループが2周目に入った場合は、データを書きだすファイルが分かれます。フォーマットは”YYYY-MM-DD_n.json”です。

豆知識 (Node on Azure Functions)

  • 通信やI/Oの関数など、非同期処理の拾い忘れ、突き抜けに注意してください
    • NodeはJavascript、シングルスレッドなので時間のかかる処理でブロックしないのが基本です
    • Azure FunctionsはNode v6.4.0が使えるのでES6のpromiseが書けるのですが、SDKがまだpromiseをサポートしていないので、サポートされるまではcallbackで堅く書きましょう
  • Nodeに限った話ではないですが、Azure Functions Timer TriggerはInput/Output Bindingと組み合わせられません
    • サポートマトリックスを確認しましょう
    • なのでサンプルではOutput Binding使わずに書きました
    • Input/Outputを使える他のTriggerでは、楽なのでぜひ活用してください

豆知識 (Azure Usage API)

  • Resource Usage APIは使用量のためのAPIなので、料金に紐づけたい場合は、Ratecard APIを組み合わせてください

それでは、幸せな運用管理サーバレス生活を。

25 Aug 2016, 16:00

OMSでLinuxコンテナのログを分析する

OMS Container Solution for Linux プレビュー開始

OMS Container Solution for Linuxのプレビューがはじまりました。OMSのログ分析機能は500MB/日のログ転送まで無料で使えるので、利用者も多いのではないでしょうか。

さて、このたびプレビュー開始したLinuxコンテナのログ分析機能、サクッと使えるので紹介します。まだプレビューなので、仕様が変わったらごめんなさい。

何ができるか、とその特徴

  • Dockerコンテナに関わるログの収集と分析、ダッシュボード表示
  • 導入が楽ちん
    1. OMSエージェントコンテナを導入し、コンテナホスト上のすべてのコンテナのログ分析ができる
    2. コンテナホストに直接OMS Agentを導入することもできる

1がコンテナ的でいいですよね。実現イメージはこんな感じです。

OMS Agent Installation Type

これであれば、CoreOSのような「コンテナホストはあれこれいじらない」というポリシーのディストリビューションにも対応できます。

では試しに、1のやり口でUbuntuへ導入してみましょう。

手順

  • OMSのログ分析機能を有効化しワークスペースを作成、IDとKeyを入手 (参考)
  • OMSポータルのソリューションギャラリーから、”Containers”を追加
  • UbuntuにDockerを導入
    • 参考
    • 現在、OMSエージェントが対応するDockerバージョンは 1.11.2までなので、たとえばUbuntu 16.04の場合は sudo apt-get install docker-engine=1.11.2-0~xenial とするなど、バージョン指定してください
  • OMSエージェントコンテナを導入
    • 先ほど入手したOMSのワークスペースIDとKeyを入れてください
sudo docker run --privileged -d -v /var/run/docker.sock:/var/run/docker.sock -e WSID="your workspace id" -e KEY="your key" -h=`hostname` -p 127.0.0.1:25224:25224/udp -p 127.0.0.1:25225:25225 --name="omsagent" --log-driver=none --restart=always microsoft/oms

以上。これでOMSポータルからログ分析ができます。こんな感じで。

Dashboard1

Dashboard2

なんと簡単じゃありませんか。詳細が気になるかたは、こちらから。

なお、フィードバック熱烈歓迎だそうです。

22 Jun 2016, 15:00

Docker for WindowsでインストールレスAzure CLI環境を作る

舌の根の乾かぬ内に

最近、VagrantとVirualBoxで似たようなやり口を紹介しましたが、気にしないでください。テクノロジーの進化は早い。

動機

  • Docker for Windows(on Client Hyper-V)のベータが一般開放された
  • Dockerもそうだが、Hyper-V前提のツールが今後増えそう、となると、それとぶつかるVirtualBoxをぼちぼちやめたい
  • 月一ペースでアップデートされるAzure CLIをいちいちインストールしたくない、コンテナ引っ張って以上、にしたい
  • 開発端末の環境を汚したくない、いつでもきれいに作り直せるようにしたい
  • ○○レスって言ってみたかった

やり口

  • もちろんDocker for Windows (on Client Hyper-V) を使う
  • いちいちdocker run…と打たなくていいよう、エイリアス的にPowerShellのfunction “azure_cli” を作る
  • “azure_cli”入力にてAzure CLIコンテナを起動
  • コンテナとホスト(Windows)間でファイル共有、ホスト側のIDEなりエディタを使えるようにする

作業の中身

  • Docker for Windowsをインストール
    • 64bit Windows 10 Pro/Enterprise/Education 1511以降に対応
    • Hyper-Vの有効化を忘れずに
    • Hyper-VとぶつかるVirtualBoxとはお別れです
    • Docker for Windowsの起動時にIPをとれないケースがありますが、その場合はsettings -> Network から、設定変えずにApplyしてみてください。いまのところこれで対処できています。この辺はベータなので今後の調整を期待しましょう。
    • 共有ドライブも共有が外れていることが。settings -> Shared Drives で共有しなおしてください。
  • PowerShell functionを作成
    • のちほど詳しく

PowerShellのfunctionを作る

ここが作業のハイライト。

PowerShellのプロファイルを編集します。ところでエディタはなんでもいいのですが、AzureやDockerをがっつり触る人にはVS Codeがおすすめです。Azure Resource Manager TemplateDockerむけextensionがあります。

PS C:\Workspace\dockereval\arm> code $profile

こんなfunctionを作ります。

function azure_cli {
   C:\PROGRA~1\Docker\Docker\Resources\bin\docker.exe run -it --rm -v ${HOME}/.azure:/root/.azure -v ${PWD}:/data -w /data microsoft/azure-cli:latest
}
  • エイリアスでなくfunctionにした理由は、引数です。エイリアスだと引数を渡せないので
  • コンテナが溜まるのがいやなので、–rmで都度消します
  • 毎度 azure login しなくていいよう、トークンが保管されるコンテナの/root/azureディレクトリをホストの${HOME}/.azureと-v オプションで共有します
  • ARM TemplateのJSONファイルなど、ホストからファイルを渡したいため、カレントディレクトリ ${PWD} をコンテナと -v オプションで共有します
  • コンテナはdocker hubのMicrosoft公式イメージ、latestを引っ張ります。latestで不具合あればバージョン指定してください

ではテスト。まずはホスト側のファイルを確認。

PS C:\Workspace\dockereval\arm> ls


    ディレクトリ: C:\Workspace\dockereval\arm


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       2016/06/22     11:21                subd
-a----       2016/06/22     10:26           8783 azuredeploy.json
-a----       2016/06/22     11:28            690 azuredeploy.parameters.json

いくつかのファイルとサブディレクトリがあります。

コンテナを起動してみましょう。azure_cli functionを呼びます。

PS C:\Workspace\dockereval\arm> azure_cli
root@be41d3389a21:/data#

コンテナを起動し、入出力をつなぎました。ここからは頭と手をLinuxに切り替えてください。公式Azure CLIコンテナはdebianベースです。

ファイル共有できているか確認。

root@be41d3389a21:/data# ls
azuredeploy.json  azuredeploy.parameters.json  subd

できてますね。

azureコマンドが打てるか確認。

root@be41d3389a21:/data# azure -v
0.10.1

しあわせ。

21 May 2016, 11:00

Azure X-Plat CLIでResource Policyを設定する

Azure X-Plat CLIのリリースサイクル

OSS/Mac/Linux派なAzurerの懐刀、Azure X-Plat CLIのリリースサイクルは、おおよそ月次です。改善と機能追加を定期的にまわしていくことには意味があるのですが、いっぽう、Azureの機能追加へタイムリーに追随できないことがあります。短期間とはいえ、次のリリースまで空白期間ができてしまうのです。

たとえば、今回のテーマであるResource Policy。GA直後に公開されたドキュメントに、X-Plat CLIでの使い方が2016/5/21現在書かれていません。おやCLIではできないのかい、と思ってしまいますね。でもその後のアップデートで、できるようになりました。

機能リリース時点ではCLIでできなかった、でもCLIの月次アップデートで追加された、いまはできる、ドキュメントの更新待ち。こんなパターンは多いので、あきらめずに探ってみてください。

ポリシーによるアクセス管理

さて本題。リソースの特性に合わせて、きめ細かいアクセス管理をしたいことがあります。

  • VMやストレージのリソースタグに組織コードを入れること強制し、費用負担の計算に使いたい
  • 日本国外リージョンのデータセンタを使えないようにしたい
  • Linuxのディストリビューションを標準化し、その他のディストリビューションは使えなくしたい
  • 開発環境リソースグループでは、大きなサイズのインスタンスを使えないようにしたい

などなど。こういう課題にポリシーが効きます。

従来からあるRBACは「役割と人」目線です。「この役割を持つ人は、このリソースを読み取り/書き込み/アクションできる」という表現をします。組み込みロールの一覧を眺めると、理解しやすいでしょう。

ですが、RBACは役割と人を切り口にしているので、各リソースの多様な特性にあわせた統一表現が難しいです。たとえばストレージにはディストリビューションという属性はありません。無理してカスタム属性なんかで表現すると破綻しそうです。

リソース目線でのアクセス管理もあったほうがいい、ということで、ポリシーの出番です。もちろんRBACと、組み合わせできます。

X-Plat CLIでの定義方法

2016/4リリースのv0.9.20から、X-Plat CLIでもResource Policyを定義できます。

ポリシーの定義、構文はPowerShellと同じなので、公式ドキュメントに任せます。ご一読を。

ポリシーを使用したリソース管理とアクセス制御

X-Plat CLI固有部分に絞って紹介します。

ポリシー定義ファイルを作る

CLIでインラインに書けるようですが、人類には早すぎる気がします。ここではファイルに。

例として、作成できるVMのサイズを限定してみましょう。開発環境などでよくあるパターンと思います。VM作成時、Standard_D1~5_v2に当てはまらないVMサイズが指定されると、拒否します。

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "not": {
          "field": "Microsoft.Compute/virtualMachines/sku.name",
          "in": [ "Standard_D1_v2", "Standard_D2_v2","Standard_D3_v2", "Standard_D4_v2", "Standard_D5_v2" ]
        }
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

policy_deny_vmsize.json というファイル名にしました。では投入。ポリシー名は deny_vmsize とします。

$ azure policy definition create -n deny_vmsize -p ./policy_deny_vmsize.json
info:    Executing command policy definition create
+ Creating policy definition deny_vmsize
data:    PolicyName:             deny_vmsize
data:    PolicyDefinitionId:     /subscriptions/mysubscription/providers/Microsoft.Authorization/policyDefinitions/deny_vmsize
data:    PolicyType:             Custom
data:    DisplayName:
data:    Description:
data:    PolicyRule:             allOf=[field=type, equals=Microsoft.Compute/virtualMachines, field=Microsoft.Compute/virtualMachines/sku.name, in=[Standard_D1_v2, Standard_D2_v2, Standard_D3_v2, Standard_D4_v2, Standard_D5_v2]], effect=deny
info:    policy definition create command OK

できたみたいです。

ポリシーをアサインする

では、このポリシーを割り当てます。割り当ての範囲(スコープ)はサブスクリプションとします。リソースグループなど、より細かいスコープも指定可能です。

$ azure policy assignment create -n deny_vmsize_assignment -p /subscriptions/mysubscription/providers/Microsoft.Authorization/policyDefinitions/deny_vmsize -s /subscriptions/mysubscription
info:    Executing command policy assignment create
+ Creating policy assignment deny_vmsize_assignment
data:    PolicyAssignmentName:     deny_vmsize_assignment
data:    Type:                     Microsoft.Authorization/policyAssignments
data:    DisplayName:
data:    PolicyDefinitionId:       /subscriptions/mysubscription/providers/Microsoft.Authorization/policyDefinitions/deny_vmsize
data:    Scope:                    /subscriptions/mysubscription
info:    policy assignment create command OK

割り当て完了。では試しに、このサブスクリプションに属するユーザで、Gシリーズのゴジラ級インスタンスを所望してみます。

$ azure vm quick-create -g RPPoC -n rppocvm westus -y Linux -Q "canonical:ubuntuserver:14.04.4-LTS:latest" -u "adminname" -p "adminpass" -z Standard_G5
info:    Executing command vm quick-create
[...snip]
+ Creating VM "rppocvm"
error:   The resource action 'Microsoft.Compute/virtualMachines/write' is disallowed by one or more policies. Policy identifier(s): '/subscriptions/mysubscription/providers/Microsoft.Authorization/policyDefinitions/deny_vmsize'.
info:    Error information has been recorded to /root/.azure/azure.err
error:   vm quick-create command failed

拒否られました。

許可されているVMサイズだと。

$ azure vm quick-create -g RPPoC -n rppocvm westus -y Linux -Q "canonical:ubuntuserver:14.04.4-LTS:latest" -u "adminname" -p "adminpass" -z Standard_D1_v2
info:    Executing command vm quick-create
[...snip]
info:    vm quick-create command OK

成功。

13 May 2016, 18:00

VagrantとDockerによるAzure向けOSS開発・管理端末のコード化

端末だってコード化されたい

Infrastructure as Codeは特に騒ぐ話でもなくなってきました。このエントリは、じゃあ端末の開発環境やツール群もコード化しようという話です。結論から書くと、VagrantとDockerを活かします。超絶便利なのにAzure界隈ではあまり使われてない印象。もっと使われていいのではと思い、書いております。

解決したい課題

こんな悩みを解決します。

  • WindowsでOSS開発環境、Azure管理ツールのセットアップをするのがめんどくさい
  • WindowsもMacも使っているので、どちらでも同じ環境を作りたい
  • サーバはLinuxなので手元にもLinux環境欲しいけど、Linuxデスクトップはノーサンキュー
  • 2016年にもなって長いコードをVimとかEmacsで書きたくない
  • Hyper-VとかVirtualboxで仮想マシンのセットアップと起動、後片付けをGUIでするのがいちいちめんどくさい
  • 仮想マシン起動したあとにターミナル起動->IP指定->ID/Passでログインとか、かったるい
  • Azure CLIやTerraformなどクラウド管理ツールの進化が頻繁でつらい(月一回アップデートとか)
  • でもアップデートのたびに超絶便利機能が追加されたりするので、なるべく追いかけたい
  • 新メンバーがチームに入るたび、セットアップが大変
  • 不思議とパソコンが生えてくる部屋に住んでおり、セットアップが大変
  • 毎度作業のどこかが抜ける、漏れる、間違う 人間だもの

やり口

VagrantとDockerで解決します。

  • Windows/Macどちらにも対応しているVirtualboxでLinux仮想マシンを作る
  • Vagrantでセットアップを自動化する
  • Vagrantfile(RubyベースのDSL)でシンプルに環境をコード化する
  • Vagrant Puttyプラグインを使って、Windowsでもsshログインを簡素化する
  • 公式dockerイメージがあるツールは、インストールせずコンテナを引っ張る
  • Windows/MacのいまどきなIDEなりエディタを使えるようにする

セットアップ概要

簡単す。

  1. Virtualboxをインストール
  2. Vagrantをインストール
  3. Vagrant Putty Plugin(vagrant-multi-putty)をインストール #Windowsのみ。Puttyは別途入れてください
  4. 作業フォルダを作り、Vagrant ファイルを書く

もしWindowsでうまく動かない時は、Hyper-Vが有効になっていないか確認しましょう。Virtualboxと共存できません。

サンプル解説

OSSなAzurerである、わたしのVagrantfileです。日々環境に合わせて変えてますが、以下は現時点でのスナップショット。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

$bootstrap=<<SCRIPT

#Common tools
sudo apt-get update
sudo apt-get -y install wget unzip jq

#Docker Engine
sudo apt-get -y install apt-transport-https ca-certificates
sudo apt-get -y install linux-image-extra-$(uname -r)
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
sudo sh -c "echo deb https://apt.dockerproject.org/repo ubuntu-trusty main > /etc/apt/sources.list.d/docker.list"
sudo apt-get update
sudo apt-get -y purge lxc-docker
sudo apt-cache policy docker-engine
sudo apt-get -y install docker-engine=1.11.1-0~trusty
sudo gpasswd -a vagrant docker
sudo service docker restart

#Docker Machine
sudo sh -c "curl -L https://github.com/docker/machine/releases/download/v0.7.0/docker-machine-`uname -s`-`uname -m` >/usr/local/bin/docker-machine && chmod +x /usr/local/bin/docker-machine"

#Azure CLI
echo "alias azure='docker run -it --rm -v \\\$HOME/.azure:/root/.azure -v \\\$PWD:/data -w /data microsoft/azure-cli:latest azure'" >> $HOME/.bashrc

#Terraform
echo "alias terraform='docker run -it --rm -v \\\$PWD:/data -w /data hashicorp/terraform:0.6.14'" >> $HOME/.bashrc

#Packer
echo "alias packer='docker run -it --rm -v \\\$PWD:/data -w /data hashicorp/packer:latest'" >> $HOME/.bashrc

#nodebrew
curl -L git.io/nodebrew | perl - setup
echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> $HOME/.bashrc
$HOME/.nodebrew/current/bin/nodebrew install-binary 5.9.1
$HOME/.nodebrew/current/bin/nodebrew use 5.9.1

#Python3
wget -qO- https://bootstrap.pypa.io/get-pip.py | sudo -H python3.4

SCRIPT

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # Every Vagrant virtual environment requires a box to build off of.

  config.vm.box = "ubuntu/trusty64"

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.

  config.vm.network "private_network", ip: "192.168.33.10"

  config.vm.provider "virtualbox" do |vb|
     vb.customize ["modifyvm", :id, "--memory", "2048"]
  end

  config.vm.provision :shell, inline: $bootstrap, privileged: false

end

$bootstrap=<<SCRIPT から SCRIPT が、プロビジョニングシェルです。初回のvagrant up時とvagrant provision時に実行されます。

Common tools

一般的なツールをaptでインストールします。wgetとかjqとか。

Docker Engine & Machine

この後前提となるDockerをインストール。Dockerのバージョンは1.11.1を明示しています。Dockerは他への影響が大きいので、バージョンアップは慎重めの方針です。

Azure CLI

インストールせずにMS公式のDockerイメージを引っ張ります。なのでalias設定だけ。 -v オプションで、ホストLinuxとコンテナ間でデータを共有します。CLIが使う認証トークン($HOME/.azure下)やCLI実行時に渡すjsonファイル(作業ディレクトリ)など。詳細は後ほど。 また、azureコマンド発行ごとにコンテナが溜まっていくのがつらいので、–rmで消します。

Terraform & Packer

Azure CLIと同様です。Hashicorpが公式イメージを提供しているので、それを活用します。 方針はlatest追いですが、不具合があればバージョンを指定します。たとえば、現状Terraformのlatestイメージに不具合があるので、0.6.14を指定しています。 -v オプションもAzure CLIと同じ。ホストとコンテナ間のファイルマッピングに使います。

なお、公式とはいえ他人のイメージを使う時には、Dockerfileの作りやビルド状況は確認しましょう。危険がデンジャラスですし、ENTRYPOINTとか知らずにうっかり使うと途方に暮れます。

nodebrew

nodeのバージョンを使い分けるため。セットアップ時にv5.9.1を入れています。Azure Functions開発向け。

Python3

Ubuntu 14.04では標準がPython2なので別途入れてます。Azure Batch向け開発でPython3使いたいので。

みなさん他にもいろいろあるでしょう。シェルなのでお好みで。

さて、ここまでがプロビジョニング時の処理です。以降の”Vagrant.configure~”は仮想マシンの定義で、難しくありません。ubuntu/trusty64(14.04)をboxイメージとし、IPやメモリを指定し、先ほど定義したプロビジョニング処理を指しているだけです。

どれだけ楽か

では、環境を作ってみましょう。Vagrantfileがあるフォルダで

vagrant up

仮想マシンが作成されます。初回はプロビジョニング処理も走ります。

できましたか。できたら、

vagrant putty

はい。Puttyが起動し、ID/Passを入れなくてもsshログインします。破壊力抜群。わたしはこの魅力だけでTeraterm(Terraformではない)からPuttyに乗り換えました。ちなみにMacでは、vagrant sshで済みます。

あとはプロビジョニングされたLinuxを使って楽しんでください。そして、必要なくなったら or 作り直したくなったら

vagrant destroy

綺麗さっぱりです。仮想マシンごと消します。消さずにまた使う時は、vagrant haltを。

なお、vagrant upしたフォルダにあるファイルは、Virtualboxの共有フォルダ機能で仮想マシンと共有されます。shareとかいう名のフォルダを作って、必要なファイルを放り込んでおきましょう。その場合、仮想マシンのUbuntuからは/vagrant/shareと見えます。双方向で同期されます。

わたしは長いコードを書くときは、Windows/Mac側のIDEなりエディタを使って、実行は仮想マシンのLinux側、という流れで作業しています。

ちなみに、改行コードの違いやパーミッションには気を付けてください。改行コードはLFにする癖をつけておくと幸せになれます。パーミッションは全開、かつ共有領域では変えられないので、問題になるときは仮想マシン側で/vagrant外にコピーして使ってください。パーミッション全開だと怒られる認証鍵など置かないよう、注意。

また、Dockerコンテナを引っ張るAzure CLI、Terraform、Packerの注意点。

  • 初回実行時にイメージのPullを行うので、帯域の十分なところでやりましょう
  • サンプルでは -v $PWD:/data オプションにて、ホストのカレントディレクトリをコンテナの/dataにひもづけています。そして、-w /data にて、コンテナ内ワーキングディレクトリを指定しています。コマンドの引数でファイル名を指定したい場合は、実行したいファイルがあるディレクトリに移動して実行してください
    • (例) azure group deployment create RG01 DEP01 -f ./azuredeploy.json -e ./azuredeploy.parameters.json

Bash on Windowsまで待つとか言わない

「WindowsではOSSの開発や管理がしにくい。Bash on Windowsが出てくるまで待ち」という人は、待たないで今すぐGoです。思い立ったが吉日です。繰り返しますがVagrantとDocker、超絶便利です。

インフラのコード化なんか信用ならん!という人も、まず今回紹介したように端末からはじめてみたらいかがでしょう。激しく生産性上がると思います。

夏近し、楽して早く帰ってビール呑みましょう。