https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/operation/opsi_vup/index.html Recent content in 5.3 Ops Iバージョンアップ対応 on JP1 Cloud Service 運用統合 利用ガイド Hugo -- gohugo.io ja https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/operation/opsi_vup/ticketcustom_incorporate/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/operation/opsi_vup/ticketcustom_incorporate/index.html Ops Iバージョンアップ時に、カスタムしたOps Iの機能を維持したまま、Ops Iバージョンアップにより追加された最新機能を取り込むために必要な作業を説明します。 ユーザーは、Ops Iからカスタム可能なYAML定義を編集し、Ops Iの機能をカスタムすることができます。カスタムが可能なYAMLファイルについては「初期YAMLファイルのカスタム」、チケット画面のカスタムについては「チケット画面のカスタム」を、ワークフロー画面のカスタムについては「ワークフロー画面のカスタム」を参照してください。 Ops Iのコードが格納されているGitLabには以下のブランチが準備されています。 mainブランチ：Ops Iがドキュメントとして認識するブランチ ユーザーがカスタムコードをコミットします。 opsi/releaseブランチ：Ops Iサービス側が提供する初期YAMLファイルが格納されるブランチ Ops Iのバージョンアップが反映されます。 また、Ops Iのバージョンアップ中に以下の作業ブランチが作成されます。 opsi/Ops Iの新バージョン-itsm チケット管理などITSMに関連する機能の基盤コードに追加・変更がある場合に作成されます。 opsi/Ops Iの新バージョン-common 上記以外の基盤コードの追加・変更がある場合に作成されます。 なお、Ops Iの新バージョンで追加された機能によっては、一部の作業ブランチは作成されないことがあります。 新バージョンで変更された基盤コードとユーザーがカスタムしたコード間で競合が発生していない場合、mainブランチに基盤コードがマージされたときに、作業ブランチが削除されます。 以下の流れでバージョンアップ時の対応をしてください。 （表）バージョンアップ時の流れ 作業時期 作業 作業者 バージョンアップ前 1. 新規デプロイ時に、デプロイ時のコミットからopsi/releaseブランチが作成されます。（バージョンアップ前のバージョンがv02-70以降の場合） Ops I提供者 2. mainブランチのコードをカスタムし、コミットします。 ユーザー バージョンアップ時 3. opsi/releaseブランチの基盤コードをバージョンアップします。 3-1. 作業ブランチを作成し、新バージョンで追加された基盤コードをコミットします。 3-2. 作業ブランチの変更内容をopsi/releaseブランチにマージします。 3-3. 過去のバージョンアップ時に作成された作業ブランチからmainブランチへの「Merge request」でマージされていないものがある場合、クローズします。 3-4. 作業ブランチからmainブランチに「Merge request」を作成し、マージを実行します。競合なし：マージが成功し、新バージョンの基盤コードがドキュメントとして認識され、作業は完了になります。 mainブランチにマージされたときに、作業ブランチが削除されます。 競合あり：マージは中断し、ユーザーに競合発生に関する通知が送信されます。 Ops I提供者 バージョンアップ後 4. 競合がある場合はユーザー自身で競合を解消し、マージを行います。 4-1. Ops I System Engineersグループに所属するユーザーは、Ops IのGUI通知機能でバージョンアップ時の競合発生に関する通知を受け取ります。 4-2. GitLabの「Ops I System Engineers」を開きます。 4-3. https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/operation/opsi_vup/ee_update/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/operation/opsi_vup/ee_update/index.html Ops IのAWXにはOpsI Automation EE（Ops IのSaaS基盤上での実行用）とOpsI Outpost EE（中継サーバーの実行用）が登録されています。また、カスタム実行環境のベースイメージがGitLabにデフォルトで登録されています。 OpsI Automation EEはOps Iのバージョンアップの際に、自動化アプリケーションから表示されるAWXの実行環境に新しいバージョンの実行環境が追加されます。 カスタム実行環境のサンプルプロジェクト"system/awx-ee"、およびそのプロジェクトに定義されたカスタム実行環境のベースイメージは、Ops Iのバージョンアップの際に更新されることがあります。 Ops Iリリース時に提供される、OpsI Automation EEとカスタム実行環境のベースイメージのバージョンは、リリースから3年間サポートされます。 （表）AWX実行環境のライフサイクル Ops I バージョン AWX実行環境 バージョン リリース日 サポート終了日 02-90 24.6.1 2026/4/30 2029/4/30 02-80 24.6.1 2025/10/31 2028/10/31 02-70 24.6.1 2025/4/30 2028/4/30 02-50 23.6.0 2024/10/31 2027/10/31 OpsI Outpost EEは、Ops Iと同じバージョンと次のバージョンがサポートされます。詳細は「（表）RPMパッケージインストール前提条件」のエージェントサポートポリシーを参照してください。 「AWX実行環境のバージョン確認」の手順で既存の実行環境がサポート期間内かどうかを確認し、必要な場合は「AWX実行環境のバージョンアップ時の対応」の手順で対応してください。 （1）AWX実行環境のバージョン確認 AWX実行環境のバージョン確認手順を以下に示します。 【OpsI Automation EE】 自動化アプリケーションから、コンテンツエリアに表示されたAWXの画面で「管理」カテゴリーの「実行環境」を選択します。 バージョンを確認したい実行環境の「イメージ」からバージョンを確認します。 レジストリ/dx-tool/dx-iac/quay.io/ansible/awx-ee:実行環境のバージョン 【OpsI Outpost EE】 OpsI Outpost EEの実行環境は、中継サーバーのRPMパッケージに同梱されたAWX実行環境のイメージを使用します。各Ops Iバージョンで提供されるAWX実行環境のバージョンのイメージが、そのOps Iバージョンの中継サーバーのRPMパッケージに同梱されます。OpsI Outpost EEの実行環境のバージョンを確認するには、中継サーバーのRPMパッケージが提供されたOps Iバージョンを確認し、「（表）AWX実行環境のライフサイクル」から、AWX実行環境のバージョンを確認してください。 【カスタム実行環境のベースイメージ】 カスタム実行環境についての詳細は「自動化実行環境の拡張」を参照してください。 自動化アプリケーションから、コンテンツエリアに表示されたAWXの画面で「管理」カテゴリーの「実行環境」を選択します。 バージョンを確認したい実行環境の「イメージ」からバージョンを確認します。