RED HAT FORUMS Ansible 利用その一歩先へ ～ Ansible Tower の使い方徹底解説！ ～ 岡野浩史 レッドハット株式会社 パートナーソリューションアーキテクト部 シニアソリューションアーキテクト 2019年11月15日

© Red Hat K.K. Ansible Tower の描く世界観 2

まず始めよう Ansible 導入への第一歩 ～ 自動化導入の進め方～

自動化へのモヤモヤした期待 4 自動化っつーか構成の 確認・レポーティング が結構大変 ワークフローと連携した仮想環境 確認とインスタンスの払い出し？ 繰り返し作業では若い人が 入社してくれない。クリエ イティブな仕事が必要 システム多すぎ。 独自の管理ツールなん て覚えらんねぇ～。 設定変更って怖い よね、基本夜中 ネットワークとパブリッ ククラウドの設定は別の 管理者へ依頼 顧客からの運用費用の 削減要求がきつい DXに対応したITって いったってね 基本塩漬けでしょ？ スクリプトベースで やられるとね・・・ 自動化の横連携ができない 同じようなことやってんのに 自動化がサイロ化してる？ 依頼すると結構時間 かかるんだよね。 目視確認って今時本当 に必要あるのか・・・ 自身の機器管理は Ansible 使っ て管理の自動化やってます。 他のシステムはどうかな？？ © Red Hat K.K.

導入障壁と効果の最大化を阻む壁 5 ➢ 既存の自動化ツールや運用手順の存在 • 全部は出来ない、価格が高い・・・など問題はありつつ • 既存ツール運用手順への慣れ＆変化への抵抗 ➢ どこから手を付けたら？？ • 多岐に渡る運用手順。どこから手を付ければ？ ➢ 自動化の検討を延々とやっている • システムをクラウドに移行中、それが終わってから考えます。 • 他の部署も巻き込んでやった方がいいのでは？ • PoC で課題解決ではなく Ansible 化の確認だけをやっている © Red Hat K.K.

導入障壁と効果の最大化を阻む壁 6 ➢ 既存の自動化ツールや運用手順の存在 • 全部は出来ない、価格が高い・・・など問題はありつつ • 既存ツール運用手順への慣れ＆変化への抵抗 ➢ どこから手を付けたら？？ • 多岐に渡る運用手順。どこから手を付ければ？ ➢ 自動化の検討を延々とやっている • システムをクラウドに移行中、それが終わってから考えます。 • 他の部署も巻き込んでやった方がいいのでは？ • PoC で課題解決ではなく Ansible 化の確認だけをやっている © Red Hat K.K. ・信じて一歩を踏み出す...早く取り組んだ者勝ち！！ 周りは後からついてくる♪ ・小さな自動化を積み重ねて ”大きな自動化の森” に 設定の確認やレポートの作成などから始めるのも良い ・課題を明確にする PoC の目的は Ansible 化の可否ではなく、課題の解決 解決のために

Ansible Automation Platform 構成要素 Ansible Engine インベントリー Playbook Modules Playbook (YAML形式のファイル) − 何をするか手順(task)を記述する Inventoryファイル − 対象となるサーバ群を記述する Module (ミニプログラム) − パラメータを渡すことで特定の動作 をするミニプログラム GUI 権限管理 Job管理 Database RestAPI Ansible Tower API SSH, NETCONF SSH, WinRM ネットワーク サーバー クラウド Simple Powerful Agentless © Red Hat K.K. 7

プレイブックの例 - 学習コストの低い標準化 --- - name: Apacheのインストールと起動 #Playbook の説明 hosts: app #app グループが対象（インベントリ） become: yes #権限昇格の有無 tasks: #実行する手順の内容 - name: httpd のインストール #実行時に処理毎に表示される名前 yum: name: httpd state: latest - name: httpd を起動 service: name: httpd state: running モジュール 実行順序 TARGET セクション TASKS セクション © Red Hat K.K. 8

3,000 を超えるモジュールで様々なシステムを自動化 他にもたくさんあります。最新の情報はこちらをご確認ください。 http://docs.ansible.com/ansible/list_of_all_modules.html © Red Hat K.K. 9

自動化の進め方 - 小さな成功の積み重ね 簡単にできる場所から 小さく始める 作業A 作業B ☓ 最初から全部を自動化する ☓ 大きな自動化は作りが複雑化 © Red Hat K.K. 10

自動化の進め方 - 小さな成功の積み重ね 小さくサービス化した 自動化を再利用する 作業A 作業B ☓ 大きく作った自動化は再利用 しにくい © Red Hat K.K. 11

自動化の進め方 - 小さな成功の積み重ね パーツが揃ったら連結し 徐々に大きくする 作業A 作業B © Red Hat K.K. 12

自動化の進め方 - 課題の明確化と仮説の立案 ～ 自動化は課題解決の”手段”であり”目的”ではない！！ ～ © Red Hat K.K. 見えないものは改善出来ません！！ 13

自動化の進め方 - 仮説に対し PoC を実施！！ 14 運用の棚卸し (課題の見える化と仮説の立案) Fact（事実） Opinion（意見） Problem（問題） Solution（解決策） 仮説 設計 実装 測定 意見 意見 意見 PoCで確認！ © Red Hat K.K.

一歩先の自動化へ！ ～ Ansible Tower が描く世界観の実現 ～

一歩先の自動化 - 管理者を超越した自動化の実現！ 16 © Red Hat K.K. LB閉塞 バックアップ アプリ更新 動作確認 動作確認 作業の 調整＆確認 作業の 調整＆確認 クラウド 管理者 アプリ 管理者 NW 管理者 手作業 or 自動化のサイロ 作業前の 準備 実作業 リストア LB 開放 動作確認 作業の 調整＆確認 クラウド 管理者 アプリ 管理者 NW チーム 一部サービス化された状態 セルフサービス化 LB閉塞 LB開放 動作確認 NWチームが登 場しなくなる サービス化 された作業 高品質かつ標準化 LB開放 失敗したらバ ックアップか らのリストア バックアップ アプリ更新 動作確認 LB 閉塞 失敗したらバ ックアップか らのリストア リストア

17 ・使いやすいインターフェース GUI/CLI/RESTAPIに対応、テンプレートで簡単設定（シェルは極力なくす） ・Playbook とインベントリの管理 集約と再利用、アクセス権限の管理 品質管理（バージョン、実行ログ、通知） ・認証情報の管理と移譲 Ansible Tower、対象ノード ・各種機能連携 外部アプリケーションとの連携 Playbook 同士の連携 ・可用性・スケーラビリティ © Red Hat K.K. Ansible Tower が描く自動化の世界 - 必要な機能

Ansible Tower - 使いやすいインターフェース 18 © Red Hat K.K. ⚫ 洗練された GUI 誰でも簡単に操作できます ⚫ CLI も充実！！ Tower3.6では AWX コマンド！！ # awx job_templates launch ⚫ 外部ソフトウェアとの連 携には RESTAPI 完備 https://docs.ansible.com/ansible-tower/latest/html/towercli/index.html

Ansible Tower - SCM と連携した Playbook の管理 19 ➢ 散在しがちな Playbook の集約 ➢ 品質とバージョンの徹底管理 ➢ 作成後・更新後の動作確認も CI で自動化（Jenkins等） ➢ Playbook 作成と利用に関する権限の明確化 dev staging production Playbook Playbook 実行管理 テストされた Playbookのみをダ ウンロード・適応 CI ネットワーク サーバー クラウド Playbook 開発 ネットワーク サーバー クラウド テスト環境 テストの自動化 Ver:2.1 © Red Hat K.K. Ver:2.0 ～ 2.2

Playbook の管理 - アクセス権限の管理 20 © Red Hat K.K. ”プロジェクト” による Playbook ディレクトリの管理と権限の委譲 Playbook ディレクトリ： /var/lib/awx/projects/<各プロジェクト>/ App 用 Playbook AWS 用 Playbook Network 用 Playbook VMware 用 Playbook プロジェクトとディレクトリは 1:1 の関係！ 利用オーナーを決めて利用権限を委譲する！！

Playbook の管理 - アクセス権限の管理 21 © Red Hat K.K. App 用 Playbook AWS 用 Playbook Network 用 Playbook VMware 用 Playbook プロジェクトと管理フォルダは 1:1 の関係！ 利用オーナーを決めて利用権限を委譲する！！ ”プロジェクト” による Playbook ディレクトリの管理と権限の委譲 Playbook ディレクトリ： /var/lib/awx/projects/<各プロジェクト>/

インベントリの管理は面倒くさい？ 22 Tower は GUI だからインベントリの管理は面倒？そんなことはありません！ Ansible のインベントリファイルから一括登録 # tower-manage inventory_import --source= --inventory-name="inv_name" © Red Hat K.K.

ダイナミックインベントリって便利だけど難しそう... 23 クラウドインスタンスの取得は、インベントリスクリプト...?? もっと簡単に！ ソースと認証情報を選択するのみ！！ デフォルトで準備されているソース EC2, GCP, Azure, VMware, Satellite, OpenStack, RHV, AnsibleTower © Red Hat K.K. *認証情報は別途設定します AWSの場合は、アクセスキーとシークレットキーです ダイナミック インベントリ

認証情報の管理 - インベントリの権限移譲 24 クラウド管理者： ・クラウド環境のインスタンスを管理 ・インスタンスをインベントリに分け、利用権限を付与 ・Tower のインスタンスフィルター機能とクラウドが持 つタグ情報などを使った動的なインスタンス分離も可能 アプリケーション管理者： 権限付与されたインベントリにアプリケーション をインストール © Red Hat K.K. VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM Web App DB インベントリ単位（タグ）

認証情報の管理 - インベントリの権限移譲 25 クラウド管理者： ・クラウド環境のインスタンスを管理 ・インスタンスをインベントリに分け、利用権限を付与 ・Tower のインスタンスフィルター機能とクラウドが持 つタグ情報などを使った動的なインスタンス分離も可能 アプリケーション管理者： 権限付与されたインベントリにアプリケーション をインストール © Red Hat K.K. VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM Web App DB インベントリ単位（タグ）

認証情報の管理 - 管理対象 26 ・Ansible Tower 自身のアカウント管理 LDAP / Azure AD / RADIUS 等を利用する 設定用に専用のテンプレートが準備 ・管理対象ノードに対するアクセス権限管理 必要な人に必要な権限を委譲する © Red Hat K.K. ネットワーク サーバー クラウド ネットワーク 管理者 サーバー 管理者 クラウド 管理者 IT 管理者 外部認証 システムで管理 Towerで 権限を委譲

Ansible Tower の機能をフル活用！ 運用のフルセルフサービス！！ ～ Survey / ワークフロー / 権限の委譲 ～ 27 © Red Hat K.K. LB閉塞 バックアップ アプリ更新 動作確認 作業の 調整＆確認 クラウド 管理者 アプリ 管理者 NW 管理者 作業前の 準備 実作業 LB開放 スタート LB閉塞 バックアップ アプリ更新 動作確認 LB開放 動作確認 動作不良の場合 バックアップか らリストア 動作確認 リストア LB開放 動作確認 実行権限 アプリ 管理者 実行権限 オーナー 実行権限 オーナー 実行権限 実行権限 オーナー 実行権限の場合も対象マシンを Survey により柔軟に変更可能 作業の 調整＆確認 スタートボタン を押すだけ ・・・ジョブテンプレート ワークフロー作成

Ansible Tower の構成 - 可用性とスケーラビリティ 28 Ansible Tower のインストール構成は以下の通りです。 1. 単一ノード ・All in One Ansible Tower に必要な機能を全て１台にインストールした構成 ・データベースのみ外部を利用（PostgreSQL 9.6） 既存のDBの利用 Tower のインストーラーを利用した別ノードへのインストール 2. 高可用性クラスター ・DB以外の部分を複数ノードで構成 + 外部データベース 各ノードは全て Active で動作します。３台～20台、奇数ノードで構成 © Red Hat K.K. Ansible Tower HTTP Service Rabbit MQ Postgre SQL

可用性とスケーラビリティについて 29 1. クラスター構成（可用性・スケーラビリティ） ・各ノードは全て Active で動作 ジョブを適宜分割して対象ノードに実行します ・ノード数は３台～20台（奇数ノード） ・データベースは別ノードに構成 ・PostgreSQL 9.6 に関しては冗長構成を別途検討いただく必要があります。 ※関連するノード間は低レイテンシ (0.2 msec以内) で接続ください。 © Red Hat K.K.

可用性とスケーラビリティについて 30 2. バックアップリストア（可用性） 運用環境のバックアップを定期的に取得し、バックアップファイルを転送 あらかじめスタンバイホストを準備しておけば、ダウンタイムは極小に # ./setup.sh -b ---> バックアップ # ./setup.sh -r ---> リストア ※DB や /var/lib/awx/project 配下のプレイブック等 Ansible Tower 全環境のリストアを実現 © Red Hat K.K. Tower #1 Tower #2 # ./setup.sh -r コールド スタンバイ # ./setup.sh -b Backup File

3. Tower のオブジェクト自体をコード化♪ Tower を単なる ”オペレーションを橋渡しするハブ” と考える。 Tower モジュールを使って Tower のオブジェクトを全て Git で管理！ 別 Tower へのオブジェクト移行も即座に完了 © Red Hat K.K. 可用性とスケーラビリティについて - 思考を変えて Playbook 開発 Tower Module プロジェクト インベントリ テンプレート 認証情報

Tower 3.6 新機能 - 速報 32 ➢ Tower 3.6 でついに GitHub / GitLab の Webhook 対応しました！ ➢ Playbook 更新をトリガーとしてジョブテンプレート / ワークフローが起動！！ Playbook ネットワーク サーバー クラウド Playbook 開発 Ver:2.3 © Red Hat K.K. Ver:2.2 New Ver:2.3 Playbook の更 新を自動検知し てJobを自動起動

Tower 3.6 新機能 - 速報 33 © Red Hat K.K. New ➢ ワークフローで承認機能をサポート！ Wait 処理として定義します。 ➢ メールや Slack 等で通知も可能！ ➢ 本格的なワークフローにちょっとだけ近づきました♪

Tower 3.6 新機能 - 速報 34 ➢ 通知も Job の成否だけではなく、内容のカスタマイズが可能に！ © Red Hat K.K. New

© Red Hat K.K. 35 Ansible Tower で Full Automation の世界へ！！

linkedin.com/company/Red-Hat youtube.com/user/RedHatAPAC facebook.com/RedHatAPAC twitter.com/Red_Hat_APAC THANK YOU RED HAT FORUMS