一般的にシステム基盤構築の自動化では、これまで手順書を見ながら人手で実施していた作業を、ドメイン特化言語（DSL）^参考2を使って"プログラミング"します。しかしドメイン特化言語と言ってもプログラミング言語である以上、ある程度のプログラミング経験がないとコーディングするのは難しいのが実情です。そのため業務アプリケーション開発チームとシステム基盤開発チーム（以下「基盤チーム」）とで分業体制を取っており、プログラミング経験のあるメンバーが基盤チームに居ないと言ったケースも多い大規模プロジェクトでは特に大きな課題となります。

代表的なシステム基盤構築の自動化ツールのひとつである「Puppet」^参考3は、代表的なOSSの監視ツールのひとつである「Nagios」^参考4の設定ファイルフォーマットから大きな影響を受けた「Puppet言語」を用いて"プログラミング"します。そのため一般的なUNIX/Linuxの知識がある方なら、汎用プログラミング言語を使う他の自動化ツールと比較して、プログラミング経験がなくても習得しやすいのが特徴です。

ただし設定ファイル感覚で記述できるPuppet言語であっても、各々が好き勝手な作り方をしてしまうとトラブルが頻発したり、保守メンテナンスで困難を極めたりして、自動化の恩恵を受けられない結果になりかねません。そんな事にならないために、コードを書くチーム内でコーディングルールを決めてから開発を始めることが重要です。ルールを策定する上で心がけるべき「三か条」を以下に挙げます。

構築時に使う設定パラメーターなどのデータをコード中に直接記述することは避けるべきです。プログラミングスキルがある方にとっては単なる変数定義でも、コードが読めない方にとっては暗号文のようなものであると認識しましょう。プログラミングできるメンバーが居るうちは良いですが、例えば運用フェーズに入ってプログラミングできるメンバーが居なくなったら、パラメーター変更すらできなくなってしまうのでは困ってしまいます。

PuppetではHiera^参考5という機構によりパラメーターを外部のYAMLフォーマットのテキストファイルに集約する事で、データとプログラムを分離することができます。この機構によりパラメーターの変更でコードを変更する必要がなくなり、プログラミングスキルがないメンバーでも容易に修正できます。

プログラミングスキルがあると使いたくなるのが、ループ構造や条件分岐などのロジック構造でしょう。しかしシステム基盤構築自動化においては最小限の使用に留めるべきです。理由として実行結果が一目でわかりにくくなる事が挙げられます。これはプログラミングスキルがある方だと逆の事を言っているように聞こえるかも知れませんが、最終的な設定内容が"一目で"判別しにくくなるため、記述ミスに気付きにくくなったり、保守性の低下につながったりするためです。

プログラミングスキルのないメンバーがコードを保守する場合を考慮しなければならないため、より高いレベルでの可読性が求められます。

Puppet言語ではシステム基盤構築のためのさまざまな機能を"リソース"という概念で表しており、一般的な機能については標準リソースとして提供されています。ユーザーがリソース定義する事もできますが、できる限り標準リソースだけで記述する努力をするべきです。もしユーザー定義のリソースを使わざるを得ない場合は、チームでリソース定義ルールを定めて、誰でも勝手にリソース定義してしまわないようにしましょう。

また、オブジェクト指向の汎用プログラム言語で一般的に使われる"継承"もPuppet言語で使えますが、一目で理解しにくくなりますし、何よりオブジェクト指向開発の経験がないメンバーには理解困難な記述のため、使用を避けるべきです。

エンタープライズ向けシステムにおいては"Infrastructure as Code"とは言え、現状ではプログラミングスキルがないメンバーでも対応しやすくする工夫が必要です。ただ、今後"Infrastructure as Code"がより浸透していけば状況が変わってくるかも知れません。