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

php

久々に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を作った話

Terraform AWS

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

Architecture AWS AWS ELB Terraform

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を作って世代管理するプラグイン書いた

AWS Capistrano

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

続きを読む

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

Architecture AWS

f:id:watass:20141103203916j:plain

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

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

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

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

続きを読む

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

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の構成管理を小さく始めてみようと思います。

続きを読む