terraform planで消耗しないためにTFLintを作った話
以前から、インフラそのものの構成管理にはTerraformを利用しています。主にAWSのリソース管理に使っていて、Terraform自体はaws-sdkのラッパーみたいな感じなのですが、宣言的に構築できるので、複製が容易であったり、変更に必要な操作（modify系のAPI実行）を意識せずに、こうなってほしい、を記述することで、現状から必要な操作を計算してAPIを叩いてくれたりというメリットがあります。
で、実際に変更したい状態にするために、Terraformが何を行なうか、については「terraform plan」というコマンドで確認できるようになっています。まぁdry-runみたいなものなのですが、あくまでもTerraformの実行計画上のdry-runであって、aws-sdkのdry-runではないというのが結構困りポイントです。
具体的には、Terraform上で別のリソースの値を参照する場合とかに、存在しないリソースとか指定すると、当然エラーになるのですが、例えば、AWSで利用できないようなインスタンスタイプとかを指定していても、terraform planでは教えてくれないわけです。これが原因でplanしてエラーじゃなかったからapplyしたら、すごいくだらないエラーで実行に失敗した、みたいなことになると結構辛い気持ちになります。そのため、terraform planしてから各値をよーく確かめて...みたいなことをしていました。
さすがにこれはどうなのよと思ったのと、最近仕事柄、Lintツールと戯れることが多かったので、これこそLintで解決するべき問題なのではと思いたち、TerraformのLinterとしてTFLintというツールを作りました。
続きを読むALBとTerraformによるBlue-Green Deployment
最近、AWSからALBというビックなアップデートが発表されました。
【新発表】AWS アプリケーションロードバランサー | Amazon Web Services ブログ
ALBは従来のELBと比べてコンテントベースルーティング、優先度の設定、HTTP/2、WebSocketの対応など、さまざまな変更点を含みます。従来のELBをClassic Load Balancerと呼んでいることからも、今後はこちらへの移行を推進していくものと思われます。
今回のアップデートはかなり衝撃的で、幅広いユースケースが見込めることから、Terraformも早々に対応しています。
Terraform 0.7.1 released! https://t.co/ZenWICp9w9 AWS ALB support along with dozens of other improvements and bug fixes.
— Mitchell Hashimoto (@mitchellh) 2016年8月19日
特にNginx的な用途が見込めることから、従来のAWS上におけるBlue-Green Deploymentの改善に繋がるのでは？と考えて、ちょっと試してみました。
続きを読む株式会社アクトキャットに入社しました
入社エントリです。正直ちょっと書くのに憧れてました。
標題の通り、株式会社アクトキャットに入社しました。
可用性の高いcron処理の為にJob Observerパターンを使う
1日に一度だけ、1時間に一度だけ、あるタイミングで処理を走らせたいというニーズは常に存在します。昔から多くのエンジニアはそういった要望に対して、サーバを用意して、crontabに独自の魔法を書くことで対応していました。
時は現代、インフラといえばAWS、GCP、Azure... サーバを使い捨て可能なリソースとして扱えることのメリットに人々は熱狂しました。また、AWSが掲げた思想、"Design for Failure"（障害の為の設計）は多くのエンジニアに受け入れられました。
ここで改めて定刻に処理を行う方法について見てみると、やっぱりインスタンスを立ててcrontabを利用する方法が使われているようです。これは決して可用性の高い実装ではありません。なんとかしなくてはいけません。
以前、同様の問題に対して、DataPipelineを用いたアプローチを検討しましたが、スケジュール処理をDataPipelineに委任しているだけで、可用性が高いとはいまいち言えませんでした。
そこで今回は、CDPでも紹介されている可用性の高いバッチ処理のデザインパターン、Job Observerパターンを使って、可用性の高いcron処理基盤を構築してみようと思います。
続きを読むPackerとTerraformで始めるミニマムなAWS構成管理
前回の記事ではDockerとECSを使ったAWS上でのInfrastructure as codeについて言及しましたが、サーバリソースの構成管理についてはAWSのマネージメントコンソールから手動で行わないといけなかったり、コンテナを用いたアプリケーション構成を強制され、従来の単純なインスタンス構成ができないという問題点がありました。前回の記事はこちら。
後者については、今後コンテナを活用したインフラ構成が普通になっていくことで許容されていくかもしれませんが、普通にインスタンスを立ててインフラを構築している方にとってはInfrastructure as codeをやりたいためにコンテナを前提としたサーバ構成に変更しなくてはいけないなんて、正直気が進まないと思います。
そこで本記事では、今インフラ界隈で非常に強い影響力を持っているHashicorpのプロダクト、PackerとTerraformを使って従来通りのインスタンス構成でInfrastructure as codeとAWSの構成管理を小さく始めてみようと思います。
続きを読むDockerとECSでInfrastructure as codeを体感する
Infrastructure as codeの思想に感動し、AWSを使い始めて早1年になりますが、なんだかんだで最近はコードを書いてばかりでAWSを触っていませんでした。貴重な無料期間も終了し、非常にもったいないことをしたなと反省中です。
さて気を取り直して、ついに先日 EC2 Container Registry (ECR)がアナウンスされましたね！
まだUSリージョンのみの公開で、相変わらず東京リージョンはもう少しかかりそうですが、これでDockerイメージの管理までAWS上で行えるようになるわけです。
ところで、インフラ構築の自動化といえば、Elastic BeanstalkやOpsWorks、CloudFormationなどなどAWS上でもサービスが乱立しており、少し外に目を向ければ、Chef、Puppet、Ansible、Terraformなどなど、もう困っちゃうぐらい選択肢にあふれている昨今です。
ただ、どうにもこれらの選択肢はアプリケーションのデプロイに難があったり、やたらと複雑だったりでイマイチピンと来ない部分があって、インフラのコード化という視点から見るとDockerが一番しっくり来る感じでしたので、今回はECRの東京リージョン公開を期待しつつ、ECSでInfrastructure as code的なものをやってみたいと思います。
