自社クラウドサービスをAnsibleで作った話
•Download as PPTX, PDF•
3 likes•2,403 views
Ansible Night in Tokyo 2019.04 登壇資料
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 自社クラウドサービスをAnsibleで作った話
Similar to 自社クラウドサービスをAnsibleで作った話 (20)
Recently uploaded
Recently uploaded (9)
自社クラウドサービスを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 承認ワークフロー
- 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！ ※冪等性の実装は忘れずに！
- 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ができない？
- 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