Contents
Ansible TowerとGitLabを入れてどういう運用を実現したかったかを簡単な例と一緒にまとめてみようと思います。（自分への備忘録含め）
ここに書くこと
ここでは Ansible Night in Tokyo 2019.04 で話をした中のLinuxサーバ運用編ついてもう少し詳細に書いてみようと思います。
ここで言う運用のイメージは 定常運用 です。
Excel運用課題の振り返り
- ファイルの管理が「yyyymmdd」などファイルの末尾で管理されていたりしてどれが最新か分かりにくい
- 手順書の変更履歴が表で管理されていて文字しか書いていなくて
beforeafterが分かりにくい - レビューシートが手順書ごとに出来ていく、これも日付管理されたり文字で書いてあるだけなので実際にどう修正したのかが残らない
- 手順書フォーマットは統一されているが、人によって手順の内容がバラバラ
- 「このファイルに
xx設定を追加する」ような書き方されていて、人によっては最終行に追加する人もいれば行の途中に追加する人もいる - 設定ファイルの変更管理はされない
- 手順実行時に発生したエラーとかは人によって「その人が必要だと思う部分のみ」とか「全部取ったと思ったけど実は一部だった」とかバラバラ
- 「あの時に実行した手順ってどこだっけ？」「このエラー前にも見たよね？何の手順だっけ？」という風になった時に大量にあるExcelファイルからの振り返りがしずらい
- 切り戻しも結果は同じだが、やり方が人によって違う
- 検証(試験)も結果だけ書いてあるけど、具体的にどうやったかまで書いていない
- 構成管理？何それ？おいしいの？
- 結果よければ全て良し的な考え
などなど。
Excel自体は別に悪いツールじゃないのですが、やっぱりこういう使い方だと課題が結構出てくるし、やり方を変えれば上記のような課題を解決できるかもしれまんせが効率化に繋がるかは疑問だったりします。
運用がどう変わったか
運用フロー
before
今までは以下のようなフローイメージでした。
after
GitLabを使ってやる時はこんなフローになりました。
これをしてよかったことは以下の点です。
誰がいつどのファイルをどこをどういった理由で追加・削除・変更したか？や差分が自動でシステム側に残るようになった誰がレビューしてどういった理由で承認したのかが自動でシステム側に残るようになった- レビュー者のコメントがマージリクエストに残るので後から見直せる
- レビューしたコメントがオープン中なのかクローズしてるのか管理できる
- レビューなどのコメントがコードの行に埋め込めて分かりやすい
- レビュー結果や差分が検索できるようになって振り返りしやすい
- 最新版は必ずベースリポジトリになった
- 切り戻しもリビジョンで管理できるようになった
構成管理について
before
Excelでシステムの変更作業をする時は日付と作業タイトルが入ったディレクトリ内に 変更計画書 と 作業手順書 と対象サーバのパラメーターExcelが保存されているフォルダのショートカットなどが保存されていました。
|
1 2 3 4 5 |
20190519_xxxxxxの作業/ ├── パラメーターシート-ショートカット ├── 作業手順書.xlsx ← 作業手順が書いてある └── 変更計画書.xlsx ← 作業概要とか目的とか対象とか書いてある |
パラメーターExcelが保存されているフォルダ内には各サーバのパラメーターがまとめて保存されています。
古いのや新しいのが混在している時もあります。
|
1 2 3 4 5 |
. ├── web_server_a_パラメーターシート.xlsx ├── web_server_b_パラメーターシート.xlsx └── web_server_c_パラメーターシート.xlsx |
after
以下は例ですが、このようなディレクトリイメージでGitLabで管理しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
. ├── host_vars │ ├── web_server_a.yml │ ├── web_server_b.yml │ └── web_server_c.yml ├── roles │ ├── common │ │ ├── os-setup │ │ │ ├── files │ │ │ │ └── command.sh │ │ │ ├── tasks │ │ │ │ └── main.yml │ │ │ └── templates │ │ │ └── chrony.conf │ │ └── zabbix │ │ ├── tasks │ │ │ └── main.yml │ │ └── templates │ │ └── zabbix_agentd.conf │ └── web_servers │ ├── apache │ │ ├── files │ │ │ └── httpd.conf │ │ └── tasks │ │ └── main.yml │ └── iptables │ ├── files │ │ ├── web_server_a.yml │ │ ├── web_server_b.yml │ │ └── web_server_c.yml │ └── tasks │ └── main.yml └── web_servers.yml |
host_varsには、各サーバのOSやNWなどのパラメーターを管理していますrolesにはそれぞれのサーバで共通する処理をまとめています- 例えば
commonには全サーバで標準になる設定をまとめています templatesは環境によって動的に生成する設定ファイルがまとめられています- 他は各サーバの共通処理や設定をまとめています
- 例えば
Ansibleのベストプラクティスは以下のドキュメントに書かれています。
手順書について
before
Excel手順書は以下のようなイメージで作っていました。
切り戻しもその逆をするイメージです。
これをダブルチェックでコピペしていく感じです。
after
Excel手順をPlaybookにするとこんなイメージです。
以下はWebサーバに対して処理を実行するメインの web_servers.yml です。
tagを使って実行するロールを制御しています。
(例なので色々端折って書いてますがご了承の程を…)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
--- - name: web servers playbook hosts: all gather_facts: no roles: - role: common/os-setup tags: os-setup - role: web_servers/iptables tags: iptables - role: web_servers/apache tags: apache |
上の手順書はapacheの作業なので apache/tasks/main.yml の中身はこんな感じです。
|
1 2 3 4 5 6 7 8 9 10 11 |
--- - name: copy httpd config. copy: src: "{{ role_path }}/files/httpd.conf" dest: /etc/httpd/conf/httpd.conf register: result - name: apache graceful. command: apachectl graceful changed_when: result.changed == True |
既に修正済み(レビュー、テスト済み)の設定ファイルをコピーして設定を反映しているだけのものになっています。
テストについて
before
その時その時に検証環境にVMを作って検証していたので手間暇がかかっていました。
after
GitLab CIでコンテナを使った試験に変更しました。
この事により、試験環境は自動で生成されて結果も自動で残るようになり効率が上がりました。
以下はgitlab-ciの例です。
以下のCIではcentos7のイメージを使って3つのステージ(PlaybookとApache設定ファイルの構文チェック、Apacheの起動確認)を実行します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
--- image: centos:centos7 stages: - check_playbook_syntax - check_apache_syntax - check_start_apache before_script: - yum -y install epel-release - yum -y install httpd ansible ansible-lint check_playbook_syntax: stage: check_playbook_syntax script: - ansible-lint web_servers.yml only: - devel check_apache_syntax: stage: check_apache_syntax script: - cp roles/web_servers/apache/files/httpd.conf /etc/httpd/conf/httpd.conf - apachectl configtest only: - devel check_start_apache: stage: check_start_apache script: - cp roles/web_servers/apache/files/httpd.conf /etc/httpd/conf/httpd.conf - /usr/sbin/httpd -DFOREGROUND & only: - devel |
実行すると結果が以下のように記録されます。
もし、失敗していたら結果を確認して修正して再度CIを走らせてます。
ここでは、コンテナで設定などを確認しているだけですが、適応後に本当に動いているのか？人間の目でコンテンツを確認する必要があるテストなどは別の話になります。
例えば、前者であればServerspecなど使って設定適応後にテストしたり、監視装置からアラートが出ていない？などを確認する必要があると思います。
レビューについて
before
以下のようなレビューシートを書く感じでした。
結果しか書いてないことの方が多いので修正前と後のdiffを取りたくても目diffをやるしかなかったです。
レビューシートも増えるし修正したExcelが日付入りでどんどん増えていきます。。。
after
GitLabでのレビュー例です。
以下のようなマージリクエストが来たとします。
差分を確認すると依頼内容と違う設定がされているので、以下のように間違っている部分に直接コメントをして残すことができます。
コメントをすると Discussion でオープンになるのでマージリクエストで発生した課題など管理することができます。
指摘部分がわかりやすくコメントできたり、課題のオープン・クローズが管理できたり、差分が綺麗に見やすかったり、記録が自動で残るので便利です。
ちなみにマージリクエストのテンプレートはこんなイメージで作っています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#### 背景 <!-- 背景を具体的に書く--> <!-- 誰・どこからの依頼なのか、依頼内容、いつまでにする必要があるのか、どういった理由で何を変更するのかなど --> #### 目的 <!-- 変更する目的を書く --> #### 作業日時・対象 <!-- 実施予定日と対象を書く --> #### 対象 <!-- 対象機器を書く --> #### エビデンス <!-- エビデンスの保存先があったら書く --> #### 切り戻しリビジョン <!-- 切り戻しのリビジョンURLを書く --> |
実行について
before
Excel手順書を元にダブルチェックで「ヨシ！」と言いながらコマンドを叩いていました。
after
実行はAnsible Towerから実施することにしました。
ここでは、以下のようなテンプレートを作ってみます。
ジョブタグ と 制限 の 起動プロンプト にチェックが入っています。
これは、テンプレートを実行する時に どのホスト に対して 何のロール を実行するか？を指定するためです。
テンプレートを実行してみます。
制限 と ジョブタグ を入力して実行します。
以下のようにテンプレートが実行され結果が記録されます。
Ansible Towerで発生したログをElasticsearchなどに取り込んで可視化したり検索できる仕組みを作れば、自動化品質の可視化および実行記録の検索や振り返りがやりやすくなります。
Ansible Towerを入れてよかったことは以下の点です。
誰がいつどのホストに対して何を実行して結果どうなったかが自動でシステム側に残るようになった- WebUIがあるのでオペレーターでもとっつきやすい
- ロール制御ができるので必要な操作のみ実行させる制御ができる
- 切り戻しもワークフローなどと組み合わせれば自動でできる
- 小さいボタンを作ってワークフローで組み合わせるような「自動化2.0」に向かえるようになった
- 人間の曖昧さがなくなった(コピペミスなどのオペミスとか作業ログが自動で残ったりなど)
最後に
これをやることで「品質の向上」や「ツールの標準化」や「効率化」や「提供スピードのアップ」や「記録の自動化(レビュー、差分、作業ログなど)」が出来るようになって便利になりました。
結構雑に書いてしまったのですが何か参考になれば幸いです。
今後、Ansibleを使った自動化がもっと流行るといいですね。
みんなで Happy Automation！！
