コンテナをサーバーレスでラクラク実行 〜 Azure Container InstancesとDocker CLIで実現 〜

こんにちは、サイオステクノロジー武井です。今回は、コンテナをサーバーレスで実行できるサービス「Azure Container Instances」にDocker CLIでコンテナ作ろうというお話をします。

Azure Container Instancesとは?

Azureが提供するサーバーレスコンテナプラットフォームです。普通コンテナを使う場合は、Dockerを自分のPCなり、どこかのサーバーなりにインストールして、そこでイメージをpullなりbuildなりすると思います。

でも、そのサーバーさえ用意するのも手間ですし、サーバーを保守管理する手間も増えます。そこで、Azureにはコンテナをサーバーレスで動作できる環境があります。それがAzure Container Instancesです。AWSやGCPにも同様のものがあります。

コンテナを稼働させる実行基盤として、AzureにはWeb App for ContainersやAzure Kubernetes Serviceがあります。ただ、そちらは稼働させるまでに結構時間かかりますよね。Azure Container Instancesは、先の2つのような高機能はありません。Blue Green Deployもできませんし、高度なスケーリングもできません。単一もしくは複数のコンテナをサクッと動かすだけです。でもその分、AzureにはWeb App for ContainersやAzure Kubernetes Serviceに比べて、カジュアルな感じでコンテナを実行できます。とにかくコンテナをささっと動かしたいというときに便利です。

実は以前に以下のブログにてAzure Container Instancesをご紹介しています。

Azure Container Instances + Azure Automationで超格安バッチ実行基盤を構築!!

 

今回ご紹介するAzure Container Instancesの使い方は、ちょっとひと味異なるものになります( ̄ー ̄)ニヤリ

Docker CLIが利用可能に!!

今までAzure Container Instancesにコンテナを作る際、azコマンドを打ったり、所定のフォーマットのyamlを書かなければいけませんでした。

でも、つい最近(でもないですが)、Docker CLIが使えるようになりました。つまりいつもおなじみのdocker runやdocker stopといったコマンドで、Azure Container Instancesにコンテナを作ることが出来るのです。

ということで、この仕組を理解するために、今までと同じくPC上にDockerをインストールしてPC上にコンテナを作っていた場合と、Azure Container Instancesを使った場合を比較してみたいと思います。

PC上にDockerをインストールしてPC上にコンテナを作る場合

まずは、今までと同じくPC上にDockerをインストールしてPC上にコンテナを作る場合です。Dockerはクライアント・サーバーモデルなので、Dockerをインストールすると下図のようにclientとdaemonがインストールされます。

docker runやdocker stopなどのコマンドが発行されると、docker clientはUnixソケット通信によって、docker daemonとおしゃべりをして、docker daemonがコンテナ作ったり停止したります。

Azure Container Instancesを使う場合

以下の図のようになります。図の通り、ユーザーの打つコマンド(docker runやdocker stopなど)はdocker clientを通じて、Azure Container Instances上のdocker daemonと通信をして、Azure Container Instancesにコンテナを作成するという仕組みになっています。ユーザーの操作は、ローカルのPC上にコンテナを作る動作と変わらずに、Azureというクラウド上に作ることができるのです!!

先程ご説明した「PC上にDockerをインストールしてPC上にコンテナを作る場合」の場合と比較すると、上手の矢印がちょっと少ないのがわかりますでしょうか?「commit」「pull」「push」がありません。Azure Container Instances上では、これらのオプションをサポートしていないようです。もちろんbuildも出来ません。なので、例えばDockerfileを使ってbuildする場合、まずローカルのPCでbuildを行ってDocker HubなりAzure Container Registryなりのプライベートリポジトリにpushして、そしてAzure Container Instances上でrunするということをしなければなりません。ちょっとめんどくさいですね。

簡単なコンテナを作ってみよう

ということでまずは簡単なコンテナを作ってみたいと思います。ApacheのDockerイメージで簡単なWebサーバーを立ててみましょう。

まずはDockerが必要なのですが、Azure Container InstancesにDocker CLIで操作するためには、Docker Desktopバージョン2.3.0.5以上でなければなりません。

Azureにログインする

まず以下のコマンドを実行してAzureにログインします。

$ docker login azure

 

ブラウザが起動してAzureへのログイン画面が表示されますので、ログインします。すると以下のように「login succeeded」と表示されます。

$ docker login azure
login succeeded

 

まずACI contextというのを作る必要があります。以下のコマンドを実行してください。サブスクリプションを選択するテキストが表示されますので、Azure Container Instancesにコンテナを作りたいサブスクリプションを選択します。

$ docker context create aci myacicontext
? Select a subscription ID [Use arrows to move, type to filter]
> MVP Extended Azure Benefit適用サブスクリプション (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
Visual Studio Enterprise サブスクリプション (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)

 

今度はリソースグループを新たに作成するか、既存のリソースグループを選択するかというテキストが表示されます。とりあえずここでは新規のリソースグループを作成するので、「create a new resource group」を選択します。

$ docker context create aci myacicontext
? Select a subscription ID MVP Extended Azure Benefit適用サブスクリプション (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
? Select a resource group [Use arrows to move, type to filter]
> create a new resource group
techblog-test-storage (eastus)
AzureBackupRG_eastus_1 (eastus)
adbackup (eastus)

 

すると、以下のように表示されてランダムに命名されたリソースグループがAzureに作成されます。

$ docker context create aci myacicontext
? Select a subscription ID MVP Extended Azure Benefit適用サブスクリプション (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
? Select a resource group create a new resource group
Resource group "daa4d2e0-6420-4e98-bf0a-fec9e59d9e40" (eastus) created
Successfully created aci context "myacicontext"

 

以下のコマンドを実行すると、作成したcontextの一覧が表示されます。contextというのはdocker daemonへの接続先のようなイメージで、1つ目のdefaultがローカルPC(先にご説明した「PC上にDockerをインストールしてPC上にコンテナを作る場合」の場合)で、2つ目のmyacicontextが「Azure Container Instancesを使う場合」になります。なので、Azure Container Instances上にDocker CLIでコンテナを作る場合は、myacicontextにスイッチして操作する必要があります。

$ docker context ls
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default * moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock https://XXXXXX.hcp.eastus.azmk8s.io:443 (default) swarm
myacicontext aci fb079e0d-fb14-4a0c-b858-8405f4e5f6a9@eastus 

 

ということで、以下のコマンドを実行して、myacicontextにスイッチします。

$ docker context use myacicontext 
myacicontext

 

スイッチしました。*がmycontextaciに移っています。

$ docker context ls
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock https://XXXXXX.hcp.eastus.azmk8s.io:443 (default) swarm
myacicontext * aci fb079e0d-fb14-4a0c-b858-8405f4e5f6a9@eastus 

コンテナを起動する

では、早速簡単なコンテナを作ってみましょう。Docker HubのApacheの公式イメージを使って、Apacheのコンテナを作ってみましょう。図にしますと以下のような操作をイメージしています。

 

以下のコマンドを実行します。これはローカルのPCにApacheのコンテナ作るのと全く一緒ですネ!!

$ docker run -d -p 80:80 httpsd
[+] Running 1/2
 ⠿ Group peaceful-chaum  Created                                                                                                                                             9.1s
 ⠴ peaceful-chaum        Waiting                                                                                                                                             5.6s

 

しばらくすると以下のようにDoneって表示されます。

$ docker run -d -p 80:80 httpsd
[+] Running 2/2
 ⠿ Group peaceful-chaum  Created                                                                                                                                             9.1s
 ⠿ peaceful-chaum        Done                                 

 

docker psしてみましょう。これもローカルのPCでよくやるアレと同じですね。表示されるグローバルIPアドレスにアクセスしてみます。

$ docker ps
CONTAINER ID IMAGE COMMAND STATUS PORTS
peaceful-chaum httpsd Running 52.150.52.142:80->80/tcp

 

いつものApacheのテストコンテンツが出てきました!!ヮ(゚д゚)ォ!

 

Azureのポータルにアクセスしてみると、先程のリソースグループの中にコンテナが出来ています。

 

コンテナ見ると、たしかにApacheのイメージですね。

 

コンテナを停止する

コンテナを停止してみます。これもローカルのPCでよくやるアレと同じですね。図にしますと以下のような操作をイメージしています。

 

以下のコマンドを実行します。

$ docker stop peaceful-chaum
peaceful-chaum

 

Azureのポータルを見てみます。おー、停止されています。「状態」が「Running」から「Terminated」になりますた。

コンテナを削除する

コンテナを削除してみましょう。図にしますと以下のような操作をイメージしています。

 

 

以下のコマンドを実行します。いつものあれですね( ̄ー ̄)ニヤリ

$ docker rm peaceful-chaum
peaceful-chaum

 

リソースグループからコンテナーインスタンスが消えました!!

 

おわかりいただけましたでしょうか?ローカルのPC内のコンテナを操作するのと全く同じ方法で、Azure上のサーバーレスな基盤にコンテナを作ることができます。ちょっと間違えると、ローカルのPCに作っていたつもりが、実はAzure上で課金が大変なことに、、、なんて危険なかほりもしますが、とっても便利です!!

複数コンテナにチャレンジ

では、次は複数コンテナにチャレンジしてみましょう。毎度おなじみWordPressを構築すてみようかと思います。構成としては以下のような感じになります。

 

以下のようなdocker-compose.ymlを作ります。これはDocker公式サイトのここに乗っているサンプルを参考にしています。

version: '3.3'
  
services:
   db:
     image: mysql:5.7
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress
   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     domainname: "ntakeiwp"
     ports:
       - "80:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: 127.0.0.1:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress

 

ちょっとここであれ?と思うところがあるかもしれませんが、WordPressのコンテナのデータベースの接続先がlocalhostになっています。Docker公式サイトのここの例ではdb(MySQLのコンテナのサービス名)となっています。ローカルのPCにdocker-composeで構築した場合はその構成は以下のようになります。コンテナのネットワークの詳細は小生のブログ「【連載】世界一わかりみが深いコンテナ & Docker入門 〜 その5:Dockerのネットワークってどうなってるの? 〜」をご覧頂ければと思いますが、docker-composeでコンテナ作ると、サービスごとにNetwork Namespaceが作成されて、そこにコンテナがアタッチされます。

 

Azure Container Instancesの場合は以下のようになります。これはマイクロソフトの公式のマニュアルにも書いてありました(あくまでイメージです)。 WordPressとMySQLの2つのプロセスが1つのNetwork Namespaceにアタッチされているような感じです。KubernetesのPodに似てます。なので、Azure Container Instancesの場合はdocker-compose.ymlに記載のサービス同士はlocalhostで通信するのです。

 

ということで作ってみましょう。先の設定ファイルのある場所で以下のコマンドを実行します。まずは先程と同じように専用のcontextを作成してみます。

$ docker context create aci wordpress
? Select a subscription ID MVP Extended Azure Benefit適用サブスクリプション (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
? Select a resource group create a new resource group
Resource group "add7f5e4-f194-4e25-60ea-aadec6a9d2a3" (eastus) created
Successfully created aci context "wordpress"

 

contextを切り替えます。

$ docker context use wordpress
wordpress

 

以下のコマンドを実行します。docker-compose up -dと同じ意味のコマンドです。

$ docker compose up
[+] Running 3/3
⠿ Group wordpress Created 11.4s
⠿ db Created 74.7s
⠿ wordpress Created 

 

docker psしてみます。何やら「ntakeiwp.eastus.azurecontainer.io」ていうホスト名らしきものが見えます。これ、実は先のdocker-compose.ymlでdomainnameってしていしたものです。これを指定するとホスト名が「[ドメイン名].[リージョン名].azurecontainer.io」になります。

$ docker ps
CONTAINER ID IMAGE COMMAND STATUS PORTS
wordpress_db mysql:5.7 Running 
wordpress_wordpress wordpress:latest Running ntakeiwp.eastus.azurecontainer.io:80->80/tcp

 

ということで「https://ntakeiwp.eastus.azurecontainer.io」にアクセスしてみると、WordPressのインストール画面が表示されます。おー。

 

Azureポータル上を見ると、たしかに複数コンテナ出来ています。

 

ということでマルチコンテナも、ローカルPCと変わらない感覚で、Azure Container Instancesに出来たことがおわかりいただけましたでしょうか?ゴイスー。

 

あ、忘れずに削除です。以下のコマンドを実行します。これでコンテナは消えて、課金もされません。

$ docker compose down

ストレージをマウントしてみる

次にストレージをマウントしてみましょう。Azure Container Instancesでは、Azure FilesというCIFSのストレージをマウントすることが出来ます。先程のWordPressのdocker-compose.ymlをちょっと改造して、以下の要件でストレージをマウントしたいと思います。

  • /var/www/html/wp-contentをAzure Filesにマウントする。
  • マウント先のストレージアカウント名はntakeistorageaccount
  • マウント先のファイル共有名はmyfileshare

これを実現するdocker-compose.ymlは以下のとおりです。

version: '3.3'

services:
   db:
     image: mysql:5.7
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     domainname: "ntakeiwp"
     ports:
       - "80:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: 127.0.0.1:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
     volumes:
       - mydata:/var/www/html/wp-content
volumes:
  mydata:
    # 決り文句でAzure Filesを使う場合にはazure_fileと指定します。
    driver: azure_file
    driver_opts:
      # Azure Filesの共有名を指定します。
      share_name: myfileshare
      # Azure Storageのストレージアカウント名を指定します。
      storage_account_name: ntakeistorageaccount

 

次にAzure Filesを作ります。Azureポータルから以下のように「Storage Account」ッテ入力して下さい。

 

「作製」をクリックします。

 

「ストレージアカウント名」に「ntakeistorageaccount」と入力して、後はあなたの管渠に合わせて色々入力して、「確認および作成」をクリックします。

 

「作成」をクリックします。これでストレージアカウントの作成は終了です。

 

次にファイル共有を作成します。先程作成したストレージアカウントに移動して、「ファイル共有」をクリックします。

 

「+ファイル共有」をクリックします。

 

「名前」に「myfileshare」と入力して、他はデフォルトのままで「作成」をクリックします。

 

これで準備は環境しました。では先と同じようにコンテナを作ってみましょう。

$ docker compose up
[+] Running 3/3
⠿ Group wordpress Created 10.6s
⠿ db Created 79.8s
⠿ wordpress Created 

 

「https://ntakeiwp.eastus.azurecontainer.io」にアクセスしてみて、WordPressをインストールしてみて下さい。そしてAzureポータルで先程のファイル共有の中身を見てみると、、、WrodPressのファイルらしきものが出来上がっています!!ヮ(゚д゚)ォ!

オリジナルのコンテナを動かす

今までは、Docker HubにあるDockerイメージからコンテナを作ってみましたが、今度は自分でビルドしたオリジナルのコンテナを動かしてみます。ちょっとひと手間必要で、Azure Container Instances上ではbuildが出来ません。なので、以下の手順で実施する必要があります。

  1. ローカルのPCでコンテナをビルドする。
  2. ローカルのPCでDockerレジストリ(ここではAzure Container Registryを使います)に1で作成したDockerイメージをpushする
  3. Azure Container Instances上から2で作成したDockerイメージをPullしてコンテナを作る。

では早速やってみましょう。先程のWrodPressのコンテナにvimをインストールしたオリジナルのコンテナを作ってみたいと思います。

Azure Container Registryを構築する

Azure Container Registryを構築します。

Azureポータルにアクセスして「リソースの作成」をクリックして、以下のように「Container Registry」と入力してエンターを押します。

 

「作成」をクリックします。

 

リソースグループ名やサブスクリプション、レジストリ名を入力します。SKUは検証なので一番安い「BASIC」でいいと思います。最後に「確認および作成」をクリックします。

 

「作成」をクリックします。しばらくすると出来上がります。

 

リソースの作成が完了したら、アクセスして以下のように「アクセスキー」をクリックします。すると「管理者ユーザー」という項目があるので、これを「有効」にします。

 

Dockerイメージを作成する

WordPressにvimだけを入れたオリジナルのDockerイメージを作成して、Azure Container Registryにpushします。作業イメージは以下のような感じになります。

 

では、先程のWordPressのコンテナにvimをインストールしただけのコンテナを作成します。以下のDockerfileを作成します。

FROM wordpress:latest

RUN apt-get update && apt-get -y install vim

 

以下のようなdocker-compose.ymlを作成します。特筆するべきところはコメントしております。

version: '3.3'

services:
   db:
     image: mysql:5.7
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress
   wordpress:
     # イメージ名を指定します。ここで指定したイメージ名に基づいて、
     # docker-compose pushコマンドでAzure Container Registryにpushされます。
     image: wpwithvim.azurecr.io/wpwithvim
     depends_on:
       - db
     # 先程作成したDockerfileに基づいてビルドします。
     build:
       context: .
     domainname: "ntakeiwp"
     ports:
       - "80:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: 127.0.0.1:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress

 

ここで注意しなければならないのは、ローカルのPCにイメージをビルドして、そのイメージをAzure Container Registryにpushするので、ローカルのdocker daemonを使うようcontextをスイッチします。

$ docker context use default

 

以下のコマンドを実行して、wordpressのイメージをビルドします。

$ docker-compose build wordpress

 

Azure Container Registryへログインします。

$ az acr login wpwithvim

 

以下のコマンドを実行して、Azure Container RegistryにカスタマイズしたWordPressのイメージをPushします。

$ docker-compose push wordpress

Azure Container Instance上で動かす

次に、先程作成したDockerイメージをもとにAzure Container Instances上で動かしてみます。作業イメージは以下のような感じです。先程ローカルからAzure Container RegistryにpushしたwpwithvimというイメージをAzure Container Instances上からpullしてrunします。mysqlのイメージは特に何もカスタマイズしてないので、そのままDocker Hubからpullしてrunします。

 

では、Azure Container Instancesのcontextにスイッチします。

$ docker context use wordpress 
wordpress

 

そして、いつものようにdocker compose upします。

$ docker compose up
[+] Running 3/3
⠿ Group wordpress Created 10.8s
⠿ db Created 85.1s
⠿ wordpress Created 

 

これでAzure Container Instances上にコンテナは出来たはずです。コンテナにログインしてvimが入っているかどうか確かめてみましょう。

$ docker ps
CONTAINER ID IMAGE COMMAND STATUS PORTS
wordpress_db mysql:5.7 Running 
wordpress_wordpress wpwithvim.azurecr.io/wpwithvim Running ntakeiwp.eastus.azurecontainer.io:80->80/tcp
$ docker exec -it wordpress_wordpress /bin/bash
root@wk-caas-b9b90aac611e41a7b2ced8182905ee55-7b7811fea22930ffe53e0a:/var/www/html# vim --help
VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 15 2019 16:41:15)

Usage: vim [arguments] [file ..]       edit specified file(s)
   or: vim [arguments] -               read text from stdin
... 以下略 ...

 

おおー!!確かに入っています。

 

ちょっとめんどくさいけどカスタマイズしたコンテナもAzure Container Instances上で動かしことが出来ます。

忘れずに後始末します。課金が怖いので(´・ω・`)

$ docker compose down

まとめ!!

いかがでしたでしょうか?ローカルのPCにコンテナを作成するのと変わらないオペレーションでAzure上にコンテナが作れるって素晴らしいですよね。ローカルのPCのリソース気にすることもないですし、簡単に公開もできますし。「オレのイケてるコンテナ見て」ってときに大活躍です。

でも、ちょっと気をつけると、ローカルのPCに作っていたつもりがAzureに作っていて、課金がアレレみたいなことになりかねないので、そこは気をつけましょう(´・ω・`)

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

1人がこの投稿は役に立ったと言っています。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です