VagrantとAnsibleでPlayground環境を作った

Posted on One min read

tl;dr

下のコマンドを叩けばCentOS7.0のplayground環境を作れる。

1
2
3

$ git clone https://github.com/masu-mi/create-env-playground.git
$ cd create-env-playground
$ vagrant up

CentOSのplayground環境を手で作るの辛かったので Vagrant + VirtualBox + Ansible で作れるようにした。

項目
provider VirtualBox
OS CentOS Linux release 7.1.1503
Network public, private:192.168.33.10

所感

とりあえずPlayground構築が自動化され快適になった。ただ仮想マシン構築とプロビジョニングは時間が掛かるのが不満として残る。 やはり開発環境やPlaygroundもビルド環境・テスト環境みたいにコンテナイメージ利用する方が時間を掛けずに要件を満たせるのでベターな解答だと思う。 ただ業務で触れない(業務だとChef, Fabric が多い)Ansible でrole分けたりtemplate使ったりmeta記述したりと目的を持って触たのは良かった。

Fabricがタスクを単純に記述する方向でプロビジョニングを表現するのと異なり、 AnsibleはChefと同様に宣言的なアプローチを取っている。 特にplaybook・role間の依存関係やモジュール単体の意味は状態記述に対応している。 一方playbookの中身(モジュールの使い方)は作業の記述という感じがあり気楽だった。 状態記述と作業記述の両方を自然に感じる所で採用している印象を受けた。

しかしChefでも感じたが目標となる状態を記述するアプローチで単純にプロビジョニングを捉えると、状態遷移の中間状態を簡単に扱えない様な気がした。 例えば、一時的にVIPから外す・プロセスを停止する・監視を外すなど、状態遷移に伴う一時的な状態とタスクってたくさんある。 選択肢としては、良い表現方法を探す・そもそも中間状態を不要とする様な仕組み(オーケストレーション利用?)を考える・プロビジョニングのベターな捉え方を作り直す、がありそう。 まずはChef,Ansibleで良い表現を探すのが意義があると思った。 今の捉え方の何が問題になっているのかをハッキリ捉えないと良い解答は出なそう。

またclient, soloが自らの状態を変更するChef に対し外部から指示するAnsible は比較的簡単に対象ホスト全体を扱え少し中間状態の管理が楽になると思った。 ただ、やはり冪等性や状態記述という枠組みから足が出ている感じは残る。

ただChefにしろAnsible にしろ状態変更の際の中間状態を定義したりするのが難しいためプロビジョニングって仕事の抽象化について足りない面があるんじゃないかって思った。 あと push-job があるのでChefでタスク実行したり色々と膨らんでるなぁって。

資料

comments powered by Disqus