構成管理ツールAnsibleの運用構成を考えてみる

ここ数日、既存Ansibleを運用するだけじゃなくてちゃんとベンキョしよ、と思ってもくもく資料読んだり手を動かしたりしてみました。

Ansibleそのもの(特にPlaybookとか)のまとめメモについてはまた別途きちんと書くとして。今日ぼにゃりと考えていたAnsibleの運用構成について書きたいと思います。結果全然たいしたことない構想で、今更何言ってんのレベルではあるんですが、自分の備忘録として残しまする。。。

【前提と環境】

  • 複数のプロジェクトのサーバの管理をしたい
  • そこそこ共通化しているはずだけどwebサーバとかDBサーバとかバッチサーバとかでやっぱりそれなりに違うものもインストールしたい
  • バージョンももしかしたらサーバによって違うものをいれたいかもしれない(Python2.7/3.4とかね)

まぁよくある感じです。「これは基盤だし、揃えておきたいからcommonとして全部セットにしておこ!みんなこれ必ず使ってね!」としたいところですが、この “全部セット” にMySQLとかnginxとかを入れてしまうと微妙に困っちゃったりする。
ので、”common” を作るというその思想は正しそうな気がします(私的には)。ただし、ここでの “common” の定義にミドルウェアをいれてはいけない。

「大抵DBは入ってるだろ〜、うちはPostgreSQLだろ〜」とか思ってうっかり “common” にpostgreSQLのインストーるタスクをいれてしまうと、「このプロジェクトではmroonga使いたいからMySQLで!」とかの事例が出てきたときに困っちゃうから(今はPGroongaとかありますけどね)。。。

“common” はどうやって作ろうか。これはincludeもしくはroleを使うのが妥当かと思います。roleかなぁ・・・roleだろうなぁ・・・

このroleの中のディレクトリは、各機能単位で区切っていくのが使いやすそう。先ほど話に上がっていた”common”も1機能としてディレクトリを切っておきます。

こんなかんじー

$ tree ./
./
├── ansible.cfg *変数設定ファイル
├── hosts
├── ignition *スターターになるplaybook
│   └── vagrant-server.yml
└── roles
├── common *yum vimとかどこにでも入れておくべきツールのみここに配置
│   ├── defaults
│   ├── files
│   ├── meta
│   ├── tasks
│   ├── templates
│   └── vars
├── java
│   ├── defaults
│   ├── files
│   ├── meta
│   ├── tasks
│   ├── templates
│   └── vars * ここでバージョン別読込ファイルを用意
├── mysql
│   ├── defaults
│   ├── files
│   ├── meta
│   ├── tasks
│   ├── templates
│   └── vars
以下続く・・・・

Java7/8 とか Python2.9/3.4 とかサーバによってバージョン異なる系のものについてはバージョンごとにvarsファイルを用意しておいて、playbook呼び出し元(ignition)で読み込みvarsファイルを変更する、とかが良さそうな気がします。そしたらわざわざtasksを2回書いたりしなくていいし・・・共通で使える変数などがあるようだったらvars/main.yml に記載しておけばよいですね。

スターターとなるplaybookを配置するignitionディレクトリも、数が増えるようであればサービスごととかにディレクトリを切っておくのが良さそう。見栄えと検索の問題。

で、一番重要そうだな、と思ったのは、「どうしてこういう構成になっているのか?」というWhyの共有。

もちろんエンジニア同士が見るわけですから、「ディレクトリ構成見ておいて」でなんとなく作業できちゃうのは事実。ただ、なんとなくで作業を続けていくと、実は最初にそのリポジトリを作った人の構成意図まで読みきれないことが(無意識的にせよ、疑問として浮上したにせよ)出てきてしまって、長く使えば使うほど、最初の構成意図から外れたファイルやハチャメチャな配置のファイルが増えてくる。いろいろなプロジェクトでいろいろな人が使っているリポジトリだからこそ、勝手にメンテしていいのかもわからなくなってきて、専属メンテさんがいないと辛い、みたいな状況になりかねない。当然メンテ担当の人がいるに越したことはないんですが、なかなか専任をつけるのは難しい、なんてことはよくあること。であればWhyを伝える何か(wikiでもメモでもreadmeでも)が残っていると、それだけで後からそのリポジトリを運用や機能追加する人たちに優しいのかもしれません。「こっちの方がいいよ!」って案も出しやすいかもですしね。

とはいえ、とにもかくにも”なんとなく”でここまで使ってきてしまった自分におおいに反省しつつ、リポジトリ構成をちゃんと考えて、とりあえずは未来の自分にreadmeを残していきたいなと思いました。
Whyの重要性に改めて気づいたゴールデンウィークでした。おしまい。

広告