Infrastructure as Codeで見えてきたLint Infrastructure

この記事はLint Advent Calendar 2016の6日目の記事です。
本記事では、インフラもLintしませんかという提案と、そのために今作っているツールの紹介をします。

TL;DR

• Infrastructure as Codeによってソフトウェア開発の良いプラクティスが活用できるようになった
• つまり、Lintの知見もインフラに活用できるはず
• 試しにTerraformのテンプレートをLintするTFLintを作りました

Infrastructure as Codeがもたらした恩恵

Infrastructure as Codeは既に広く知られるようになった考え方だと思います。ここまで普及したのは、AWSなどのIaaSの存在ももちろんあったと思いますが、ソフトウェア開発におけるGitによるバージョン管理や、PR駆動開発などの良いプラクティスが広く開発者に受け入れられていたことが背景にあったかなと考えています。
歴史の話や、Infrastructure as Codeの考え方の話は、以前mizzyさんが書かれていたブログ記事がすごくわかりやすいので、そちらを読むと良いです。

ソフトウェア開発現場におけるLintの活用

一方で、ソフトウェア開発の現場ではCIやバージョン管理ほどスタンダードにはなっていませんが、Lintツールが活用されている現場もあります。
例えば、Rubyで言えばRuboCopを使って複数人での開発時に共通のスタイルガイドに従うことを保証したり、Rails Best Practicesを使って、ベストプラクティスに従わないコードを予め検知したり、大まかに言えば、人が確認するまでもない問題や、細かなチェックを自動化するという試みに使われています。

個人的な話をすると、最近、React+Redux+ES2015を使ったフロントエンドの開発を行なう機会があって、社内にあまり知見を持ったエンジニアがいなかったのですが、ESLintを定期的に回しながら開発することで、ある程度バッドプラクティスを回避することができました。

ただ、Lintには大多数（または一部の開発者）が良いと思う思想や哲学を元に指摘するものが多いので、Lintが嫌い、肌に合わないという人も結構いらっしゃいます。この辺はまだまだ解決するべき問題が眠っているかなと思います。

InfrastructureをLintする

前述したように、Infrastructure as Codeはソフトウェア開発のプラクティスをインフラに取り込むものです。つまり、きっとLintも適用できるはずです。インフラの構成や使用方法などのベストプラクティスを集約して、誰でもよりよい構成を作ることができるのでは！？と考えました。

そうして生まれたのがTFLintです。

TFLint

名前の通り、TerraformのテンプレートをLintするものです。テンプレートはHCLという独自言語で書かれているのですが、パーサーが公開されているので、これを使いました。パーサーがGo言語で実装されているので、TFLintもGo言語で書かれています。

使い方はREADMEを読んでいただければなんとなくわかると思うのですが、大雑把に言えば、Terraformを実行するディレクトリ下で実行することで、Terraformが読み込むテンプレートをチェックして、問題があれば指摘を出します。

$ tflint
template.tf
        WARNING:3 "t1.micro" is previous generation instance type.

Result: 1 issues  (0 errors , 1 warnings , 0 notices)

上記の例だと、非推奨になっている旧世代のインスタンスを選択していることが問題として指摘されています。
他にも存在しないインスタンスタイプが選択されていることを検知したり、terraform apply時にエラーになるような問題を弾くための指摘もあるのですが、詳しくはドキュメントを見てもらえればと思います。

生まれた背景

なぜTerraformなのか、というと、実はTerraform独自の事情としてDry-runとして機能するterraform planがあまり厳しくないという背景があります。例えば、AWSで存在しないようなインスタンスタイプを起動しようとしても、terraform planではエラーにならず、terraform apply時に初めてエラーになります。

これが結構辛いなぁと感じていて、本家での解決も難しそうだったので、何か静的解析でチェックするツールを作ろうと思い立ちました。加えて、ベストプラクティスに従わないものも弾けるようになるといいね、という感じで今作っています。

今後

しばらくTerraformのGoogle Groupsとか覗きつつ、良さそうなものを追加していきたいなぁと思っていますが、どのくらい効果的に機能するかは全然わかりません。ソフトウェアと大きく違うのは、ベストプラクティスに従っていないからといって、すぐに直すのが難しいというのがあるかなと思っているので、その辺は微妙かもしれません。しばらくはTerraformでエラーになるような記述をちゃんと検知できるものを目指していけるといいかなぁと思っています。

Terraformに限って言えば、知見がなかなか集まっている場所が無いにも関わらず、みんな一度は何らかのハマった経験があると思うので、そういったものを集約できる何かがあるといいなーと漠然と思っています。