Posts

こんにちは。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 の構成 章ごとの説明は詳細には書きませんが、大体の流れは下記のようになっています。 ...

こんにちは。@jedipunkz です。 少し前の話なのですが Google Cloud Platform が Terraformer というツールを出しました。正確には数年前に Google が買収した Waze というサービスのエンジニア達が開発したようです。このツールは GCP, AWS, OpenStack, Kubernetes 等、各クラウド・プラットフォームに対応したリバース Terraform と言えるツールになっていて、構築されたクラウド上の状態を元に terraform の .tf コードと .tfstate ファイルをインポートしてくれます。terraform import は tfstate のインポートのみに対応してたのでこれは夢のツールじゃないか！ということで当初期待して使い始めたのですが、使ってみる中で幾つかの問題点も見えてきました。今回はその気になった問題点を中心に Terraformer の基本的な動作を説明していきたいと思います。 公式サイト 下記の Github アカウントで公開されています。 https://github.com/GoogleCloudPlatform/terraformer Requrements Terraformer を動作させるには下記のソフトウェアが必要です。今回は macos を想定して情報を記していますが Linux でも動作します。適宜読み替えてください。インストール方法と設定方法はここでは割愛させて頂きます。 macos homebrew terraform awscli 今回の前提のクラウドプラットフォーム 自分がいつも使っているプラットフォームということで今回は aws を前提に記事を書いていきます。ここが結構肝心なところで、Google Cloud Platform が開発したこともあり GCP 向けの機能が一番 Feature されているように読み取れます。つまり aws を対象とした Terraformer の機能が一部追いついていない点も後に述べたいと思います。 動作させるまでの準備 Terraform と同様に Terraformer でも動作せせるディレクトリが必要になります。 mkdir working_dir cd working_dir Terraformer を動作させるために Terraform の plugin が必要です。先に述べたようにここでは ‘aws’ Plugin をダウンロードします。そのために init.tf を下記の通り作成します。 ...

こんにちは。@jedipunkz です。 今回は Hashicorp の Consul クラスタを Kubernetes 上で稼働させる方法について調べてみました。 Hashicorp Consul はサービスディスカバリが行えるソフトウェアで、私も以前居た職場で利用していました。アプリケーション間で互いに接続先を確認し合う事が出来ます。以前構築した Consul クラスタはインスタンス上に直に起動していたのですが最近だとどうやってデプロイするのか興味を持ち Kubernetes 上にデプロイする方法を調べた所 Helm を使って簡単にデプロイ出来る事が分かりました。 また今回は minikube を使って複数のレプリカを起動するようにしていますが、Helm Chart を用いると Kubernetes のノード毎に Consul Pod が1つずつ起動するようになっていて、ノードの障害を考慮した可用性という点でも優れているなぁと感じました。また Kubernetes の Pod ですのでプロセスが落ちた際に即座に再起動が行われるという点でも優れています。勿論 Consul クラスタの Leader が落ちた場合には Leader Election (リーダ昇格のための選挙) が行われ、直ちに隣接した Kubernetes ノード上の Consul Pod がリーダーに昇格します。といった意味でも Kubernetes 上に Consul をデプロイするという考えは優れているのではないでしょうか。 Requirements 下記のソフトウェアが事前に必要です。この手順では予めこれらがインストールされていることとして記していきます。 minikube kubectl helm Consul クラスタ起動までの手順 早速ですが手順を記していきます。 Hashicorp の Github にて Consul の Helm Chart が公開されています。helm search しても出てきますが、今回は Github のものを用いました。 ...