DockerでTerraformを利用してみる

しばらく暫定的にWindow直でTerraformを利用していたが、環境を再現しづらく、従って環境の統一もしづらい問題が気になる。ついでに、AWSをMFA付きで利用するにあたっては、いちいち公式で紹介されている手順を使うのも地味に手間がかかるので、こちらで紹介されているスクリプトを導入したいところ。

というわけで試してみることにした。

ちなみにTerraformの公式コンテナのページに曰く、

Running Terraform inside a Docker container requires more configuration than running the Terraform CLI executables directly. Unless you need container isolation, we recommend using the non-containerized Terraform CLI packages.

意訳: コンテナ上でTerraformを使うのは、CLIを直接設置するのに比べて必要な設定が多くなる。コンテナとして隔離しなくていいんだったらCLIをそのまま使ったほうがいいと思うよ。

だそうである。

やってみた感じ、たしかにこれは真実であった。

やること

  1. ベースイメージを決め、Dockerfileを作る
  2. AWS CLIで使うための設定ファイルを用意する
  3. docker-composeでビルドと起動
  4. コンテナに入って起動

コンテナを起動する際にterraformも起動する方式が、たぶんコンテナの精神には沿うのだろうが――たしかワンバイナリっぽく扱うのがカッコいいとされていたはず、公式のTerraformコンテナもそんな作りになっている――、今回の場合、それだとトライ・エラーがやりづらい。というわけで自分が使いやすいようにdocker execを使うことにした。

1. ベースイメージを決め、Dockerfileを作る

Terraformは公式がコンテナを用意してくれているのだが、開発しながら利用するにはAlpineで使いづらい。そのためあえて避け、amazon/aws-cli:latestにTerraformをインストールして使うことにした。もっとプレーンなイメージにAWS CLIとTerraformをインストールして使ってもいいわけだが、aws-cliがプリインストールされているAWSオフィシャルなAmazonLinux2という点が個人的にポイントであった。

Dockerfile

Dockerfileはこれだけ。

FROM amazon/aws-cli:latest

RUN yum update -y
RUN yum install -y unzip jq tar gzip
RUN curl  -OL https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_amd64.zip
RUN unzip terraform_1.3.4_linux_amd64.zip -d /bin

ENTRYPOINT ["/bin/bash"]

tarやgzipリモートデスクトップに必要だった。

2. AWS CLIで使うための設定ファイルを用意する

これはaws configureをホスト(自分の環境ではWindows)側で実行し、docker-compose.ymlでボリュームをマウントすればOK。

    version: "3.9"
    services:
    terraform:
        container_name: terraform
        build: ./containers/terraform1.3
        tty: true
        volumes:
        - ./src:/src
        - ~/.aws:/root/.aws

3. docker-composeでビルドと起動

下記コマンドを打つ。

docker-compose up --build

4. コンテナに入って起動

下記コマンドを打つ。

docker-compose exec terraform /bin/bash

実際に利用してみた結果

結論、これはこれで手間がかかる。というのは、terraform applyをかけた後でキャンセルしただけでもコンテナからログアウトしてしまうため。

MFA認証がいらないならまた話が変わってきそうだが、要MFAだと、環境の統一はWSLで行うほうが良い印象。

究極的には、いっそクラウド版のTerraformやEC2上でTerraformを利用するにしくはないかも。

AWSのVPC作成に"VPC and more"が増えていたので使ってみた

今日別件でVPC画面を触っていたら、VPCに新しい操作画面が追加されていたので早速触ってみた。

なにこれ素敵

なんとVPCと一緒に作るリソース、すなわちSubnet、Route Table、igw、S3 Endpoint、Nat gatewayをセットで作ってくれる。

20221113133410

試してみたところ、これまでVPCを作るにあたって逐一別々に作らないといけなかったのが、実に簡単に作れた。S3 Endpointも採用されているあたりポイント高い。

CoolなScaffold

もちろん誰にとっても銀の弾丸になるというものではなく、Dynamo用のEndpointが欲しいなら自分で作らないといけなさそう。他には細かい点だがS3 Endpointのポリシーが全通しだったり、それぞれの名称(Nameタグ)が冗長気味だったりするのが気になるなら、そちらも自分で変えないといけないだろう。

ただScaffoldとして見れば最高にCoolだ。作ったリソースはちゃんと全部結果画面で表示してくれるから、この手のサービスでよくある"何が作られているのかわからなくて困る"ということもない。

もちろん気になる点がないならそのまま使ってもよさそうだ。

総じて、新規からVPCをマネジメントコンソールから作るなら検討に値するサービスと思える。

読書感想文:稼ぐ力を手にするたったひとつの方法 Kindle版

稼ぐ力を手にするたったひとつの方法 Kindle版を呼んだため、自分の中のまとめがてらにメモ。

相手の立場で物事を考える

というのが"たったひとつ"であるようだ。

大事なことであるのはたしか。そして自分のことばかり考えているとおろそかになりやすいのもたしかで、よく気を付けないといけない。

実力と社内政治

それ以上に、社内の泥臭い人間関係や人間の感情と、実務能力との兼ね合いについての記述のほうが個人的に興味を惹かれた。

自分はエンジニアなのでどちらかというと実務能力のほうを重視するのだが、そちらに偏重すると上手くいくはずのことが上手くいかなかったりして、おかしなことになるのは痛感している。自分自身が痛い目を見たことも一度や二度ではない。

IT業界での開発プロジェクトはそれでなくても困難が多い。本来必要なだけの時間が用意できないことは珍しくなく、初めてみるまで予想だにしなかった落とし穴が後から見つかるなどザラ、やりたいことが途中で変わることも珍しくなく、ひたすら不確定要素と戦い続けねばならないのが開発プロジェクトだ。

そんな難事にチームで当たろうというのに、メンバー同士で嫌がらせをしたり足を引っ張ったりしていたら世話がないのだが、残念ながらいつもいつもチーム一丸となって事にあたれるとは限らない。というより、大なり小なりなにかしらあるもので、スクラムが語るような理想的な姿が最初から最後まで完全に保たれているようなチームは今のところ見たことがない。この本の中で語られている、"上司は利用する相手、メンバーは競争相手"という殺伐とした姿は、残念ながら一面の真理であろう。

理想的なチームを見てみたくもある

しかし理想的なチームがどこにもないと決めつけるのは早計、と考えるのは楽観的すぎるであろうか。必ずしもそうとは言えないとも思う。雑多な人間が大量に集まる大規模なチームだと難しいかもしれない。だが少人数のチームであれば、構築することはできるのではないか。

そういった観点で今後の仕事を考えてみたいところである。

Visual Studio Code Draw.io Integrationを試してみた

Draw.ioをVSCodeから使えるという拡張機能Draw.io Integrationを試してみた。

こんな感じ

20221108163424

素晴らしいことに、編集結果をエクスポート作業なしに普通のsvgファイルとして扱うことができる。

20221108163828

ということは、VSCodeをいれていない人にも作成した図を共有できるはず。クラウド型のツールは権限がない人に共有したいがアカウントがなくてできない、なんてケースがしばしばあるのだが、ただファイルが共有できればいいだけというお手軽な条件を満たすだけで良いのは個人的にかなりポイント高い。

Visual Studio Live Shareと組み合わせれば、会議中に話しながら修正することもできるのではなかろうか。

感想

  • ローカルのVSCodeでDraw.ioを気軽に扱えるのは驚き。
  • 微妙にもっさり感を感じることがあるものの妥協できるレベル。多彩な表現が欲しいなら採用を検討する価値あり。
  • 当たり前だがVSCodeが必要なので、VSCodeを使わない人が手を出すのはちょっと大変かも。

長く使えることを期待したい。

Terraformを使えるならAmplifyを使わずにS3+CloudFrontでよさそう

この比較記事をたまたま見ていたのでメモ。

結論、現段階では、Terraformを使っているならS3+CloudFrontでよいという印象。

Amplifyは、手軽さとのバーターなのである意味当然なのだが、カスタマイズ性が弱い。たとえばDevelop環境のCloudFrontにWAFをセットしてアクセスを固定IPで制限したい、と思っても、現時点(20221108)まだできない。

この例については今後できるようになるかもしれないが、問題はそこではない。柔軟なカスタマイズがしたくても対応できないデメリットがもったいない、ということだ。

Terraformをすでに使っており、かつAWSの学習コストをサンクコスト扱いできるなら(できる人は多いはずだ。むしろ、それができない状況でAWSを使うべきだろうか)、というかなり重い前提がつくのだが、無理にAmplifyを使えるよう頑張るくらいなら、素直にS3+CloudFrontをTerraformで構築するほうが、かえって工数も短縮できるように思う。過去のコードを流用できれば――ちなみに自分のコードはここで公開する予定―――リソースを用意する程度はそう難しくない。

ただ一方で、カスタマイズが必要ない軽い用途で、お手軽にマネジメントコンソールからポチポチやるだけで自動デプロイまで用意できるのは、Amplifyの素晴らしい点である。Terraform他のIaCを使っておらず、かつ要件的にも問題なければ、Amplifyに検討の価値があるのは間違いない。

The API with ID XXXXXXXXXX doesn’t include a resource with path /* having an integration arn:aws:lambda:ap-northeast-1:XXXXXXXXXX:function:product-send-mail on the ANY method.

課題

Lambdaの実行権限をAPI Gatewayに与えると、どういうわけかタイトルのエラーメッセージが、コンソール上で、下記のように赤字で表示された。

20221107225848

解決

表示の問題にすぎないので気にしなくていいらしい。自分の環境ではAPI GatewayからLambdaを実行することができていた。

ちなみに操作によって消せることもあるそうで、呼び出し元のARNの末尾の///*となっている部分を

--source-arn "arn:aws:execute-api:ap-northeast-1:[アカウントID]:[API Gateway ID]/*/*/*"

ちゃんと[Stage]/[Method]/[Resource]と指定すればよいそうである。

--source-arn "arn:aws:execute-api:ap-northeast-1:[アカウントID]:[API Gateway ID
]/v1/POST/send-mail"

試してみたところ、実際綺麗に表示されるようになった。

20221107225844

【日記】個人サイトをリニューアル

ここ数年くらい放置していた個人サイトを、技術検証も兼ねてリニューアルした。

といってもメインコンテンツはブログなので、個人サイトのほうはトップページとお問い合わせフォームくらいしかないのだが、

  • Visual Studio Codeの活用。
  • 同じくWSLとコンテナ(Docker)も利用してのローカル開発環境の整備
  • ヘッドレスかつサーバーレスなfront(Next.js)とback(Python)の分離
  • TerraformによるIaC
  • GitHub Actionsを使ったCI/CD

を行ったかなりの意欲作である。

ほとんど裏側の話のため、利用者にはあまり関係がないのがさみしいところだ。

やってみた感想

Visual Studio Code

Visual Studio Codeがさらにすばらしくなっている。元々Visual Studio大好きだったので使い勝手もよく似ている点も個人的にうれしいところ。

LinterやFormatter等のツールとも連携できるのはもちろん、コンテナ上でのリモート開発までできると来ており、文句なし。

WSLとコンテナ(Docker)も利用してのローカル開発環境の整備

ながらくVagrantを使っていたのだが、Docker desctopを使うために鞍替えした。コンテナを使うと設定や通信がやや複雑化するものの、気軽に立ち上げて気軽に捨てられる他、いつ立ち上げても同じ(おおむねは)環境が用意できるのは安心感がある。一人で開発している場合でも便利だが、チーム開発では威力を発揮してくれるに違いない。

ヘッドレスかつサーバーレス

安い、安い、実際安い。月200円いくかどうかというところじゃなかろうか。

しかも早いし堅牢である。FrontendがCloudFront+S3、BackendがAPI Gateway + Lambdaなので、ちょっとやそっとスパイクしても――してほしいものだが――ダウンどころか遅延さえしないであろう。もっともその場合はコストに反映されるのだが、それでも全てEC2で賄うことを考えれば全然安いほうであろう。

かねてから十全にS3へのオフロードをしたいと思っていて、Hugoを使いつつ頑張っていたのだが、やや使い勝手に欠ける面が無きにしも非ずだった。今回は割と満足いく使い勝手になった気がしている。ある程度の規模があるプロジェクトだと、おそらく素直にコンテナ+Fargateの構成が開発効率がよいと思うが(思いっきりマイクロサービス化するならともかくとして)、小規模なプロジェクトだとAPI Gateway+Lambdaは素晴らしい選択肢になると感じる。

ただ一方で、API GatewayのリソースをTerraformで構築するのは、業務用の本番環境にはお勧めしたくない選択肢という感があった。開発・運用で頻繁に更新をかける類のリソースはTerraformと相性がいまいち良くない。

TerraformによるIaC

コードとして書き上げるまでに本当に本当に本当に手間がかかるのだが、一方で、設定の統一が大変行いやすいというメリットは捨てがたい。雑にTerraform applyを欠けただけでも設定がすっきり統一されるのは爽快である。また、どのようなリソースをどの流れで作ったのか、確実にドキュメント化されているという安心感があるのも管理上見逃せない。コンソール上でポチポチ手作業で作るのは臨時の作業くらいなものであった。むしろこれまでに手作業で作ったリソースもTerraform化を進めたくらいである。

作業効率の不利さもコードの再利用が進めば軽減できるのではないかと期待している。今回、あとで流用できるようにコードはほぼ全部Publicリポジトリで公開するつもり。

GitHub Actionsを使ったCI/CD

CodePipelineも便利なのだが、GitHub Actionsはgitなのにディレクトリ単位でCI/CDの起動を管理できる点が見逃せない。LambdaについてはMonorepo構成を取ったので――さすがに関数ごとにリポジトリを切りたくなかった――これは嬉しい点。

おそらく個人サイトのほうはそこまで頻繁に更新しないのでメリットが目立たないが、頻繁に更新するのなら(すべきなのだが)CI/CDで自動化できているとやはり楽。しかも手作業がないのでオペミスの心配もない。構築するまでが大変だが、いったん構築できてしまえば大変幸せになれる印象。