はじめに

最近仕事でcapistranoを使っています。

take-she12.hatenablog.com

これ、インフラに対するパッチ適用時の、保守手順の自動化なんです。安全にサーバを止めるために大変長い手順の実施が必要で、運用チームが大変だからなんとかしてくれ、というのが発端。

つまり手順の自動化はその一部で、最終的にはインフラの更新をどう自動化するか、というところになる。

現状

変更するファイルを用意して、その適用手順書を出して、保守手順でサーバを安全に停止したのち、適用手順書で変更ファイルを置き換える。やってられないですよね。

理想

元々のベースイメージがあり、（OS）全ての変更をpuppetやchefのレシピで管理する。このレシピをgithubで管理し、パッチのバージョンがそのままレシピのバージョンとなる。適用の度にVMを新規で構築し、デプロイする。素晴らしい世界。

で見事これを最後まで面倒見ることになりそうなので周辺ツールをググって分かる程度に見てみます。

構成管理ツール

Puppet

エージェントあり。Ruby製。冪等性あり。レシピはRubyベースのDSL。

Chef

エージェントあり。Ruby製。冪等性あり。レシピはRubyベースのDSL。Puppetと似てるな。

Ansible

エージェントレス。Python製。冪等性あり。レシピはyaml。

itamae

エージェントレス。Ruby製。冪等性あり。レシピはRubyベースのDSL。

社内で実績あるのはPuppetなので、Puppetになりそうな予感です。

インフラテストツール

ServerSpec

もうこれ一択かなと思ってます。基本的に今回の構想はImmutable Infrustructureの考えなので、冪等性すらもいらないし、インフラのテストをする必要もないかと思えますが、それでも今のインフラの健康状態をいち早くチェックできるということは、トラブルにすぐに対応するためにも重要です。これは早く導入したいですね。

リモートコマンドツール

capistrano

本当はコードをデプロイするのですが、リモートへコマンドを実行するツールとして使っています。構成管理ツールとしても使うことはできるのですが、サービスを止めるとか、ログに何の文字が出てればOKとか、そういう複雑な条件をRubyで扱えるので、いいあんばいのツールです。今回は稼動状態から保守状態へ移行するときにこれを使っています。