ECSの記事一覧｜ハンズラボエンジニアブログ

こんにちは、ハンズラボの清水です。東急ハンズのECサイトを担当しています。今回は前回の続き、GitHubのリポジトリにpushしたらECRへpushを行うGitHubActionsを紹介します。

前回の記事はこちら
バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1

前回の記事の追記(Fargateになりました)

前回の記事のクラスターを作成にEC2を利用しましたが、その後、NATGatewayにElasticIPをつけることでFargateで出て行くIPアドレスを固定することができたのでFargateになりました。

IPアドレスを固定する理由は外部ECモール(yahoo, 楽天など)のAPIを利用する際、IPアドレスの制限があるのでIPを固定しています。

GitHubActionsを作成する

ここから本題！GitHubのリポジトリにpushしたらECRへpushを行うGitHubActionsを作成していきます。
参考にしたもの(https://github.com/actions/example-aws)

主な流れはこんな感じ

GitHubのリポジトリにコードをpushする
docker buildを行う
dockerにタグをつける
AWSのアカウントにログイン
ECRにpushする

GitHubのリポジトリから作成します。
作成を行うとプロジェクト内に.github/main.workflowというファイルが作成されます。GitHubActionsのGUIで作成も出来ますし、main.workflowを編集して作成もできます。

個人的にはGUIで大まかな流れを作成して、main.workflowを編集するやり方が個人的には作成しやすいです。

main.workflowの見方

workflow "Build and Deploy(prod)" {
  resolves = [ # 実行するAction
    "Filters Branch(prod)",
    "Slack Push Finish(prod)",
    "Slack Push Start(prod)",
  ]
  on = "push"
}

action "Filters Branch(prod)" {
  uses = "actions/bin/filter@master"
  args = "branch master" # ブランチがmasterの時のみ
}

action "Build Docker Image(prod)" {
  uses = "actions/docker/cli@master"
  # 環境変数
  env = {
    STAGE = "prod"
  }
  args = ["build", "-t", "test-python", ".", "--build-arg", "STAGE=$STAGE"] # dockerコマンドのargs
  needs = ["Filters Branch(prod)"] # Filters Branch(prod)の後に実行
}

workflow "Build and Deploy(prod)" {

resolves = [ # 実行するAction

"Filters Branch(prod)",

"Slack Push Finish(prod)",

"Slack Push Start(prod)",

]

on = "push"

}

action "Filters Branch(prod)" {

uses = "actions/bin/filter@master"

args = "branch master" # ブランチがmasterの時のみ

}

action "Build Docker Image(prod)" {

uses = "actions/docker/cli@master"

# 環境変数

env = {

STAGE = "prod"

}

args = ["build", "-t", "test-python", ".", "--build-arg", "STAGE=$STAGE"] # dockerコマンドのargs

needs = ["Filters Branch(prod)"] # Filters Branch(prod)の後に実行

}

がっつりmain.workflowを書くことはありませんが、GUIである程度作成してしまえばいいので編集するのはenvやargsくらいです。
usesは使用するdocker imageです。(独自の環境での実行もできます)

作成したもの

各説明(処理の流れ)

1. ブランチをフィルタリングする

pushされたブランチがmasterの時のみ下に処理を流します。
GitHubActionsでは条件分岐ができないのでFillterを使用しています。

2. イメージのbuild, ECRへのログイン, slack通知

ここではイメージの build、ECRへのログイン、slackへの通知を並列で実行します。

action "Build Docker Image(prod)" {
  uses = "actions/docker/cli@master"
  env = {
    STAGE = "prod"
  }
  args = ["build", "-t", "test-python", ".", "--build-arg", "STAGE=$STAGE"]
  needs = ["Filters Branch(prod)"]
}

action "Build Docker Image(prod)" {

uses = "actions/docker/cli@master"

env = {

STAGE = "prod"

}

args = ["build", "-t", "test-python", ".", "--build-arg", "STAGE=$STAGE"]

needs = ["Filters Branch(prod)"]

}

やっていることはdocker build -t test-python . –build-arg STAGE=$STAGEのコマンドを実行しています。

action "Login to ECR(prod)" {
  uses = "actions/aws/cli@master"
  args = "ecr get-login --no-include-email --region ap-northeast-1 | sh"
  secrets = [
    "AWS_ACCESS_KEY_ID",
    "AWS_SECRET_ACCESS_KEY",
  ]
  needs = ["Filters Branch(prod)"]
}

action "Login to ECR(prod)" {

uses = "actions/aws/cli@master"

args = "ecr get-login --no-include-email --region ap-northeast-1 | sh"

secrets = [

"AWS_ACCESS_KEY_ID",

"AWS_SECRET_ACCESS_KEY",

]

needs = ["Filters Branch(prod)"]

}

ECRへのログインも先ほどのdocker build同様にawsのコマンドを実行しています。secretsにAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYをセットすることでECRにログインできます。

secretsの登録は割と簡単です。

action "Slack Push Start(prod)" {
  uses = "Ilshidur/action-slack@master"
  needs = ["Filters Branch(prod)"]
  secrets = ["SLACK_WEBHOOK"]
  args = "push開始(prod)"
}

action "Slack Push Start(prod)" {

uses = "Ilshidur/action-slack@master"

needs = ["Filters Branch(prod)"]

secrets = ["SLACK_WEBHOOK"]

args = "push開始(prod)"

}

slack通知はsecretsにwebhookのURLをセットしてargsにチャンネルに通知するメッセージを設定します。

3. dockerイメージにタグをつける

action "Tag image for ECR(prod)" {
  uses = "actions/docker/tag@master"
  env = {
    CONTAINER_REGISTRY_PATH = "<アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com"
    IMAGE_NAME = "test-python"
  }
  args = ["$IMAGE_NAME", "$CONTAINER_REGISTRY_PATH/$IMAGE_NAME"]
  needs = ["Build Docker Image(prod)"]
}

action "Tag image for ECR(prod)" {

uses = "actions/docker/tag@master"

env = {

CONTAINER_REGISTRY_PATH = "<アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com"

IMAGE_NAME = "test-python"

}

args = ["$IMAGE_NAME", "$CONTAINER_REGISTRY_PATH/$IMAGE_NAME"]

needs = ["Build Docker Image(prod)"]

}

docker tag test-python:latest <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/hogehoge:latest

1	docker tag test-python:latest <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/hogehoge:latest

行なっていることは上記のコマンドと同じですコマンドではバージョンをlatestとしていますが、GitHubActionsではバージョンにブランチ名が適応されます。

4. ECRへpushする

action "Push image to ECR(prod)" {
  uses = "actions/docker/cli@master"
  needs = [
    "Login to ECR(prod)",
    "Tag image for ECR(prod)",
  ]
  env = {
    CONTAINER_REGISTRY_PATH = "<アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com"
    IMAGE_NAME = "test-python"
  }
  args = ["push", "$CONTAINER_REGISTRY_PATH/$IMAGE_NAME"]
}

action "Push image to ECR(prod)" {

uses = "actions/docker/cli@master"

needs = [

"Login to ECR(prod)",

"Tag image for ECR(prod)",

]

env = {

CONTAINER_REGISTRY_PATH = "<アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com"

IMAGE_NAME = "test-python"

}

args = ["push", "$CONTAINER_REGISTRY_PATH/$IMAGE_NAME"]

}

dockerイメージのタグ付け、ECRへのログインが終わり次第ECRへpushを行います。

docker push <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/test-python:latest

1	docker push <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/test-python:latest

行なっているコマンドは同じですがバージョンのlatestは今回masterになっています。ECSのタスク定義でイメージのURLをlatestにしている場合はmasterに変更しましょう。

5. 完了通知をslackに飛ばす

2. の工程で説明を行なっているので省略します。

masterへpushを行うと、リポジトリのActionsタブから実行ログを見ることができます。

GitHubActionsを使って見ての感想

良い点

作成が簡単
処理の流れが見やすい
Dockerとの相性が良い

悪い点

ブランチごとにActionsを定義できない
条件分岐が使用できない(失敗したら~~するとか)
AWSの複数アカウントに対応できない(Keyを1セットしか登録できない)

現在GitHubActionsはPublicBetaなので今後の機能追加に期待しています。

はじめに

こんにちは、ハンズラボの清水です。東急ハンズのECサイトを担当しています。今回はEC2上で動いている外部ECモール連携バッチをAmazon ECS ScheduleTaskに移行しました。そして、GitHubにpushした際にECRにイメージをpushできるようなGitHubActionsも作成しました。今回はECSのScheduleTask機能を使用してバッチ処理を作成していきます。

※外部ECモールとはyahooや楽天といったショッピングサイトのことです。

既存バッチ処理の内容

既存のバッチ処理ではEC2インスタンス上にバッチサーバーを用意、cronにスケジュールを登録してバッチを叩いています。
処理の内容としては、Auroraに追加された注文変更情報を取得して、注文情報商品の数量変更、注文キャンセル等を行っています。
今回は注文情報変更処理をECSに移行しました。

ECSへ移行

移行の理由

移行の理由としては以下の点が挙げられます。

AWSのサポートを受けられる
各バージョンアップに対応できる
EC2を冗長化したい
dockerを使用するのでローカルでの開発が楽になる

注文情報変更の処理のみをdockerのイメージとして切り出し,ECR(Amazon Elastic Container Registry)にpushします。 Amazon ECS ScheduleTaskでスケジュールを指定して、処理を開始します。

ECRの作成

ECR(Amazon Elastic Container Registry)の作成を行い、ローカル開発環境にあるdockerイメージをECRへpushします。はじめにECRでリポジトリを作成しましょう。作成したらリポジトリ名をコピーしておくと後々楽です。

dockerイメージの作成&ECRへpush

ECR(Amazon Elastic Container Registry)へpushする用のdockerイメージを作成して,pushしましょう。以下のbashスクリプトで行いました。

#!/usr/bin/env bash

# DCTを有効化
DOCKER_CONTENT_TRUST=1

# ecrにログインする
aws ecr get-login --no-include-email --region ap-northeast-1

# 先ほど作成したリポジトリ名を使用する
docker build -t hogehoge .
docker tag hogehoge:latest <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/hogehoge:latest
docker push <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/hogehoge:latest

#!/usr/bin/env bash

# DCTを有効化

DOCKER_CONTENT_TRUST=1

# ecrにログインする

aws ecr get-login --no-include-email --region ap-northeast-1

# 先ほど作成したリポジトリ名を使用する

docker build -t hogehoge .

docker tag hogehoge:latest <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/hogehoge:latest

docker push <アカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/hogehoge:latest

のちのAmazon ECS ScheduleTaskで説明しますが作成したDockerfileのENTRYPOINTを"/bin/ash"のようにしておくとコンテナの挙動を変更できます。(今回はpython:3.7.3-alpine3.8を使用したのでashです)

クラスターを作成

ECSからクラスターを作成します。クラスターのテンプレートですが、今回は出て行くIPアドレスを固定したいためFargateを使用せずにEC2を利用しました。クラスターの設定は各自お任せします。

後に気づいたのですが、NATGatewayにElasticIPをつけることでFargateでもIPアドレスを固定できます。

タスクを定義

ECSからタスクを定義します。起動タイプはEC2を選択。

コンテナ定義でコンテナの追加します。イメージには先ほど作成したECRのURLのパスを貼り付ければOK。

環境のコマンドに今回はテストとしてecho testを実行します。

ログ設定のAuto-configure CloudWatch Logsにチェックを入れておくとCloudWatch Logsにログを吐いてくれるのでチェックを入れました。

タスクを実行してみる

作成したクラスター→タスク→新しいタスクの実行からタスクを実行する。先ほど作成したクラスターとタスク定義を選択をして実行しましょう。実行ログはCLoudWatchLogsに吐かれるので確認しましょう。

成功です。

スケジュールを設定する

作成したクラスター→タスクのスケジューリングから作成します。
スケジュールタイプはCron式でも設定できます。タスク定義を先ほど定義したタスクを設定して作成完了です。

CloudWatchLogsでログを確認したところスケジュール通りに動いてくれています。

ハマったところ

タスクが実行されない(CloudWatchメトリクスにFailedInvocationsが出ている)問題がありました。調査の結果以下の二つが問題の原因でした。

インターネットに接続出来ていない(ElasticIPを付与したら解決)
コンテナインスタンス IAM ロールに権限が付与されていない(IAMロールからECSFullAccessつけることで解決)

終わりに

今回はECSのECS ScheduleTaskを利用してバッチ処理を移行しました。次回はGitHubActionsを利用したECRへのpushを紹介できればと思います。

カテゴリー: ECS

バッチ処理をECSに移行した話(GitHubActionsもあるよ)その2

前回の記事の追記(Fargateになりました)

GitHubActionsを作成する

main.workflowの見方

作成したもの

各説明(処理の流れ)

1. ブランチをフィルタリングする

2. イメージのbuild, ECRへのログイン, slack通知

3. dockerイメージにタグをつける

4. ECRへpushする

5. 完了通知をslackに飛ばす

GitHubActionsを使って見ての感想

バッチ処理をECSに移行した話(GitHubActionsもあるよ)その1

はじめに

既存バッチ処理の内容

ECSへ移行

移行の理由

ECRの作成

dockerイメージの作成&ECRへpush

クラスターを作成

タスクを定義

タスクを実行してみる

スケジュールを設定する

ハマったところ

終わりに