Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RHF2019_Ansible_利用その一歩先へ

Hiroshi Okano
November 15, 2019

 RHF2019_Ansible_利用その一歩先へ

Red Hat Forum 2019 で講演した資料です。
以下の内容を網羅しています。
・自動化導入へ、第一歩を踏み出そう!
・Ansible Tower の使い方について

Hiroshi Okano

November 15, 2019
Tweet

More Decks by Hiroshi Okano

Other Decks in Technology

Transcript

  1. RED HAT FORUMS Ansible 利用その一歩先へ ~ Ansible Tower の使い方徹底解説! ~

    岡野浩史 レッドハット株式会社 パートナーソリューションアーキテクト部 シニアソリューションアーキテクト 2019年11月15日
  2. 自動化へのモヤモヤした期待 4 自動化っつーか構成の 確認・レポーティング が結構大変 ワークフローと連携した仮想環境 確認とインスタンスの払い出し? 繰り返し作業では若い人が 入社してくれない。クリエ イティブな仕事が必要

    システム多すぎ。 独自の管理ツールなん て覚えらんねぇ~。 設定変更って怖い よね、基本夜中 ネットワークとパブリッ ククラウドの設定は別の 管理者へ依頼 顧客からの運用費用の 削減要求がきつい DXに対応したITって いったってね 基本塩漬けでしょ? スクリプトベースで やられるとね・・・ 自動化の横連携ができない 同じようなことやってんのに 自動化がサイロ化してる? 依頼すると結構時間 かかるんだよね。 目視確認って今時本当 に必要あるのか・・・ 自身の機器管理は Ansible 使っ て管理の自動化やってます。 他のシステムはどうかな?? © Red Hat K.K.
  3. 導入障壁と効果の最大化を阻む壁 5 ➢ 既存の自動化ツールや運用手順の存在 • 全部は出来ない、価格が高い・・・など問題はありつつ • 既存ツール運用手順への慣れ&変化への抵抗 ➢ どこから手を付けたら??

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

    • 多岐に渡る運用手順。どこから手を付ければ? ➢ 自動化の検討を延々とやっている • システムをクラウドに移行中、それが終わってから考えます。 • 他の部署も巻き込んでやった方がいいのでは? • PoC で課題解決ではなく Ansible 化の確認だけをやっている © Red Hat K.K. ・信じて一歩を踏み出す...早く取り組んだ者勝ち!! 周りは後からついてくる♪ ・小さな自動化を積み重ねて ”大きな自動化の森” に 設定の確認やレポートの作成などから始めるのも良い ・課題を明確にする PoC の目的は Ansible 化の可否ではなく、課題の解決 解決のために
  5. 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
  6. プレイブックの例 - 学習コストの低い標準化 --- - 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
  7. 自動化の進め方 - 仮説に対し PoC を実施!! 14 運用の棚卸し (課題の見える化と仮説の立案) Fact(事実) Opinion(意見)

    Problem(問題) Solution(解決策) 仮説 設計 実装 測定 意見 意見 意見 PoCで確認! © Red Hat K.K.
  8. 一歩先の自動化 - 管理者を超越した自動化の実現! 16 © Red Hat K.K. LB閉塞 バックアップ

    アプリ更新 動作確認 動作確認 作業の 調整&確認 作業の 調整&確認 クラウド 管理者 アプリ 管理者 NW 管理者 手作業 or 自動化のサイロ 作業前の 準備 実作業 リストア LB 開放 動作確認 作業の 調整&確認 クラウド 管理者 アプリ 管理者 NW チーム 一部サービス化された状態 セルフサービス化 LB閉塞 LB開放 動作確認 NWチームが登 場しなくなる サービス化 された作業 高品質かつ標準化 LB開放 失敗したらバ ックアップか らのリストア バックアップ アプリ更新 動作確認 LB 閉塞 失敗したらバ ックアップか らのリストア リストア
  9. Ansible Tower - 使いやすいインターフェース 18 © Red Hat K.K. ⚫

    洗練された GUI 誰でも簡単に操作できます ⚫ CLI も充実!! Tower3.6では AWX コマンド!! # awx job_templates launch <id> ⚫ 外部ソフトウェアとの連 携には RESTAPI 完備 https://docs.ansible.com/ansible-tower/latest/html/towercli/index.html
  10. 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
  11. Playbook の管理 - アクセス権限の管理 20 © Red Hat K.K. ”プロジェクト”

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

    用 Playbook AWS 用 Playbook Network 用 Playbook VMware 用 Playbook プロジェクトと管理フォルダは 1:1 の関係! 利用オーナーを決めて利用権限を委譲する!! ”プロジェクト” による Playbook ディレクトリの管理と権限の委譲 Playbook ディレクトリ: /var/lib/awx/projects/<各プロジェクト>/
  13. 認証情報の管理 - インベントリの権限移譲 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 インベントリ単位(タグ)
  14. 認証情報の管理 - インベントリの権限移譲 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 インベントリ単位(タグ)
  15. 認証情報の管理 - 管理対象 26 ・Ansible Tower 自身のアカウント管理 LDAP / Azure

    AD / RADIUS 等を利用する 設定用に専用のテンプレートが準備 ・管理対象ノードに対するアクセス権限管理 必要な人に必要な権限を委譲する © Red Hat K.K. ネットワーク サーバー クラウド ネットワーク 管理者 サーバー 管理者 クラウド 管理者 IT 管理者 外部認証 システムで管理 Towerで 権限を委譲
  16. Ansible Tower の機能をフル活用! 運用のフルセルフサービス!! ~ Survey / ワークフロー / 権限の委譲

    ~ 27 © Red Hat K.K. LB閉塞 バックアップ アプリ更新 動作確認 作業の 調整&確認 クラウド 管理者 アプリ 管理者 NW 管理者 作業前の 準備 実作業 LB開放 スタート LB閉塞 バックアップ アプリ更新 動作確認 LB開放 動作確認 動作不良の場合 バックアップか らリストア 動作確認 リストア LB開放 動作確認 実行権限 アプリ 管理者 実行権限 オーナー 実行権限 オーナー 実行権限 実行権限 オーナー 実行権限の場合も対象マシンを Survey により柔軟に変更可能 作業の 調整&確認 スタートボタン を押すだけ ・・・ジョブテンプレート ワークフロー作成
  17. Ansible Tower の構成 - 可用性とスケーラビリティ 28 Ansible Tower のインストール構成は以下の通りです。 1.

    単一ノード ・All in One Ansible Tower に必要な機能を全て1台にインストールした構成 ・データベースのみ外部を利用(PostgreSQL 9.6) 既存のDBの利用 Tower のインストーラーを利用した別ノードへのインストール 2. 高可用性クラスター ・DB以外の部分を複数ノードで構成 + 外部データベース 各ノードは全て Active で動作します。3台~20台、奇数ノードで構成 © Red Hat K.K. Ansible Tower HTTP Service Rabbit MQ Postgre SQL
  18. 可用性とスケーラビリティについて 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
  19. 3. Tower のオブジェクト自体をコード化♪ Tower を単なる ”オペレーションを橋渡しするハブ” と考える。 Tower モジュールを使って Tower

    のオブジェクトを全て Git で管理! 別 Tower へのオブジェクト移行も即座に完了 © Red Hat K.K. 可用性とスケーラビリティについて - 思考を変えて Playbook 開発 Tower Module プロジェクト インベントリ テンプレート 認証情報
  20. 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を自動起動
  21. Tower 3.6 新機能 - 速報 33 © Red Hat K.K.

    New ➢ ワークフローで承認機能をサポート! Wait 処理として定義します。 ➢ メールや Slack 等で通知も可能! ➢ 本格的なワークフローにちょっとだけ近づきました♪