Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ansibleで始めるインフラ構築自動化

37,599 views

Published on

https://d-cube.connpass.com/

Published in: Technology
  • Visit this site: tinyurl.com/sexinarea and find sex in your area for one night)) You can find me on this site too)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area for one night is there tinyurl.com/hotsexinarea Copy and paste link in your browser to visit a site)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Girls for sex are waiting for you https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Meetings for sex in your area are there: https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Ansibleで始めるインフラ構築自動化

  1. 1. Ansibleで始める      インフラ構築自動化 2017/02/06 D-Cube 株式会社ビズリーチ 長原 佑紀
  2. 2. Profile - 名前: 長原 佑紀 (Yuuki Nagahara) - 所属: 株式会社ビズリーチ - 部署: ビズリーチ事業 インフラ - 経歴: - 2007- SIer - 2015- ビズリーチ - 好き: - AWS - Android
  3. 3. 1. Infrastructure as Code 2. Ansible (概要) 3. Ansible (基礎編) 4. Ansibleデモ 5. Ansible (実践編) Agenda
  4. 4. Ansibleを使われたことがある方は? 1. 使ったことない。これから学ぶ。 2. 多少触ったことがある。 3. 業務でがっつり利用している。 Question 回答 1. 5割 2. 3割 3. 2割
  5. 5. 1. Infrastructure as Code
  6. 6. manual Operator Infrastructure as Code とは Infrastructure
  7. 7. constraction manual Operator Infrastructure as Code とは source code Infrastructure
  8. 8. Infrastructure as Code とは ?
  9. 9. Infrastructure as Code とは インフラの構成管理を 宣言的なコードで記述し、 ソフトウェア開発の プラクティスを適用すること
  10. 10. Infrastructure as Codeのプラクティス ソフトウェア開発と同様にソースコードをGit管理
  11. 11. - バージョン管理(Git) - Pull Request(レビュー) - TDI(TDD)(テスト駆動インフラストラクチャ) - CI(継続的インテグレーション) - CD(継続的デプロイ) Infrastructure as Codeのプラクティス
  12. 12. Infrastructure as Codeの領域 システムコンフィグレーション デプロイ、サーバ間連携 クラウド、VM、コンテナ、 OSインストール オーケストレーション (Orchestration) コンフィグレーション (Configuration) ブートストラッピング (Bootstrapping) Fabric, Capistrano, Serf, Consol Puppet, Chef, Ansible, Itamae AWS, OpenStack, Docker, KickStart, Cobbler, Terraform
  13. 13. Infrastructure as Codeの領域 OS / ミドルウェア設 定 デプロイ、サーバ間連携 仮想 マシン 作成 オーケストレーション コンフィグレーション ブートストラッピング OS インス トール Server#1 Server#2 Server#3
  14. 14. ▷ ブートストラッピング ○ プラットフォームそのもの。または、サーバとしてOSが利用可能な状態 を作るツール。 ○ 仮想マシンやコンテナ、クラウドにおいてAPIを利用してリソースの定 義を行う。 ▷ コンフィグレーション ○ サーバへミドルウェアのインストールや各種設定を行うツール。 ○ サーバ構成管理の自動化に当たる部分を担う領域。 ▷ オーケストレーション ○ リソースの集合体に連携したサービスを提供するツール。 ○ 構築済みの環境に対して振る舞いを行う。 Infrastructure as Codeの領域
  15. 15. ▷ ブートストラッピング ○ AWSのAPIを利用したEC2インスタンス管理 ○ Dockerを利用したコンテナ管理 ○ Vagrantでの仮想マシン立ち上げ ▷ コンフィグレーション ○ 各種ミドルウェアでのサーバの構築 ○ パッチ適用 ▷ オーケストレーション ○ アプリケーションの分散デプロイ(ローリングアップデート) ○ Hadoopクラスタの構築 ○ メトリクス/監視ツールへのノード追加 ユースケース
  16. 16. ▷ オペレーション品質の向上    人的ミス発生確率低減、再現性の向上 ▷ システム運用の標準化    変更履歴で属人化の防止 ▷ 再利用性の向上    部品化により再利用が容易 ▷ 作業工数削減    手動オペレーションのタイムロス削減 ▷ セキュリティの向上    直接多数のサーバを操作する機会を最小化 コード化によるメリット
  17. 17. 2. Ansible 概要
  18. 18. Python製の構成管理ツール。 2015年にRed Hat社が買収。 クラウド操作やデプロイ等も 利用可能で、ブートストラッピング やオーケストレーションのレイヤ の機能も一部提供する。 『Infrastructure as Code』を 実現するためのフレームワーク Ansible 概要 Configration Orchstration Bootstrapping “Ansible is Simple IT Automation.” ※名前の由来は、SF小説に登場する”超光速通信技術”
  19. 19. ▷ Simple - Yaml形式の設定ファイル - 可読性高、コーディング不要 - 低い学習コスト ▷ Powerful - "Batteries Included" (電池同梱) - パッケージ1つで導入可能 ▷ Agentless - 構築対象にエージェントは不要 - sshが接続可能であれば良い Ansibleの特徴
  20. 20. サーバの状態を一定に保つための特性  対象リソースに対して「何を実行するのか」ではなく、  「どういう状態があるべき姿なのか」を定義する。  ある操作を1回行っても複数回行っても結果が同じとなる性質。 冪等性(べきとうせい) ➔ × 冪等性がない ➔ ◯ 冪等性がある $ echo “parameter=1” >> /etc/configfile Ansibleで記述したコードは基本的に冪等性を担保する仕組み $ echo “parameter=1” >> /opt/app/config $ sudo yum install -y nginx-1.10.2 Package nginx-1.10.2-1.el6.x86_64 already installed and latest version Nothing to do
  21. 21. Ansibleをインストールしたホストより、サーバのあるべき状態を定義したファ イルを実行してリモートホストに対して変更を加える Ansibleを利用した構築イメージ サーバ構成定義 Ansibleホスト リモートホスト (構築対象サーバ) software software configuration application ホスト情報
  22. 22. リモートホストが複数台の場合は、サーバ構成定義ファイル(=サーバ種別 単位)で並列実行可能 Ansibleを利用した構築イメージ サーバ構成定義 Ansibleホスト リモートホスト1 “ ホスト情報 リモートホスト2 “ リモートホスト3 “ parallel
  23. 23. Ansibleは構成定義からAnsibleに組み込まれたモジュールを元に PythonCodeを生成し、リモートホストに転送して、ssh経由で実行 Ansibleの実行の内部処理 Python Code ③ ssh ① 自動生成 Python Code Ansibleホスト リモートホスト (構築対象サーバ) ④コード実行② sftpサーバ構成定義 ホスト情報 ⑤コード削除
  24. 24. 構成管理ツール比較 Puppet Chef Ansible 開発言語 Ruby Ruby Python 開発開始 2005年 2009年 2012年 書式 独自DSL Ruby DSL yaml 冪等制 ◯ ◯ ◯ 構成管理方法 Pull型 Pull型 Push型 エージェント 必要 必要 不要 ※1 ※1: AnsibleもリモートホストにPython 2.4以降のインストールが予め必要。
  25. 25. 構成管理ツール比較
  26. 26. 3. Ansible 基礎編
  27. 27. Ansibleインストール ansibleはyum、apt、pipで提供されているため環境に合わせてインストー ル。 ### Latest Release Via Yum (CentOS, RHEL) $ yum install -y epel-release $ sudo yum install ansible --enablerepo=epel ### Latest Releases Via Apt (Ubuntu) $ sudo apt-get install software-properties-common $ sudo apt-add-repository ppa:ansible/ansible $ sudo apt-get update $ sudo apt-get install ansible ### Latest Releases Via Pip (Linux, MacOS) $ sudo easy_install pip $ sudo pip install ansible
  28. 28. Ansibleの最小構成 Ansibleで環境構築を行う最低限の2ファイル 1. Inventory - リモートホストのホストやグループを管理するファイル - ファイル名に規定なし ex.) hosts, inventory 2. Playbook - リモートホストの状態 (構成) を定義するyamlファイル - Inventoryで管理されたグループやホスト単位で作成 - ファイルの拡張子は”.yml” 最小構成 ├── hosts  # Inventory └── site.yml # Playbook
  29. 29. Inventory(インベントリ) 192.168.33.101 foo [webservers] web01 web02 [dbservers] db[01:03] [xxxservice:children] webservers dbservers [bastion] bastion ansible_port=30022 [all:vars] ansible_user=vagrant グループ名 複数のホストをグルーピングした名称 グループ単位でPlaybookを実行可能 ホスト省略形式指定 (db01,db02,db03) SSHのポート番号を指定するパラメータ (デフォルトは22番を利用) 全ホストに対して指定するパラメータ “all”グループは予約されており、インベントリ の全ホストがターゲットとなる ホスト SSHで接続可能なホスト IPアドレスや名前解決可能なホスト名 “:children”を指定して、グループを束ねたグ ループを作成
  30. 30. Playbook リモートホストの構成をタスク又はロールで定義 タスクはAnsibleのモジュールを利用して定義し、上から順番に実行 --- - hosts: 192.168.33.101 become: yes tasks: - name: install nginx yum: name=nginx state=present - name: nginx running and enabled service: name=nginx state=started enabled=yes リモートホスト(インベントリのホスト or グループ) sudoで実行 モジュール モジュールの引数 nginxのインストール nginxサービスの起動 / 自動起動有効化
  31. 31. ansible-playbook コマンド $ ansible-playbook -i hosts site.yml PLAY [192.168.33.101] ************************************************* TASK [setup] ******************************************************************* ok: [192.168.33.101] TASK [install nginx] *********************************************************** changed: [192.168.33.101] TASK [nginx running and enabled] *********************************************** changed: [192.168.33.101] PLAY RECAP ********************************************************************* 192.168.33.101 : ok=3 changed=2 unreachable=0 failed=0 インベントリ Playbook 初回実行時
  32. 32. ansible-playbook コマンド $ ansible-playbook -i hosts site.yml PLAY [192.168.33.101] ************************************************* TASK [setup] ******************************************************************* ok: [192.168.33.101] TASK [install nginx] *********************************************************** ok: [192.168.33.101] TASK [nginx running and enabled] *********************************************** ok: [192.168.33.101] PLAY RECAP ********************************************************************* 192.168.33.101 : ok=3 changed=0 unreachable=0 failed=0 再実行時 変更点なし
  33. 33. ansible-playbook コマンド $ ansible-playbook -i hosts site.yml … (snip) … PLAY RECAP ********************************************************************* 192.168.33.101 : ok=3 changed=2 unreachable=0 failed=0 結果 説明 ok 定義された状態となっている changed 定義された状態に変更が行われた unreachable リモートホストへの接続に失敗した failed タスクの実行に失敗(エラー) 実行結果にて、各リモートホストの実行結果の要約(RECAP)を出力
  34. 34. PlaybookのDry Run 手動でPlaybookを流す前には必ず事前に意図した変更となるか確認する ansible-playbook コマンド $ ansible-playbook -i hosts site.yml --check その他のオプション  -D, --diffオプション   ファイル等の変更差分内容を出力。  --syntax-check   playbookのシンタックスを検査。  --list-tasks   実行されるタスクの一覧を表示。  --start-at-taskオプション(=”task名”)   playbookを途中から実行する場合に有効。  --step   playbookを(N)o/(y)es/(c)ontinue入力でステップ実行。 Tips  Inventoryfileなしでplaybook実行  $ ansible-playbook -i "192.168.1.2," site.yml  ※1台の場合は末尾にカンマが必要
  35. 35. ansibleコマンドを利用してAd-Hocにモジュールを実行可能 ▷ yumモジュール(パッケージ管理) playbookで実行したnginxインストールタスクの実行例 ansible コマンド(Ad-Hoc) $ ansible -i hosts 192.168.33.101 -m yum -a "name=nginx state=present" -b 192.168.33.101 | SUCCESS => { "changed": false, "msg": "", "rc": 0, "results": [ "nginx-1.10.2-1.el6.x86_64 providing nginx is already installed" ] } ターゲットインベントリ モジュール モジュールのOptions become(sudo)
  36. 36. タスクはモジュールを指定して構成を定義 モジュールは基本的に冪等性を担保した実装が行われている。 モジュールの分類 ▷ Core Modules https://github.com/ansible/ansible-modules-core 利用頻度の高いモジュール群 ▷ Extra Modules https://github.com/ansible/ansible-modules-extras 利用頻度の中以下のモジュール群、Core Modulesの登竜門 Ansible module index (core + extra)  モジュール数:900超 Ansibleモジュール
  37. 37. 利用可能なモジュール一覧の確認 モジュールに関するドキュメントは`ansible-doc`コマンドで参照 Ansibleモジュール $ ansible-doc -l $ ansible-doc file Sets attributes of files, symlinks, and directories, or removes files/symlinks/directories. Many other modules support the same options as the [file] module - including [copy], [template], and [assemble]. Options (= is mandatory): - follow This flag indicates that filesystem links, if they exist, should be followed. (Choices: yes, no)[Default: no] - force force the creation of the symlinks in two cases: the source file does not exist (but will appear later); the destination exists and is a file (so, we need to unlink the "path" file and create モジュール名
  38. 38. ▷ pingモジュール(リモートホストの疎通確認) サーバ新設後の接続確認や障害発生時の疎通確認に利用可能。 Ansibleモジュール $ ansible web -i hosts -m ping web01 | SUCCESS => { "changed": false, "ping": "pong" } web02 | SUCCESS => { "changed": false, "ping": "pong" } ※※インベントリ※※ [web] web01 web02
  39. 39. ▷ setupモジュール(リモートホストの情報取得) playbookの実行時は、デフォルトで始めに setupモジュールが実行されてファクト変数を取得 ファクト変数はplaybook内で変数として利用可( Distributionによる条件式等) Ansibleモジュール $ ansible 192.168.33.101 -i hosts -m setup --one-line 192.168.33.101 | SUCCESS => {"ansible_facts": {"ansible_all_ipv4_addresses": ["10.0.2.15", "192.168.33.101"], "ansible_all_ipv6_addresses": ["fe80::a00:27ff:fe4f:b806", "fe80::a00:27ff:fe03:c0a5"], "ansible_architecture": "x86_64", "ansible_bios_date": "12/01/2006", "ansible_bios_version": "VirtualBox", "ansible_cmdline": {"KEYBOARDTYPE": "pc", "KEYTABLE": "us", "LANG": "en_US.UTF-8", "SYSFONT": "latarcyrheb-sun16", "clocksource_failover": "acpi_pm", "rd_NO_DM": true, "rd_NO_LUKS": true, "rd_NO_LVM": true, "rd_NO_MD": true, "ro": true, "root": "UUID=1d798f26-8ace-413f-9530-2d1d1d4fdbb5"}, "ansible_date_time": {"date": "2017-02-05", "day": "05", "epoch": "1486270715", "hour": "04", "iso8601": "2017-02-05T04:58:35Z", "iso8601_basic": "20170205T045835431149", "iso8601_basic_short": "20170205T045835", "iso8601_micro": "2017-02-05T04:58:35.431233Z", "minute": "58", "month": "02", "second": "35", "time": "04:58:35", "tz": "UTC", "tz_offset": "+0000", "weekday": "Sunday", "weekday_number": "0", "weeknumber": "05", "year": "2017"}, "ansible_default_ipv4": {"address": "10.0.2.15", "alias": "eth0", "broadcast": "10.0.2.255", "gateway": "10.0.2.2", …(snip)…
  40. 40. Ansibleモジュール その他の代表的なモジュール ● file - ファイル/ディレクトリ作成や所有者/権限変更 ● copy - リモートホストにファイルを転送 ● template - テンプレートファイル(jinja2)を展開した      ファイルをリモートホストへ転送 ● get_url - 指定URLからファイルをダウンロード ● lineinfile - リモートホストのファイルで正規表現にマッチ      する行の書き換え ● shell - シェルの実行 ● yum / apt - パッケージ操作 ● service - サービス操作
  41. 41. Role Playbookを疎結合なコンポーネントの処理で分割したもの tasks / defaults / files / templates / handlers / varsのディレクトリ構成 Roleを作成することで再利用可能となり、Playbookの可読性も高まる site.yml     # playbook roles/nginx/    # roles/[Role名]ディレクトリ ├─ defaults/   # 変数のデフォルト値 |  └ main.yml # Roleで利用する変数default ├─ files/     # copyモジュールのファイル ├─ handlers/   # 特定イベント発火タスク |  └ main.yml # ├─ meta/    # Roleのメタ情報(依存Role) ├─ tasks/    # Roleで実行されるタスク |  └ main.yml # 実行タスクファイル ※必須 ├─ templates/  # templateモジュール |  └ xxx.xxx.j2 # Jinja2形式ファイル └─ vars/     #    └ main.yml # --- - hosts: web roles: - nginx nginxロール呼び出し --- - name: install nginx yum: name=nginx-{{ nginx_version }} state=present - name: nginx running and enabled service: name=nginx state=started enabled=yes nginx_version: 1.10.2
  42. 42. vars / templates varsはホスト/グループ/環境毎の設定値を定義、templates等にて変数代入 group_varsはグループ単位の設定値を変えることが可能 site.yml   # playbook hosts    #インベントリ group_vars ├─ web.yml # group: webのvars ├─ db.yml  # group: dbのvars roles └─nginx/  # nginx rolesディレクトリ   ├─ tasks/   |  └ main.yml # roleの実行タスク   └─ templates/     └ index.html.j2 # index.htmlのテンプレート - hosts: web roles: - nginx - name: replace index.html template: src: index.html.j2 dest: /usr/share/nginx/html/index.html name: “webserver” group_vars name: {{ name }} name: “dbserver” $ ansible-playbook -i develop site.yml $ ssh web01 “cat /usr/share/nginx/html/index.html” group_vars name: webserver
  43. 43. vars / templates varsの値定義箇所は複数存在し、各優先度が複雑な為に注意が必要 ● role defaults ● inventory vars ● inventory group_vars ● inventory host_vars ● playbook group_vars ● playbook host_vars ● host facts ● play vars ● play vars_prompt ● play vars_files ● registered vars ● set_facts ● role and include vars ● block vars (only for tasks in block) ● task vars (only for the task) ● extra vars (always win precedence) low priority high
  44. 44. Ansible Vault $ cat group_vars/webserver.vault nginx_htpasswd: '9s36?;fyNp' $ ansible-vault encrypt group_vars/webserver.vault Encryption successful $ cat group_vars/webserver.vault $ANSIBLE_VAULT;1.1;AES256 61386434353264313436616339353933666163333931323262383 064343738643639373239643462 6665363764373265366464626666613535326531666363630a6 56332646462616231613438383233 ... snip ... ### view encrypt vars file $ ansible-vault view group_vars/webserver.vault nginx_htpasswd: '9s36?;fyNp' ### edit encrypt vars file $ ansible-vault edit group_vars/webserver.vault ### decrypt encrypted vars file $ ansible-vault decrypt group_vars/webserver.vault 機密情報のvarsを暗号化してリポジ トリ管理可能とするツール playbook実行時にはパスワードに より復号化して変数利用 パスワードファイル設置   ansible.cfgに以下の設定を追加 vault_password_file = ~/.vault_password $ echo “passwd” > ~/.vault_password
  45. 45. Ansible Galaxy AnsibleのRoleが公開されるサービス 世界中のユーザが作成したOSSのRoleの検索が可能 - サポートプラットフォーム - タグ - Github Watch/Start数 - ダウンロード数 利用方法  → rolesディレクトリ配下へDL 新規ロール作成時には、目的のRoleがないか検索 抽象度が高いRoleはメンテコストが掛かるため独自Roleの選択肢も検討 $ ansible-galaxy install user.repo
  46. 46. Best Practice production # inventory file for production servers staging # inventory file for staging environment group_vars/ group1 # here we assign variables to particular groups group2 # "" host_vars/ hostname1 # if systems need specific variables, put them here hostname2 # "" library/ # if any custom modules, put them here (optional) filter_plugins/ # if any custom filter plugins, put them here (optional) site.yml # master playbook webservers.yml # playbook for webserver tier dbservers.yml # playbook for dbserver tier roles/ common/ # this hierarchy represents a "role" tasks/ # main.yml # <-- tasks file can include smaller files if warranted handlers/ # main.yml # <-- handlers file templates/ # <-- files for use with the template resource ntp.conf.j2 # <------- templates end in .j2 files/ # bar.txt # <-- files for use with the copy resource vars/ # main.yml # <-- variables associated with this role defaults/ # main.yml # <-- default lower priority variables for this role meta/ # main.yml # <-- role dependencies library/ # roles can also include custom modules lookup_plugins/ # or other types of plugins, like lookup in this case webtier/ # same kind of structure as "common" was above, done for the webtier role monitoring/ # "" fooapp/ # "" 公式のAnsibleディレクトリ構成の ベストプラクティス マルチステージに対応  production / staging
  47. 47. 4. Ansible Demonstration
  48. 48. Demo (3) オーケストレーション  ローリングアップデートによるデプロイ (2) コンフィグレーション  EC2のサーバ構築 x2台   common / ngnix (1) ブートストラッピング  Ansibleを用いたAWSの環境構築   VPC / KeyPair / InternetGateway   Subnet / RouteTable / SecurityGroup /   EC2 x2台 / ELB Availability Zone 1a Availability Zone 1c web web EC2 EC2 Elastic Load Balancing
  49. 49. Demo (3) オーケストレーション  ローリングアップデートによるデプロイ (2) コンフィグレーション  EC2のサーバ構築 x2台   common / ngnix (1) ブートストラッピング  Ansibleを用いたAWSの環境構築   VPC / KeyPair / InternetGateway   Subnet / RouteTable / SecurityGroup /   EC2 x2台 / ELB Availability Zone 1a Availability Zone 1c web web EC2 EC2 Elastic Load Balancing AWS via Ansible ● Rate exceededでAPI発行がこけることがある  (terraformは自動でリトライ) ● リソースを削除する場合には state: absentのPlaybookが別途必要  (terraformはdestroyで一括削除) ● AWSサービスのモジュールサポートは事前に要チェック  (デモ範囲は全てモジュールで実現)
  50. 50. 5. Ansible 実践編
  51. 51. - バージョン管理(Git) - Pull Request(レビュー) - TDI(TDD)(テスト駆動インフラストラクチャ) - CI(継続的インテグレーション) - CD(継続的デプロイ) (再) Infrastructure as Codeのプラクティス
  52. 52. - バージョン管理(Git) - Pull Request(レビュー) - TDI(TDD)(テスト駆動インフラストラクチャ) - CI(継続的インテグレーション) - CD(継続的デプロイ) (再) Infrastructure as Codeのプラクティス
  53. 53. バージョン管理 AnsibleのGitブランチ戦略 本番 / 検証環境をそれぞれmaster / developブランチで運用。 各環境とソースコードが適合する状態を維持し続ける。 master develop Feature Feature
  54. 54. Pull Request(レビュー) GithubのPull Requestでレビュー実施。 - 概要(変更内容) - レビュー観点 - 適用時ansible-playbookコマンド (その他必要作業漏れないか) - CIテスト実行設定 - 適用時のサービス影響
  55. 55. Pull Request(レビュー) ## 概要 xxx ## レビュー観点 - xxx ## 環境適用手順 ### ローカル環境 ``` ansible-playbook -i inventories/local/hosts playbooks/xxx.yml --diff --check ``` ### 検証環境 ``` ansible-playbook -i inventories/develop/hosts playbooks/xxx.yml --diff --check ``` ### 本番環境 ``` ansible-playbook -i inventories/production/hosts playbooks/xxx.yml --diff --check ``` ## CIテスト実行設定 - テスト実行可否 [true/false] test-enable: true - テスト対象Playbook [csv形式] test-playbooks: webservers.yml, dbservers.yml ## サービスへの影響 xxxx ## レビュー期日 xx/xx .github/PULL_REQUEST_TEMPLATE.mdを作成することでPR作成簡略化
  56. 56. TDI(テスト駆動インフラストラクチャ) インフラテストの自動化ツール   RSpecを拡張したサーバテストのRuby製のフレームワーク。   テスト対象サーバにsshでログインしてサーバの状態を確認。 Ansibleは、fail-fastの思想に基づいており、Ansibleの実行が成功すれば定 義したリソースの状態は正しい。 但し、定義誤りによりリソースや設定に不備がある場合Ansibleでは検知不 能。 Serverspecで各種設定を定義する場合、Ansibleと冗長管理となるため注 意。
  57. 57. CI(継続的インテグレーション) Ansibleで冪等性の考慮漏れは良く発生する。 CIで予め初期構築及び、冪等性をテストする。 (1) Apply [1st] - 初回構築の正常性確認 (2) Dry-Run - 初回構築後のdry-runで冪等性を検証 (changed=0) (3) Apply [2nd] - 2回目以降の適用で冪等性を検証 (changed=0) ※(2)(3)を実施する理由は`check_mode: no`のtaskを考慮。 (1) 未構築 構築済 (2)(3)
  58. 58. CI(継続的インテグレーション) (4) launch instances   and exec playbook   (run, dry-run, run) (1) pull request   push (2) webhook Jenkins test script test script (3) exec playbooks x procs (6) post results (7) result (5) notify EC2 EC2
  59. 59. callback_plugin Playbook実行結果のok, changed, unreachable, failure数の取得に callback_pluginが利用可能。 playbookの実行開始や終了などの イベントにフックして、処理を行うプ ラグイン。 実行後にログやメール、チャットで 通知する用途など。 ここでplaybook_on_stats()の実行 結果を集計してjsonで出力させて、 CIでの結果判定に利用している。 ## etc/callback_plugins/output_json.py import os import json class CallbackModule(object): def __init__(self): self.hosts_name = None self.results_dir = 'results' ## call on start playbook def playbook_on_play_start(self, name): self.hosts_name = self.play.hosts ## call at end playbook def playbook_on_stats(self, stats): hosts = sorted(stats.processed.keys()) result_hosts = [] for host in hosts: s = stats.summarize(host) dict = { "host": host, "result": { "ok": s['ok'], "changed": s['changed'], "unreachable": s['unreachable'], "failures": s['failures'] } } result_hosts.append(dict) …..
  60. 60. その他(Ansibleと環境の乖離対策) サーバの予期せぬ状態変化や、緊急時の手動設定変更、及びPlaybookの実 行漏れなどが発生した場合、Ansibleのコードと環境に差異が起こる。 コードと環境が正しい状態(changed=0)で運用が行われていなければ、緊急 でPlaybookを流したい場合などに混乱を招く可能性がある。 そこで、日次でPlaybookをdry-runで実行し、環境との差異がないことを確認し ている。 コードと環境状態を合わせることがAnsible運用において肝心。
  61. 61. dry-run実行結果のjsonファイルをAWS S3へ置いて静的Webホスティングの ページから参照して一覧化している。 その他(Ansibleと環境の乖離対策)
  62. 62. 機能 ▷ ビジュアルダッシュボード ▷ ロールベースのアクセス制御 ▷ ジョブスケジューリング ▷ グラフィカルな在庫管理 ▷ リアルタイムでの ジョブステータス更新 https://www.redhat.com/ja/technologies/management/ansible Ansible Tower Ansibleの管理・操作用のWeb GUI インタフェース。 10ホストまでは無料、それ以上は有償。 ホストの状態はAnsible Towerでも管理可能。
  63. 63. Thanks! Any questions?

×