【お約束】 投稿内容は個人の見解であり、所属する（していた）組織の公式見解ではありません。
名前：uyamazak（昔いた会社で上司が開発用Linuxサーバーのユーザー名に「yuyamazaki」が長いので勝手に作ってくれた。読み方わからないけどウヤマザク）
高校あたりからWEBサイトをやったり趣味の延長でWEB系を仕事にした感じの人間。
2020年1月から株式会社シニアジョブにジョイン。
2021/1現在、まだ開発者は３人、これからの会社なのでビジネス貢献しつつ、きれいな設計をしたい
アズールレーン@竹敷でモバイルのUI、UX研究中（初嫁ジャベリン）
フレンド＆大艦隊メンバー募集してます ID:939524678 @竹敷
GitHub: https://github.com/uyamazak/
これまでの主なプロジェクト
続きを読むAWSのECSを使った環境構築、↓この記事からの続きで、
uyamazak.hatenablog.com
Laravelの
php artisan schedule:run
を実行するためにタスクのスケジューリングを使ってみることに。
新規作成はコンソール上でなんなくできたものの、CircleCIからの更新方法が見つかりませんでした。
コンテナのビルドからECRへのプッシュとか、ECSのサービスの更新などはCircleCIの公式Orbがあったけど、スケジュールに関するものは見当たらない。
CircleCI Developer Hub - circleci/aws-ecs
どうやらスケジュールタスクはECSの画面にあるもののAWSの裏側ではいろいろ組み合わせて構成されてるようで、ECSのコマンドでは更新できないもよう。
shirakiya.hatenablog.com
この記事だと手で叩くことはできても、タスク定義のリビジョンは毎回異なるため、そこは別に用意する必要があった。
公式ドキュメントには新規作成だけあった。
AWS CLI を使用したスケジュールされたタスクの作成 - Amazon Elastic Container Service
個人のOrbもあったけど、ソースをみるとPython使ってたり、ちょっと無理やりな感じなので勉強も兼ねてAWS CLIでやることに。
CircleCI Developer Hub - pbrisbin/aws-ecs-scheduled-tasks
実行タイミング的には上記Orbのaws-ecs/deploy-service-updateが終わり、タスク定義が更新された後。
まずはCIでいちいちやると大変なので、自分のPCから更新が成功するか試します。AWS CLIのインストールや設定は大前提。
上記の記事のようにaws events put-targetsを使います。
基本的に指定はArnなのでECSの画面とかIAMとかで調べながら埋めていきます。
helpを見ながら叩いて、エラーで出た不足した項目を追加していったところ、最低限はこんな感じ。
aws events put-targets --rule your-rule-id --targets="[{"Id":"ターゲットのID","Arn":"クラスターのArn","RoleArn":"ロールのARN","EcsParameters":{"TaskDefinitionArn":タスク定義ののArn"`}}]"タスク定義のArnには最新でなくとも、変わっているのが分かるように、今のスケジュールタスクの指定とは違うものを指定すればよさそう。
こんな感じの結果が返ってきて、コンソールで見て変更されてればOK
{
"FailedEntryCount": 0,
"FailedEntries": []
}
上記のコマンドがうまくいくのがわかったら、TaskDefinitionArnの部分を動的に最新の1件を取得するようにします。
タスク定義はECSの範疇なのでaws ecs list-task-definitionsで取得し、--sortと--max-itemsを使って最新1件にしぼります
$ aws ecs list-task-definitions --family-prefix タスク定義の名前 --sort DESC --max-items 1
{
"taskDefinitionArns": [
"arn:aws:ecs:{リージョン}:{アカウントID}:task-definition/タスク定義の名前:8"
],
"NextToken": "tekitooooooooooo=="
}このままだとJSON的なものなので使いにくい・・・使えなくはないけどCIでjqとかインストールするのもださい。
ということでいろいろ調べているとAWS CLIには--queryという全体で使えるオプションがあることを知りました。
AWS CLI 出力をフィルタリングする - AWS Command Line Interface
ほしいのはtaskDefinitionArnsの1つ目なので--query "taskDefinitionArns[0]"をつけます。
$ aws ecs list-task-definitions --family-prefix タスク定義の名前 --sort DESC --max-items 1 --query "taskDefinitionArns[0]"
"arn:aws:ecs:{リージョン}:{アカウントID}:task-definition/タスク定義の名前:8"
これでタスク定義のArnだけが取得できました。
あとはシェル芸なんですが、私はあまりシェル力は高くないので一旦JSON的な部分を環境変数にして使うことにしました。
最終的にこんな感じの.circleci/config.yml。
とりあえず今回環境で変わりそうなところだけparameter化したけどもっときれいにできそう。
version: 2.1
orbs:
aws-cli: circleci/aws-cli@2.0.0
commands:
put_targets:
parameters:
target_id:
type: string
cluster:
type: string
family:
type: string
rule:
type: string
steps:
- run:
command: |
TARGETS="[{\"Id\":\"<< parameters.target_id >>\",\"Arn\":\"arn:aws:ecs:リージョン:アカウントID:cluster/<< parameters.cluster >>\",\"RoleArn\":\"arn:aws:iam::アカウントID:role/ecsEventsRole\",\"EcsParameters\":{\"TaskDefinitionArn\":`aws ecs list-task-definitions --family-prefix << parameters.family >> --sort DESC --max-items 1 --query "taskDefinitionArns[0]"`}}]"
aws events put-targets --rule << parameters.rule >> --targets=$TARGETS
jobs:
update_scheduled_task:
executor: aws-cli/default
steps:
- aws-cli/setup
- put_targets:
cluster: hogeeee
family: hoggeeee
target_id: hogeeee
rule: hogeeee
workflows:
hogeeee-workflow-name:
jobs:
- update_scheduled_task:
requires:
- deploy-service-update-queue
filters:
branches:
only:
- stage
- push_dockerimage_to_ecrこれでサービスやタスク定義の更新後に、スケジュールしたタスクの定義も更新することができました。
ただ常に最新になってしまうので、もしかしたら問題が起きるときもあるかも？（ロールバックとか）
優先度が高い仕事が落ち着いてきたため、ずっとやりたかった本番環境コンテナ化に着手しました。
たぶんお休みで全部忘れるので社内に説明用も兼ねてメモ。
下記の記事のように現在のシニアジョブに入社してすぐ、開発環境はDocker化していました。
シニアジョブに入社して１ヶ月でやったこととこれから - GAミント至上主義
現在、本番環境はElastic Beanstalkで動いていますが、Dockerfileで管理できるため、いつかは揃えてコンテナ化したいなぁと思っていました。
AWS ECSからEC2の管理を（でき）なくしたサーバーレス的なもの・・・という雑な認識。詳細は公式。
AWS Fargate（サーバーやクラスターの管理が不要なコンテナの使用）| AWS
専用ページはあるものの、コンソールの中だと、ECSやEKSの起動タイプとして存在してるだけで意外と地味な存在でした。
コンテナ化に際しては、タイトルのFargateの他、下記の選択肢がありました。
下記がFargateにした理由です。
シニアジョブでは、現在のシステムが動いた当初（2016年ごろ？）からAWS上で求人サイトや管理システムも動かしていました。
そのためRDS（MySQL）をはじめ、Elasticsearch、DynamoDB、SQSなども使用しています。
そのため、個人的にはGCPのGKEは使い慣れていたので使いたい気持ちはあるものの、わざわざGCPに移すという選択肢はありませんでした。
これまで触ったことはないものの、ネット上の記事とかの印象だと、AWSでそこまで大規模じゃないシステムだったらFargateかなぁというイメージでした。
シニアジョブのシステムで必要になりそうなコンテナは下記3つだけで、ほかはRDS, RedisなどはAWSのマネージドで済みます。
これだけだとKubernetesの機能はちょっとオーバーかなぁという印象。あとAWSでKubernetesはGKEと比較すると高くつくというのもあります。
実際構築してみた感じ、ハードウェアリソースも柔軟で、Fargateで十分でした。
EC2タイプを使ったことはないので比較はできないのですが、EC2を意識せずに使えるというのは、エンジニア3人で何とかしている現状では、メンテナンスコストを削減できそうなので、大きな価値がありました。
サーバーレスとあるので、GCPでいうCloud Runみたいな感じかなぁと思ってたら、どちらかというとKubernetesで最近出たAutopilot的なものでした。
GCPではいろいろ構築したことがあるもののAWSで複数サーバーのシステム構築は初めてでした。
そのためFargateを使用するにあたり、AWSの他のサービス、機能を知る必要がありました。
まずはDockerで作ったコンテナをAWSに置いておく必要があります。その置き場所がECR。
Amazon ECR（Docker イメージの保存と取得）| AWS
最初1回だけ手作業でローカルからビルド＆プッシュしましたが、面倒なのでCircle CIで自動化しました（後述）
これが今回使うメインのサービスになります。
Amazon ECS（Docker コンテナを実行および管理）| AWS
ECSの中に下記があります
ECSの一番外側、EC2をひとまとめにしたもの。Kubernetesのクラスターと同じ感じですね。
今回はFargateを使うので、ネットワーキングのみを使用します。
後述するタスクを管理するもので、タスク定義や、起動数を指定し、その状態に変更、維持してくれます。
1サービスに対し、1タスク定義っぽい。
また後述するロードバランサーもサービスと紐づけることになります。
Amazon ECS サービス - Amazon ECS
作成後に変更できない設定が多々あり、5回ぐらいは作り直した記憶があります。
タスクの設計書のようなもので、ここに使用するコンテナ（複数可）や、コンテナごとの環境変数などの設定、必要なリソース（CPU、メモリ等）を指定します。
こちらも作成時に起動タイプにFargateを指定します（もう一つはEC2）。
更新の際は、上書きではなく、リビジョンを増やしていく形になります。
Amazon ECS タスク定義 - Amazon Elastic Container Service
具体的なコンテナ定義はタスク定義内にあります。開けるポートの指定もここ。
同じタスク定義内であれば、127.0.0.1で通信できるようなので、nginxからappへのプロキシ設定では127.0.0.1を使用しました。
KubernetesだとServiceを作る必要があったり面倒なので、今回はこれで十分だし、シンプルに感じます。
※あとでqueueは別サービスに分けました
サービスでのロードバランサー設定は、ここで設定したnginxコンテナのポート80を指定しました。
上記のタスクをサービスが起動したもの。プログラミングだとタスク定義がクラス、タスクがインスタンス、みたいなイメージ？
変更の際はタスク定義のリビジョンを指定して更新します。
スケールさせるのもこのタスク単位
頻繁に消したり、作ったりするものなので、タスクIDは
32034c0a56d84d5eb95908090cdec44c
みたいなランダムな16進文字列になります（後述のシェルで入るときに使う）。
サービスを更新すると新しいのができたり古いのが消えたりします。
ECSと関係するのが以下のサービス＆機能になります。
Amazon VPC（仮想ネットワーク内での AWS リソースの起動）| AWS
クラスター使用時に選択、または作成します。仮想のネットワークで、セキュリティ設定などに影響します。
新規のときは一緒に作ればいいですが、既存のシステムがあるときは同じものを使用しないと、いろいろ繋げるのが面倒になるので、注意が必要でした。
Amazon Route 53（スケーラブルなドメインネームシステム (DNS)）| AWS
言わずとしれたDNSサービス。
上記ロードバランサーでは
foobar-4580172169.ap-northeast-1.elb.amazonaws.com
のような長めのURLが振られるため、独自ドメインを使用する際はRoute53で紐付けます。
Aレコードから選択形式で簡単に指定できます。
ロードバランサーから今回のECSのサービスに繋げる転送先（実体はタスクのローカルIP）に使用されます。
ロードバランサーの新規作成時や、ECSでサービスを作る際に自動でできてしまうので、サービスを作り直したりすると、余計なものが残っていて邪魔になり消すのが面倒でした。
ECSのサービスは、タスクが更新され、ヘルスチェックが通ると、このターゲットグループのIPを自動で変更することで、ユーザー側へも変更されます。
ECSのサービスが持ちます。
IPは変わってしまうので、これを使って、VPC内の通信許可などを行います。
現環境では既存のセキュリティグループに、サービスからRDSやRedisへの許可を追加しました。
コンテナで使うパスワード等の機密情報を保持します。
とりあえずLaravelで.envファイルで使用していた項目を移しました。
AWS Secrets Manager（シークレットのローテーション、管理、取得）| AWS
タスク定義で、コンテナごとに設定し、環境変数として使うことができます。
JSON形式のオブジェクト形式で複数持つことができますが、自動で環境変数に展開することはできないようなので
valueFromで一つずつ
arn:aws:secretsmanager:ap-northeast-1:user-id:secret:secret-name-AAAAAA:YOURENV::
のように指定して読み込む必要がありました。
このチュートリアルのようにIAMロールの追加も必要です。
チュートリアル: Secrets Manager シークレットを使用した機密データの指定 - Amazon Elastic Container Service
動かすためにいろんな設定を理解、修正する必要があり、独自ドメインからコンテナのWEBアプリケーションまで繋がるのに幾度となくはまり、3日ぐらいかかりましたがなんとか動かくことができました。
コンテナ変更のたびに手作業でビルド、プッシュするのは現実的ではないのでなるべく早い段階でやった方がよさそうです。
シニアジョブではCircle CIを使っていたので、そのまま利用しました。GitHub Actionsでもやってみたいなぁ。
Circle CIのいろんな処理をまとめたOrbsを使うとめっちゃ簡単でした。
ほぼ公式まんまですが、service-nameだけ公式ドキュメントになく、デフォルト値ではうまくいかなかったので、orbのソースを見て追加しました。
またfamilyがわかりにくいですが、タスク定義をJSONで確認するとfamilyの項目が見つかります。
まだステージング環境だけなのでtagの先頭にstageを固定でつけてます。
.circleci/config.yml
version: 2.1 orbs: aws-ecr: circleci/aws-ecr@6.15.3 aws-ecs: circleci/aws-ecs@2.0.0 workflows: build_and_push_image_app: jobs: - aws-ecr/build-and-push-image: account-url: AWS_ECR_ACCOUNT_URL aws-access-key-id: AWS_ACCESS_KEY_ID aws-secret-access-key: AWS_SECRET_ACCESS_KEY dockerfile: ./Dockerfiles/app/Dockerfile path: . region: AWS_REGION repo: senior-job/app create-repo: true tag: "stage-$CIRCLE_SHA1" - aws-ecs/deploy-service-update: cluster-name: 'example' service-name: 'example-service' container-image-name-updates: 'container=app-container,tag=stage-${CIRCLE_SHA1}' family: 'example' requires: - aws-ecr/build-and-push-image - aws-ecs/deploy-service-update: cluster-name: 'example' service-name: 'example-service' container-image-name-updates: 'container=queue-container,tag=stage-${CIRCLE_SHA1}' family: 'example' requires: - aws-ecr/build-and-push-image
なぜかうまく行かない時は、中で環境変数がどうなってるかとか、ファイルちゃんとあるかとか、やっぱりコンテナの中に入って確認したいもの。
Kubernetesだと`kubectl exec -it pod_name bash`みたいにサラっと入れますが、一筋縄では行きませんでした。
特にFargateはEC2を触れないことから、難しかったみたいですが最近(2021/3)公式な手段が準備されたようです。
このプロジェクトが2ヶ月早かったら詰んでたかも。5年以上前でもexecはできてたので、全体的な完成度としてはKubernetesがやっぱ進んでるなぁと思ったできごとでした。
New – Amazon ECS Exec による AWS Fargate, Amazon EC2 上のコンテナへのアクセス | Amazon Web Services ブログ
権限付与、サービスの設定変更、CLIのアップデートなどいろいろ面倒でしたが、こちらの記事がまとまっていてわかりやすかったです。
[アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました | DevelopersIO
まだステージング環境が動いただけなので、いくつかまだたりないデプロイプロセスの追加や、死活監視関係、本番でのリソース調整やオートスケール設定など、まだまだたくさんありそうです。
あとAWSだけだと自動化つらいのでTerraformも使った方がいいのかなぁとか。
appのサービス（php-fpmとnginx）とqueueを実行するサービス＆タスクは分けた方が良いと思った
趣味で開発しているPuppeteerを使ったPDFサーバーhc-pdf-serverで一部分をnpmにパッケージとして公開しています。
これ↓
www.npmjs.com
FastifyからPuppeteerを通して、Headless ChromeのPageを使用できるプラグインです。
名前の通り速いFastifyの長所を殺すこと無く、起動しておくPageを増やすことで大量リクエストもさばけそうな気がします（実戦経験はない）。
PDFだけでなく、スクリーンショットとか、JavaScriptでできたHTMLを取得したりいろいろできるよ！
Puppeteerとの連携部分はもともとFastifyのプラグインとして作っていたこともあり、
また超絶頭のいいと思われる見知らぬプログラマからすばらしいプルリクを頂いて強いプラグインとなったという理由もあり、
次もPuppeteer + Fastifyで何か作ろうと思っているのもあり。
で、npmにパッケージ公開してそれを使ってみたら、いろいろ世界の見え方変わった気がしたのでかなりおすすめです。基本無料です。
細かい説明は他にあるので、ざっくり流れを忘れないようにメモ。
既存のアプリケーションからの分離なのでまずはこれでした。
必要最低限なファイルや設定で新しいレポジトリをつくり、package.jsonに必要な情報を書きます。
この記事を参考にしました。
qiita.com
nameには最初でグローバルを汚すのも申し訳ないのでscopedと呼ばれる@uyamazak/をつけました
package.json
"name": "@uyamazak/fastify-hc-pages",
TypeScriptのコードで、jsはレポジトリに含まれていないため、prepublishOnlyでビルドするようにしました。
package.json
"scripts": {
"build": "rm -rf ./dist && tsc",
"prepublishOnly": "npm run build",TypeScriptでnpmライブラリ開発ことはじめ - Qiita
あとmainのパスをちゃんとやったりぐらいかな？
ここらへんで普段意識していなかったpackage.jsonの項目を理解し、意識できるようになった気がします。
それっぽいものができたら、npmjsで公開する前に自分のGitHubレポジトリにプッシュしてそこからインストールして試します。
yarnでGitHubのレポジトリからインストールを初めて使いました。
$ yarn add https://github.com/uyamazak/fastify-hc-pages
package.jsonにこんな感じで入ります。
バージョンの数字の代わりにURLが入るんだなぁ。ブランチとかの指定もできそう
"dependencies": {
"@uyamazak/fastify-hc-pages": "https://github.com/uyamazak/fastify-hc-pages",
"fastify": "^3.13.0",型定義が吐き出されずに困ってましたが、原因は拡張子を.d.tsにしてたため、というしょうもないミスでハマってました。
ここらへんでnpmパッケージがどうインストールされるかとか、かなり理解できた気がします。
まあ普通にやるので割愛。
GitHubに吸収されて1年経つので、アイコンはGitHubの使えるのかと思ったら・・・
Gravatarェ・・・・。
太古に作ったWordPressアカウントがあった気がするけど面倒なのでそのまま。
準備ができたらpublishします。公開パッケージなのでpublicが必要です。
npm publish --access public
ここでやらかしましたが、パッケージ名が他のFastifyプラグインと違うため、変更したくなりました（最後のpluginいらなかった・・・）
でも一度公開してしまうと基本的に名前の変更、削除はできないため、新しく作って、古いのはdeprecateして放置する必要があります。
以前消えて問題になったことあるししょうがない。
↓殘骸
@uyamazak/fastify-hc-pages-plugin - npm
改めてパッケージ名を変更し、このページができました。
www.npmjs.com
それからしばらくバージョンアップのたびに手動でやってましたが、ローカルで操作するの面倒ですね。
自動でできるようにします。
npmとは別のGithub Packagesの説明が入っていて邪魔ですが、こちらを参考にしました。
docs.github.com
npm側でトークンを作り、GitHubのSecretsに入れるNPM_TOKENの設定が必要ですが、yamlは最終的にはこんな感じ。
.github/workflows/npm.yml
name: Node.js Package
on:
release:
types: [created]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
# npmに公開する.npmrcファイルを設定する
- uses: actions/setup-node@v1
with:
node-version: '14.x'
registry-url: 'https://registry.npmjs.org'
- run: npm install
# npmに公開する
- run: npm publish --access public
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}タイミングは、いつものマージ、プルリクなどではなく、GitHubのReleaseという機能を使います。
ここから、タグにバージョンを入れてリリースを作成すると、自動で公開されるようになりました。
リリースの作成もcommitメッセージを集めてきたり、ある程度自動化できそうですが、しばらくはこのままでいいかな。
ここらへんで、他のレポジトリがどうnpmのパッケージをリリースしているのかを理解できた気がします。
で、しばらく開発をすすめると、プラグインを更新するたびにそれを利用している元本体側も変更が必要など手間が増え、作業時間は増えてしまいます。
が、そのおかげでユーザーとしての気持ちも持つことができるので、変更する際には少し慎重になり、いい設計、コードにしたいという気持ちが強くなった気がします。
でも趣味なので作業時間はプライスレス。
ここのダウンロード数、自分しか使ってないので結構行ってますが、このレポジトリと元のレポジトリのGitHub Actionsで回しているテスト時のダウンロードもカウントされてるようです。
そのため自動でdepandabotがつくるプルリク×3環境×2Node.jsバージョン分だけこの数が増えていくことに。
1人しかユーザーいなくてもCIなどのDLが含まれて200近く行ってしまうということで、他のパッケージのダウンロード数もそこまで参考にならないかなぁという気がします。
