sometimes I laugh

高専卒WEBエンジニアがいろいろ残しておくブログ

RailsアプリをECSにのせてecs-cliでデプロイとかをする

RailsのECS移行事例なんて既に山ほどあるので、特に書くつもりは無かったのですが、実際にやってみると

  • 時代が進んで、より便利なものが出てきている
  • デプロイどうするのよ、となったときに各自が最強のECSデプロイツールを作っていて、参考にならない

といった体験をしたので、最近やったECS移行の話を書くことにしました。

もちろん、この記事も古くなると何の役にも立たないと思うので、古くなったら、みなさん頑張って調べてください。

続きを読む

PHPをもっと良く書くためのLinterを作った

久々にPHPを書きたいなと思い、まず、頭の中の古い常識をクリアするために一通りphp.netを眺めていました。僕のPHPの知識は5.6辺りで止まっているのですが、ヌル合体演算子とか型宣言とか結構便利な感じになってますね。

ヌル合体演算子というのは、簡単に説明すると

<?php
// hogehoge

$val = isset($array['key']) ? $array['key'] : null;

// fugafuga

みたいなおなじみのコードを

<?php
// hogehoge

$val = $array['key'] ?? null;

// fugafuga

みたいに書けるというやつです。便利。

つまり、PHP5.6とかの常識の上で、このように書かれているコードがあれば、レビューで「ヌル合体演算子使うと楽だよー」などと指摘できるのですが、こーいうのはLinterの仕事じゃない??でもPHPにはRuboCop*1みたいな、こーいう便利なことを教えてくれるLinterが無くない??となったので、夏休みを使って作りました。

*1:RubyのLinter、Style/EachWithObject みたいなのが意外と便利だったので同じものが欲しいなーと思っていた

続きを読む

terraform planで消耗しないためにTFLintを作った話

f:id:watass:20161127204632p:plain

以前から、インフラそのものの構成管理には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

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処理基盤を構築してみようと思います。

続きを読む