Intelligent Platform Management Interface (IPMI) Host を VMDB に追加するには、Red Hat CloudForms の検出プロセスを使用する方法と、IP アドレスと認証情報を使用してホストを追加する方法の 2 つ選択肢があります。

オペレーティングシステムの初期ロードのためのキックスタートファイルを提供するためのカスタマイズテンプレートを追加します。Red Hat CloudForms によって提供されるプロビジョニングダイアログとの対話を許可するのに使用する特定のセクションがあります。

Provisioning Profiles を使用して、カスタマイズ設定が記載された特定のファイルを指定することができます。そのためには、Red Hat CloudForms の Applications/provisioning/profile/VM provisioning by group クラス内に、このファイルにマッピングするインスタンスを作成する必要があります。デフォルトでは、プロビジョニングプロファイルを使用する場合、そのグループに定義されたインスタンスがなければ、選択したプロビジョニングタイプに基づいて適切なデフォルトのダイアログが使用されます。

適切な Red Hat CloudForms Applications/provisioning/profile instance のダイアログ名のフィールドに、新規ダイアログ名を入力します。このダイアログは、プロビジョニングプロファイルクラスのインスタンスで参照できるようなり、複数のユーザーグループで使用できるようになりました。

一部の非デフォルトの配置メソッド (例: redhat_best_placement_with_scope または vmware_best_fit_with_scope メソッド) では、ホストとデータストアに プロビジョニングスコープ タグを設定する必要がある場合があります。

全グループに対してこれらのリソースを有効化するには、スコープを All に設定します。選択したグループのみにアクセスを制限するには、プロビジョニングスコープ カテゴリーでユーザーグループ名と全く同じ名前でタグを作成して、そのタグを対象のリソースに対して設定します。タグの作成についての説明は、『設定全般』の「タグ」のセクションを参照してください。

ホストにスコープを設定するには、以下のステップを実行します。

データストアのスコープを設定するには、以下のステップを実行します。

デフォルトの承認値のグローバルセットを有効にするには、自動化 → エクスプローラー をクリックしてから、アコーディオンメニューで DOMAIN → Cloud|Infrastructure → VM → Provisioning → StateMachines → ProvisionRequestApproval に移動し、デフォルトのインスタンスを編集します。このインスタンス内のパラメーターは、同じクラス内のメソッドで使用されます。デフォルトでは、プロビジョニングで自動承認できる仮想マシン/インスタンスの最大数は 1 となっています。仮想マシンの最大数をチェックしないようにするには、このフィールドを 0 に設定します。また、手動の承認を強制するには、このフィールドを -1 に設定します。すべてのパラメーターが検証されるようにするには、少なくともこのパラメーターを変更する必要があります。

自動承認のための閾値が設定されました。次回にプロビジョニング要求を作成すると、これらの閾値がチェックされ、要件を満たしている場合には、プロビジョニング要求はユーザーの介入なしに承認されます。

Red Hat CloudForms は、テンプレートまたはイメージ毎にデフォルトの自動承認値を設定するのに使用可能なタグを提供しています。これらの値は、自動化 モデルの値に優先します。これらのタグを使用すると、全プロビジョニング要求を手動で承認する必要がなくなります。自動承認を有効化するには、タグをテンプレートまたはイメージに直接割り当ててください。

特定のテンプレートの自動承認のための閾値が設定されました。次回にこのテンプレートのプロビジョニング要求を作成すると、これらの閾値がチェックされ、要件を満たしている場合には、プロビジョニング要求はユーザーの介入なしに承認されます。

Red Hat CloudForms には、プロビジョニング用の自動化インスタンスのセットが含まれています。これらの自動化インスタンスには、要求などのプロビジョニングの通知の送信者と受信者を設定するメールのフィールドも含まれています。これらのフィールドは、デフォルトでは evmadmin@company.com に設定されます。

Red Hat CloudForms は、仮想マシン/インスタンスの所有者のクォータを適用するためのタグを提供しています。仮想マシン/インスタンスの所有権はプロビジョニングプロセス中か、Configuration Set Ownership ボタンを使用して設定することができます。仮想マシン/インスタンスに所有者が設定されている場合には、仮想マシン/インスタンスの概要ページの ライフサイクル のセクションに値が表示されます。

クォータタグは、設定項目に対してではなく、グループまたは所有者のいずれかに直接割り当てることができます。以下の表にはクォータに使用するタグをまとめています。

自動化のステートマシンは、順序指定された一覧を処理します。これにより、1 つのステップが正常に完了してから次のステップが実行されるようにし、ステップの再試行を許可し、状態の再試行を終了するまでの最大時間を設定することができます。各状態が実行される前には、On_Entry メソッドが実行され、状態が終了すると、その終了した状態によって On_Exit または On_Error メソッドが実行されます。

Red Hat CloudForms Automate のステートマシンは、以下のコンポーネントで構成されます。

以下の図には、これらのコンポーネントを組み合わせてステートマシンのワークフローを作成する方法を示しています。

ステートマシンの再試行ロジックを示すコードスニペット:

# Get current provisioning status
task = $evm.root['service_template_provision_task']
task_status = task['status']
result = task.status

Then check the result to see how it should proceed:

case result
when 'error'
  $evm.root['ae_result'] = 'error'
.....
when 'retry'
  $evm.root['ae_result'] = 'retry'
  $evm.root['ae_retry_interval'] = '1.minute'
when 'ok'
  $evm.root['ae_result'] = 'ok'
end

When the result is "retry", it sets:
  $evm.root['ae_result'] = 'retry'
  $evm.root['ae_retry_interval'] = '1.minute'

以下の図は、プロビジョニング要求の承認に関する単純なステートマシンを示しています。このインスタンスは、Datastore → ManageIQ → Infrastructure → VM → Provisioning → StateMachines → ProvisioningRequestApproval → Default に移動すると表示することができます。

仮想マシンまたはクラウドインスタンスのプロビジョニング時に従うステップは、DOMAIN → Cloud|Infrastructure → VM → Provisioning → StateMachines → VMProvision_VM クラスのインスタンスに基づいています。環境に応じて、プロビジョニングプロセスのステップを削除、変更、追加することができます。たとえば、IPAM または CMDB と統合していない場合には、それらの実行ステップを削除することができます。

要求が承認された後には、フルフィルメントのさまざまな段階が実行されます。プロビジョニング要求プロセスの進捗状況はステータスを表示して確認することができます。

プロビジョニング要求によって仮想マシンまたはインスタンスが作成されると、ライフサイクルe のセクションにプロビジョニングの完了時にサマリーの画面にその概要が表示されます。

サービス → ワークロード に移動して、表示する仮想マシンをクリックします。

Ansible プレイブックを使用してバックアップするカタログ項目の作成

Red Hat CloudForms で Ansible Tower プレイブックを実行するために使用可能な Ansible Tower テンプレートからサービスカタログ項目を作成します。

最初にカタログを作成します。

次に Ansible Tower サービスカタログ項目を作成します。

インポート/エクスポート機能を使用すると、複数のアプライアンス間でサービスダイアログを共有することができます。

インポート/エクスポート機能を使用すると、複数のアプライアンス間でサービスダイアログを共有することができます。

ダイアログの値をプロビジョニング要求に結びつけるためのメソッドを作成する必要があります。メソッドは、Automate モデルの DOMAIN/Service/Provisioning/StateMachines/ServiceProvision_Template クラスに作成する必要があります。

その下に提供されるメソッドは、以下のシナリオで作成されています。

#            Automate Method
#
$evm.log("info", "Automate Method ConfigureChildDialog Started")
#
#            Method Code Goes here
#
$evm.log("info", "===========================================")
$evm.log("info", "Listing ROOT Attributes:")
$evm.root.attributes.sort.each { |k, v| $evm.log("info", "\t#{k}: #{v}")}
$evm.log("info", "===========================================")

stp_task = $evm.root["service_template_provision_task"]
$evm.log("info", "===========================================")
$evm.log("info", "Listing task Attributes:")
stp_task.attributes.sort.each { |k, v| $evm.log("info", "\t#{k}: #{v}")}
$evm.log("info", "===========================================")

#############################################################
#### This is how the method would look for dialog variables
#############################################################
dialog_service_type = $evm.root['dialog_service_type']
$evm.log("info","User selected Dialog option = [#{dialog_service_type}]")

stp_miq_request_task = stp_task.miq_request_task
#$evm.log("info","(parent) miq_request_task:  = [#{stp_miq_request_task}]")

#############################################################
#### This is how you get the catalog items for the catalog bundle
#############################################################

stp_miq_request_tasks = stp_task.miq_request_tasks
#$evm.log("info","(children) miq_request_tasks count:  = [#{stp_miq_request_tasks.count}]")

#############################################################
#### By going through the children, you can set the dialog variable for each of the children (we based our values on the childrens service tags)
#############################################################

stp_miq_request_tasks.each do |t|

  $evm.log("info"," Setting dialog for: #{t.description}")
  service = t.source
  service_resource = t.service_resource
  #$evm.log("info"," Child service resource name: #{service_resource.resource_name}")
  #$evm.log("info"," Child service resource description: #{service_resource.resource_description}")

  service_tag_array = service.tags(:app_tier)
  service_tag = service_tag_array.first.to_s

  memory_size = nil

#############################################################
#### The dialog_service_type is the attribute set on the service dialog
#### We use the service_tag to decide what child gets what dialog
#############################################################

  case dialog_service_type
  when "Small"
    case service_tag
    when "app"
      memory_size = 1024
    when "web"
      memory_size = 1024
    when "db"
      memory_size = 4096
    else
      $evm.log("info","Unknown Dialog type")
    end
  when "Large"
    case service_tag
    when "app"
      memory_size = 4096
    when "web"
      memory_size = 4096
    when "db"
      memory_size = 8192
    else
      $evm.log("info","Unknown Dialog type")
    end
  else
    $evm.log("info","Unknown Dialog type - setting Dialog options here")
  end

#############################################################
#### set_dialog_option sets the dialog for the child
#############################################################

  t.set_dialog_option('memory',memory_size) unless memory_size.nil?
  $evm.log("info","Set dialog for selection: [#{dialog_service_type}]  Service_Tier: [#{service_tag}] Memory size: [#{memory_size}]")

end
#
#
#
$evm.log("info", "Automate Method ConfigureChildDialog Ended")
exit MIQ_OK

サービスメソッドは、目的別に分割されています。

インスタンスが作成され、ServiceProvision クラスから呼び出せるようになります。

サービスメソッドは、目的別に分割されています。

これでカタログ項目、サービスダイアログ、ダイアログメソッド、サービスプロビジョニングインスタンスが作成されたので、カタログ一式を作成することができます。

パラメーターは、ダイアログ内での選択項目に関連付けられたメソッドに基づいて、子に渡されます。