【改訂】Oracle Cloud InfrastructureでOS Management Serviceがリリースされたよ

<font color="red">2024/04/25 OS Managementは2025年4月までにEOL（End of Life）になることが発表されました。後継サービスは[OS Management Hub](https://docs.oracle.com/ja-jp/iaas/osmh/doc/home.htm)です。</font> 

<font color="red">2023/04/19 現在は数多くリージョンサポートし、Autonomous LinuxなどOSサポートも増えている。OS Management Serviceのアップデート情報は[こちら](https://docs.oracle.com/en-us/iaas/releasenotes/services/os-management/)</font>
<font color="red">2020/02/11 東京リージョン対応</font>


2019/12にOS Management Serviceの[記事](https://qiita.com/yamada-hakase/items/3b244c94d429ac40f003)を書いたが、マニュアルの記述が不足していたこともあり、設定が完了しなかった。その後マニュアルが大幅に拡充されたのと、当初の記事は実験的な操作も含まれていたため、新たに加筆修正して書くことにした。

# 1. OS Management Serviceがリリース！

**OS Management Service**がリリースされた。OOW 2019や[Oracle Linux on Oracle Cloud Infrastructureブログ](https://community.oracle.com/docs/DOC-1034101)で事前に紹介されていた機能だ。

* 2019/12/17 [OS Management Service Released](https://docs.cloud.oracle.com/iaas/releasenotes/changes/78459b02-dafa-4db8-b84a-9f6f295140af/)

ただし現時点（2020/02）では2つの注意点がある。

**1点目：**<font color="blue">提供しているのは以下のリージョンに限られる。2020/02/11に東京リージョンとソウルリージョン対応し、現在はほとんどのリージョンで利用可能。

* [最新の対応リージョン情報](https://docs.oracle.com/en-us/iaas/os-management/osms/osms-overview.htm#osms-availability)

**2点目：**<font color="blue">サービスの対象はOracle Linux 6 / 7 / 8で、Oracle Autonomous Linuxは含まれていない。</font>以下のブログではOracle Autonomous Linuxも対象にしているように思えるが、少なくとも現時点は対象外である。

* [In an Industry First, Oracle Brings Autonomous Operation to Linux](https://community.oracle.com/docs/DOC-1033577)

> 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好きの筆者にとって興味のあった**<font color="red">Oracle Autonomous Linux</font>**。世界で一番早く一番詳しい記事を書いた、と勝手に思っている。
> 
> * [Oracle Autonomous Linuxをハックする Part 1](https://qiita.com/yamada-hakase/items/3b29b49703d2c807349b), [Part 2](https://qiita.com/yamada-hakase/items/b735ec62ddcb38eb19f5), [Part 3](https://qiita.com/yamada-hakase/items/f613ef367bd5ddfee987)
>
> そして、ついに待望のOS Management Serviceがリリースされた。

<font color="blue">2021/01/06追記：以下のWindowsにも対応</font>

* Windows Server 2012 R2 Standard, Datacenter
* Windows Server 2016 Standard, Datacenter
* Windows Server 2019 Standard, Datacenter

# 2. マニュアルを眺める

マニュアル「[Overview of OS Management](https://docs.cloud.oracle.com/iaas/os-management/index.html)」をサクッと眺めてみよう。

> 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.

<font color="blue">**OS Management Serviceは、Computeインスタンスのオペレーティング・システム管理ツールで、最初はLinuxインスタンスのパッケージ管理機能を提供する。**</font>

気になるところをピックアップすると以下のとおり。

* OS Management ServiceでComputeインスタンスを管理するには、OS Management Agentのインストールが必要
* <font color="blue">OS Management Serviceを有効にすると、Computeインスタンスに対してパッケージの参照／追加／更新／削除できる
* <font color="blue">OS Management Serviceに登録したComputeインスタンスは、個別もしくはグループ化してパッチ管理できる
* Computeインスタンスのパッケージ管理は、ジョブとして即時実行やスケジュール実行（1回、定期間隔）ができる
* <font color="red">対象のオペレーティングシステムは Oracle Linux 6 / 7 / 8</a>
* 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の仕組みや、主要コンポーネントを説明する。下図は、マニュアルの記述や実際の調査から推測したアーキテクチャ図である。

![osms-arch00.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/978da909-45e3-5c3f-40ed-a11335d3b239.png)

<dl>
  <dt>OS Management Service</dt>
    <dd>OS Managementの機能を提供する主体。管理下のインスタンス情報を提供するだけでなく、インスタンスに対してパッケージのインストールやアップデートを行う。Oracle Enterprise ManagerにおけるOMS+リポジトリDBに相当</dd>
  <dt>OS Management Agent</dt>
    <dd>管理下のインスタンスで稼働するエージェント（osms-agent）。インスタンス作成後にインストールする</dd>
  <dt>マネージド・インスタンス（Managed Instance）</dt>
    <dd>OS Managementに登録したComputeインスタンス。osms-agentが稼働し、OS Management Serviceを通じてさまざまな操作ができる。また登録したインスタンスのリポジトリ情報（/etc/yum.repos.d/*repo）は無効化される</dd>
  <dt>ソフトウェア・ソース（Software Sources）</dt>
    <dd>サーバー側で集中管理されたYumリポジトリ情報。デフォルトのソフトウェア・ソースは自テナントのRootコンパートメントにあるが、実体は管理情報DB内に格納されたYumリポジトリ情報（repoファイル相当）</dd>
  <dt>Oracle Linux Yum Repository</dt>
    <dd>Oracle LinuxのYumリポジトリには、どこからでもアクセス可能な「Public Yumリポジトリ」と、OCIからだけアクセスできる「OCIリージョンごとに用意されたYumリポジトリ」がある</dd>
</dl>

これらのなかで**ソフトウェア・ソース**はとくに分かりづらい。しかし現時点では「サーバー側で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]**メニューが表示されない。

![osmanage01.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/ce44088a-db5b-2c62-1db2-b36565062784.png)

また前提条件で説明したように、インスタンス作成時に**[Oracle Cloud Agentを使用してインスタンスを管理（Use Oracle Cloud Agent to mange this instance）]**が有効にしている必要がある。新規インスタンスではデフォルトで有効になっているので、新しくインスタンスを作成した方がよいだろう。

このオプションは、インスタンス作成ページで**[拡張オプションの表示（Show Advanced Options）]**をクリックすると表示される。

![autonomous11.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/50c1bef7-604e-e396-3201-f0491ecc823a.png)


### 4-4. OS Management管理者へのポリシー設定

コンソールやCLI、RESTでOS Managementを操作するユーザーにポリシーを割り当てる。ユーザーには直接割り当てられないので、ユーザーが属するグループを指定する。

1. 管理コンソールから**[Identity]-[Policies]**を選択する。
2. 以下の内容でポリシーを作成する。

| 項目 | 値 |
|:---|:---|
| 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. ダイナミック・グループの作成

1. 管理コンソールから**[Identity]-[Dynamic Groups]**を選択する。
1. 以下の内容でダイナミック・グループを作成する。

| 項目 | 値 |
|:---|:---|
| 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. ポリシーの割り当て

1. 管理コンソールから**[Identity]-[Policies]**を選択する。
1. 以下の内容でポリシーを作成する。

| 項目 | 値 |
|:---|:---|
| 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はインストール済みである。次のように表示されればエージェントはインストールされている。

```shell-session
$ 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時間以上放置する。設定が完了すると管理コンソールの表示が次のように変わる。

![osms-con04.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/9dd87d47-8c4e-35cf-3deb-11f2ff2ab886.png)

初回セットアップ終了後の2台目以降は、すぐに登録が完了する。

<font color="red">**トラブル時の対応**</font>
<font color="red">もし2時間以上たっても画面が変わらず、以下のファイルにエラーが数分おきに出続けているようであればPostfixを起動してみよう。そして2時間放置する。

`/var/log/messages`
`/var/log/oracle-cloud-agent/plugins/osms/agent.log`
`/var/log/oracle-cloud-agent/plugins/osms/osms.log`


```shell-session:Postfixの起動
# systemctl start postfix
```

筆者は同時にいろいろなことをしたため、根本原因を突き止めていないのだが．．．。 Please teach me.


# 5. 設定後の状態を確認

設定が終わったら、管理コンソールとマネージド・インスタンスの内部を見てみよう。

### 5-1. 管理コンソールの確認

1. Computeインスタンスの詳細を表示する。
![osms-con04.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/9dd87d47-8c4e-35cf-3deb-11f2ff2ab886.png)

2. 右の**「・・・」**をクリックするとポップアップが表示される。「View OS Management Details」「Install Security Updates」「Install All Upadates」という3つのメニューがある。
![osms-con05.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/55d29f1e-74b9-4a0a-a745-e6e5729625eb.png)

3. **「View OS Management Details」**をクリックすると次のページが表示される。
![osms-con06.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/8272fd52-f07c-bcdc-d874-11008d943b85.png)

4. 次に管理コンソールのメニューから**[Compute]-[OS Management]**を選択する。ここでは**[Software Sources]**を表示している。ここに表示されているのは一部で、複数ページにわたっている。
![osms-con03.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/32f9afb1-d67c-d789-7b6c-c530645872dd.png)

5. 次の画面はインスタンス・グループを作成し、2つのインスタンスをメンバーにしたときのものだ。グループ化することで、複数インスタンスに対して同時にアップデートを指示できる。
![osms-con08.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/266049/7cdfeecd-c06f-708a-33bb-992c49055be0.png)

<font color="red">**注意**
同じインスタンス・グループのメンバーにできるのは、同一バージョン、同一種類のオペレーティングシステムに限られる。

### 5-2. マネージド・インスタンスの確認

インスタンスにsshでログインしてrepoファイルまわりを確認する。

osms-agentをインストールし、OS Management Serviceの構成が終了すると、次のようにすべてのrepoファイルがリネームされる。

```shell-session
$ 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が使えるのか不安になる。しかし、リポジトリを確認すると利用できることがわかる（初回はメタデータ同期に時間がかかる）。

```shell-session
# 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に怪しいファイルを発見。

```shell-session
# 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の**「ソフトウェア・ソース」**のことだ。

```shell-session:/usr/share/yum-plugins/osmsplugin.py
# 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](https://www.redhat.com/ja/technologies/management/satellite)**/**[Spacewalk](https://spacewalkproject.github.io/)**のコードを利用しているから。

次にnetstatで調べてみると、osms-agentがセッションを張っている。`169.254.169.254`はOCIの内部ネットワークで、`129.146.12.149`はPhoenixリージョンの[Oracle Service Network](https://docs.cloud.oracle.com/iaas/Content/General/Concepts/addressranges.htm#osn-ranges)が使用しているグローバルIPだ。

```shell-session
# 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. 登録の解除方法

登録解除に関する[マニュアルの記述](https://docs.cloud.oracle.com/en-us/iaas/os-management/index.html#agent-disable)は日々進化しているようだ。最新情報はマニュアルを参照のこと。

1. osms-agentを停止して無効化する。

```shell-session
# systemctl stop osms-agent
# systemctl disable osms-agent
```

2.可能であればインスタンス／グループから除外する。
3.次のコマンドを実行し、repoファイルの定義を元に戻す。

```shell-session
# osms unregister
# yum clean all
```

4.repoファイルの拡張子が元に戻っていることを確認する。

```shell-session
# 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. まとめ
すべての機能を使っているわけではないが、推測を含めて書いてみる。

* **<font color="blue">OS Management ServiceはOracle Linux 6 / 7 / 8とWindows Serverを対象としたサービス。Oracle Autonomous Linuxは対象外</font>**
* **<font color="blue">複数のサーバー群をまとめたパッケージ管理ができる</font>**
* **<font color="blue">OS Management Serviceは、[Red Hat Satellite](https://www.redhat.com/ja/technologies/management/satellite)や、そのクローンである[Spacewalk](https://spacewalkproject.github.io/)のようなパッケージ管理ツールのマネージド・サービス版</font>**

実際に操作するとわかるが、OS Management Serviceの設定／運用はマニュアルの難解さもあり簡単ではない。マネージド・サービスなので、オンプレミスでRed Hat SatelliteやSpacewalkを導入するほど面倒ではないが、最低でも十数ノード以上ないと効果は実感できないかもしれない。

またエンタープライズに向けての機能ならば、Red Hat Satelliteにある「リポジトリのスナップショット機能」が欲しいところ。

マニュアルには**focusing initially**と書いていたので、今後はいろいろ拡張するのだろうけど。