本記事は
マイグレーションウィーク
3日目の記事です。
💻🖥
2日目
▶▶ 本記事 ▶▶
4日目
🖥💻
はじめに
こんにちは。入社2年目の牛塚です。部署に配属されてからもうすぐ一年になりますが、さまざまな経験をし多くのことを学ぶことが出来ました。私は普段オンプレサーバーからクラウド環境へ移行する案件を担当しており、その中でAnsibleをはじめて使いました。今回はAnsibleについて簡単な説明と、実際に案件で使ってみて感じたことをまとめてみました。
Ansibleとは
AnsibleとはサーバーをはじめとしたIT機器の構築作業を自動化できるIaCサービスです。サーバーのセットアップをする際には要件に合わせて、ソフトウェアのインストール、サービスの設定・起動、など一連の作業が必要となります。これらの作業をコマンドを入力して手作業で進めると、思わぬミスが起こる可能性があります。
AnsibleはPlayBookと呼ばれるYAML形式のファイルで一連作業をまとめて実施することが出来ます。正確なPlaybookであれば、何度でも同じ作業を行うことが出来ます。
多くのサーバーをセットアップする際には、共通の設定などは同じPlaybookを使用することで手作業で行うよりも設定漏れなどの可能性も低くなり、効率もよくなります。
また、後からPlaybookを見ればどんな設定を導入しているかわかりやすいという利点もあります。
セットアップするサーバーを対象サーバーとします。PlayBookが保存されていて、Ansibleを実行するサーバーをAnsible実行サーバーとします。双方のサーバーはsshなどで接続できることが前提条件となります。
今回はssh接続を想定していますが、ssh以外の接続でのAnsible実行も可能です。詳しくは以下をご覧ください。
インベントリーの構築方法 — Ansible Documentation
インベントリファイルについて
どのサーバーに対してAnsibleを実行するか(対象サーバーの指定)を定義しているのがインベントリファイルです。インベントリファイルの書き方は以下のようになります。
[webservers] foo.example.com bar.example.com または [webservers] 192.168.10.100 192.168.10.101
[]で定義したホストグループの下に実行されるホストやIPアドレスを記載します。一つのホストグループに複数のホストやIPアドレスを記載することが出来るので、一度に複数の対象に対してAnsibleを実行することが出来ます。
Ansible Playbookについて
Ansible Playbookは上から順番に実行されていきます。簡単な例を以下に示します。 Apacheインストール→confファイルの作成→Apacheの起動の三つの処理を行います。
- hosts: webservers become: true tasks: - name: 1.Apacheのインストール ansible.builtin.yum: name: httpd state: latest - name: 2.Configファイルの作成 ansible.builtin.copy: src: /srv/httpd.conf dest: /etc/httpd.conf mode: "0644" - name: 3.Apacheの起動と自動起動の設定オン ansible.builtin.systemd_service: name: httpd.service state: started enabled=yes
1行目:対象のサーバーを指定
今回の例では「webservers」を指定しています。インベントリファイルで定義したホストグループを記載します。ホストグループ含まれる機器すべてに対してAnsibleを実行します。
5行目:Apacheのインストール
state: latestで最新バージョンのApacheをyumでパッケージインストールします。
もし既に最新版がインストールされているならば、この処理はスキップされます。Ansibleはすでに実施済みなどの理由で実施しなくてもよい処理は自動でスキップしてくれます。
9行目: Configファイルの作成
Ansible実行サーバー内に保存しているファイルを対象サーバーへコピーすることも可能です。
14行目:Apacheの起動と自動起動の設定オン
enabled=yesとすることで自動起動をオンにします。
クラウド移行案件でAnsibleを使ってみての感想
最後に私がクラウド移行案件でAnsibleをはじめて使ってみて感じたことをまとめてみます。
効率のよさ
担当した案件では100台近くのサーバーを移行することになったので共通の設定を全サーバーに導入することも多かったのですが、同じOSであれば同じPlayBookを使用してサーバーのセットアップが出来ました。 そのため一度Ansible PlayBookを作成すれば何度でも使用できたり、一度に複数台の作業を行えるので効率的に作業を進められました。
引継ぎのしやすさ
Ansible Playbookを見るとどんな設定がされているかすぐに把握することが出来るので、他の人の仕事を引き継いだ際にもサーバー内の状況を把握しやすかったです。(もちろん設計書も確認することは大事です。)
同じ環境を作成することが簡単
私たちが担当しているクラウド移行案件は開発環境での検証・調査なども必要でした。その際に、Ansibleを使用することで同じ状態のサーバーを簡単に作成できて効率的に作業を進められました。
既存サーバーからの設定を引き継ぎのしやすさ
私が担当している案件では既存サーバーから設定を引き継いで、新サーバーへ導入することが多くありました。 この際に、confファイルを既存サーバーから取り出して、新サーバーへ導入するまでの作業をAnsibleを使用することで作業時間の短縮することが出来ました。
エラーの原因特定までに時間がかかる
Ansible実行画面だけではエラーの原因などを特定することが難しい場合もあり、サービスの設定やスクリプトの動作確認などはAnsibleでは行わずサーバー内でコマンドを入力して進めていました。 サービスの設定やスクリプトの動作確認など済んだうえでAnsibleを実行するのが状況把握もでき効率的に進められる方法だと感じました。
まとめ
今回初めてAnsibleを使用してみてとても効率的に作業を進められるツールだと感じました。特に新しいサーバーを払い出すときはプロキシの設定やDNSの設定など初期セットアップをする時間を短縮できました。 まだまだAnsibleで出来ることは多くあり、これからも勉強していきたいです。