はてなブックマーク

Aurora Auroraについては以下のように定義する。 メインになるリソースは以下だ。 aws_rds_cluster: Auroraクラスタの定義 aws_rds_cluster_instance：Auroraクラスタ上で起動するDBインスタンスの定義 aws_rds_cluster_parameter_group: クラスタ単位に設定するDBパラメータの定義 aws_db_parameter_group: インスタンス単位に設定するDBパラメータの定義 Auroraクラスタとパラメータ Auroraクラスタのdb_subnet_group_nameについては、↑で作成したDBサブネットグループを設定する。 RDBMSのエンジンは、今回はMySQL5.7互換のAurora2.09.2を使う。 セキュリティグループについては、インバウンドで3306を開けたセキュリティグループを作ってお

はじめに 昨年末にGAされたLambdaのコンテナイメージ機能。 プラットフォームとしてのデプロイ方法が増えて、ますますLambdaの使い勝手が良くなってきている。 今回は、通常のZipによるデプロイではなくて、コンテナイメージでのデプロイをTerraformで自動化してみよう。 前提知識としては以下だ。 TerraformによるLambdaのデプロイ経験がある SAMによるLambdaのデプロイ経験がある(参考記事) Dockerの基本のキは理解している(参考記事) ソースコード 今回は動けば何でもよいので、AWSリソースとも接続しない、テキトーにJSONを返すだけのコードにしよう。 クエリからidを受け取り、それに応じた名前を返すような機能(getemployee)とする。 package main import ( "context" "encoding/json" "log" "g

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに コンテナオーケストレーションツールと言えば、パブリッククラウドのプロバイダが提供するマネージドサービスを除けば Kubernetes がほぼデファクトスタンダードになってきたと言っても過言ではないだろう。 そこで、そろそろ真面目に Kubernetes を勉強しようにも最初の一歩で何をしたら良いか躓いている人も多いと思う。 本記事では、そんな感じで Kubernetes やってみようぜ！な初学者向けに書いてみる。 これでいいのか？という気はするが、Kubernetes のコントロールプレーンのインストール等の手間を省くことを考慮して、EKS を使ってみる。 一方で、コンテナやパブリッククラウドに関しての完全な初学者向けに書くのはなかなか難しいため、以下の知識があることを前提にする。 ECS でのコンテナ管理を少しでもしたことがある Terraform をそこそこ書いたことがある

はじめに Amazon AthenaはS3に入ったログをSQLで抽出したり集計したりできる超便利機能。 でも、Terraformで一発で作ろうとするとちょっとクセがあるので、整理をしてみた。 Amazon Athenaに必要なリソース Amazon Athenaに必要なリソースは以下の5つ。 ワークグループ データベース テーブル データ SQL だ。データベースに登録するデータはS3に格納しておく必要がある。 ワークスペース＋データベースの作成 これはそんなに難しいことはない。Terraformで普通に定義していこう。 ################################################################################ # Athena # ############################################

はじめに API Gateway＋Terraform記事第5弾。 API Gateway に独自ドメイン(カスタムドメイン)設定を実践する。慣れてしまえば難しいことはないけど、最初は戸惑うので整理しよう。 API Gateway の REST API は既に構築できている前提とする。 構築方法については、以下の記事を参考にしていただければ。 【Qiita】TerraformでAmazon API Gatewayを構築する(基本編) 【Qiita】TerraformでAmazon API Gatewayを構築する(ゲートウェイのレスポンス＆ステージ詳細編) AWS なお、今回の記事では、API Gateway はリージョナルなものを使う前提としている。 エッジ最適化の場合は、ACM の証明書をバージニアで作る必要があったりするので注意が必要だ。 全体の流れ カスタムドメインを設定するまでの手

はじめに AWS WAF はフルマネージドで便利なファイアウォールであり、インターネットに面したゲートウェイ機能を有するシステムをお手軽に構築するなら、ほぼ必須で使うことになるサービスだろう(自前で手塩にかけて育てたWAFを持っているのであれば話は別だろうけど)。 ということで、お手軽に使える AWS WAF をお手軽に Terraform で構築しつつ基礎を理解していく。 インテグレーションは API Gateway を使う。 今回作る「IPアドレス制限」だけであれば、API Gateway のリソースポリシーを使った方が手っ取り早い。あくまでも練習のためにやっていると考えていただきたい。 IPアドレス制限する AWS WAF の基本セット 今回の構成では、ブラックリスト形式で実施する。 ルール設定に必要になる Terraform のリソースは以下の2種類。 aws_wafv2_web_

はじめに ECS＋Fargateでサーバレス＆運用省エネにシステムを構築しているのだから、やはりここは負荷量に応じた運用負荷も軽減したい。 TerraformでサクッとAutoScaling設定をしてみよう。 なお、本記事ではキャパシティプロバイダは使用しないケースで対応している。 また、マルチAZ構成を前提としてTerraformを書いている。Fargateの前段に配置するELBは、クロスゾーン負荷分散を有効にしておかないと、AutoScalingで1台増設が走ったときに正しく分散されないので注意(クロスゾーン負荷分散はNLBのみデフォルトでOFF)。 ECS＋FargateのTerraform設定 今回はこの部分は本筋ではないので割愛する。 自分の過去記事では、↓このあたりが参考になると思う。 Terraformの初心者がAmazon EC2に実行環境を作ってECS Fargateなア

はじめに CodePipelineによるCI/CDパイプラインは便利なんだけど、せっかくTerraformやCloudFormationであれこれ変数化して自動化しているにもかかわらず、ECS Fargateにデプロイするための taskdef.json と Appspec.yml で変数化できずにハマるケースがあって困る。今回は、これを解決する手段を考えた。 前提条件 初学者向けのパイプライン作成ハンズオンに出てくるアウトプットをごちゃごちゃいじるので、少なくとも、CodePipelineの基礎は抑えていないと厳しい。過去の記事では以下のあたりを読んでおくと分かりやすくなっているはずだ。 なお、この記事ではIaCはTerraformで書いている。 CloudFormationテンプレートを1からしっかり理解しながらECS on Fargateなアプリを自動構築する(前編) CloudFo

はじめに 前回の続編。 サーバレスの走り切り処理を書いたのだから、今度は常駐処理を書いてみよう。 JavaではWebアプリケーションサーバはSpringがデファクトになりつつあるが、GoのWebアプリケーションフレームワークはGinが良いという話を聞いた。今回は、Ginを試してみつつ、せっかく作ったのだから常駐のサーバレスコンテナで動かしてみよう。 統合開発環境は前回に引き続き、VSCode＋Remote Development Extension Pack＋EC2を使った。 Cloud9でいいじゃんという話もありつつ、ここはもう好みの問題だということで、こっちを使い続けた。 ※Cloud9も使いやすくて好き。 Go言語ランタイムのインストールなんかも、前回の記事を参照。 全体構成 以下のようになる。アプリケーションの仕様は以下の通り。 ※Ginのサンプルプロジェクトを少しだけ改造。 /a

はじめに CI/CDパイプラインは素晴らしい。 AWSのCode兄弟を使ったパイプラインは、機能をAWSに閉じ込めながらなんでもできる万能感を感じる。 しかし、チュートリアルに載っているようなシンプルなパイプラインだけでは、現実にある課題を解決することはできない。 金融サービス向けに理想のCI/CDを追い求めたお話は、そんな現実にある課題もひっくるめてある程度解決してくれるベストプラクティスだと考えている。 が、実際にこれを運用しようとすると、クロスアカウントで色々なことをしなければならず、シンプルなパイプラインと比べると難易度が高くなる。 この記事では、このパイプラインを実現するためのクロスアカウント設定を中心にポイントを整理しながらTerraformで実装してみる。 前提知識として、以下が必要である(この時点でちょっとハードルが高い)。 (実際に試してみるなら)クロスアカウントな環境

はじめに これまで何度かAmazon API Gatewayに関して書いてきたが、直近の記事で、「結局色々な機能を統合したAPI GatewayってSAMに組み込めないし、そうなるとSAMにするメリットってIaCの記述量がちょっと少ないくらいだよね」な結論になったので、そうであれば業界でややデファクト化しているTerraformでも作れた方が良いのだろう、という感じで書いてみた。 前提知識 今回作るTerraformは直近の記事のSAMテンプレートをリファクタしているだけなので、中身については該当記事を読んでもらうことを前提とする。 Terraformについてはある程度書き方を理解していて、自力でリファレンスを見ながら書くことができる程度の知識量を期待する Swagger版で作ってみる 慣れている人にとってはSwaggerの方が簡単な気がする。 あとは、一旦手でポチポチ作ったものをエクスポ

はじめに 2020年6月にGAされたAWS CodeArtifact、大きいプロジェクトなんかで、共通のライブラリを管理するのにローカルリポジトリが欲しいけど、わざわざそのためにEC2立てたりコンテナ立てたりするのはな……と思っている人には大変使い勝手の良さそうなもの。 というわけで、今回は実際にAWS CodeArtifactに触ってJavaのライブラリを管理してみる。 せっかくだから、MavenとGradleで動かしてみるし、CodeArtifactと連携したライブラリのCI/CDまでやってみる。 お供になるのは、いつでも公式のユーザーガイド(なお、この記事を書いている時点ではまだ日本語マニュアルは存在しない) あと、ユーザーガイドに書いてあるように、CLIは最新版にアップデートしないと使えないので注意。 まずはリポジトリを作ってみる サービス選択からCodeArtifactを検索して

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?