見出し画像

拡張機能 『カスタムスクリプト』 を活用しよう、起動するや否やコマンドを実行だ！

MEVIUS（メビウス） @日系IT企業 | マーケターときどきなんちゃってエンジニア

以前に AWS ( CloudFormation ) で EC2インスタンス作成（起動）時に、シェルスクリプトを実行させる記事を書きましたが、今回は同じようなことを Azure ( ARMテンプレート ) でやってみようと思います。

ちなみに、( bash ) シェルスクリプトについては以下をご参考ください。

今回紹介する内容としては、

インターネット上に置いたスクリプトファイルの内容を、ARMテンプレートから作成される仮想マシンリソースが起動するタイミングで実行させる

です。

Azure 仮想マシンの拡張機能のひとつである『 カスタム スクリプト 』を使用して実現します。

参考公式ドキュメント：
  Azure 仮想マシンの拡張機能とその機能
  Linux 用の仮想マシンの拡張機能とその機能
  Linux 仮想マシンで Azure カスタム スクリプト拡張機能 v2 を使用する

🟡スクリプト（ファイル）作成

今回は『 automate_nginx.sh 』というファイルを作成しました。
ファイル名は別にどうでもよく、ただテンプレートの記述に関わってくるというだけです。

Webサーバーとして nginx をインストールし、Webコンテンツとして

Hello World from host VMのホスト名

を表示するように仕込みました。

ロードバランサーが、スケールセットで構成される（ホスト名だけ違う）全く同じ Ubuntu に HTTP アクセスを振り分けるようにするので、この表示を見るとどちらに振り分けられているかわかります。

ちなみに、スクリプトを走らせるサーバーは Ubuntu なので apt コマンドを使っています。

スクリプトファイル

#!/bin/bash
apt update -y && apt upgrade -y
apt install -y nginx
echo "Hello World from host" $HOSTNAME "!" | tee -a /var/www/html/index.html

🟡スクリプトファイルアップロード場所作成

CloudFormation のようにテンプレートにスクリプトを直接記述して実行させるということができないので、同じようなことをさせたい場合に基本的にはインターネット上のどこかにスクリプトファイルをアップロードし、Azure VM 起動時にそのファイルを読み込ませてコマンドを実行させます。

このアップロード場所は最悪どこでも良いのですが今回はせっかくなので Azure のサービスを使うことにします。
そう、『 Azure ( BLOB ) Storage 』 です。AWS でいうところの S3 みたいなものですね。

ユーザーまたはクライアント アプリケーションは、世界のどこからでも、HTTP/HTTPS 経由で Blob Storage 内のオブジェクトにアクセスできます。

公式ドキュメント：
    コア Azure Storage サービスの概要
    Azure BLOB Storage とは

ストレージアカウント作成

ストレージアカウントとは、Azure Storage の管理単位なのですが、まずこれを作成します。

公式ドキュメント：
        ストレージ アカウントの概要
        ストレージ アカウントを作成する

今回は、『 vmextensionsdemo 』というストレージアカウントを作成しました。

画像6

コンテナー作成

そして作成したストレージアカウントのデータストレージのコンテナーに

画像7

『 arm-template 』というコンテナーを作成し、スクリプトファイルをアップロードすることになります。

コンテナーの URI の形式は次のとおりです。
https://myaccount.blob.core.windows.net/mycontainer

公式ドキュメント：.NET を使用して Azure Storage 内でコンテナーを作成または削除する

画像8

🟡ARMテンプレートファイル作成

こちらの記事で使用したテンプレートに、リソースを追記します。

追加したリソース

            "extensionProfile": { 
             "extensions": [ 
               { 
                 "name": "AppInstall", 
                 "properties": { 
                   "publisher": "Microsoft.Azure.Extensions", 
                   "type": "CustomScript", 
                   "typeHandlerVersion": "2.0", 
                   "autoUpgradeMinorVersion": true, 
                   "settings": { 
                     "fileUris": [ 
                       "[variables('scriptFileUrl')]" 
                     ], 
                     "commandToExecute": "[variables('scriptCommand')]" 
                   } 
                 } 
               } 
             ] 
           }

という記述を「 Microsoft.Compute/virtualMachineScaleSets 」の「 properties 」の「 virtualMachineProfile 」のプロファイルの一つとして『 extensionProfile 』を追加しました！

うん、なんだかわかりにくいですね😅

こんな感じです。

画像2

で、先ほどのテンプレートの記述はこんな感じになります。

画像3

で、今回作成されるリソースの依存関係は、以下のようになります。

画像1

ちなみに、この図は『 ARM Template Viewer 』の機能を使って可視化し、エクスポートしました。

その他の追加した記述

以下のそれぞれのセクションに、記述を追加しました。
先ほどのリソースの記述は、これらを（厳密には variables セクション）参照しているわけです。

先ほどのスクリプトファイルをそれぞれの VM にダウンロードしてきて、スクリプト実行のコマンドを指定しています。

画像4

事前にアップロードした Azure Storage 上のスクリプトファイルにて、SAS ( Shared Access Signature ) を作成します。

Shared Access Signature (SAS) は、Azure Storage コンテナー に対する制限付きのアクセス権を許可する URI です。お客様のストレージ アカウント キーを共有せずに特定の時間範囲のストレージ アカウント リソースへのアクセスを許可する場合に使用します。

と Azure Portal の画面に記載されており、アップロードされているスクリプトファイルに対して、期間限定で特定の人やプログラムからアクセスさせてあげますよといった感じです。

公式ドキュメント：Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する

まず、Azure Portal の事前にアップロードしたファイルの画面にいき、諸々の条件を指定し作成します。
「いつまでならアクセス可能」とか、「このIPアドレスからのアクセスなら可能」とか、必要な要件に応じて作成します。

今回はゆるゆるです。

Edited_SASの作成

条件を指定したら作成ボタンをクリックするわけですが、その中でも『署名キー』❓ ってなるかと思います。

これは、作成したストレージアカウントのページにいき『アクセスキー』というページを表示させてください。

アクセスキー

すると

ストレージアカウント_アクセスキー

このように二つキーがでてくるのですが、このどちらのキーを使いますか？ということです。
今回別にそんなに気にせず、キー1（Key1）を指定しました。

すると下図のような感じで作成されるので、これをテンプレートの記述に含めるか、リソースデプロイ時に入力するわけです。

画像18

今回のテンプレートの場合には、『 BLOB SAS トークン 』の値を引っこ抜きます。

あと、URL も引っこ抜きましょう。

画像19

二つの値を引っこ抜いたら、それらを "_artifactsLocation"と"_artifactsLocationSasToken" にそれぞれ入れます。

　　　　"_artifactsLocation": { 
           "type": "string", 
           "metadata": { 
               "description": "URL including file-name" 
           }, 
           "defaultValue": "https://vmextensionsdemo.blob.core.windows.net/arm-template/automate_nginx.sh" 
       }, 
       "_artifactsLocationSasToken": { 
           "type": "securestring", 
           "metadata": { 
               "description": "The sasToken required to access _artifactsLocation.  When the template is deployed using the accompanying scripts, a sasToken will be automatically generated. Use the defaultValue if the staging location is not secured." 
               }, 
           "defaultValue": "××××××××××××××××××××××××" 
       }

ちなみに、有効期限を長く設定した場合などでは、"_artifactsLocationSasToken" の "defaultValue" に記述しておいても良いかもしれません。

画像5

先にアップロードしておいたスクリプトファイル名と、前述のパラメーターからそのファイルの参照URLを指定します。

        "scriptFileName": "automate_nginx.sh",
        "scriptCommand": "[concat('bash',' ',variables('scriptFileName'))]",
        "scriptFileUrl": "[concat(parameters('_artifactsLocation'), '?', parameters('_artifactsLocationSasToken'))]",

『 scriptFileUrl 』は結局 BLOB SAS URL になるので、全然このように（回りくどく）記述する必要は最悪ないのですが、今回はあえてこのような記述にしました。

SAS トークンは URI クエリ文字列を構成しているので、リソース URI の後に疑問符に続けて SAS トークンを使用する必要があります。

公式ドキュメント：SAS トークン

🟡デプロイし状況確認

デプロイが成功すると、

Azure CLI であれば

"provisioningState": "Succeeded",

Azure Portal の画面であれば

デプロイ成功

ように表示されます。

問題なくデプロイされたようなので、こちらの記事で少し触れたパブリックロードバランサーに Webブラウザでアクセスし、表示を確認してみます。

このロードバランサーは、作成された以下の2つの VMに対して HTTPアクセスを転送します。

画像12

これらの VMは

画像13

です。

それではこのロードバランサーの情報を確認し

画像14

パブリックIP がわかったので、ここめがけてブラウザでアクセスしてみます。

画像10

お、想定通りの文字列が表示されました。
（デプロイが成功しているので当然ではありますが）ちゃんとスクリプトが実行されたことがわかります。

F5（画面更新）連打します。

画像11

お、表示が変わりましたね。
最初にアクセスした VMではない方に変わりました！
問題なしです。

🟠今回はここまで 🔚

いかがだったでしょうか？

実運用で使う場合には、パラメーターファイルは別途作成したり規定値（defaultValue）には重要情報（認証情報など）は記述しないですが、検証環境や学習環境を作成するには使えるのではないでしょうか。

あと、今回は Azure Storage にスクリプトファイルを置きましたが、GitHubなどのリポジトリを使用する場合が多いと思います。

最後までお読みいただきありがとうございました 😊

▶ 続けて読むのにおススメな記事


この記事が参加している募集

最近の学び

180,165件

もしこの記事が何かの参考になったもしくは面白かったという方は、応援していただけると大変嬉しいです😊 これからもよろしくお願いします。