こんにちは @jedipunkz 🚀 です。 今回は Go 言語で ECS コンテナにログインする CLI を作った話を書きます。 開発の経緯 自分はまだ Go 言語の初学者で学習のために開発するアイデアを探していた状態でした。そこで自分の勤めている会社で ECS Execute 機能を使ったコンテナログインの機能を開発者に提供していた事を思い出し色々調べていて「もう少し手間が省けないか？」と思い立った、という経緯で開発をはじめました。 awscli を使った ECS Execute 機能によるコンテナログイン 手間が多いと書きましたが実際に awscli を使う場合どの程度の手間があるのか簡単に記します。まず下記のコマンドを実行して $ aws ecs list-tasks --cluster <クラスタ名> --service <サービス名> taskArn が得られるので Arn から task ID を拾って、その task ID を使って $ aws ecs execute --cluster <クラスタ名> \ --task <task ID> \ -- container <コンテナ名> \ --interfactive \ --command "sh" とコマンドを実行することでコンテナにログイン出来ます。が手間が少し多いのと task ID を拾い出す作業も辛いので改善したい…。 操作画面 ということで miniecs という CLI を作ったのですが、 まずは操作している様子を貼り付けます。😷 Fuzzy Finder なインクリメンタルサーチが出来る CLI になっていて、ECS クラスタ名・ECS サービス名・コンテナ名を一部入力するとログインしたい環境が選択出来るツールになっています。 ...

こんにちは。jedipunkz🚀 です。 今回も READYFOR Advent Calendar 2021 の記事として執筆します。 今回のテーマ 前回の記事 では ECS 移行後の構成について検討する内容を記しました。Progressive Delivery を実践する上でもその一歩手前の構成と言っていいカナリーリリース構成について、今回は記していきたいと思います。 デグレしてしまっていたカナリーリリース READYFOR では AWS ECS 移行を行い ECS + CodeDeploy による Blue/Green デプロイメントを導入しました。逆に移行前までに出来ていたカナリーリリースが実施できなくなりました。とは言ってもそれまで開発者がカナリーリリースに対して求めていた主な機能はロールバックだったため、ひとまずは Blue/Green デプロイメントで事足りている状況なのですが、今後大きな機能をリリースする際にはトラヒックを徐々に寄せ影響を把握した上でリリース進めるという作業は必要になってくる可能性があります。 よって、 Progressive Delivery の一歩手前の構成を実践する 大きなリリースのための環境整備 という意味でも、一回カナリーリリース構成について検討しておこうと考えました。 環境構築 今回用意した Terraform コード 検証で作成した AWS 環境をデプロイするための Terraform コードを下記の場所に置いてあります。参考にしてください。 https://github.com/jedipunkz/tf-appmesh-ecs-canary-release (今回検証で作成したコードは業務上作成したものですが、READYFOR の OSS ポリシーに則り著作権譲渡をうけており、自らのGitHubリポジトリで公開しています。) App Mesh ECS NLB Service Discovery Envoy X-Ray といった技術要素で構成されています。 Terraform コードによるデプロイ実施 上記に記した Terraform コードを使った構成のデプロイ手順を記します。 前提として Terraform バージョン 1.0.x 系以上をローカルにインストールする必要があります。 $ # AWS クレデンシャル情報を設定 $ git clone https://github.com/jedipunkz/tf-appmesh-ecs-canary-release $ cd tf-appmesh-ecs-canary-release $ terraform plan $ terraform apply 構成 検証で構築した構成(上記の Terraform コードで構築できる) は下記になります。 ...

こんにちは。jedipunkz です。 今回は READYFOR Advent Calendar 2021 の記事として執筆します。 READYFOR では 2021 年の夏に AWS ECS へプラットフォーム移行をしました。ECS は自分達の要件を全て満たしてくれ運用コストも極小化できて更に周辺の技術も AWS 公式のものが揃っているので、とても満足している状況です。 移行を終えたばかりなので「では次のアーキテクチャは？」という話にはまだなっていないのですが、今は準備期間として余裕を持ってスケジューリングできる状態にして頂いているので、SRE チームとしては色々な技術をリサーチしている段階になります。 今現在は ECS + CodeDeploy を使って Blue/Green デプロイメントを実現しているのですが、よりモダンなデプロイ方式 Progressive Delivery について去年あたりから興味を持っていました。ただ、今までは実際に技術を触るまでには至っていなかったのでこの機会に色々と触ってみたという次第です。 今までも Blue/Green デプロイメント, Canary リリースとデプロイ方式が複数ありましたが、これらを含む継続的デリバリの次のステップと言われているのが Progressive Delivery です。2020年に Hashicorp 社の Mitchell Hashimoto 氏 が来日した際に「今一番気になっているワード」としてあげていましたのが印象的でした。 ECS を使った Canary リリース Progressive Delivery の話をする前に ECS を使った Canary リリースについて少し触れておきます。 (具体的な話についても、どこかのタイミングで記事にできればと思っています) AWS App Mesh と ECS, X-Ray を使って下記のような構成を作りました。この構成中の App Mesh の Virtual Router のルーティング情報を修正する形で Canary リリースのトラヒック操作が行えます。ECS 以前は Canary リリースを実現できていて ECS 導入によってそれがデグレした状態だったので、この構成の検証は一つの成果だったと思っていますし、今回話をする Progressive Delivery のひとつ前のステップとも考えています。 ...

こんにちは @jedipunkz 🚀 です。 最近、職場では ECS/Fargate でサービスを運用しています。そこで ECS Task 上でコマンドを実行する必要に迫られて幾つか調べたのですが、複数の方法があり検証をしてみました。これには 2021/03 にリリースされたばかりの ECS 上のコンテナでコマンドを実行する機能も含まれています。 自分たちは自動化する必要があったので Go 言語 (aws-sdk-go) を中心に検証実施しましたが同時に awscli でも動作検証しましたので、その方法をこの記事に記そうかと思います。 下記の2つの ECS の機能についてそれぞれ Go 言語, awscli で動作検証実施しました。 (1) ECS Execute Command (2021/03 リリース) (2) ECS Run Task 用いるツール類 下記のツールを前提に記事を記します。 aws-sdk-go Terraform awscli 共通で必要な taskRoleArn まず Task Definition に対して executeRoleArn とは別に TaskRoleArn の付与が必要になります。 resource "aws_ecs_task_definition" "sample" { family = "sample" cpu = "256" memory = "512" network_mode = "awsvpc" requires_compatibilities = ["FARGATE"] execution_role_arn = module.ecs_task_execution_role.iam_role_arn task_role_arn = module.ecs_task__role.iam_role_arn container_definitions = data.template_file.container_definition_sample.rendered } taksRoleArn の内容については https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-iam-roles.html に情報があり、下記が必要になります。 ...

こんにちは。jedipunkz です。 仕事ではこれから会社のサービス環境として AWS ECS の導入を始めていくところなのですが、最近の SRE/インフラ界隈のトレンドを自分たちが追うために自分たち SRE が管理しているボット環境を EKS を使って GitOps 化しようということになり色々と準備を進めています。導入までもう一歩のところまで来たので、構成や技術要素についてここに記したいと思います。 どんなボットが動いているの？ まずボット開発に用いてる言語は Go 言語です。主に aws-sdk-go を使ってボットを開発しています。私達はコミュニケーションツールとして Slack を使っているので Slack ボット化するためには slack-go を使っています。 ただまだボットの数が少なく主に利用されてるのは Ansible を実行するモノです。開発環境へアプリをデプロイするのに Ansible を使っています。もうすぐ ECS 化するので役割はそろそろ終えるのですが… 利点は開発者だけでなく非エンジニアの方が GitHub のブランチ上のアプリの動作をしたい際に Slack を使って簡単にアプリの動作ができるところです。今後は自動化目的でもっと沢山のボットを開発していきたいです。 EKS/Fargate vs EKS/EC2 EKS の利用を検討する際に Fargate タイプと EC2 タイプがあります。2020年の今年頭に評価した際には ALB Ingress Controller と HPA のための Metrics Server が正常に動作しない状態だったので、まだ EC2 タイプを選択すべきなのかな…と考えたのですが AWS 的にも Fargate を推してる気もするし再度評価実施しました。結果ドキュメントもソフトウェアもだいぶ更新されていて ALB Ingress Controller も Metrics Server もあっけなく動作し、今回のボット環境も EKS/Fargte を選択しました。 ...

こんにちは。@jedipunkz です。 今日は Pulumi (https://www.pulumi.com/) について紹介したいと思います。 最近ではすっかり Terraform がマルチクラウドな IaC ツールとして定着しましたが、巷では AWS CDK を使う現場も増えてきている印象です。AWS CDK は Typescript, Python などのプログラミング言語の中でインフラを定義・操作することができる AWS が提供しているツールです。ただ AWS CDK は名前の通り AWS にのみ対応していて内部的には Cloudformation Template がエキスポートされています。AWS オンリーという点と Cloudformation という点、また 2019 年時点で進化が激しく後方互換性を全く失っているので AWS CDK のアップデートに追従するのに苦労する点、色々ありまだ利用するには早いのかなぁという印象を個人的には持っています。 そこで今回紹介する Pulumi なのですが CDK 同様にプログラミング言語の中でインフラを定義できて尚且つマルチクラウド対応しています。どちらかというと旧来の SDK の分類だと思うのですが、Terraform 同様にマルチクラウドという点で個人的には以前よりウォッチしていました。 今回は公式の Getting Started 的なドキュメントに従って作業を進め Kubernetes の上に Pod を起動、その後コードを修正して再デプロイを実施して理解を深めてみたいと思います。 作業に必要なソフトウェア 下記のソフトウェア・ツールが事前にインストールされていることを前提としたいと思います。また macOS を前提に手順を記します。 Python3, Pip Minikube 参考 https://www.pulumi.com/docs/get-started/kubernetes/ 事前準備 まず macOS を使っている場合 Pulumi は下記の通り brew を使ってインストールできます。 ...

こんにちは。@jedipunkz です。 今回は AWS ECS についてです。直近の仕事で ECS の Terraform コード開発をしていたのですがコードの構造化について考えていました。一枚岩のコードを書いても運用に耐えられるとは考えられません。また ECS を構成するにあたって ECS のネットワークモードとコンテナのロギングについて考えているうちに、どの構成が一番適しているのか？について時間を掛けて考えました。ここではそれらについてまとめたいと思います。 Terraform コードの構造化 運用の精神的な負担を軽減するという観点で Terraform のコード開発をする上で一番重要なのはコードの構造化だと思います。前回のブログ記事に書いたのですがコードの構造化をする上で下記に留意して考えると良いと思います。 影響範囲 ステートレスかステートフルか 安定度 ライフサイクル 結果、具体的に Terraform のコードはどのような構造になるでしょうか。自分は下記のようにコンポーネント化して Terraform の実行単位を別けました。ここは人それぞれだと思いますが、ECS 本体と ECS の周辺 AWS サービスの一般的な物を考慮しつつ、いかにシンプルに構造化するかを考えると自然と下記の区分けになる気がします。 コンポーネント 具体的なリソース ネットワーク vpc, route table, igw, endpoint, subnet ECS 本体 ecs, alb, autoscaling, cloudwatch, iam CI/CD codebuild, codepipeline, ecr, iam パラメータ ssm, kms データストア s3, rds, elasticache … vpc や subnet に関して頻繁に更新を掛ける人は少ないのではないでしょうか。よってネットワークは “影響範囲” を考慮しつつコンポーネントを別けました。また、同じ理由でパラメータ・CI/CD も ECS 本体とは実行単位を別けた方が好ましいと思います。また “ステートフルかステートレスか” という観点でデータベースやストレージは頻繁に更新する ECS 本体とは別けるべきでしょう。 ...

こんにちは。@jedipunkz です。 今回は電子書籍 ‘Pragmatic Terraform on AWS’ を読んでとても内容が素晴らしかったので紹介させて頂きます。書籍の購入は下記の URL から可能です。 https://booth.pm/ja/items/1318735 ブログ記事では書籍の細かい内容については述べません。これから購入される方々が買う意欲を無くすようなブログ記事にしたくないからです。なのでこのブログでは自分が Terraform 運用について感じていた問題点とこの電子書籍がどう解決してくれたのかについて記したいと思います。 自分が Terraform 運用で感じていた問題点 Terraform を使ったインフラコード化と構築は自分の結構経験があるのですが、その構築に使ったコードで構成を運用する難しさはいつも感じていました。Terraform を使った継続的なインフラの運用についてです。具体的には下記のような疑問と言いますか問題点です。 (1) どのような実行単位で .tf コードを書くか (2) 削除系・修正系の操作も Terraform で行うのか (3) ステートフルなインフラとステートレスなインフラの管理方法 (1) は terraform plan/apply を実行するディレクトリの構造についてです。Terraform は同じディレクトリ上にある .tf ファイル全てを読み込んでくれますし一斉にインフラをデプロイすることも可能です。ですが、何かインフラを修正・削除したい場合、削除してはいけないリソースも同ディレクトリ上の .tf ファイルで管理しているわけですから何かしらのミスで大事なインフラに影響を与えてしまう事になります。影響範囲が大きすぎるのです。 (2) は、‘初期の構成のみを Terraform で構築自動化する’ のかどうか、ということになります。構築に使ったコードで継続的に削除系・修正系の操作も行うのか。これも (1) と同様に管理するインフラの規模が大きくなると影響範囲が大きくなり、運用者の精神的負担が増します。 (3) は RDS, S3 等のステートフルなインフラと、それ以外のステートレスなインフラを同じ .tf コードで管理していいのか、という疑問です。修正・削除が多発するインフラは .tf コードで継続的に運用出来たとしても、RDS, S3 の様な状態が重要になるインフラは滅多に削除・修正操作は通常行いません。これら二種類のインフラを同じように管理してしまっていいのか？という疑問です。 これらの疑問や思っていた問題点について、この ‘Pragmatic Terraform on AWS’ は全て解決してくれました。 Pragmatic Terraform on AWS の構成 章ごとの説明は詳細には書きませんが、大体の流れは下記のようになっています。 ...