前回のあらすじ

みなさん、こんにちは。
Oracle Cloud Infrastructure検証チームです。
OCIのOS管理ハブを利用してパッケージ・パッチの管理をしてみよう(1/2)の続きとなりますがご覧いただけたでしょうか。

前回は OS管理ハブの基本設定(ポリシーの作成、ソフトウェア・ソースの作成、プロファイルの作成) インスタンスの登録 実施しました。
今回は作成したOS管理ハブを利用してOSパッケージの更新をしていきたいと思います。

それでは実際に更新していきましょう!

検証のサマリー

今回の検証内容で実施する順番は以下となります。全2回に分けて掲載予定です。

  1. ポリシーの作成(前回)
  2. ソフトウェア・ソースの作成(前回)
  3. プロファイルの作成(前回)
  4. インスタンスの登録(前回)
  5. OSパッケージの更新

OSパッケージの更新

今回の検証では以下のような流れで更新していきます。
なお、「2.」と「3.」の間で前回で事前に作成したインスタンス(os-management)と同じインスタンス(os-management2)を作成・追加登録しております。

  1. コンパートメント全体での更新1回目(セキュリティのみ)
  2. 対象インスタンスでの更新(バグのみ)
  3. コンパートメント全体での更新2回目(拡張のみ)

上記でセキュリティ・バグ・拡張の3つがありますが、こちらはLinuxのRPMパッケージをそれぞれの種別で分けられています。
Oracleで例えるとリリース更新(RU)およびリリース更新リビジョン(RUR)や個別パッチで分けられているイメージを持っていただければ大丈夫です。

今回の検証では、ジョブ作成で更新するとコンパートメント全体でパッケージ更新が行われてしまいますが、グループを作成することで更新するインスタンスを選ぶことができます。
「2.」のように必要なインスタンスを1つずつ実施しないといけない。といったことにはなりませんのでご安心ください。

※今回の検証ではパッケージ更新後のOS再起動は省略しています。OS再起動しないと脆弱性が更新されないものもあるため、ご注意ください。

コンパートメント全体での更新1回目(セキュリティのみ)

更新前の状況を確認してみると全体で62件あり、そのうちセキュリティが30件更新できるものがあると確認できます。
※確認方法は前回紹介していますので省略します。

セキュリティのみ更新をするため、左側のFiltersから[セキュリティ]にします。
30件すべてを確認するのは時間がかかるため、今回は「expat」というパッケージに焦点を当てて実機でも確認していきます。

実機で確認すると「Installed version」と一致していることが確認できます。

更新前の確認ができましたので、実際に更新していきます。
OS管理ハブの画面から左側の[ジョブ][Create update job] をクリックします。

ジョブの作成画面が出てきますので、[ジョブ名]に任意の名前と[説明]に任意の説明を入力します。
検証では以下を入力します。
ジョブ名:セキュリティ更新
説明:os-managementインスタンスのセキュリティを更新

[Updates to apply]「Security」 をチェックします。配下のもの(Ksplice~~)はチェックが自動で付きます。
[スケジュール]「即時実行」をチェックします。
最後に [作成] をクリックします。

作成したジョブが [Completed jobs]「Successful」になるまで待ちます。
Nameをクリックしていくことでジョブの詳細を確認することも可能です。

・ジョブ実行時のログメッセージ抜粋

This system is receiving updates from OSMH.
os-management 1.6 kB/s | 2.0 kB 00:01
Dependencies resolved.
===========================================================================================================================
Package Arch Version Repository Size
===========================================================================================================================
Installing:
kernel x86_64 4.18.0-553.22.1.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 10 M
kernel-core x86_64 4.18.0-553.22.1.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 43 M
kernel-devel x86_64 4.18.0-553.22.1.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 24 M
kernel-modules x86_64 4.18.0-553.22.1.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 36 M
Upgrading:
emacs-filesystem noarch 1:26.1-12.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 69 k
~<中略>~
expat x86_64 2.2.5-15.0.1.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 113 k
iwl100-firmware noarch 999:39.31.5.1-999.35.el8 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 166 k
iwl1000-firmware noarch 999:39.31.5.1-999.35.el8 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 166 k
kernel-tools-libs x86_64 4.18.0-553.22.1.el8_10 custom.os-ma.1247ade0-930a-468f-94f1-8d02d66809b4 10 M
~<中略>~
Upgraded:
emacs-filesystem-1:26.1-12.el8_10.noarch
expat-2.2.5-15.0.1.el8_10.x86_64
iwl100-firmware-999:39.31.5.1-999.35.el8.noarch
c
kernel-core-4.18.0-553.22.1.el8_10.x86_64
kernel-devel-4.18.0-553.22.1.el8_10.x86_64
kernel-modules-4.18.0-553.22.1.el8_10.x86_64

Complete!

更新後の状況を確認すると、セキュリティの30件が無くなっているのが確認できます。

左側のFiltersを [セキュリティ] にすると、「アイテムが見つかりませんでした。」と1件もないことが確認できます。

実機で確認すると更新前に表記のあった「Avaliable version」と一致していることが確認できます。

対象インスタンスでの更新(バグのみ)

更新前の確認すると、「コンパートメント全体での更新1回目(セキュリティのみ)」の続きとなるため、31件のバグと1件の拡張が残っている状態です。
ここでは、31件のバグをインスタンスから更新していきます。

OS管理ハブの画面から [インスタンス][<対象のインスタンス>] をクリックします。

インスタンスの詳細画面から [Create update job] をクリックします。

ジョブの作成画面が出てきますので、[ジョブ名] に任意の名前と [説明] に任意の説明を入力します。
検証では以下を入力します。
ジョブ名:バグ更新
説明:os-managementインスタンスのセキュリティを更新

[Updates to apply]「Bug fix」をチェックします。
[スケジュール]「即時実行」をチェックします。
最後に [作成] をクリックします。

作成したジョブが [Completed jobs]「Successful」になるまで待ちます。

更新後の状況を確認すると、バグの31件が無くなっているのが確認できます。

このようにインスタンスの詳細から適用することもできます。
「このインスタンスはまだ適用したくないなぁ・・。」といった状況にも問題なく対応することができます。

コンパートメント全体での更新2回目(拡張のみ)

前述通り、ここで前回で事前に作成したインスタンス(os-management)と同じインスタンス(os-management2)を作成・追加登録しています。

プロファイルにソフトウェア・ソースを紐づけているので、ソフトウェア・ソースを見ると2つのインスタンスがあることが確認できます。

更新前の確認を行い、os-management拡張1件os-management2セキュリティ30件・バグ31件・拡張1件となっているのが確認できます。

更新前の確認ができましたので、実際に更新していきます。
OS管理ハブの画面から左側の [ジョブ][Create update job] をクリックします。

ジョブの作成画面が出てきますので、[ジョブ名] に任意の名前と [説明] に任意の説明を入力します。
検証では以下を入力します。
Name:microcode拡張

[Updates to apply]「Enhancement」をチェックし、[スケジュール]「即時実行」をチェックします。
最後に [作成] をクリックします。

作成したジョブが [Completed jobs]「Successful」になるまで待ちます。

更新後の確認を行うと、os-management0件になりos-management2セキュリティ30件・バグ31件と拡張が適用されているのが確認できました。

無事1つのジョブからすべてのインスタンスに適用できることが確認できました。

さいごに

OCIの管理ハブでパッケージの管理・更新を検証してみましたが、いかがでしたでしょうか?
今回の検証ではインスタンス数は多くないので必要性は実感できないかもしれません。
管理したいパッケージやインスタンスが新しく増えたときにOS管理ハブを設定しておくと、インスタンスを登録するだけになりますので運用面でコスト削減に大きく貢献できる機能となっています。

OS管理が2025年4月23日にサービス終了となりますので、この機会にOS管理ハブ の利用もご検討下さい。

お問い合わせはこちらから

投稿者プロフィール

技術チーム
技術チーム
DBひとりでできるもんを盛り上げるべく、技術チームが立ち上がり早6年。ひとりでできるもんと言いつつ、技術者が読んでプッとなるような、極めてピンポイントでマニアックな技術ネタを執筆しています!