2024/04/25 OS Managementは2025年4月までにEOL（End of Life）になることが発表されました。後継サービスはOS Management Hubです。
2023/04/19 現在は数多くリージョンサポートし、Autonomous LinuxなどOSサポートも増えている。OS Management Serviceのアップデート情報はこちら
2020/02/11 東京リージョン対応
2019/12にOS Management Serviceの記事を書いたが、マニュアルの記述が不足していたこともあり、設定が完了しなかった。その後マニュアルが大幅に拡充されたのと、当初の記事は実験的な操作も含まれていたため、新たに加筆修正して書くことにした。
1. OS Management Serviceがリリース！
OS Management Serviceがリリースされた。OOW 2019やOracle Linux on Oracle Cloud Infrastructureブログで事前に紹介されていた機能だ。
- 2019/12/17 OS Management Service Released
ただし現時点（2020/02）では2つの注意点がある。
1点目：提供しているのは以下のリージョンに限られる。2020/02/11に東京リージョンとソウルリージョン対応し、現在はほとんどのリージョンで利用可能。
2点目：サービスの対象はOracle Linux 6 / 7 / 8で、Oracle Autonomous Linuxは含まれていない。以下のブログではOracle Autonomous Linuxも対象にしているように思えるが、少なくとも現時点は対象外である。
This service is included by default with Oracle Autonomous Linux images provided by Oracle Cloud Infrastructure, and you don’t need to install any special software to enable OS Management Service.
当初はOracle Autonomous Linuxを対象としていると思い、次のような始まりで書いてしまった。ちぇっ！
Linux好きの筆者にとって興味のあった**Oracle Autonomous Linux**。世界で一番早く一番詳しい記事を書いた、と勝手に思っている。
そして、ついに待望のOS Management Serviceがリリースされた。
2021/01/06追記：以下のWindowsにも対応
- Windows Server 2012 R2 Standard, Datacenter
- Windows Server 2016 Standard, Datacenter
- Windows Server 2019 Standard, Datacenter
2. マニュアルを眺める
マニュアル「Overview of OS Management」をサクッと眺めてみよう。
The Oracle Cloud Infrastructure OS Management service provides tools for common operating system management tasks for Compute instances, focusing initially on managing software packages for Oracle Linux instances.
OS Management Serviceは、Computeインスタンスのオペレーティング・システム管理ツールで、最初はLinuxインスタンスのパッケージ管理機能を提供する。
気になるところをピックアップすると以下のとおり。
- OS Management ServiceでComputeインスタンスを管理するには、OS Management Agentのインストールが必要
- OS Management Serviceを有効にすると、Computeインスタンスに対してパッケージの参照／追加／更新／削除できる
- OS Management Serviceに登録したComputeインスタンスは、個別もしくはグループ化してパッチ管理できる
- Computeインスタンスのパッケージ管理は、ジョブとして即時実行やスケジュール実行（1回、定期間隔）ができる
- 対象のオペレーティングシステムは Oracle Linux 6 / 7 / 8
- OS Management Serviceに登録したComputeインスタンスは、既存のYumリポジトリ設定が無効化される
- OS Management Serviceに登録したComputeインスタンスは、ルート・コンパートメントに配置された「ソフトウェア・ソース」というYumリポジトリ情報を参照する
- テナントで最初にOS Management Serviceを利用するときは、Computeインスタンスが登録されるまで60分から90分かかる
ここで重要なことの一つは**「対象オペレーティングシステムはOracle Linux 6 / 7 / 8」**ということだ。Oracle Autonomous Linuxは含まれていない。
冷静に考えると両者のポリシーは正反対だ。
- Oracle Autonomous Linux: 毎日自動的にパッチを適用。管理者はパッチ管理に関与しない。
- OS Management Service: 管理者がパッチ適用を管理。手動もしくは自動（事前スケジュール）で複数インスタンスに対して効率的に実施。
将来はOracle Autonomous Linuxもサポートされるかもしれないが、管理ポリシーが異なるので、現時点で対象にする必要性は低い。
3. OS Management Serviceのアーキテクチャ
実際に設定する前に、OS Management Serviceの仕組みや、主要コンポーネントを説明する。下図は、マニュアルの記述や実際の調査から推測したアーキテクチャ図である。
- OS Management Service
- OS Managementの機能を提供する主体。管理下のインスタンス情報を提供するだけでなく、インスタンスに対してパッケージのインストールやアップデートを行う。Oracle Enterprise ManagerにおけるOMS+リポジトリDBに相当
- OS Management Agent
- 管理下のインスタンスで稼働するエージェント（osms-agent）。インスタンス作成後にインストールする
- マネージド・インスタンス（Managed Instance）
- OS Managementに登録したComputeインスタンス。osms-agentが稼働し、OS Management Serviceを通じてさまざまな操作ができる。また登録したインスタンスのリポジトリ情報（/etc/yum.repos.d/*repo）は無効化される
- ソフトウェア・ソース（Software Sources）
- サーバー側で集中管理されたYumリポジトリ情報。デフォルトのソフトウェア・ソースは自テナントのRootコンパートメントにあるが、実体は管理情報DB内に格納されたYumリポジトリ情報（repoファイル相当）
- Oracle Linux Yum Repository
- Oracle LinuxのYumリポジトリには、どこからでもアクセス可能な「Public Yumリポジトリ」と、OCIからだけアクセスできる「OCIリージョンごとに用意されたYumリポジトリ」がある
これらのなかでソフトウェア・ソースはとくに分かりづらい。しかし現時点では「サーバー側でYumリポジトリ情報を集中管理して提供しているもの」程度の理解で問題ない。それなりに複雑なので、マニュアルを読み込み、実際に操作しないとわからないかもしれない。
4. OS Management Serviceのセットアップ
OS Management Serviceのセットアップ方法を説明する。おもな作業は「権限の付与」と「エージェントのインストール」だ。これだけ設定すれば、最低限の機能は利用できるようになる。
愚痴モード。初期バージョンの公式マニュアルは出来が悪く、設定に必要な最低限の情報にも抜け漏れがあった。改訂されて充実したけれど、それでも難解。ストレスかかる！
4-1. OS Management Service利用の前提条件
OS Managementを利用するには以下の条件を満たす必要がある。
- OS Management Serviceの対象リージョンであること
- Computeインスタンス作成時に**「Oracle Cloud Agentを使用してインスタンスを管理」**を有効にしていること
- プライベート・サブネットではService GatewayもしくはNAT Gatewayを利用できること
- パブリック・サブネットではInternet Gatewayを利用できること
- 対象オペレーティングシステムはOracle Linux 6 / 7 / 8
4-2. セットアップ手順
OS Managementのセットアップ手順は以下のとおり。OS Management管理者に対してポリシー（権限）を与えるだけでなく、マネージド・インスタンスがOS Managementを利用できるようにインスタンス・プリンシパルを構成する必要がある。
1. OS Management管理者へのポリシー設定
- コンソールやCLI、RESTでOS Managementを操作するユーザーにポリシーを割り当て
2. インスタンス・プリンシパルのセットアップ
- ダイナミック・グループの作成
- ダイナミック・グループにポリシー割り当て
3. 管理対象のインスタンスにOS Management Agentをインストール
- 現在のLinuxイメージではデフォルトインストール済み
以上で最低限の作業は終了だ。初回登録時は、3を実行したあと60分から90分過ぎると利用できるようになる。
4-3. 初期状態の確認
設定前の状態を確認する。管理コンソールにログインして、インスタンス詳細を表示する。左下の**[OS Management]をクリックすると次のように表示される。東京リージョンなど非対応のリージョンでは[OS Management]**メニューが表示されない。
また前提条件で説明したように、インスタンス作成時に**[Oracle Cloud Agentを使用してインスタンスを管理（Use Oracle Cloud Agent to mange this instance）]**が有効にしている必要がある。新規インスタンスではデフォルトで有効になっているので、新しくインスタンスを作成した方がよいだろう。
このオプションは、インスタンス作成ページで**[拡張オプションの表示（Show Advanced Options）]**をクリックすると表示される。
4-4. OS Management管理者へのポリシー設定
コンソールやCLI、RESTでOS Managementを操作するユーザーにポリシーを割り当てる。ユーザーには直接割り当てられないので、ユーザーが属するグループを指定する。
- 管理コンソールから**[Identity]-[Policies]**を選択する。
- 以下の内容でポリシーを作成する。
| 項目 | 値 |
|---|---|
| NAME | OsmsAdmin_policy |
| DESCRIPTION | for OS Management Admin Group |
| Policy Statements | ALLOW group ＜グループ名＞ to manage osms-family in compartment ＜コンパートメント名＞ |
ALLOW group ＜グループ名＞ to manage osms-family in compartment ＜コンパートメント名＞
自分が作成したインスタンスならば問題ないが、管理対象とするインスタンスに対してREAD権限が必要になる。
4-5. インスタンス・プリンシパルのセットアップ
OS Management Serviceでは、管理コンソールからの制御だけでなく、マネージド・インスタンスからの逆方向の制御も必要になる。そのためダイナミック・グループとポリシーを作成し、インスタンス・プリンシパルを構成する。
4-5-1. ダイナミック・グループの作成
- 管理コンソールから**[Identity]-[Dynamic Groups]**を選択する。
- 以下の内容でダイナミック・グループを作成する。
| 項目 | 値 |
|---|---|
| NAME | OsmsManagedInstance_dgrp |
| DESCRIPTION | for OS Management Service |
| Matching Rules | ANY {instance.compartment.id = '＜コンパートメントID＞'} |
ANY {instance.compartment.id = 'ocidv1:compartment:oc1:phx:samplecompartmentocid6q6igvfauxmima74jv', instance.compartment.id = 'ocidv1:compartment:oc1:phx:samplecompartmentocidythksk89ekslsoelu2'}
4-5-2. ポリシーの割り当て
- 管理コンソールから**[Identity]-[Policies]**を選択する。
- 以下の内容でポリシーを作成する。
| 項目 | 値 |
|---|---|
| NAME | OsmsInstancePrincipal_policy |
| DESCRIPTION | for OS Management Service |
| Policy Statements1 | Allow dynamic-group ＜dynamic group name＞ to use osms-managed-instances in tenancy |
| Policy Statements2 | ALLOW dynamic-group ＜dynamic group name＞ to read instance-family in tenancy |
| Policy Statements3 | ALLOW service osms to read instances in tenancy |
Allow dynamic-group OsmsManagedInstance_dgrp to use osms-managed-instances in tenancy
ALLOW dynamic-group OsmsManagedInstance_dgrp to read instance-family in tenancy
ALLOW service osms to read instances in tenancy
4-6. OS Management Agentのインストール
現在のOracle LinuxイメージではAgentはインストール済みである。次のように表示されればエージェントはインストールされている。
$ ps -elf | grep osms | grep -v grep
4 S root 8711 8517 0 80 0 - 62265 - 2020 ? 00:00:00 /usr/bin/sudo -n /usr/libexec/oracle-cloud-agent/plugins/osms/osms-agent
4 S root 8727 8711 0 80 0 - 2163 - 2020 ? 00:00:00 /usr/libexec/oracle-cloud-agent/plugins/osms/osms-agent
4 S root 8730 8727 0 80 0 - 365347 - 2020 ? 00:05:48 /usr/libexec/oracle-cloud-agent/plugins/osms/osms-agent
エージェントがインストールされていないときは、マニュアルを参照のこと。
4-7. OS Management Serviceへの登録確認
初回セットアップには時間がかかるので、念のため2時間以上放置する。設定が完了すると管理コンソールの表示が次のように変わる。
初回セットアップ終了後の2台目以降は、すぐに登録が完了する。
トラブル時の対応
もし2時間以上たっても画面が変わらず、以下のファイルにエラーが数分おきに出続けているようであればPostfixを起動してみよう。そして2時間放置する。
/var/log/messages
/var/log/oracle-cloud-agent/plugins/osms/agent.log
/var/log/oracle-cloud-agent/plugins/osms/osms.log
# systemctl start postfix
筆者は同時にいろいろなことをしたため、根本原因を突き止めていないのだが．．．。 Please teach me.
5. 設定後の状態を確認
設定が終わったら、管理コンソールとマネージド・インスタンスの内部を見てみよう。
5-1. 管理コンソールの確認
-
Computeインスタンスの詳細を表示する。
-
右の**「・・・」**をクリックするとポップアップが表示される。「View OS Management Details」「Install Security Updates」「Install All Upadates」という3つのメニューがある。
-
**「View OS Management Details」**をクリックすると次のページが表示される。
-
次に管理コンソールのメニューから**[Compute]-[OS Management]を選択する。ここでは[Software Sources]**を表示している。ここに表示されているのは一部で、複数ページにわたっている。
-
次の画面はインスタンス・グループを作成し、2つのインスタンスをメンバーにしたときのものだ。グループ化することで、複数インスタンスに対して同時にアップデートを指示できる。
注意
同じインスタンス・グループのメンバーにできるのは、同一バージョン、同一種類のオペレーティングシステムに限られる。
5-2. マネージド・インスタンスの確認
インスタンスにsshでログインしてrepoファイルまわりを確認する。
osms-agentをインストールし、OS Management Serviceの構成が終了すると、次のようにすべてのrepoファイルがリネームされる。
$ ls /etc/yum.repos.d/
ksplice-ol7.repo.osms-backup oracle-linux-ol7.repo.osms-backup
ksplice-uptrack.repo.osms-backup oracle-softwarecollection-ol7.repo.osms-backup
oci-included-ol7.repo.osms-backup uek-ol7.repo.osms-backup
oracle-epel-ol7.repo.osms-backup virt-ol7.repo.osms-backup
oraclelinux-developer-ol7.repo.osms-backup
yumコマンドは/etc/yum.repos.d/*.repoファイルを読むため、これでyumが使えるのか不安になる。しかし、リポジトリを確認すると利用できることがわかる（初回はメタデータ同期に時間がかかる）。
# yum repolist enabled
Loaded plugins: langpacks, osmsplugin, ulninfo
This system is receiving updates from OSMS. ★OSMSになっているのがポイント★
repo id repo name status
ol7_addons-x86_64 Oracle Linux 7Server Add ons (x86_64) 245
ol7_developer-x86_64 Oracle Linux 7Server Development Packages 650
ol7_developer_epel-x86_64 Oracle Linux 7Server Development Packages 20,231
ol7_ksplice-x86_64 Ksplice for Oracle Linux 7 (x86_64) 6,749
ol7_latest-x86_64 Oracle Linux 7Server Latest (x86_64) 12,370
ol7_oci_included-x86_64 Oracle Software for OCI users on Oracle L 117
ol7_optional_latest-x86_64 Oracle Linux 7Server Optional Latest (x86 9,710
ol7_software_collections-x86_64 Software Collection Library release 3.0 p 9,983
ol7_uekr5-x86_64 Latest Unbreakable Enterprise Kernel Rele 195
repolist: 60,250
何でだろうと思い調べてみると、osms-agentに怪しいファイルを発見。
# rpm -qf /usr/share/yum-plugins/osmsplugin.py
osms-agent-0.0.1-444.el7.x86_64
なんと1行目はRed HatのCopyright。そのあとのコードを見ると、Yumコマンドをフックし、リモートのリポジトリ（OSMS channels）を参照しているのだ。リモートのリポジトリとは、OS Managementの**「ソフトウェア・ソース」**のことだ。
# Copyright (c) 1999-2016 Red Hat, Inc. Distributed under GPLv2.
★中略
def init_hook(conduit):
"""
Plugin initialization hook. We setup the Spacewlk channels here.
We get a list of OSMS channels from the server, then make a repo obj
each one. This list of repos is then added to yum's list of repos vi
conduit.
"""
global rhn_enabled, external_proxy_dict
conduit_conf = conduit.getConf()
timeout = conduit.confFloat('main', 'timeout', conduit_conf.timeout)
Red HatのCopyrightになっている理由は**Red Hat Satellite/Spacewalk**のコードを利用しているから。
次にnetstatで調べてみると、osms-agentがセッションを張っている。169.254.169.254はOCIの内部ネットワークで、129.146.12.149はPhoenixリージョンのOracle Service Networkが使用しているグローバルIPだ。
# netstat -anp | grep osms
tcp 0 0 127.0.0.1:9003 0.0.0.0:* LISTEN 2173/osms-agent
tcp 1 0 10.0.2.23:54778 169.254.169.254:80 CLOSE_WAIT 2173/osms-agent
tcp 32 0 10.0.2.23:39368 129.146.12.149:443 CLOSE_WAIT 2173/osms-agent
tcp 1 0 10.0.2.23:54776 169.254.169.254:80 CLOSE_WAIT 2173/osms-agent
unix 2 [ ACC ] STREAM LISTENING 26635 2173/osms-agent ///var/lib/osms-agent/osms-agent.sock
unix 3 [ ] STREAM CONNECTED 25321 2166/osms-agent
5-3. 登録の解除方法
登録解除に関するマニュアルの記述は日々進化しているようだ。最新情報はマニュアルを参照のこと。
- osms-agentを停止して無効化する。
# systemctl stop osms-agent
# systemctl disable osms-agent
2.可能であればインスタンス／グループから除外する。
3.次のコマンドを実行し、repoファイルの定義を元に戻す。
# osms unregister
# yum clean all
4.repoファイルの拡張子が元に戻っていることを確認する。
# ls /etc/yum.repos.d/
ksplice-ol7.repo oracle-epel-ol7.repo oracle-softwarecollection-ol7.repo
ksplice-uptrack.repo oraclelinux-developer-ol7.repo uek-ol7.repo
oci-included-ol7.repo oracle-linux-ol7.repo virt-ol7.repo
6. まとめ
すべての機能を使っているわけではないが、推測を含めて書いてみる。
- OS Management ServiceはOracle Linux 6 / 7 / 8とWindows Serverを対象としたサービス。Oracle Autonomous Linuxは対象外
- 複数のサーバー群をまとめたパッケージ管理ができる
- OS Management Serviceは、Red Hat Satelliteや、そのクローンであるSpacewalkのようなパッケージ管理ツールのマネージド・サービス版
実際に操作するとわかるが、OS Management Serviceの設定／運用はマニュアルの難解さもあり簡単ではない。マネージド・サービスなので、オンプレミスでRed Hat SatelliteやSpacewalkを導入するほど面倒ではないが、最低でも十数ノード以上ないと効果は実感できないかもしれない。
またエンタープライズに向けての機能ならば、Red Hat Satelliteにある「リポジトリのスナップショット機能」が欲しいところ。
マニュアルにはfocusing initiallyと書いていたので、今後はいろいろ拡張するのだろうけど。