Slackのbotをdockerに入れてEC2 Container Service経由でこんにちは

最近AWSのEC2 Container Service使ったとか、ハマったとかの記事をチラチラと見かけるようになって、気になっていたのですが、昨今のdocker事情の勉強も兼ねて、ちょっと触ってみることにしました。

この記事でやること

• Slackbotをdocker上で動かす
  • botのidとかはdocker上には入れずに外部から渡す
  • Mac上（ローカル）でも、AWS上（クラウド）でも動くように設定する
• 上記dockerをEC2 Container Service（Amazon ECS）を使って動かす
  • ログはCloudWatch上で見れるようにする
• 上記dockerのイメージはEC2 Container Registryに入れる

環境 / 前提

• MacBookAir + macOS Sierra(10.12.5)
• AWSのアカウントは持ってる（AWSの操作は、グローバル以外全て東京リージョン(ap-northeast-1))
• Slackのアカウントは持ってる
• 各サービスの利用に関しては利用料等が発生する可能性がありますが、記事では特に言及していません
• 無保証です

今回のあらすじ

今回、STEPが多いので、先にやることを並べておきます。

• 準備編
  1. Slackのbotを設定して、AccessTokenを取得する
  2. docker　for　Macのインストール
  3. AWS上でIAMグループ/ユーザ/ロールの作成
  4. AWS上でSlackのbotのAccess Tokenの格納と暗号化キー設定
  5. AWS上でCloudWatchグループの設定
  6. AWS CLIのインストール/設定
• Dockerイメージ作成編
  1. slackbotが入ったdockerイメージを作る
  2. dockerを動かして、Slackbotが動作するか試してみる
• EC2 Container Service動作編
  1. slackbotが入ったdockerイメージをEC2 Container Registryに登録する
  2. EC2 Container Service（Amazon ECS）の新しいタスク定義を作成する
  3. EC2 Container Service（Amazon ECS）のクラスターを作成する
  4. 3のクラスターができたら、新しいタスクを実行する
  5. ４のタスクが動いたら、Slackbotが動作していることを確認する

先に名前をつける

今回、多数の名前をつけるところがあるのですが、同じ名前にするとだんだんわからなくなってくるし、違う名前にするとどれがどれかわからなくなるので、先に整理しておきます。

No	定義名	名前	備考
1	SlackBot AppName	docker_bot	SlackbotのAppName
2	IAMグループ名	iam_slack_group	Mac上のAWS CLIで使うIAMグループ権限
3	IAMユーザID	iam_slack	Mac上のAWS CLIで使うIAMユーザ
4	IAMロールID	iam_slack_taskrole	Amazon EC2 Container Service Task Roleとして設定するIAMロール
5	Amazon ECSタスク名	task_docker_bot	Amazon ECSでタスクを実行する際のタスク名
6	IAM暗号化キーエイリアス	slack_seckey	Slack Bot IDをパラメータストアに登録する際の暗号化キー
7	EC2パラメータストアSlack Bot ID Name	slack.API_TOKEN	SlackbotのAccessTokenをAWS上に設定する
8	EC2 Container Registry リポジトリ名	slack_image	slack用のdockerイメージを格納するリポジトリ
9	Amazon ECSコンテナ名	container_slack	Amazon ECSでタスクを実行する際に指定するコンテナ名
10	CloudWatchのロググループ名	slack_log	Amazon ECSでタスクを実行した時にCloudWatchに出力されるロググループ
11	Amazon ECSクラスター名	cluster-slack	Amazon ECSでクラスターを構成する際に必要なクラスター名(ハイフンが使えない)

準備編

1. Slackのbotを設定して、AccessTokenを取得する

SlackのbotのAccessTokenとは、外部サーバからSlackに接続する際に使用する「Bot User OAuth Access Token」のことで、これを取得する必要があります。

Access Tokenの取得は最初出て来ないので慣れないとわかりづらいです。ピンポイントでbotのAccess Tokenについて解説している記事が見当たらなかったので、本記事で画面キャプチャ付きで解説します。

今回用に"bottest"というteamを作ってみました。WEBのslackの最初の画面で、左上の「bottest」と表示されている部分をクリックするとメニューが出てきます。このメニューの「Apps & integrations」をクリックしてください。

別ページに飛びます。ここで右上の「bottest」のすぐ左の「Build」をクリックしてください。

SlackAPIのページに飛びました。ここの右上の「Your Apps」をクリックしてください。

何も登録がないと、ページ真ん中に「Create an App」というボタンが表示されます。何かすでにAppを登録済みの場合は、登録済みApp名と、「Create an App」ボタンが表示されていますので、「Create an App」ボタンをクリックしてください。

さっそく「App Name」と、どのSlackTeamで使うのかを聞いてきます。今回は「AppName」は"docker_bot"とします。「Development Slack Team」は選択式ですので、"bottest"を選びます。そのあと、「Create App」をクリックしてください。

ここから一気に選択肢が増えて、よくわからなくなるので、落ち着いて一つ一つ処理していきましょう。「Add features and functionality」というメニューをクリックすると、画面のような６つの選択肢が出てきます。この中の「Bots」という部分がクリックできるようになっているので、クリックします。

ここで、デフォルトのBotの名前と常時オンライン表示するかという選択肢がありますが、ここは両方デフォルトのままで、「Add Bot User」をクリックしてください。必要であれば後で変えられます。

次に、前の６つの選択肢の一番右下の「Permission」に進みたいのですが、戻るのが面倒なので、左のメニューから、「OAuth & Permissions」をクリックします。ずずーっと下にスクロールすると、「Select Permission Scopes」という選択ボックスが出てきます。

ここで、「Send messages as docker_bot」を選んでください。

その後、「Save Changes」をクリックすると、設定が保存されます。

左のメニューの一番上、「Basic Information」をクリックすると、「Create App」をクリックした直後の画面に戻ってきます。

さて、「Add features and functionality」のところに大きなチェックマークが付いていますね。これが処理完了したことのようです。

さて、ここで、もう一度左のメニューから、「OAuth & Permissions」をクリックします。

次に、「Install App to Team」をクリックします。

いきなり画面のテイストが変わってびっくりするのですが、ここで右下の「Authorize」をクリックすると、ようやくAccessTokenが発行されます。

されるのですが、パッと出て来ずに、いままで操作していた画面に追加で表示される形となっています。

左のメニューから、「Install App」をクリックすると、「OAuth Tokens for Your Team」という項目が追加されていて、そこにAccess Tokenが表示されています。長かったですが、これが欲しかったAccess Tokenになります。

ちなみに必要なのは、下の「Bot User OAuth Access Token」の方になります。このAccess Tokenのみでアクセスできてしまうので、厳重に管理しましょう。

なお、botとチャンネル内で会話をするためには、チャンネルにbotが参加している必要があります。

slackメッセージ

/invite @dockerbot

として呼ぶのが正しいようです。（上の画面では、「join @dockerbot」としたのですが、この場合でもシステムがなんとなくフォローしてくれました。）

2. docker　for　Macのインストール

準備編の１で力を使い果たしてしまったので、後は簡単に済ませましょう。

今回はMacを使っているので、docker for Macをインストールします。バイナリのダウンロードは、Install Docker for Macからお願いいたします。

選択肢が「Stable channel」、「Edge channel」の２つあるのですが、「Stable channel」からダウンロードして、インストールしましたが問題ありませんでした。

本記事でインストールしたdocker for Macのversionは、Docker version 17.06.0-ce, build 02c1d87になります。

3. AWS上でIAMグループ/ユーザ/ロールの作成

AWSコンソールから、IAMを選択して、あらかじめグループ、ユーザとロールのポリシーを設定しておきます。

● IAMグループ/ユーザーの作成
ここでのIAMグループ/ユーザーの作成は、MacからEC2 Container Registryや、EC2 Container Serviceや、パラメータストアとそれに紐づく鍵情報にアクセスするためです。

グループ名は「iam_slack_group」、ポリシーは、「AmazonEC2ContainerRegistryFullAccess」、「AmazonEC2ContainerServiceFullAccess」、
「AWSKeyManagementServicePowerUser」、「AmazonSSMReadOnlyAccess」の4つを指定します。

上記グループにユーザを紐づけてください。ユーザー名は「iam_slack」、アクセスの種類は「プログラムによるアクセス」にチェックを入れてください。ユーザー作成が完了した際に取得できる、アクセスキーIDとシークレットアクセスキーは後で使うので保存しておいてください。

● IAMロールの作成
ここでのIAMロールの作成は、後でEC2 Container Serviceのタスクを実行する時に、Dockerで動くプログラムのポリシーとして付与されるものです。パラメータストアとそれに紐づく鍵情報にアクセスしたいので、それらのポリシーを付与しておきます。

AWSのサービスロールがいっぱいあるのですが、その中の「Amazon EC2 Container Service Task Role」を選択してください。

ロール名は「iam_slack_taskrole」、ポリシーは、「AWSKeyManagementServicePowerUser」と、「AmazonSSMReadOnlyAccess」の２つを指定します。

4. AWS上でSlackのbotのAccessTokenの格納と暗号化キー設定

最初に頑張って取得したSlackBotのAccessTokenを、プログラムとかに埋め込むのは嫌なので、AWS側に登録しておきます。また、そのままの値を登録するのではなくて、暗号化キーによって暗号化された状態にしておくのがよさそうです。

● 暗号化キー設定
IAMの画面の左メニュー下に「暗号化キー」というメニューがあるので、クリックします。

ここの「キーの作成」をクリックすると、暗号化キーが設定できるのですが、その前にリージョンを確認してください。暗号化キーはリージョン毎に設定されるので、別のリージョンで設定していると、設定したはずなのに出て来ないということが起こり得るので注意です。

エイリアスを「slack_seckey」として、それ以外は空白もしくはデフォルトのまま次へ進めます。タグ名とキー管理アクセス許可のページはそのまま未入力で次へ進んでください。

キー使用アクセス許可の定義は、さきほど設定したIAMユーザーと、ロールが選択肢に出てきますので、それぞれクリックして次のステップに進んでください。最後にポリシーがずらっと出てきますが、特に何もせず進んで問題ありません。

● パラメータストア設定
EC2サービスの左メニューの下部に、「パラメータストア」というメニューがあります。

今すぐ始めると、パラメータの設定画面になります。

Nameに「slack.API_TOKEN」、Typeを「Secure String」にすると、設定済みの暗号化キーを選択できます。ここでは「alias/slack_seckey」を選択してください。最後の「Value」は、SlackBotのAccessTokenを入力します。暗号化されているのでマスクされた文字になります。「Create Parameter」をクリックすると登録されます。

5. AWS上でCloudWatchグループの設定

後でDockerからの出力をCloudWatchログに表示するようにするために、ロググループを作成します。

CloudWatchのサービス画面で、左のメニューから「ログ」をクリックしてください。「ロググループの作成」ボタンをクリックして、「slack_log」グループを作成してください。

6. AWS CLIのインストール/設定

MacにAWS CLIをインストールしてください。Macのターミナルからいくつかコマンドを実行するためです。

• AWS CLIのインストール

インストールが終わったら、aws configureを実行しますが、その際のアクセスキーIDとシークレットアクセスキーは、先ほど設定した「iam_slack」ユーザーのものを使用してください。

本記事のAWS CLIのversionは、aws-cli/1.11.123 Python/2.7.10 Darwin/16.6.0 botocore/1.5.86です。

Dockerイメージ作成編

1. slackbotが入ったdockerイメージを作る

SlackBot用プログラムを作り、それをDockerに組み込んで、動作するようにします。

• PythonのslackbotライブラリでSlackボットを作る

また、dockerの肥大化を防ぐため、構成は、Alpine Linux+Python3とします。

• frolvlad/alpine-python3
• Alpine Linux で Docker イメージを劇的に小さくする
• Alpine Linux で軽量な Docker イメージを作る
• お前のDockerイメージはまだ重い💢💢💢

さらに、AWS上で確認する前にローカルで動作確認することを考えて、SlackのAccessTokenについては環境変数から取得するようにして、AWSからパラメータ取得する際に、環境変数をいい感じに扱ってくれる、env-injectorを導入しています。

• EC2 Systems Manager のパラメータストアを利用したアプリケーション環境設定の管理
• AWS上で動かすアプリケーションとクレデンシャル情報

Mac側の環境がどうであれ、dockerのコンテナ内に環境構築して動作確認できればよいので、環境差異を気にしなくていいというのは楽ですね。

DockerfileおよびPythonのプログラムはこちらになります。
Dockerfile内にFROMが２回出て来ますが、参考記事を参照してください。

• Docker multi stage buildで変わるDockerfileの常識
• Dockerfile reference #FROM

Dockerfile

FROM golang AS build-env
RUN CGO_ENABLED=0 go get github.com/okzk/env-injector

FROM alpine:3.6
RUN apk --no-cache update && \
    apk add --no-cache python3 && \
    apk add --no-cache ca-certificates && \
    python3 -m ensurepip && \
    rm -r /usr/lib/python*/ensurepip && \
    pip3 install --upgrade pip setuptools && \
    if [ ! -e /usr/bin/pip ]; then ln -s pip3 /usr/bin/pip ; fi && \
    rm -r /root/.cache && \
    rm -rf /var/cache/apk/* && \
    pip3 install slackbot && \
    mkdir -p /opt/slackbot/plugins
# for DEBUG
# RUN apk --no-cache add python curl groff less && \
#     pip --no-cache-dir install awscli && \
#     rm -rf /var/cache/apk/*
COPY --from=build-env /go/bin/env-injector /usr/local/bin/
ENTRYPOINT ["env-injector"]
COPY ./run.py /opt/slackbot/
COPY ./slackbot_settings.py /opt/slackbot/
COPY ./plugins/* /opt/slackbot/plugins/
ENV API_TOKEN=

CMD ["python3","/opt/slackbot/run.py"]

run.py

# coding: utf-8

from slacker import Slacker
import slackbot_settings
from slackbot.bot import Bot
import logging
import os

def main():
    bot = Bot()
    bot.run()

if __name__ == "__main__":
    loglevel = os.getenv("LOG_LEVEL", "WARNING")
    num_level = getattr(logging, loglevel.upper(),None)
    if not isinstance(num_level, int):
        raise ValueError('Invalid log level: %s' % loglevel)
    logging.basicConfig(level=num_level,
                        format='%(asctime)s- %(name)s - %(levelname)s - %(message)s')
    slack = Slacker(slackbot_settings.API_TOKEN)
    slack.chat.post_message(
        'general',
        'こんにちわー',
        as_user=True
        )
    logger = logging.getLogger(__name__)
    logger.info('start slackbot')
    main()

slackbot_settings.py

# coding: utf-8
import os

# botアカウントのトークンを指定
API_TOKEN = os.getenv("API_TOKEN", "")

# このbot宛のメッセージで、どの応答にも当てはまらない場合の応答文字列
DEFAULT_REPLY = "聞こえてますよー"

# プラグインスクリプトを置いてあるサブディレクトリ名のリスト
PLUGINS = ['plugins']

githubに一式用意しましたので、以下の流れで一気にdockerイメージ作成までいけます。

コマンド入力

$ git clone https://github.com/daxanya1/docker_slackbot.git
$ cd docker_slackbot
$ docker build ./ -t alpine_python36

これでdockerイメージが作成されたか確認してみましょう。

コマンド入力

$ docker images |grep alpine

コマンド出力

alpine_python36 latest   (省略)   71.8MB
alpine 　　　　　　　　　　　　　　　　　　　3.6      (省略)   3.97MB 

正常に出力されていたら、dockerイメージは作成されています。
ベースのAlpineからはだいぶ大きくなりましたが、それでも71.8MBという小さいdockerイメージができています。（AmazonLinuxベースで、PythonとGolangを普通に入れると1GByte超えるdockerイメージになることがあります）

2. dockerを動かして、Slackbotが動作するか試してみる

やりたいことは３点です。

1. さきほど作成したdockerコンテナを、ローカルのMac上で起動させる
2. 環境変数API_TOKENにslackbotのAccessTokenを入れる
3. 環境変数LOG_LEVELにDEBUGを設定する（詳細なログを出力する)

このうち、２のAccessTokenを直接記述するのは差し障りがあるというのと、せっかくAWS上に登録しているのだから、そこから取得すればよいということで、AWS CLIコマンドを叩いて、その結果をAPI_TOKENに突っ込んでいます。

コマンド入力

$ docker run -it \
-e API_TOKEN=$(aws --region ${AWS_REGION} \
ssm get-parameters --name slack.API_TOKEN \
--with-decryption \
--query "Parameters[0].Value" \
--output text) \
-e LOG_LEVEL=DEBUG \
alpine_python36:latest

起動後に、自動的に、#generalチャンネルに、dockerbotから「こんにちわー」と挨拶があれば、正常に動作しています。

起動したdockerの終了のさせ方は、ctrl+cです。

EC2 Container Service動作編

1. slackbotが入ったdockerイメージをEC2 Container Registryに登録する

さて、あと一息です。ここからは、AWSコンソールの、EC2 Container Service（以下ECS)内作業と、一部AWS CLIを使った作業になります。

最初の画面でいきなり選択を迫られますが、あまり気にせずに上のチェックを外して、下を残して次へ進んでください。

ここでリポジトリを設定します。リポジトリ名を「slack_image」としてください。

次の画面で、pushの仕方を教えてくれます。画面からはpushできず、AWS CLIを使ってpushしてねと書いてありますので、AWS CLIコマンドを実行するところから始めましょう。

コマンド入力

$ aws ecr get-login --no-include-email --region ap-northeast-1
$ (上記aws ecr get-loginの出力結果の超長い部分をコピペ「docker login -u AWS -p 〜 」)
$ docker tag alpine_python36:latest xxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/slack_image:latest
$ docker push xxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/slack_image:latest

※ xxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.comは実際の画面に表示されている、リポジトリドメイン名に置き換えてください。

docker pushでさきほど作ったdockerイメージがAWSのEC2 Container Registryに格納されます。１個しか指定していないはずなのに、複数個Pushされているように見えますが、dockerイメージ作成の際に、ベースとなったAlpineLinuxのイメージや中間で作成されたイメージと共にpushされるからで、とくに問題ありません。

さて、イメージが無事pushされたか、AWSコンソール画面で確認しましょう。

「latest」というImageTagが追加されていますね。22.57MBと表示されていますが、Docker クライアントは V2 Docker レジストリにプッシュする前にイメージレイヤーを圧縮するので、ローカルで表示されているサイズ（非圧縮）に比べて、サイズが小さくなるようです。

• リポジトリ情報の表示

さて、毎回latestを上書き更新するというのも変なので、同じイメージでバージョン番号もつけておきたいです。もう一度同じイメージをpushし直す必要はなくて、AWS CLIを使ってpush済みのイメージに別のタグを振ることができます。

• AWS CLI を使用してイメージにもう一度タグを付ける

コマンド入力

$ aws ecr batch-get-image --repository-name slack_image --image-ids imageTag=latest --query images[].imageManifest --output text > amazonlinux.manifest
$ aws ecr put-image --repository-name slack_image --image-tag v1.0 --image-manifest file://amazonlinux.manifest

２番目のコマンドを実行すると、出力結果がどばっと出ますが、特に今回は使いません。

画面を見ると、v1.0が追加されているのがわかりますね。容量は同じですがダイジェストが違うので、同一イメージではなくて別のイメージとして扱われているようです。

2. EC2 Container Service（Amazon ECS）の新しいタスク定義を作成する

ECSの２番目のメニューとなっている、タスク定義をクリックして、新しいタスク定義を作りましょう。

このあたりから用語がよくわからなくなってくるのですが、一度動かしてみると理解が早いと思うので、特に定義を語ったりせずに先に進みます。

● タスク定義

タスク定義名を「task_docker_bot」、タスクロールを以前に作成したIAMロール「iam_slack_taskrole」を選択します。ネットワークモードは「bridge」のままで良いです。

画面を少し下にスクロールすると、「コンテナの追加」ボタンがあるのでクリックします。

● コンテナの追加

コンテナ名を「container_slack」、イメージを、EC2 Container Registryにpushした、「xxxxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/slack_image:latest」と入力します。

※画面ではlatestの部分を入力し忘れていますが、コンテナ名はDocker デーモンに直接渡される名前で、タグ名はDocker Engine はデフォルトで :latest タグを使うため、指定がなくてもlatestが使用されるため問題ありませんでした。

また、メモリの制限を指定します。ここでは「ハード制限」として「300」を指定していますが、今回１つのタスクしか起動しないので、厳密には意味がない数字になります（指定が必須なので適当に指定しています）。

下にスクロールしていくと、「環境変数」という記載があるので、キーを「ENV_INJECTOR_PREFIX」、値を「slack」とします。この設定で、dockerのENTRYPOINTに登録した「env-injector」が、パラメータストアの設定を取得しに行きます。

コンテナ設定の最後に、ログドライバーの設定を行います。これでCloudWatchからログが出力されるようになります。「awslogs-group」をさきほど設定した、「slack_log」に、「awslogs-region」を「ap-northeast-1」と入力します。

コンテナの追加ページはこれで入力終了です。画面右下の「追加」をクリックして戻りまして、タスク定義のページ画面右下の「作成」をクリックするとタスク定義が作成されます。

3. EC2 Container Service（Amazon ECS）のクラスターを作成する

さて、最後の大物、ECSのクラスターを作成します。一度ボタンを押すと、勝手に実行中！完了！実行中！完了！と、自動で動き出すところに大物感を感じます。

ここではクラスター名を「cluster-slack」として、空のクラスター作成にはチェックをつけないで、プロビジョニングモデルは「オンデマンドインスタンス」を選択してください。

次に、大事なところですが、テストで使うだけであれば、「EC2インスタンスタイプ」は「t2.micro」で十分です。費用に影響するので一番小さいのにして置きましょう。

後は特に触らずに、画面下の「作成」をクリックすると、自動的に裏でごそごそ動き始めて、ステータスが変わるのがわかります。

全部緑になったら完了です。私が何度か実行した感じですと、毎回3〜５分程度で終わりました。

4. 3のクラスターができたら、新しいタスクを実行する

ようやくここまで来ました！　もう一息です。さきほど作ったクラスターに、その前に作ったタスクを紐づけて、dockerイメージを動かします。

設定されたクラスターを開くと、最初にサービスタブの画面が出るのですが、サービスは今回使いませんので無視します。

タブを「タスク」に切り替えて「新しいタスクの実行」をクリックします。

タスクの実行画面が表示されて、どのタスクをどのクラスターで実行するかを定義できます。ここでは１個ずつしか定義していないので、そのまま選択された状態になっています。

ここで、ログをCloudWatchに出したいので、ログレベルをINFOに設定したいとします。（今回docker上のプログラムはデフォルトがWARNINGで、WARNINGにすると正常時は出力するログがありません)

その場合は、タスク定義のコンテナの設定で指定した環境変数以外に、この画面で更新、追加が可能です。ここでは、環境変数のキー「LOG_LEVEL」、値「INFO」を追加します。

最後に画面下の「実行」をクリックすると、タスクを実行します。

5. ４のタスクが動いたら、Slackbotが動作していることを確認する

タスクを実行すると、画面上でPENDINGとなり、RUNNING待ち状態となります。

タスクの部分がリンクになっているので、タスクの文字列をクリックすると、詳細画面に飛びます。RUNNINGになるまで待ちましょう。

RUNNINGになると、slack上でもbotから挨拶があるので、起動していることがわかります。

CloudWatchログのslack_logにもログが出力されていることが確認できます。

今回のdocker内のプログラムは、Slackのbotなのですが、Slack側で何かお話すると止まるとか高度な機能は入っていないので、ECSのクラスターのタスクの画面から直接停止させてください。

試行錯誤

何度か動かない〜ということがあり、何が悪いのかわからず、いろいろ調査していたのですが、面倒なことをする前にここを見ておけ、というコツがわかりましたので、共有しておきます。

タスクでdockerイメージの指定が間違っている

URLを省略しすぎたり、文字列が間違っていると、登録自体はできてしまって、起動時にPENDING→STOPPEDと自動的に止まるのですが、そもそもなぜ止まったのかがわかりにくいという特徴があります。

止まったタスクのIDをクリックすると、詳細ページが出てくるのですが、その中のコンテナをクリックすると、コンテナの詳細情報が表示されます。ここに状況の理由という項目があって、エラー内容が書いてあります。

Invalid parameter at 'registryIds' failed to satisfy constraint

これはレジストリのIDがおかしいというエラーですが、それ以外にも、ファイルがpullできないというエラーのケースもあります。

タスク停止理由:Essential container in task exited
コンテナ詳細：状況の理由：CannotPullContainerError: API error (404): repository ***** not found: does not exist or no pull access

awslogsログドライバーを指定しているのに、aws-logsに指定したグループがCloudWatch上に設定されていない

aws-logsのグループ名を適当につけて、CloudWatch側にそのグループ名がない場合にも、登録はできるのに、起動時にPENDING→STOPPEDで無慈悲に止まります。

The specified log group does not exist.

と、エラー理由が明確に書いてあるわけで、この詳細さえ見てれば、まずはケアレスミス的なものは潰せるのかなと。

まとめ

サーバ建てて、sshで入って、プログラムコピーして、設定して、動作確認して、といういままでの進め方が、今回AWS上ではサーバに一切触れていない（EC2もS3も触ってない）のに目的を達成しているわけでして、なんか一気に未来に来た感がありますね。

IoTとも相性良さそうなので、もう少し突き詰めていきたいと思います。