どうも、Kohei(@koheinishino_)です。
今回はAnsibleの使い方と注意点について解説します。
Ansible(アンシブル)とは、オープンソースの構成管理ツールのことです。
例えば、Ruby on Railsの実行環境を作成する場合は、まずRubyやnginx、MySQLなどの必要なソフトウェアの情報を設定ファイルに記述します。
その後、Ansibleから対象のサーバーへの接続を確立し、設定ファイルを読み込ませることでソフトウェアのインストールや設定を自動的に実行することができます。
Ansibleは他の構成管理ツールと比較して下記の特徴があります。
- エージェントレスのため、対象のサーバーにAnsibleを使用するための設定はいらない。
- 独自の言語ではなくYAML形式で設定ファイルを作成できるため、学習コストが低い。
- あらかじめ提供されているモジュールによって、設定ファイルを容易に作成できる。
- ツール側で「何度実行されても同じ状態に収束する」ことが保証されており、冪等性（べきとうせい）が担保されている。
この記事を読むことでAnsibleの使い方や躓きやすいポイントについて理解して、環境構築を自動化に挑戦できるようになります。
初めてAnsibleを導入することになったけど使い方がよくわからない…。
Ansibleの使い方や注意点を知りたい！
と悩まれている方は是非最後までお読みください！
今回の記事作成にあたり、下記のサイトを参考にさせていただきました。
Ansibleの使い方
まずはAnsibleの大まかな利用の流れについて確認し、次にメインとなる設定ファイルの内容について説明します。
そして最後に私が実際に作成したRailsアプリケーションの環境構築を自動実行する設定を例に、設定ファイルの具体的な書き方について解説します。
利用の流れ
基本的なAnsibleの利用の流れは下記となります。
- Inventryを作成する
- Playbookを作成する
- コマンドを実行する
たったこれだけですw
しかし、上記の説明だけでは
Inventry？Playbook？って何？
まず読み方よくわからんぞ…。
と思われた方もいらっしゃると思うので、しっかり解説していきますw
用語の解説
まずはAnsibleを扱う上で頻出の用語を覚えておきましょう。
とりあえず最低限の構成を実現するためには下記の2つのファイルが必要となります。
Inventry（インベントリ）
対象サーバーの情報を記述するためのファイルになります。拡張子なしのhostsやinventryというファイル名で作成することが一般的です。
サーバーのIPアドレスをベタ書きしても問題ないです。今後環境ごとに実行ファイルを分けたい場合は、下記のようにproductionやdevelopmentで区切ることも可能です。
[production]
(事前に用意した対象サーバーのIPアドレス or ホスト名)
ここで注意なのですが、AWSのEC2インスタンスにAnsibleをSSH接続させる場合はansible.cfgファイルを同階層に作成しておきましょう。鍵（pemファイル）とユーザーがわからないためエラーになります。
ansible.cfgは下記のように設定すればOKです。
[defaults]
remote_user: ec2-user
private_key_file: ~/.ssh/ansible-practice.pem
個人的にEC2インスタンス上に構築する場合は、あらかじめ~/.ssh/configにホストの設定をしておき、Inventryには接続名のみ記載する方がオススメです。ansible.cfgを作成する必要がなくなります。
Playbook（プレイブック）
構成を記述するメインの設定ファイルになります。YAMLファイルで作成するので、インデントやスペースに注意しましょう。コチラもファイル名に指定はありませんが、playbook.ymlや環境ごとにproduction.ymlやstaging.ymlとするのが一般的です。
下記はGitのみをインストールする際のPlaybookになります。
---
- name: Playbook for Production.
hosts: production
become: yes
tasks:
- name: Install Git
yum:
name: git
state: present
Keyはそれぞれ下記のような意味を持ちます。
- name：Playbookの説明を記載。
- hosts：hostsファイルに定義したサーバーの中から実際に接続する環境名を記載。
- become：yesとするとsudo実行となる。
- tasks：インストールするパッケージを記載。
実行コマンド
hostsファイルとplaybook.ymlを作成できたら同じディレクトリ内に配置しましょう。ターミナルでそのディレクトリに移動して、下記のコマンドを叩くとAnsibleが実行されます。
-iオプションの後ろに使用するInventryを指定し、その後ろに使用するPlaybookを指定するだけでOKです。
これで対象サーバーにGitをインストールすることが出来ると思います！
$ ansible-playbook -i hosts playbook.yml
Ansibleのディレクトリ構成
ここまでAnsibleでは最低限必要なファイルとして、InventryとPlaybookがあるという説明をしてきました。
基本的にはそれらのファイルを同階層に配置して実行すればOKです。しかし、下記の点から実際の環境構築では2ファイルのみで管理するのは無理があると言えます。
- 必要なパッケージが複数必要な場合が多く、Playbookの行数が多くなってしまう。
- 開発、ステージング、本番など環境ごとにファイルを分ける必要が出てくる場合もある。
②については個人利用であれば気にする必要はないですが、①については個人利用であっても気にする必要が出てくると思います。
ここからは具体的にRuby on Railsの環境構築を例に私なりのディレクトリ構成を解説していきます。
Railsアプリケーションの環境構築を自動実行する設定を解説
まず、私が事前に作成したAnsibleのディレクトリがコチラとなりますので、別途参照しながら以降の説明を見ていただければと思います。
作成するにあたり、下記のAnsible公式のベストプラクティスを参考にしました。
すべて詳細に説明していくとかなり長くなってしまうため、要所要所のみ解説していきますね。まずは今まで出てこなかった2つのディレクトリのファイルについて説明します。
group_vars/all.yml
こちらは共通で使用する変数をまとめているファイルです。
グループ単位でファイルを分けることも可能ですが、今回は1つのファイルにまとめてしまいました。
URL等の長い文字列や、バージョン等の将来的に変更する可能性のあるものをここに記載しています。
roles/xxx/tasks/main.yml
こちらはインストールや構築を行うパッケージやミドルウェアごとに分割したPlaybookのようなものです。
最上位のディレクトリにあるPlaybookからこれらのYAMLファイルを参照してAnsibleが実行されるようなイメージです。
Playbookが長くなりすぎないようにする対策は、これらのファイルが肝になります。例えばRubyのインストールと一口に言っても
- rbenvのインストール
- ruby-buildのインストール
- bashの設定
- Rubyのインストール
- 使用するRubyのバージョンを指定
などなど色々やることがあるので、他の人が見たときに理解しやすくするために分割する必要があります。
Ansibleの注意点
ここまではAnsibleの基本的な使い方について解説してきました。ここからは私が初めてAnsibleを使う方に伝えたい注意点を説明していきます。
まずは最小構成で動作確認をする
まずは何かパッケージを1つ選択し、Ansibleを使って練習用のサーバーにインストールしてみるところから始めるのがオススメです。
具体的には上述したようにGitのみインストールしてみるとかですね。1つに絞ることで下記のメリットがあります。
- エラーの箇所が特定しやすい。
- 設定ファイルの構成などの理解に注力できる。
何をインストールするかというよりは、Ansibleがどのように動作しているのかを確認するのが重要です。そうすることで、インストールするパッケージの量が増えた場合も対処しやすくなります。
ここの設定をイジればこんな風に出力結果が変わるってことね！
というような感じで、全体の理解から進めていきましょう。
今はAWSのEC2で気軽に練習用のサーバーを立てられるので、とにかく実践あるのみです！
dry-runを活用する
dry-runとは、Playbookの内容を空実行するためのオプションです。
dry-runでは実際に対象のサーバーに接続して構築が実行されているように見えますが、あくまでPlaybookの動作確認のみで構築はしません。
具体的には下記のように「–check」というオプションを付けて実行します。
$ ansible-playbook -i hosts playbook.yml –check
dry-runを活用しないとコマンドを実行するたびに対象のサーバーにパッケージがインストールされてしまうため、動作確認の際に非常に手間です。
dry-runを活用することでパッケージをインストールすることなく動作確認を行えるため、効率的にAnsibleの学習を進めることが出来ます！
個人利用の場合はディレクトリ構成にこだわらなくてもOK
例えばRailsの環境構築のために必要なリソースをAnsibleで設定しようと思うと、必要なパッケージが多いのでどうしても記述量が増えてしまいます。
Ansibleには記述量やディレクトリ構成をわかりやすくするための工夫ポイントがいくつかあるのですが、それらは後回しでも全く問題ないです。
Jenkins等も同じでこのへんは職人芸になってくるところもあるので、
このへん冗長だから書き直すか…。いや、このディレクトリの分け方がスッキリして見やすいのでは…？んー待てよ…。（無限ループ）
みたいな感じで沼にハマって数時間経過していたみたいなことが起こります…w
まずは構築したい環境を冗長でもいいので作成できるようになることを優先すべきですね！
まとめ：Ansibleで環境構築の自動化にチャレンジ
Ansibleの使い方と注意点について解説しました。
私が思うAnsible最大のメリットは、同じ環境を異なるサーバーでも再現できることです。これは自身の失敗経験からそう感じるようになりました。
私自身、Ansibleを導入する前は手動でコマンドを打ってAWSのEC2上にRails環境を構築していました。しかし、とあるタイミングで誤ってインスタンスを削除してしまい、またコマンドを打つ羽目になってしまった経験があります…(泣)
Ansibleで環境構築していれば、すぐに同じ環境を構築できました。この経験からインフラのコード化の重要性を身に染みて感じましたね…。
正直はじめはAnsibleのメリットがあまり理解できないかもしれません。なぜなら手動でコマンドを打っても同じことができてしまいますし、インフラ専門の方でなければ環境構築の機会ってほぼないです。
なので優先度は高くする必要はないですが、エンジニアであれば学んでおいて損はない技術です。特にAWSとAnsibleの相性はかなり良いと思うので、手動での環境構築に慣れてきた方はAnsibleへチャレンジしてみるのがオススメです！
