ALBとTerraformによるBlue-Green Deployment

f:id:watass:20141103203916j:plain

最近、AWSからALBというビックなアップデートが発表されました。
【新発表】AWS アプリケーションロードバランサー | Amazon Web Services ブログ

ALBは従来のELBと比べてコンテントベースルーティング、優先度の設定、HTTP/2、WebSocketの対応など、さまざまな変更点を含みます。従来のELBをClassic Load Balancerと呼んでいることからも、今後はこちらへの移行を推進していくものと思われます。

今回のアップデートはかなり衝撃的で、幅広いユースケースが見込めることから、Terraformも早々に対応しています。

特にNginx的な用途が見込めることから、従来のAWS上におけるBlue-Green Deploymentの改善に繋がるのでは?と考えて、ちょっと試してみました。

続きを読む

Capistranoでデプロイした後にAMIを作って世代管理するプラグイン書いた

タイトルの通り、デプロイ後にAMIを作ってAMIの世代管理もできるCapistrano3向けのプラグインを作りました。
要件としては意外とありそうなのに、(自分で調べた限り)gemがなかったので、作ったという経緯です。AMIを作るだけならば、適当にaws-sdkをrequireしてタスクを一から書いてもよさそうですが、世代管理まで自前で書くのは面倒かと思う(というか自分で書いてみて面倒だった)ので、とりあえずバックアップとしてAMIは定期的に取得したいよねっていうときに使ってもらえるといいんじゃないかと思います。

続きを読む

可用性の高いcron処理の為にJob Observerパターンを使う

f:id:watass:20141103203916j:plain

1日に一度だけ、1時間に一度だけ、あるタイミングで処理を走らせたいというニーズは常に存在します。昔から多くのエンジニアはそういった要望に対して、サーバを用意して、crontabに独自の魔法を書くことで対応していました。

時は現代、インフラといえばAWSGCP、Azure... サーバを使い捨て可能なリソースとして扱えることのメリットに人々は熱狂しました。また、AWSが掲げた思想、"Design for Failure"(障害の為の設計)は多くのエンジニアに受け入れられました。
ここで改めて定刻に処理を行う方法について見てみると、やっぱりインスタンスを立ててcrontabを利用する方法が使われているようです。これは決して可用性の高い実装ではありません。なんとかしなくてはいけません。

以前、同様の問題に対して、DataPipelineを用いたアプローチを検討しましたが、スケジュール処理をDataPipelineに委任しているだけで、可用性が高いとはいまいち言えませんでした。

そこで今回は、CDPでも紹介されている可用性の高いバッチ処理デザインパターン、Job Observerパターンを使って、可用性の高いcron処理基盤を構築してみようと思います。

続きを読む

PackerとTerraformで始めるミニマムなAWS構成管理

f:id:watass:20151227163838p:plain

前回の記事ではDockerとECSを使ったAWS上でのInfrastructure as codeについて言及しましたが、サーバリソースの構成管理についてはAWSのマネージメントコンソールから手動で行わないといけなかったり、コンテナを用いたアプリケーション構成を強制され、従来の単純なインスタンス構成ができないという問題点がありました。前回の記事はこちら。

後者については、今後コンテナを活用したインフラ構成が普通になっていくことで許容されていくかもしれませんが、普通にインスタンスを立ててインフラを構築している方にとってはInfrastructure as codeをやりたいためにコンテナを前提としたサーバ構成に変更しなくてはいけないなんて、正直気が進まないと思います。

そこで本記事では、今インフラ界隈で非常に強い影響力を持っているHashicorpのプロダクト、PackerとTerraformを使って従来通りのインスタンス構成でInfrastructure as codeとAWSの構成管理を小さく始めてみようと思います。

続きを読む

DockerとECSでInfrastructure as codeを体感する

f:id:watass:20151223222329p:plain

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的なものをやってみたいと思います。

続きを読む

FuelPHPのデフォルトバリデーションルールの仕様について調べた話

f:id:watass:20141214211533p:plain

最近仕事でFuelPHPを使う機会を得たのですが、FuelPHPのデフォルトで用意されているバリデーションルールで少しハマった部分があったため、戒めのためにまとめておきます。

意外とググッても情報が出てこない部分があって、公式ドキュメントはそれなりに充実しているものの、細かな仕様までは書かれていません。最終的にはコアのコードを読むのが一番だと気づいてようやくバリデーションルールの仕様がわかってきたのですが、やっぱり困ったらコアのコードを読む気持ちを持とうよという話です。

続きを読む