GNU/Linux >> Linux の 問題 >  >> Linux

Red Hat AnsibleAutomationPlatformを使用したServiceNowの自動化

システム管理者は、ビジネスとユーザーのニーズにより適切に対応するために、サービスリクエストを迅速に完了するように定期的に求められ、ますます多くの管理者がAnsibleに依存しています。これらの要求が発生したときに、システム管理者としてどのように迅速に対応できますか？

ITサービス管理（ITSM）は、ITサービスの管理とサポートのためのポリシーとプロセスのコレクションです。 ITSMの主な焦点は、顧客のサービスチェーンの価値を高めることです。しかし、適切な自動化サポートがなければ、ITサービスの提供はすぐに管理者にとって大きな時間の浪費になる可能性があります。

[次のこともお勧めします：AnsibleforLinuxシステム管理者向けクイックスタートガイド]

ここで、Red Hat AnsibleAutomationPlatformとServiceNow用のRedHatAnsible認定コンテンツコレクションが登場します。 Ansible Automation（既存のAnsibleコンテンツの助けを借りて）は、ほぼすべてのタスクを自動化できますが、この認定コレクションのモジュールを使用すると、ServiceNow情報を最新の状態に保つことができます。

このコレクションは、特にエンドユーザーを念頭に置いて、RedHatAnsibleと緊密に協力してXLABスチームパンクチームによって設計および開発されました。 ServiceNowモジュールは、堅牢な実装に裏打ちされた直感的なユーザーインターフェースを備えており、Ansibleユーザーが期待するもの（チェックモードや変更検出など）をサポートします。

この投稿では、次のような重要な管理タスクを処理するAnsiblePlaybookのサンプルをいくつか紹介します。

  1. インシデント、問題、および変更リクエストの更新
  2. ServiceNow構成管理データベース（CMDB）の更新
  3. CMDBをインベントリソースとして使用する

ServiceNowの認定コンテンツコレクションのインストール

servicenow.itsmをダウンロードできます 自動化ハブまたはAnsibleGalaxyからのコレクション。自動化ハブのコンテンツにアクセスする前に、まずAnsible構成ファイルで認証情報を構成する必要があります。詳細については、「Hands OnWithAnsibleCollections」ブログ投稿を参照してください。

資格情報を取得したら、次のコマンドを実行してServiceNowコレクションをインストールできます。

  $ ansible-galaxy collection install servicenow.itsm

すべてが計画どおりに進んだ場合、次のモジュールにアクセスできるようになります。

  1. servicenow.itsm.incident インシデントチケットの管理用
  2. servicenow.itsm.problem 問題との相互作用のために
  3. servicenow.itsm.change_request 変更を処理するため
  4. servicenow.itsm.configuration_item CMDBを管理するための

各モジュールには、ServiceNowレコードへの読み取り専用アクセスを提供する対応するモジュールもあります。

ServiceNowの認定コンテンツコレクションには、 servicenow.itsm.nowというインベントリプラグインも含まれています これにより、CMDBをインベントリソースとして使用できます。

何も問題がなかったことを確認するには、次のコマンドを実行して、モジュールの1つのドキュメントを表示します。

  $ ansible-doc servicenow.itsm.incident

Ansibleが私たちに怒鳴らなかった場合、あなたはすべて準備ができています。

インシデントの管理、Ansibleの方法

Ansibleを使用して新しいインシデントチケットを作成するのはかなり簡単ですが、その前に、ServiceNowインスタンスが存在する場所と使用するクレデンシャルをAnsibleに通知する必要があります。これを行うには、次の3つの環境変数を設定します。

  $ export SN_HOST ='https://dev12345.service-now.com' $ export SN_USERNAME ='user' $ export SN_PASSWORD ='pass'

クレデンシャルの準備ができたので、新しいインシデントを作成できます。最小限のAnsibleプレイブックは次のようになります：

  ----ホスト：localhost collect_facts：falseタスク：-名前：新しいインシデントを作成するservicenow.itsm.incident：状態：新しいshort_description：デモインシデント

前のプレイブックの実行が完了すると、ServiceNowに新しいインシデントがリストされます。

インシデントレコードのチケット番号またはシステムIDを指定することにより、既存のインシデントを更新できます。 Ansibleは、インシデントの現在の状態と望ましい状態を比較し、それらを同期させるために必要な変更を加えます。

  ----ホスト：localhost collect_facts：falseタスク：-名前：インシデントの更新servicenow.itsm.incident：番号：INC0010022状態：in_progress

-diffを使用してAnsibleを実行する場合 スイッチを押すと、実装した変更がインシデントレコードに報告されます：

 TASK[問題情報でインシデントを更新]***************************--- before +++ after @@- 50,7 +50,7 @@ "parent"： ""、 "parent_incident"： ""、 "priority"： "5"、-"state"： "new"、+ "state"： "in_progress"、 " reassignment_count "：" 0 "、" reopen_count "：" 0 "、" reopened_by "：" "、@@ -71,10 +71,10 @@" sys_domain "：" global "、" sys_domain_path "：" / "、 "sys_id"： "2396e496074f2010d4a1fa9e7c1ed01c"、-"sys_mod_count"： "0"、+ "sys_mod_count"： "1"、 "sys_tags"： ""、 "sys_updated_by"： "admin"、 

 状態を設定して、既存のインシデントを削除することもできます  absentへのパラメータ 。
 
  ----ホスト：localhost collect_facts：falseタスク：-名前：インシデントの削除servicenow.itsm.incident：番号：INC0010022状態：不在 
 

 同じ方法で、問題を処理したり、要求を変更したりできます。ただし、構成アイテムの管理は少し異なるため、次にこの領域に焦点を当てましょう。
 
CMDBの更新
 

 ServiceNow CMDBには複数の構成アイテムタイプがあるため、 sys_class_nameを指定する必要があります 新しいアイテムを追加するときのパラメータ。デフォルトでは、 servicenow.itsm.configuration_item  モジュールはcmdb_ciを使用します システムクラス名。ただし、他のcmdb_ciから派生したに変更できます。 クラス。
 
  ---- name：CMDB管理ホストのデモンストレーション：localhost collect_facts：falseタスク：-name：VM作成のシミュレーションansible.builtin.set_fact：instance：name：some-name public：1.2 _ ip：vm1234 569 --name：新しく作成されたVMインスタンスを登録しますservicenow.itsm.configuration_item：name： "{{instance.name}}" sys_class_name：cmdb_ci_vm_instance ip_address： "{{instance.public_ip_address}}" id}} " 
 

 一般的なその他を使用しました 最後のタスクで任意のキーと値のペアを含めることができるパラメーター。 ServiceNowテーブルは拡張可能であるため、すべてのモジュールにこのパラメーターがあります。 その他を使用できます モジュールがトップレベルのパラメーターとして公開しない列値を設定するパラメーター。すべてのServiceNowAnsibleモジュールにこのパラメーターがあります。
 

 既存のアイテムを更新または削除する場合、モジュールは現在のレコードから名前を自動的に取得するため、システムクラス名を指定する必要はありません。ただし、 sys_idを提供する必要があります パラメータ値。
 
  ---- name：CMDBアイテムの更新と削除のデモンストレーションホスト：localhost collect_facts：falseタスク：-name：VMの状態を更新しますservicenow.itsm.configuration_item：sys_id：b0ccabf1c0a80009001f14fd151d8df0 CMDBからservicenow.itsm.configuration_item：sys_id：b0ccabf1c0a80009001f14fd151d8df0状態：不在 
 
動的在庫
 

 CMDBは、インベントリソースとしても機能します。サーバーと仮想マシン（VM）を表す構成アイテムには通常IPアドレスが含まれているため、それらをインベントリソースとして使用できます。
 

 インベントリプラグインの最小構成は次のようになります：
 
  --- plugin：servicenow.itsm.now  
 

 プラグインをインベントリソースとして使用すると、 cmdb_ci_serverのすべてのサーバーが一覧表示されます。 テーブル。  group_by で指定された条件に基づいて、インベントリホストを自動的にグループ化してフィルタリングできます 構成オプション：
 
  --- plugin：servicenow.itsm.nowgroup_by：os：includes：-Linux Red Hat --Windows XP  
 

 前の例では、Ansibleは2つのグループを作成しました。1つはWindows XP用で、もう1つはLinuxコンピューター用です。インベントリプラグインは、バックエンドで可能な限り多くのフィルタリングを実行し、ダウンロードされるデータの量を最小限に抑えます。
 

 インベントリプラグインがホスト変数として追加する列の値を構成することもできます：
 
  --- plugin：servicenow.itsm.nowcolumns：-name --classification --cpu_typegroup_by：os：includes：-Linux Red Hat --Windows XP  
 

 構成をテストするには、次のコマンドを実行します。
 
  $ ansible-inventory -i Inventory.now.yaml --graph --vars  
 

 インベントリ構成をinventory.now.yamlに保存したと仮定します ファイル。出力は次のようになります。
 
  @all：|-@ Linux_Red_Hat：| | --P1000019 | | |-{ansible_host =my1.server.com} | | |-{分類=本番}| | |-{cpu_type =Intel} | | |-{name =SAP-SD-01} |-@ Windows_XP：| | --P1000020 | | |-{ansible_host =my2.server.com} | | |-{分類=本番}| | |-{cpu_type =Intel} | | |-{name =SAP-SD-02} |-@ ungrouped： 
 

 個々のモジュールとインベントリプラグインの使用方法がわかったので、次はグランドフィナーレです。
 
標準の変更リクエストの自動解決
 

 標準の変更リクエストは、リスクを最小限に抑えた事前承認済みの手順であり、これらのプロパティにより、自動化の最有力候補になります。
 

 ですから、これ以上苦労することなく、次のようなプレイブックがあります。
 
     
  1. 変更リクエストを番号で検索します
    2. 
 
  2. 変更リクエストを処理中としてマークします
    3. 
 
  3. 影響を受ける構成アイテムを変更要求から取得します
    4. 
 
  4. 上記の構成アイテムに対して要求された操作を実行し、最後に
    5.  
  5. 変更リクエストを閉じます
    6. 
 
 
  ----ホスト：localhost collect_facts：falseタスク：-名前：変更リクエストを進行中としてマークするservicenow.itsm.change_request：番号： "{{change_number}}"状態：実装登録：変更-名前：更新する構成アイテムを取得しますservicenow.itsm.configuration_item_info：sys_id： "{{change.record.cmdb_ci}}" register：citem --name：アイテムを使用してメモリ内インベントリを作成しますansible_host： "{{citem.record.ip_address}}"-ホスト：host_to_updateタスク：-名前：いくつかの作業をシミュレートするansible.builtin.debug：msg：ここで実際の作業を行う-ホスト：localhost collect_facts：falseタスク：-名前：マーク完了したリクエストの変更servicenow.itsm.change_request：number： "{{change_number}}" state：closed  
 

 これだけの素晴らしさを1つのプレイブックに詰め込めると誰が思ったでしょうか。
 

   [システム自動化についてもっと知りたいですか？ RedHatの無料の本であるTheAutomatedEnterpriseを始めましょう。 ]   
 
未来は自動です
 

 私はかなり多くをカバーしましたが、それでも可能なことの表面を引っ掻くことができました。そこで、自動化ハブまたはAnsible Galaxyにアクセスし、ServiceNow ITSM Ansible Collectionをダウンロードして、探索を開始してください。この新しいソリューションの実際の動作は、このウェビナーでも確認できます。
 

 ServiceNowプロセスの自動化とRedHatAnsible Automation Platformとの統合についてサポートが必要な場合は、XLAB Steampunkのチームに連絡して、すぐに起動して実行できるようにしてください。
Linux

  1. release-botを使用したアップストリームリリースの自動化

  2. Red Hat Enterprise Linuxを登録し、Ansibleにサブスクリプションを添付します

  3. Linuxでリポジトリをミラーリングする方法

  1. Ansibleを使用してMicrosoftSQLServer2019をRedHatEnterpriseLinux8にデプロイする

  2. Ansibleで仕事中のスリルを一新

  3. Red Hat Linux とは?

  1. RedHatでApachehttpdを使用してSSL/TLSを設定する方法

  2. RedHatLinuxでのパッケージ依存関係の操作

  3. プロキシを使用する場合と使用しない場合のRedHatLinuxにリポジトリを追加する方法