Ansible Night in Tokyo 2019.04 登壇資料

1. 自社クラウドサービス
をAnsibleで作った話
8割がAnsibleでできています

2. 自己紹介
- name: 自己紹介
selfintroduction:
name: 渡部俊治
belong: インフォテック株式会社
role: 自社クラウドサービスの開発、運用
sns:
- { name: https://qiita.com/comefigo }
favorite_module:
- “include_tasks”
other:
- { name: “好きなゲーム”, value: “Call of Duty、Witcher” }
- { name: “Ansible歴”, value: “1年半”}

3. レジュメ
• 自社クラウドサービスの説明
• システム構成
• デモ
• Ansibleを選んだ理由
• よかった点
• 苦労した点
• 工夫している点
• 今後のはなし

4. 会社概要
• インフォテック株式会社
• 独立系SIer
• パッケージソフト
• Create! Form 帳票作成ツール
• Create! Webflow 承認ワークフロー

7. 自社クラウドサービス
承認ワークフローシステム「Create!Webフロー」をクラウドサービス化した
「Create!WebフローCloud」

8. システム構成
AWX
APPインスタンス
Amazon
Route 53
Amazon ECR
AMI
Zabbix Server
DBインスタンス
Amazon
S3
Trend Micro Deep Security
as a Service
ALB

9. 適用範囲
• AMI作成
• ECR登録
• ELBにターゲットの登録
• Route53にドメイン登録
• OS初期設定（ユーザ作成、アップデート、ミドルのインスコ）
• アプリケーション起動
• Dockerの起動、停止、破棄
• Zabbixに登録、削除
• AWX、Zabbixサーバの作成
• バックアップ、アプリケーションの更新 などなど

10. デモ

11. Ansibleを選んだ理由

12. Ansibleを選んだ理由
• 業務とシームレスに連携
• 人件費が一番高い
• オペミス防止
• Infrastructure as a Code
• エージェントレス
• 学習コストが低い
• 可用性が高い

13. よかったこと

14. よかった点
• エージェントレス
• 学習コストが低い
• 開発が活発
• ベンダーやコミュニティのサポートが熱い
• 適用範囲（Windows、Linux、NW機器など）が広い

15. プラグイン開発が容易
• モジュールにないものは自前でプラグインとして実装できる
標準出力に決められたメッセージ（{ “changed”: true }）が出力できればOK！
なので、どの言語（Python、Ruby、Javascript、Shell）でもOK！
※冪等性の実装は忘れずに！

16. Vaultによる暗号化
• 各種認証鍵の取り扱いは悩みの種だったが、暗号化したことで安心してコミット
できるようになった
https://docs.ansible.com/ansible/latest/user_guide/vault.html

17. AWX
• REST APIでシステム連携が容易になった
• 認証鍵の暗号化
• 実行結果の保持
• 実行権限の管理
• GUI

18. 苦労したこと

19. 変数
• 思うように変数が作れない
[{“name”: “hogehoge”}, {“name”: “fugafuga”}]
どうやってつくるの？
→ json_query
→ これだけ覚えとけばもう怖くないAnsibleの（動的）変数

20. 変数
• 異なるホスト間で変数を共有する
→ localhostに変数を読み込んで、各ホストで hostvars.localhost.hoge で取得
• 異なるホストで処理中に生成した変数をホスト間で共有する
→ varsファイルを生成して、各ホストで読み込む
※異なるホストのhostvarsの書き込みはできない

21. エラーハンドリング
• try catchのようにエラーハンドリング
→ block / rescue でまとまったタスクのtry catchが可能
ただし、複数のimport_playbookで構成されたplaybookでは
全体を包括したtry catchができない？

22. リソースが煩雑になってきた
• 時間が経つのにつれ、playbook、rolesなどが煩雑になってきた
→命名規則やルールを設け、一定の基準で整理しないといけない

23. 社内政治
一切なし！

24. 工夫している点

25. DockerイメージビルドはDocker in Docker
Windows環境のため、AnsibleはDockerコンテナから実行している
コンテナイメージをビルドするためのDockerfileがJinjaテンプレート化されている
ため、Ansibleコンテナ内でDockerfileを展開してイメージビルドしている
version: "3.7"
services:
ansible:
build:
context: ./
dockerfile: Dockerfile
image: ansible
container_name: ansible
volumes:
- /var/run/docker.sock:/var/run/docker.sock

26. ステージング環境に応じて変数群を切り替えている
本番、ステージング、開発の3環境で運用しているため、それぞれ異なる変数を使用し
てる
今後↓にしていきたい
https://qiita.com/kotarella1110/items/79af4485bd7985935d6b
hoge_playbook.yml
vars_files:
- "../vars/env/all_{{ env_all.stage }}.yml"
- "../vars/env/auths_{{ env_all.stage }}.yml"
group_vars/all.yml
env_all:
stage: "dev"

27. 命名規則
• set_factで生成している変数名は _xxx (アンダーバー開始の変数名)
動的に生成した変数であることがすぐにわかる
• playbook、role、taskのファイル名は種別で命名（可読性が向上）
例）ec2_instance_create.yml、ec2_instance_delete.yml
• group_vars変数はxx_allで開始
group_varsと一目でわかる

28. ドライバ変数
• 本番はREST API経由で変数が渡されるが、ローカルで開発する際はドライバ変数
を用いてパラメータの引き渡しを行っている
- include_vars:
file: ../vars/extra/var.yml
when: hostvars[inventory_hostname]['awx_job_template_name'] is not defined
※hostvars[inventory_hostname][‘awx_job_template_name‘]でAWXかどうかを判定している

29. 関数っぽい使い方
• 関数のように引数によって振る舞いを変える
hoge_playbook.yml
tasks:
- set_fact:
_hoge_state: present ← 変数名にロール名、タスク名などを付与して、被りを防ぐ
- include_role:
name: ../roles/hoge
roles/hoge/tasks/main.yml
- my_module:
state: “{{ _hoge_state }}”

30. include_tasks
• 意味を持ったまとまったタスクをtaskとして外だしすることで、role内のタスク
も再利用性が高くなり、可読性も高まる
また、条件分岐するようなタスクも外だしすると良い

31. # EBSボリューム情報の取得
- name: Describe volume info
local_action:
module: ec2_vol_facts
# ボリュームの作成/アタッチ
- name: Attach volume to instance
local_action:
module: ec2_vol
# ファイルシステムを作成
- name: Create file system
filesystem:
fstype: "xfs“
# ディクトリの作成
- name: Create data dir
file:
state: directory
# ボリュームをマウント
- name: Mount filesystem to data directory
mount:
path: “hoge"
- include_tasks: ../tasks/aws_ebs_attache.yml
- include_tasks: ../tasks/ebs_mount_app.yml

32. 開発用上書き変数
• 複数人で開発していると個人環境によってパラメータ（認証情報とか）が異なる
ため、開発環境のみで変数の上書きができるような仕組みを導入
vars_import.yml
set_fact:
_var_file: "../vars/dev/my_vars.yml"
- name: Check variable file is exist
stat:
path: "{{ _var_file }}"
register: _var_exist
- name: Import variable file
include_vars:
file: "{{ _var_file }}"
when:
- _var_exist.stat is defined
- _var_exist.stat.exists
使う時
- include_tasks: ../tasks/vars_import.yml
when: stage == “dev”
- my_module:
name: “{{ hoge }}”
my_vars.yml
hoge: dev

33. これから始める方へ
※画像は翔泳社より
• Ansible徹底入門
• 実践！Ansibleベストプラクティス（前編、後編）
• Ansibleのモジュール開発
• Ansible応用編：より実践的なPlaybookを作り上げる
• Ansible Galaxy
• Ansible Best Practices
• Ansible オレオレベストプラクティス
• Docker内でAnsibleの勉強をしよう
• Ansible勉強＆実践結果（随時更新）

34. 今後のはなし
• リソースの整理
• 処理の効率化
• AWXのバージョンアップ
• AWXを使いこなす
• 社内布教

35. END