Ansible と Insights パート 2 - Ansible Core 修復の自動化

前回のブログ投稿 で Insights による Ansible 自動化を説明しましたが、今回は Insights による発見と、Ansible playbook による自動修復を実行するために提供される実行可能なインテリジェンスに使用について詳しく見ていきます。Ansible Tower の設定と修復については、次回の投稿でお話しする予定です。

現時点では、Insights と Tower 向けの playbook は、Red Hat カスタマーポータルで生成されます。Satellite 6 がリリースされれば、Satellite UI から playbook が生成できるようになり、Insights 自動修復機能がさらに Satellite に統合されます。

Insights で Ansible 機能を活用するには、以下が必要になります:
- 有効な RHEL サブスクリプション
- 有効な Insights 評価版またはエンタイトルメント
- RHEL 7 または RHEL 6.4 以降
- インストール済み Ansible (もしくは Ansible Tower)
- Insights システムの登録とレポーティング で特定可能な問題があること
- Insights システムのホスト名または「ディスプレイ名」が Ansible のインベントリー内でホスト名となっている Ansible でシステム管理機能があること

Insights インターフェースには、カスタマーポータル https://access.redhat.com/insights からログインします。

すでにログインしている場合は、Insights 概要が開きます。

概要からは、自動修復が特定されたシステムがあるかどうかがすばやく確認できます。コンソール右下のプランナーでは、「Ansible を使用して 5 件の問題が自動的に解決可能」といったメッセージが表示されます。これを使用すると、Ansible で修復できる全アイテムをすばやく確認できます。

ここからはオプションがあります。左側のナビゲーションメニューからプランナーを選択してプランを構築するか、概要から「新規プラン/Playbook の作成」をクリックするか、または影響のあるシステムのアクション (アクション -> カテゴリー) ドロップダウンメニューを使用することができます。

この例ではアクション -> セキュリティーと移動し、「Kernel vulnerable to man-in-the-middle payload injection」を選択してみます。このリスクで数台のシステムが影響を受け、可能性が中、影響は重大、総合リスクは高であることが分かります。このアクションは、Ansible にも対応しています。

アクション自体をクリックすると問題の内容と影響を受けるシステム一覧が表示されます。ここからは、影響を受けるシステム向けに playbook を作成できます。

影響を受けるシステム 3 台を選択し、アクションドロップダウンダイアログから「新規プラン/Playbook の作成」をクリックします。

プラン名を指定 (これは重要です: Tower 統合を使用している場合は、この名前で Tower 内の playbook を特定します) し、選択したシステムを確認します。「保存」をクリックするとプランが作成されます。ここからはプランを削除したり、メンテナンス期間を特定するためにプランを編集したりすることができます。また、このプランに関連付けられているシステムを編集したり、「Playbook を生成」や「CSV でエクスポート」もできます。
playbook を生成したいので、このボタンをクリックします。

ビルドしている playbook に (この例のような) オプションがある場合は、Ansible playbook にどのタスクを含めるかを決定するダイアログが表示されます。現在、playbook のオプションを変更するには、上記の図のように「Playbook サマリー」に移動する必要があります。選択したマシンは私の環境でクリティカルで、カーネル更新と再起動でこれらのマシンを修正するために停止させる余裕はないので、ここで私はアクティブな軽減策と「Set sysctl ipv4 challenge ack limit」を使用します。こうすることで軽減策をもたらし、脆弱でないシステムにすることができます。より恒久的な修正は、カーネルを更新することですが、sysctl 変数を元に戻すものがないことが確認できれば (設定管理ツールも更新されなければ、これらの変更を元に戻す可能性があります)、このアクティブな軽減策で安全を確保できます。

保存をクリックして選択を確認し、Playbook をダウンロードすることで生成を完了させます。

これでこのダウンロードした Ansible playbook YML ファイルを使って、以下のようにシステムを修復できます。: $ ansible-playbook $downloaded_filename.yml

ファイル名は、plan_name-plan_number-unixtime.yml の形式を取り、どの修復システムおよびルールのバックエンドが使用されているかについての情報が含まれます。

Playbook の稼働を確認して、調査するエラーがない場合は、プランナーをリフレッシュすると、3/3 のシステムが修復されたことが示されます。

プランナーのインターフェースをリフレッシュすると、修復の実行が成功し、システムのステータスにチェックが入っていることが確認できます。

Ansible playbook を使って、リスクがレポートされているシステムを修復することは、このように簡単です。次回のブログ投稿では、Ansible Tower を使ってこの方法をインフラストラクチャー全体に適用する方法について見ていきます。

新機能についての前回の投稿へのご感想をお聞かせください。ブログにコメントをいただくか、Insights の「フィードバックを提供する」ボタンからお寄せいただけます。

Insights エンジニアチームと製品チームから感謝を申し上げます。パート 3 をお楽しみに。エンタープライズの修復向けに Ansible Tower と Insights を取り上げる予定です。
-Will Nix