ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

自動化推進への取り組み: Ansibleコード規約編

ライター:猪子 亮
2019年ネットワンシステムズに新卒入社。

社内/外 向けサービス開発に従事。
主にWeb アプリケーションのフロントエンド、バックエンド開発。

他には社内の自動化推進、業務改善活動、開発エンジニア育成などに取り組んでいる。

目次

はじめに

本記事では、弊社における自動化推進の取り組みの一例として、Ansibleコード規約について簡単に説明いたします。

本稿で説明するコード規約は公式のものではなく、[1] Ansible Best Practices を基に社内向けにアレンジしたものです。

IaCとAnsible

IaC(Infrastructure as Code)は、ソフトウェア開発のベストプラクティスをインフラのオートメーションに活かすアプローチのことです。

日々刻々と変化するビジネス、IT戦略の対応が必要なのは、アプリケーションだけでなくインフラも同様です。

仮想化やクラウドによって簡素化されたインフラに対し、コードで定義された構成を自動的にテスト、適応させ、アジリティの高いインフラを目指します。

これを実現させるために、インフラをコードで定義可能にするツールの1つがAnsibleです。

画像クリックすると大きな画像が表示されます

図1 IaCのメカニズム

Ansibleを使う理由

Ansibleには以下の3つのコンセプトがあります。

Simple
読み書きし易い定義ファイル(YAML)を使用

Powerful
マルチベンダにモジュールが用意されているため、あらゆる環境に利用可能

Agentless
対象にエージェントインストールなどの特別な準備は必要なく、ネットワークが繋がっていれば実行可能

詳細な説明は省略しますが、これらの点から弊社において、自動化の標準言語(※1)としてAnsibleが採用されています。

(※1)状況によってツールの使い分けはあるが、サイロ化された自動化(各々のスクリプト)を防ぐ意味合い。

サイロ化された自動化の改善方法はこちら

コード規約の必要性

Ansibleで用いられているYAMLは、同じ意味のコードを異なる記述方法で定義できます。

例えば、以下の2つのコードは同じ内容の配列を定義しているコードです。

図2 リスト表記のスタイル


処理するコンピュータ目線では、どのような書き方であっても文法が正しければ同一のものと解釈されます。

一方でコードを保守する人間目線では、記述方法が統一されていないコードは扱いにくく、変更時のバグの温床となりかねません。

特に本番環境で使われているコードであれば、その品質管理は重要です。

人によりコードの書き方がバラバラにならないよう、決まり事をまとめたものがコード規約です。

図3 社内で公開されているAnsibleコード規約の例

コード規約の課題

例えば、コード規約がWordファイルで書かれていたとします。

あなたはエディタでコードを開発しており、記述方法に迷いがありました。

その時、わざわざファイルエクスプローラーでWordファイルを探し出し、ほんの少しの起動時間を待ちながらコード規約を読むでしょうか?

コード規約は存在するものの、展開初期の頃にしか読まれず、形骸化されがちです。

また、Wordなどで記述してしまうとバージョン管理に手間がかかり、アップデートの障壁となります。

コード規約は作って終わりではなく、適宜アップデートされ、開発者とって従いやすい状態を保つことが理想です。

コード規約の開発と提供方法

IaCの考え方同様、コード規約という文書自体もコードで定義し、ウェブブラウザで閲覧可能な状態にあれば、上記課題を解決することができます。

弊社では、コード規約を以下のような形態で開発、提供しています。

  • Ansible同様にYAMLで記述
  • GitLabでプロジェクト、バージョン管理
  • GitLab PagesでHTML形式を公開

これにより、規約の管理と閲覧が容易になり、提供者、開発者双方でメリットが得られます。

また、追加や改善などのアップデート事項はissueで管理しています。
ほかにもmasterに変更がコミットされるとコード規約を公開しているPagesがアップデートされるようにCI/CDパイプラインを構築しています。

図4 GitLabにおけるCI/CDパイプラインの例

GitLabCIとの連携

見やすい形でコード規約が提供されていたとしても、最終的に確認をするのは人間です。

コードが数十行であれば、目視でも確認可能ですが、コード量が増えてくるとそうも言ってられません。

Linterを使うと、そのコードが規約に則っているかを機械的に確認できます。
(Ansibleのコード開発であれば、ansible-lintyamllint が便利です。)

デフォルトルールで対応していない規約に関しては、追加のカスタムリントの開発が必要です。

CIの中でリントチェックを行うようにパイプラインを組めば、push時に自動的にコード規約に準拠しているかを確認できます。

まとめ

本稿ではIaCに用いられるAnsibleのコード規約について、弊社の例を基に解説しました。

  • コードの品質を担保するために、コード規約の策定が重要である
  • コード規約自体もコード化して、GitLabでプロジェクト管理
  • 規約のコード化により、HTML形式での提供が可能
  • CIパイプライン上でリントチェックを行い、自動的に規約のチェックを行える

図5 コード規約のトップページ

参考文献

[1] https://docs.ansible.com/ansible/2.9_ja/user_guide/playbooks_best_practices.html

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND