あらすじ
仕事で Ansible と Docker を使っているうちに、
より良い使い方（コラボ方法）がわかってきた気がする。
独り言 memo。
Ansible だけでも十分管理できそうですが、
よりクリーンな環境、安全なデプロイを実現するには Docker も必要と考えるようになりました。
今までのデプロイの問題点
さて、あなたは新しく現場に配置されました。
保守のため、ローカル環境に本番環境と同様の環境を作らなければなりません。
「サーバには何がインストールされているでしょうか？」
と聞かれたときにすぐにはわからないでしょう。
さらに、
「入っているパッケージのうち使っているものはどれでしょうか？」
と聞かれてもよりわからないでしょう。
特に出入りの多い環境では、先にいた人でもわからないことの方が多いのではないでしょうか。
また、検証環境の A サーバには入っていたのに
本番環境のB サーバにはとあるパッケージが入っていない！なんてことも考えられます。
これでは検証環境で作成したソースコードを展開しても動かなくなってしまい、
最悪本番環境が止まってしまうことも考えられます。
そうです。サーバの中が今までの積み重ねになってしまい、綺麗な状態（最小限で実行できる状態）がわからなくなり、正しいパッケージ管理が不可能になってしまいます。
Ansible
デプロイメントツール
メリット
- サーバにあらかじめソフトを入れておかなくても実行可能（SSH 接続できれば可能）
これがいちばんの強みだと思います。
一台だけ汚れ仕事を担う司令塔を作っておけば後は失敗なく作ることが可能
その司令塔もDocker 内に作ればサーバは汚れない！
- Jinja を用いたテンプレートによって変数を自由に変えられる
開発環境や、本番環境でデプロイの仕方は基本的に変わらないが、
環境変数は異なるのが普通だと思います。
そんな時、各環境の vars.yml を用意しておいて、
実行時に引数に追加するだけで同じコードで別環境のデプロイができる。
これは、本番環境との誤差をなくすためにもなくてはならないものだと考えます。
- 人の代わりにデプロイ
Ansible の実行コードもシェルで固めておけば、人がデプロイに関わらないので
人為的ミスによるリスクが大幅に軽減可能。
Docker
パッケージ管理
メリット
- 最小構成の把握
システムで用いる最小構成を Dockerfile を見るだけで把握することが可能。
もし新たいパッケージが必要となった時は前項の Ansible で
追加していくのではなく Dockerfile に追記し、Image を更新します。
- パッケージが万が一落とせなくなった時にも対応できる
Ansible でパッケージ追加をしていると、何らかのはずみで
install ができなくなってしまった際、そのパッケージを使わない改修が
必要となってしまいます。
ですが、Image として環境を保存しておけば、次 Image を更新するまでは
一時的に今までのパッケージを使うことが可能です。
- デプロイ時の時間短縮
パッケージの容量にもよりますが、大きいものを毎回のデプロイ時に実行するのは
時間の無駄になってしまう。
二つに共通すること ＝ 定義書としての活用
コードと定義書を別々に作るのはとってもめんどくさいことであると感じます。
よく「コードを見てくれればわかる」と言う人がいます。
リバースエンジニアリングはこりごりです。
しかし、Docker と Ansible に関してはその通りだと思います。
Dockerfile にはサーバの環境整備に必要な手順をそのまま埋め込めます。
次の例のように環境にどのようなパッケージを入れたかが一目でわかります。
例）
# 基本的なパッケージのインストール
RUN yum -y install httpd
一方 Ansible では一動作に対し name で何の動作をさせているか
自由記述が可能です。
例）
- name: start httpd
systemd:
name: httpd
state: started
enabled: yes
これら2つを見れば、手動での構築も容易です。
まとめ
- Docker を用いてシステムを運用することで、ホストの環境を汚さない
- 後から見た時にわかりやすい環境構築
- Dockerfile でパッケージ管理
- Ansible で環境整備