ECS の構成と Terraform コード化する際の構造化について

こんにちは。@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 本体とは別けるべきでしょう。 ...

Pragmatic Terraform on AWS の内容が素晴らしかったので感想を述べる

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

期待のツール Terrafomer の基本動作方法と問題点

こんにちは。@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 を下記の通り作成します。 ...

Consul Helm Chart で Kubernetes 上に Consul をデプロイ

こんにちは。@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 のものを用いました。 ...

Istio Sidecar Injection を理解する

こんにちは。@jedipunkz です。 前回の記事 「Istio, Helm を使って Getting Started 的なアプリをデプロイ」で kubernetes 上で istio をインストールし sidecar injection を有効化しサンプルアプリケーションを起動しました。その結果、sidecar 的に envoy コンテナが起動するところまで確認しました。今回はもう少し単純な pod を用いて ‘sidecar injection’ の中身をもう少しだけ深掘りして見ていきたいと思います。 Rquirements 記事と同等の動きを確認するために下記のソフトウェアが必要になります。 それぞれのソフトウェアは事前にインストールされた前提で記事を記していきます。 macos or linux os kubectl istioctl minikube 参考 URL 下記の istio 公式ドキュメントを参考に動作確認しました。 https://istio.io/docs/setup/kubernetes/additional-setup/sidecar-injection/ https://istio.io/docs/setup/kubernetes/additional-setup/sidecar-injection/ minikube で kubenetes をデプロイ 前回同様に minikube 上で動作を確認していきます。パラメータは適宜、自分の環境に読み替えてください。 minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \ --extra-config=controller-manager.cluster-signing-cert-file="/var/lib/minikube/certs/ca.crt" \ --extra-config=controller-manager.cluster-signing-key-file="/var/lib/minikube/certs/ca.key" \ --vm-driver=virtualbox istio を稼働させる 下記のコマンドを用いてカレントディレクトリに istio のサンプル yaml が入ったフォルダを展開します。 curl -L https://git.io/getLatestIstio | sh - 次に下記のコマンドで kubernetes 上に istio をインストールします。 istio コンテナ間の通信をプレインテキスト or TLS で行うよう istio-demo.yml を apply しています。 ...

Istio, Helm を使って Getting Started 的なアプリをデプロイ

こんにちは。@jedipunkz です。 最近は kubernetes を触ってなかったのですが Istio や Envoy 等 CNCF 関連のソフトウェアの記事をよく見かけるようになって、少し理解しておいたほうがいいかなと思い Istio と Minikube を使って Getting Started 的な事をやってみました。Istio をダウンロードすると中にサンプルアプリケーションが入っているのでそれを利用してアプリのデプロイまでを行ってみます。 Istio をダウンロードするとお手軽に Istio 環境を作るための yaml ファイルがあり、それを kubectl apply することで Istio 環境を整えられるのですが、ドキュメントにプロダクション環境を想定した場合は Helm Template を用いた方がいいだろう、と記載あったので今回は Helm Template を用いて Istio 環境を作ります。 前提の環境 下記の環境でテストを行いました。 macos Mojave minikube v0.32.0 kubectl v1.10.3 helm v2.12.1 virtualbox 準備 kubectl と helm のインストール kubctl と helm をインストールします。両者共に homebrew でインストールします。 brew install kubernetes-cli brew install kubernetes-helm minikube のインストールと起動 minikube をインストールして起動します。 ...

Docker,Test-Kitchen,Ansible でクラスタを構成する

こんにちは。@jedipunkz です。 以前、“Test-Kitchen, Docker で Ansible Role 開発サイクル高速化!” ってタイトルで Ansible Role の開発を test-kitchen を使って行う方法について記事にしたのですが、やっぱりローカルで Docker コンテナ立ち上げてデプロしてテストして.. ってすごく楽というか速くて今の現場でも便利につかっています。前の記事の URL は下記です。 https://jedipunkz.github.io/blog/2016/07/14/test-kitchen-with-ansible/ 最近?は ansible container って技術もあるけど、僕らが Docker 使う目的はコンテナでデプロイするのではなくて単に Ansible を実行するローカル環境が欲しいってこととか、Serverspec をローカル・実機に実行する環境が欲しいってことなので、今でも test-kitchen 使っています。 で、最近になって複数ノードの構成の Ansible Role を test-kitchen, Docker を使って開発できることに気がついたので記事にしようと思います。これができるとローカルで Redis Master + Redis Slave(s) + Sentinel って環境も容易にできると思います。 使うソフトウェア 前提は macOS ですが Linux マシンでも問題なく動作するはずです。 ほぼ前回と同じです。 Ansible Docker test-kitchen kitchen-docker (test-kitchen ドライバ) kitchen-ansible (test-kitchen ドライバ) Serverspec インストール ソフトウェアののインストール方法については前回の記事を見てもらうこととして割愛します。 test-kitchen の環境を作る test-kitchen の環境を作ります。‘kitchen init’ を実行して基本的には生成された .kitchen.yml を弄るんじゃなくて .kitchen.local.yml を修正していきます。こちらの記述が必ず上書きされて優先されます。 ...

GCP ロードバランサと GKE クラスタを Terraform を使って構築する

こんにちは。@jedipunkz です。 少し前まで Google Cloud Platform (GCP) を使っていたのですが、今回はその時に得たノウハウを記事にしようと思います。 Google Container Engine (GKE) とロードバランサを組み合わせてサービスを立ち上げていました。手動でブラウザ上からポチポチして構築すると人的ミスや情報共有という観点でマズイと思ったので Terraform を使って GCP の各リソースを構築するよう仕掛けたのですが、まだまだ Terraform を使って GCP インフラを構築されている方が少ないため情報が無く情報収集や検証に時間が掛かりました。よって今回はまだネット上に情報が少ない GKE とロードバランサの構築を Terraform を使って行う方法を共有します。 構築のシナリオ 構築するにあたって2パターンの構築の流れがあると思います。 GKE クラスタとロードバランサを同時に構築する GKE クラスタを予め構築しそのクラスタ向けにロードバランサを構築する 両方の方法を記していきます。 GKE クラスタとロードバランサを同時に構築する GKE クラスタとロードバランサを同時に作る方法です。 早速ですが下記に terraform ファイルを記しました。それぞれのシンタックスの意味については Terraform の公式ドキュメントをご覧になってください。 公式ドキュメント : https://www.terraform.io/docs/providers/google/ ここで特筆すべき点としては下記が挙げられます。 ロードバランサに紐付けるバックエンドの ID 取得のため “${replace(element…” 的なことをしている ロードバランサのバックエンドサービスに対して GKE クラスタを作成した際に自動で作成されるインスタンスグループの URI を紐付ける必要があります。ユーザとしては URI ではなく “インスタンスグループ名” であると扱いやすいのですが、URI が必要になります。この情報は下記のサイトを参考にさせていただきました。 参考サイト : GKEでkubernetesのnodesをロードバランサーのバックエンドとして使いたいとき with terraform URL : http://qiita.com/techeten/items/b2ec5f11f4a70dd21d70 ロードバランサ一つ作るために 6 個ものインフラリソースを作っている 一つのロードバランサを作るために6つのインフラリソースが必要になるというのも驚きですが公式ドキュメントを読むとなかなかその感覚がつかめませんでした。それぞれの簡単な意味を下記に記しておきます。 ...