Red Hat Satellite 6 のコンテキストでは、コンテンツ管理は複数のコンテンツタイプ向けの持続可能なリポジトリーを提供するワークフローを意味します。Red Hat コンテンツの場合、Red Hat Satellite 6 はユーザーに利用可能なコンテンツを認識するためにサブスクリプション情報も使用します。つまり、Red Hat Satellite 6 は以下のものを管理するコンポーネントを使用します。

アプリケーションライフサイクルは、Red Hat Satellite 6 のコンテンツ管理機能の中心となる概念です。アプリケーションライフサイクルは、特定の段階で特定のシステムとソフトウェアがどのように見えるかを定義します。例えば、アプリケーションライフサイクルが単純な場合には、開発段階と実稼働段階のみになります。このような場合、アプリケーションライフサイクルは以下のようになります。

ただし、より複雑なアプリケーションライフサイクルには、テストやベータリリースなどのさらに多くの段階があることがあります。

結局は、アプリケーションライフサイクルの段階は、それぞれの組織とソフトウェア開発方法によって異なります。Red Hat Satellite 6 はそれぞれの仕様を満たすために各アプリケーションライフサイクル段階をカスタマイズする方法を提供します。

Red Hat Satellite 6 では、アプリケーションライフサイクルの各段階は環境と呼ばれます。各環境はコンテンツの特定のコレクションを使用します。Red Hat Satellite 6 では、これらのコンテンツコレクションはコンテンツビューとして定義されます。各コンテンツビューは、特定の環境に含めるリポジトリー、パッケージ、および Puppet モジュールを定義できるフィルターとして動作します。これにより、ユーザーは各環境に指定する特定のコンテンツセットを定義できるようになります。

アプリケーションライフサイクルの概念は、進捗状況によって異なります。例えば、アプリケーションライフサイクルの初期段階の環境では新しい機能の開発とテストを行うために新しいリリース前のパッケージを使用することがあります。同様に、それ以降の段階の環境では、実稼働用ソフトウェアに最適な安定したパッケージのみを使用することがあります。開発中のパッケージのテストが完了したら、アプリケーションライフサイクルで開発コンテンツビューをプロモートして、実稼働環境用のコンテンツビューにすることができます。この結果、アプリケーションの開発でアプリケーションライフサイクルが進行することになります。

図1.1 Red Hat Satellite 6 アプリケーションライフサイクル

Red Hat Satellite 6 では、以下のものを含むさまざまなコンテンツタイプを管理できます。

本書では、シナリオ例を使用して Red Hat Satellite 6 の機能について説明します。このシナリオでは、ACME という名前のソフトウェア開発会社が最近 Red Hat Satellite 6 をインストールし、その会社のシステム管理者が Red Hat コンテンツをインポートおよび管理したいとします。ACME の最終的な目標は以下のとおりです。

本書ではコンテンツ管理のみを取り上げます。ホストプロビジョニング、環境アーキテクチャー、Satellite Server 管理などの他の機能については、Red Hat Satellite 6 シリーズの他のガイドを参照してください。

本書では、Red Hat Satellite 6 Web UI または CLI ツール (hammer) のいずれかを使用する手順を提供します。Red Hat Satellite 6 とのお好みの対話方法に応じていずれかを使用します。CLI を使用しており、hammer コマンドを実行するたびに認証詳細情報を提供したくない場合は、ローカルユーザーに対して CLI 設定ファイルを作成します。

# mkdir ~/.hammer
# cat > .hammer/cli_config.yml <<EOF
:foreman:
    :host: 'https://satellite.example.com/'
    :username: 'admin'
    :password: 'p@55w0rd!'

EOF

一部の CLI コマンドでは、特定のタスクを非同期的に実行するために --async オプションを使用できます。例えば、コンテンツを同期し、監視するのではなくコンテンツビューを非同期タスクとして公開できます。本書では、ユーザーが完了するタスクの進行状況を監視できるよう --async が省略されます。特定のタスクで --async オプションを含める場合は、次のタスクに進む前にタスクを完了させてください。

Red Hat Satellite 6 では、Red Hat のコンテンツ配信ネットワークと同期されるコンテンツを含む RPM および Puppet コンテンツ用リポジトリーと独自のカスタムリポジトリーがホストされます。このようなリポジトリーのサイズは時間の経過とともに大きくなります。したがって、それぞれの環境に合わせて適切なサイズ要件を推定し、将来の要件を適切にスケールする必要があります。

Red Hat Satellite 6 では、リポジトリーコンテンツの保存と管理が /var/lib/pulp で行われます。このディレクトリーは、スケール可能な大規模ローカルパーティションにマウントすることをお勧めします。例えば、このパーティションを作成するには論理ボリュームマネージャー (LVM) を使用します。

Red Hat Satellite 6 は、Red Hat のコンテンツ配信ネットワークからのパッケージを同期し、保存します。これには、Red Hat Enterprise Linux および他の Red Hat ソフトウェア向けのリポジトリーが含まれます。Red Hat コンテンツの推奨ストレージ要件は以下のとおりです。

主要な Red Hat Enterprise Linux バージョンの実稼働フェーズ 1 の間:

主要な Red Hat Enterprise Linux バージョンの実稼働フェーズ 1 の後:

Red Hat 実稼働フェーズの詳細については、"Red Hat Enterprise Linux Life Cycle" を参照してください。

Red Hat Satellite 6 では、ユーザーはコンテンツビューを作成できます。コンテンツビューは、特定の時点でユーザー定義コンテンツコレクションのスナップショットとして動作します。これにより、既存のリポジトリーからカスタマイズコンテンツコレクションを作成できるようになります。

コンテンツビューのコンテンツの各ユニットは、/var/lib/pulp/content ディレクトリーに格納された Definitive Media Library へのシンボリックリンクを使用します。また、コンテンツビュー内の各リポジトリーには、コンテンツビューに属するコンテンツに関するメタデータが含まれます。したがって、最小の数のパッケージを使用しているコンテンツビューは少量のストレージを使用します。ただし、ストレージサイズは、複数のコンテンツビューを使用し、ビューごとに大量のパッケージを使用すると、増加します。

例えば、Red Hat Enterprise Linux 7 RPM リポジトリーを使用しているコンテンツビューには 7000 を超えるパッケージが含まれることがあります。このディスク領域はシンボリックリンクの 100MB 未満になります。ただし、以下のことを考慮してください。

コンテンツビューが使用するストレージの量を削減するには、以下のことを行うことをお勧めします。

また、Red Hat Satellite 6 はコンテンツ管理コンポーネント向けに以下のデータベースを使用します。

本章では、Red Hat Satellite 6 のコンテキストのコンテンツ管理の基本的な概念について説明しました。これには、Red Hat Satellite 6 アプリケーションライフサイクルのフェーズの定義と Red Hat Satellite 6 が管理するコンテンツのさまざまなタイプが含まれます。また、本章では、シナリオ例のスコープが定義され、それぞれのコンテンツ管理のニーズを満たすストレージ要件が提供されました。

次章では、組織を作成してコンテンツを保存する方法について説明します。

新規組織 をクリックします。

以下の 3 つのセクションから構成される作成ウィザードが表示されます。

組織の作成後に、送信 をクリックします。

# hammer organization create \
--name "ACME" \
--label "ACME" \
--description "Our example organization for managing content."

これにより、最初の組織が作成されます。

Red Hat Satellite 6 でコンテンツを管理する前に、コンテキストを設定する必要があります。コンテキストは、コンテンツを使用する組織を定義します。

# hammer subscription list --organization "ACME"

これにより、CLI を介した各対話のコンテキストが設定されます。

本章では、新しい組織を作成し、コンテンツ管理のコンテキストとして設定する方法について説明しました。

次章では、Red Hat Satellite 6 でサブスクリプションを組織にインポートする方法について説明します。サブスクリプションがインポートされると、Red Hat コンテンツを管理できるようになります。

複数の組織を管理する場合は、Satellite Server で複数のマニフェストを使用できます。Satellite 6 では、各組織ごとにSatellite で設定された単一マニフェストが必要になります。この利点は、各組織が完全に独立したサブスクリプションを保持するため、複数の組織それぞれを独自の Red Hat Network アカウントでサポートできることです。

Red Hat カスタマーポータルでは、サブスクリプション情報にアクセスできます。また、Satellite Server をサブスクリプション管理アプリケーションとして追加することもできます。これは、カスタマーポータルでサブスクリプションを Satellite に割り当てるために必要になります。

このシナリオでは、カスタマーポータルで Satellite Server をコンテンツコントリビューターとして追加します。以下の手順に従ってください。

この時点でカスタマーポータルには、Satellite Server のエントリーが含まれます。このページではサブスクリプションを割り当て、サブスクリプションマニフェストを作成することができます。

Satellite サーバーのカスタマーポータルページでは、サブスクリプションのグループを収集し、管理対象システムに配布するためにサーバーに割り当てます。説明したように、Satellite Server 向けのサブスクリプションマニフェストを作成します。サブスクリプションを割り当て、ACME のマニフェストを作成するには、以下の手順を実行します。

これで、Satellite Server にアップロードするサブスクリプションマニフェストを取得できました。

マニフェストは、Red Hat Satellite 6 の Web UI と CLI の両方でインポートできます。

[user@client ~]$ scp ~/<manifest_file>.zip root@satellite.example.com:~/.

次に、以下のコマンドを使用してインポートします。

[root@satellite ~]# hammer subscription upload \
--file ~/<manifest_file>.zip \
--organization "ACME"

数分後に、CLI により、正常なマニフェストのインポートが報告されます。

カスタマーポータルでマニフェストに対するリポジトリーの追加と削除を行い、更新されたマニフェストを以下の 3 つのいずれかの方法で Satellite に追加します。

# hammer subscription upload --file ~/<manifest_file>.zip

本章では、サブスクリプションマニフェストを使用して Red Hat カスタマーポータルからサブスクリプション情報を取得し、Satellite Server にインポートする方法について説明しました。

次章では、コンテンツ (特に Red Hat の RPM リポジトリー) をインポートする方法について説明します。

DML は、ソフトウェアおよび設定の承認された最終的なバージョンを保存および保護するリポジトリーです。つまり、DML は Satellite にインポートされたコンテンツのマスターバージョンとして機能します。これには、RPM ファイル、キックスタートツリー、ISO イメージなどの Red Hat コンテンツが含まれます。「Red Hat Satellite 6 コンテンツ管理の概要」 で説明したように、Red Hat Satellite 6 ではコンテンツは DML で保存および管理されます。

Satellite では、製品の概念を組織単位として使用して複数のリポジトリーをグループ化します。このようなリポジトリーコレクションは実際の製品の概念と似ています。例えば、Satellite で Red Hat Enterprise Linux Server を製品として見ると、その製品のリポジトリーは異なるバージョン (6.0, 6.1, 7.0)、異なるアーキテクチャー (i386、x86_64、s390x、arm)、および異なるアドオン (オプションリポジトリー、補助リポジトリー、Virt V2V ツール) から構成されることになります。これにより、関連するすべてのリポジトリーが DML 内で統合されます。製品を使用すると、お互いに依存するリポジトリーが一緒に同期されます。Red Hat リポジトリーの場合、製品はリポジトリーの有効後に自動的に作成されます。

本章では、Red Hat コンテンツを使用して DML を作成します。これを行うには、DML と Red Hat の製品およびリポジトリーとを同期します。

DML を構成するリポジトリーを選択すると、Satellite Server により独自のリポジトリーと Red Hat CDN 上のリポジトリーが同期されます。これにより、Satellite Server では Red Hat のリポジトリーの同一コピーが DML の一部として保持されます。Satellite Server はこのリポジトリー情報を取得し、Satellite Server のファイルシステムに保存します。最初の同期後に、DML 内のリポジトリーが CDN のリポジトリーと同期された状態であることを確認する同期計画を作成できます。

最初の更新は ISO イメージを使用して実行できます。コンテンツ ISO の使用の詳細については、付録C 接続済み Satellite Server へのコンテンツ ISO のインポート を参照してください。帯域幅制限がある場所では、以下で説明されているように オンデマンド または 背景 ダウンロードポリシーを使用すると、コンテンツ ISO をダウンロードおよびインポートよりも時間が短縮されることがあります。

Satellite Server では、RPM コンテンツの同期に関する複数のダウンロードポリシーが提供されます。例えば、コンテンツメタデータのみをダウンロードし、実際のコンテンツのダウンロードは後で行うことにより時間を短縮したい場合があります。Satellite Server では以下のポリシーが提供されます。

最後の 2 つのポリシーは、コンテンツの同期時間を短縮するため、レイジー同期機能として動作します。レイジー同期機能は yum リポジトリーのみに使用してください。

Satellite Server に格納されたすべてのリポジトリーは、ダウンロードポリシーを使用します。ダウンロードポリシーは、それぞれのニーズに合わせて変更できます。

同期するリポジトリーを選択する最初の手順では、リポジトリーを含む製品を特定し、リリースバージョンとベースアーキテクチャーに基づいてリポジトリーを有効にします。

製品と特定のリポジトリーの関係は、カスケード型の階層で結ばれます。製品を選択すると、その製品のリポジトリーセットの一覧が開きます。リポジトリーセットを選択すると、有効にできるリポジトリーの一覧が開きます。このシナリオでは、Red Hat Enterprise Linux Server、次に Red Hat Enterprise Linux 7 Server (RPMs) を選択し、Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server を有効にします。これにより、 Red Hat Enterprise Linux 7 用の最新の RPM ファイルが有効になります。

# hammer product list --organization "ACME"

製品のリポジトリーセットをリストします。

# hammer repository-set list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

これにより、製品のリポジトリーセット内のリポジトリーが表示されます (名前と ID 番号を含む)。名前または ID 番号を使用してリポジトリーを有効にします。また、リリースバージョン (7Server) とベースアーキテクチャー (x86_64) を含めます。以下に例を示します。

# hammer repository-set enable \
--name "Red Hat Enterprise Linux 7 Server (RPMs)" \
--releasever "7Server" \
--basearch "x86_64" \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

このシナリオでは、Web UI または CLI を使用して ACME 向けの以下のリポジトリーを有効にします。

これらのリポジトリーは、このシナリオの DML 向けの初期コンテンツを提供します。それぞれのニーズに基づいて複数のリポジトリーを選択できます。

ここまでに、初期 DML を形成する特定のリポジトリーが有効になっています。ここからはこれらのリポジトリーを Red Hat CDN のリポジトリーと同期します。

# hammer product synchronize \
--name "Red Hat Enterprise Linux Server" \
--organization "ACME"

また、各リポジトリーを個別に同期することもできます。製品内のすべてのリポジトリーをリストし、対応するリポジトリーの ID 番号を使用して同期します。以下に例を示します。

# hammer repository list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"
# hammer repository synchronize \
--name "Red Hat Enterprise Linux 7 Server RPMs x86_64 7Server" \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

同期にかかる時間は、各リポジトリーのサイズとネットワーク接続の速度によって異なります。以下の表は、利用可能なインターネット帯域幅に応じてコンテンツの同期にかかる推定の時間を示しています。

DML に初期コンテンツをインポートする場合は、手動による同期が必要になることがよくあります。ただし、DML が定期的に更新されるように同期計画を作成することが推奨されます。

同期計画では、スケジュールされた日時に DML 内のコンテンツをチェックおよび更新します。Red Hat Satellite 6 では、ユーザーは同期計画を作成し、同期計画に製品を割り当てることができます。

保存 をクリックして計画を作成します。計画詳細ページが 詳細 と 製品 の 2 つのタブとともに表示されます。

この時点で製品を追加します。製品 タブをクリックし、次に 追加 をクリックします。Red Hat Enterprise Linux Server 製品を選択し、選択を追加 をクリックします。

# hammer sync-plan create \
--name "Red Hat Products 2" \
--description "Example Plan for ACME's Red Hat Products" \
--interval daily \
--sync-date "2016-02-01 01:00:00" \
--enabled true \
--organization "ACME"

次に、その同期計画に Red Hat Enterprise Linux Server 製品を割り当てます。

# hammer product set-sync-plan \
--name "Red Hat Enterprise Linux Server" \
--sync-plan "Red Hat Products" \
--organization "ACME"

この結果、Satellite Server は毎日 DML コンテンツを Red Hat CDN に対してチェックし、Red Hat リポジトリーを最新の状態にします。

本章では、Red Hat コンテンツを ACME の Satellite Server にインポートし、同期計画を介して Red Hat コンテンツを最新の状態にする方法について説明しました。

次章では、Satellite Server の DML へのカスタムコンテンツのインポートについて説明します。このプロセスは、カスタム製品を作成および管理する点を除いては、Red Hat コンテンツのインポートと同様のものです。

「Satellite での製品およびリポジトリーの使用」 では、Red Hat Satellite 6 の製品の概念とその概念を使用してリポジトリーをグループ化する方法について説明しました。Red Hat Satellite 6 では、カスタム製品を作成して複数の関連リポジトリーを追加することをもできます。Red Hat Satellite 6 における Red Hat コンテンツとカスタムコンテンツにはいくつかの類似点があります。

本章では、2 つの関連リポジトリー (RPM コンテンツを含む RPM リポジトリーと RPM コンテンツを設定するためのモジュール向け Puppet リポジトリー) を含む製品を作成します。

このシナリオでは、ACME は、PostgreSQL データベースを必要とする Web ベースアプリケーションである Exampleware という名前の製品を開発することを目的としています。また、ACME は、Red Hat Enterprise Linux リポジトリーから PostgreSQL を使用して実稼働レベルの Exampleware を現場で使用し、新しいバージョンの PostgreSQL で Exampleware をテストすることもあります。このような場合は、新しいバージョンを同期できるよう PostgreSQL 向けのカスタム製品を作成します。

この情報を入力したら、保存 をクリックします。

# hammer product create \
--name "PostgreSQL" \
--sync-plan "Example Plan" \
--description "Content from PostgreSQL repositories" \
--organization "ACME"

これにより、独自のカスタムリポジトリーを作成し、そのコンテンツを同期できる新しい製品が作成されます。

カスタム製品を作成する前に、カスタム GPG キーを作成する必要がある場合があります。これは、PostgreSQL リポジトリーとの RPM トランザクションに対してある程度のセキュリティーを提供するために使用されます。

最初に、バージョン固有のリポジトリーパッケージのコピーをクライアントシステムにダウンロードします。この場合は、pgdg-redhat95 をダウンロードします。

[user@client ~]$ wget http://yum.postgresql.org/9.5/redhat/rhel-7-x86_64/pgdg-redhat95-9.5-2.noarch.rpm

RPM ファイルをインストールせずに抽出します。

[user@client ~]$ rpm2cpio pgdg-redhat95-9.5-2.noarch.rpm | cpio -idmv

GPG キーは、その抽出ファイルに相対的な場所である etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-95 に存在します。

[user@client ~]$ scp ~/etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG-95 root@satellite.example.com:~/.

GPG キーを Satellite にアップロードします。

[root@satellite ~]# hammer gpg create \
--key ~/RPM-GPG-KEY-PGDG-95 \
--name "PostgreSQL 9.5" \
--organization "ACME"

これで、リポジトリーに関連付ける GPG キーが用意できました。

通常は、実稼働レベルのサーバーでは、安定のために Red Hat Enterprise Linux に含まれる PostgreSQL のバージョンを使用します。ただし、ACME の開発者はより新しいバージョンの PostgreSQL で Exampleware をテストするとします。このような場合は、新しいバージョンの PostgreSQL 向けのカスタムリポジトリーを作成できます。

保存 をクリックしてこのリポジトリーエントリーを保存します。

リポジトリーは同期プランを使用して定期的に更新されますが、ここで初期同期を実行します。PostgreSQL 9.5 リポジトリーを選択して 同期開始 をクリックします。これでリポジトリーと外部 PostgreSQL リポジトリーとの同期が開始されます。

# hammer repository create \
--name "PostgreSQL 9.5" \
--content-type "yum" \
--publish-via-http true \
--url http://yum.postgresql.org/9.5/redhat/rhel-7-x86_64/ \
--gpg-key "PostgreSQL 9.5" \
--product "PostgreSQL" \
--organization "ACME"

次にリポジトリーを同期します。

# hammer repository synchronize \
--name "PostgreSQL 9.5" \
--product "PostgreSQL" \
--organization "ACME"

これで PostgreSQL 9.5 の同期コピーが用意できました。さらに Puppet モジュールを含めて PostgreSQL サーバーを設定することができます。

カスタム製品にも Puppet モジュールのリポジトリーを含めることができます。これを含めると、ホストの状態構成を組み込む方法が提供されます。

まず、PostgreSQL 製品のリポジトリーを作成します。

保存 をクリックしてこのリポジトリーエントリーを保存します。

# hammer repository create \
--name "PostgreSQL Puppet Modules" \
--content-type "puppet" \
--product "PostgreSQL" \
--organization "ACME"

これで Puppet モジュールのカスタムリポジトリーができました。モジュールを加えていきます。

このシナリオでは、PostgreSQL 設定用の Puppet モジュールを手動でインポートします。

Puppet Forge サイト (https://forge.puppetlabs.com/puppetlabs/postgresql) からこのモジュールをダウンロードします。ブラウザーでこのページを開き、download latest tar.gz をクリックしてローカルのファイルシステムに保存します。

Upload Puppet Module セクションにスクロールし、参照 をクリックしてダウンロードした PostgreSQL Puppet Module を選択し、アップロードします。数秒すると、Satellite Server が Content successfully uploaded とレポートします。

[user@client ~]$ scp ~/<puppet_module>.tar.gz root@satellite.example.com:~/.

Puppet モジュールを PostgreSQL Puppet Modules リポジトリーにインポートします。

[root@satellite ~]# hammer repository upload-content \
--path ~/<puppet_module>.tar.gz \
--name "PostgreSQL Puppet Modules" \
--product "PostgreSQL" \
--organization "ACME"

これで RPM コンテンツを使用したサーバーをインストール、設定するための、RPM コンテンツ と Puppet モジュールの両方を格納したカスタムリポジトリーができました。

アップロードした Puppet モジュールのリポジトリー作成に加え、Satellite Server は完全な Puppet モジュールリポジトリーの同期ができます。この例では、Satellite Server は Puppet Forge リポジトリー全体を同期します。

この情報を入力したら、保存 をクリックします。

カスタム製品の作成後は、リポジトリー画面が表示されます。リポジトリーの作成 をクリックし、新しいリポジトリー用のフォームを表示します。以下の詳細情報を入力します。

保存 をクリックしてこのリポジトリーエントリーを保存します。

Puppet Forge Modules リポジトリーを選択し、同期開始 をクリックします。これで Puppet Forge から Satellite Server に全モジュールがインポートされます。

# hammer product create \
--name "Puppet Forge" \
--sync-plan "Example Plan" \
--description "All modules from Puppet Forge" \
--organization "ACME"

Puppet Forge リポジトリーを作成します。

# hammer repository create \
--name "Puppet Forge Modules" \
--content-type "puppet" \
--product "Puppet Forge" \
--organization "ACME" \
--url http://forge.puppetlabs.com/

リポジトリーを同期します。

# hammer repository synchronize \
--name "Puppet Forge Modules" \
--product "Puppet Forge" \
--organization "ACME"

Red Hat Satellite 6 には pulp-puppet-module-builder と呼ばれるユーティリティーが含まれており、これは pulp-puppet-tools RPM から他のシステムにインストールできます。このツールは Git リポジトリーをチェックアウトし、全モジュールをビルドして、それらを Satellite 6 が同期できる構造で発行します。よくある方法の 1 つは、Satellite Server 上でこのユーティリティーを実行し、ローカルディレクトリーに公開して、そのディレクトリーに対して同期するというものです。例を示します。

# mkdir /modules
# chmod 755 /modules
# pulp-puppet-module-builder \
--output-dir=/modules \
--url=git@mygitserver.com:mymodules.git \
--branch=develop

これで Git リポジトリーの develop ブランチが git@mygitserver.com:mymodules.git からチェックアウトされ、/modules に発行されます。このディレクトリーを Satellite Server の新規リポジトリーの URL (file:///modules) として追加します。

# hammer repository create \
--name "Modules from Git" \
--content-type "puppet" \
--product "MyProduct" \
--organization "ACME" \
--url file:///modules

# mkdir /var/www/html/modules/
# chmod 755 /var/www/html/modules/
# pulp-puppet-module-builder \
--output-dir=/var/www/html/modules/ \
--url=git@mygitserver.com:mymodules.git \
--branch=develop

本章では、Red Hat 以外のコンテンツ向けのカスタムリポジトリーの作成方法を説明しました。これには RPM ファイルや Puppet モジュールが含まれます。

これで、ベースコンテンツすべてが Satellite Server の DML にインポートされました。これをアプリケーションのライフサイクルに使用できます。

次章では、ACME の開発および実稼働プロセスに一致するようにアプリケーションのライフサイクルを開発する方法を説明します。

ここまで見てきたように、アプリケーションライフサイクルはあるステージでシステムがどのように表示されるかを定義します。しかし、実際のライフサイクルは、組織と組織が特定の実稼働チェーンを構成する方法によって異なります。

例えば、E メールサーバーの場合、実際の使用における実稼働レベルのサーバーと、最新のメールサーバーパッケージをテストするテストサーバーという、単純なアプリケーションライフサイクルのみを必要とします。テストサーバーが初期段階をパスすれば、実稼働レベルのサーバーで新パッケージを使用するよう設定できます。

別の例としては、ソフトウェア製品の開発ライフサイクルがあります。開発環境でソフトウェアの新しい部分を開発し、品質保証環境でこれをテストしてベータ版としてプレリリースした後、実稼働レベルのアプリケーションとしてリリースします。

各アプリケーションライフサイクルでは、環境 と呼ばれる段階を使用します。各環境は、システムに対して特定の状態として機能します。各環境は前の環境に続くもので、アプリケーションライフサイクルを構成することになる環境チェーンを作り出します。アプリケーションライフサイクルはそれぞれ、初期の ライブラリー が備わった状態で開始され、これは Definitive Media Library (DML) 内の中央ソースとして機能します。ライブラリー環境には、ここまでの章で同期した全コンテンツが含まれています。ここからは、ライブラリー環境からリンクされる新たな環境を作成します。

本ガイドのシナリオでは、ACME の Exampleware を開発、リリースする単純なアプリケーションライフサイクルを作成します。初期環境にライブラリー環境を使用し、以下の順序で 3 つの環境を続けます: 開発、テスト、および 実稼働。

新規環境パス をクリックして、新規のアプリケーションライフサイクルを起動します。ライブラリーに新規環境を追加するフォームが表示されます。名前 に Development を入力すると ラベル が自動的に完了します。説明 に Environment for ACME's Development Team と入力します。保存 をクリックします。

環境一覧に戻ります。開発環境の新たなテーブルが表示されます。このテーブルは、新規のアプリケーションライフサイクルを示します。これで残りの環境をアプリケーションライフサイクルに追加できます。

新規テーブルの上にある 新規環境の追加 をクリックします。名前 に Testing、説明 に Environment for ACME's Quality Engineering Team と入力して、保存 をクリックします。

再度 新規環境の追加 をクリックします。名前 に Production、説明 に Environment for ACME's Product Releases と入力して、保存 をクリmックします。

これで Development、Testing、および Production という 3 つの環境が揃ったテーブルのアプリケーションライフサイクルが表示されます。

# hammer lifecycle-environment create \
--name "Development" \
--description "Environment for ACME's Development Team" \
--prior "Library" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Testing" \
--description "Environment for ACME's Quality Engineering Team" \
--prior "Development" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Production" \
--description "Environment for ACME's Product Releases" \
--prior "Testing" \
--organization "ACME"

hammer lifecycle-environment paths コマンドでチェーンを確認できます。

# hammer lifecycle-environment paths --organization "ACME"
-----------------------------------------------
LIFECYCLE PATH
-----------------------------------------------
Library >> Development >> Testing >> Production
-----------------------------------------------

アプリケーションライフサイクルのチェーンでは、コンテンツはある環境から次の環境に移動します。このプロセスは プロモーション と呼ばれます。プロモーションはアプリケーションライフサイクルに渡ってコンテンツを管理する基礎となるもので、これを理解することは重要です。

本ガイドのシナリオでは、ACME の Exampleware の開発が完了しており、実稼働しているとします。ACME は Exampleware コンテンツを RPM ファイルにパッケージ化し、これは別製品の一部となります。この状態では、ACME は Exampleware のバージョン 1.0 をリリースしており、このため exampleware-1.0-0.noarch.rpm が実稼働環境にあることになります。

ACME では Exampleware のパッチをリリースするので、Exampleware バージョン 1.1 の開発を開始します。このインスタンスでは、アプリケーションライフサイクルの環境には以下の Exampleware のバージョンが含まれます。

パッチの開発が完了したら、ACME は RPM をテスト環境にプロモートして、ACME の品質保証エンジニアチームがレビューできるようにします。この時点では、アプリケーションライフサイクルには以下のバージョンが含まれます。

品質保証エンジニアチームがレビューを行う間、開発チームは Exampleware 2.0 の作業に着手します。このため、アプリケーションライフサイクルは以下のようになります。

品質保証エンジニアチームがパッチのレビューを完了したので、Exampleware 1.1 のリリース準備が完了しました。ACME では 1.1 を実稼働環境にプロモートします。

開発チームが Exampleware 2.0 の作業を完了し、これをテスト環境にプロモートします。

最後に品質保証エンジニアチームがこのパッケージのレビューを行います。レビューが完了すると、パッケージは実稼働環境にプロモートされます。

この例では、ACME の開発プロセスを Red Hat Satellite 6 アプリケーションライフサイクルにマッピングするステップを説明しています。これらのシステムがアクセスできるのは、各環境に関連するリポジトリーのみです。ある環境から次の環境にパッケージをプロモートすると、プロモート先のリポジトリーはパッケージの新バージョンを受け取ります。この結果、プロモート先の環境にあるシステムはパッケージを新バージョンに更新することができます。

次章では、コンテンツビュー という概念を説明します。これは、ライブラリーから収集されフィルタリングされたコンテンツのコレクションで、リポジトリーに公開されたものです。Red Hat のリポジトリーとこれまでに同期したカスタムリポジトリーはソースコンテンツとして機能しますが、コンテンツビューは作成したリポジトリーをカスタマイズするものです。コンテンツビューにはパッケージが含まれ、Satellite Server はアプリケーションライフサイクルの各環境にコンテンツビューをプロモートします。ある環境でコンテンツビュー (バージョン 1.0) を使用していても、次に新バージョン (バージョン 1.1) のコンテンツビューを受け取ります。この場合、バージョン 1.0 のリポジトリーは、Exampleware RPM の新バージョンが含まれているバージョン 1.1 のリポジトリーに置き換えられます。

本章ではアプリケーションライフサイクルの概念と Red Hat Satellite 6 のコンテンツ管理について説明しました。また、Red Hat Satellite 6 がアプリケーションライフサイクルの各環境にコンテンツをプロモートする方法についても説明しました。

次章では、コンテンツビューとそれを使用したカスタマイズリポジトリーを既存の DML から作成する方法について説明します。

この例では、リポジトリー 2 つとフィルターなしというシンプルなコンテンツビューを作成します。リポジトリーは、Red Hat Enterprise Linux リポジトリーと Satellite Tools リポジトリーになります。このコンテンツビューには Red Hat Enterprise Linux の全 RPM が含まれるので、公開には数分かかる場合があります。

保存 をクリックします。

これで新規コンテンツビューのエントリーが作成され、リポジトリーを追加することができます。Red Hat Enterprise Linux 7 Server RPMs (Kickstart RPMs ではありません) と Red Hat Satellite Tools のリポジトリーを選択し、リポジトリーの追加 をクリックします。これでコンテンツビューにこれらのリポジトリーから全パッケージが追加されます。

これでコンテンツビューを公開する準備ができました。バージョン に移動し、新規バージョンの公開 をクリックします。Satellite Server が新規バージョン (バージョン 1) についての詳細を提供し、説明 にこのバージョンについての説明が入力できます。ここには、新規コンテンツビューの変更を記録しておくことができます。Initial content view for our operating system と入力し、保存 をクリックします。

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

# hammer repository list --organization "ACME"

この例では、2 つのリポジトリーはそれぞれ ID に 1 と 2 を使用しています。

コンテンツビューを作成し、リポジトリーに追加します。

# hammer content-view create \
--name "Base" \
--description "Base operating system" \
--repository-ids 1,2 \
--organization "ACME"

ビューを公開します。

# hammer content-view publish \
--name "Base" \
--description "Initial content view for our operating system" \
--organization "ACME"

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

この例では、リポジトリー 1 つとフィルターなしというコンテンツビューを作成します。リポジトリーは、PostgreSQL リポジトリーになります。

保存 をクリックします。

これで新規コンテンツビューのエントリーが作成されます。PostgreSQL のリポジトリーを選択し、リポジトリーの追加 をクリックします。これでコンテンツビューに PostgreSQL リポジトリーから全パッケージが追加されます。

Puppet モジュール に移動し、新規モジュールの追加 をクリックします。これでインポート済みの Puppet モジュールが表示されます。postgresql モジュールまでスクロールし、バージョンの選択 をクリックします。

最新を使用 のエントリーをスクロールし、アクション コラムの バージョンの選択 をクリックします。

Puppet モジュールがコンテンツビューに追加されました。新バージョンを公開します。

バージョン に移動し、新規バージョンの公開 をクリックします。説明 に Initial RPMs and Puppet module for database と入力し、保存 をクリックします。

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

# hammer repository list --organization "ACME"

必要になるのは PostgreSQL RPM リポジトリーのみで、Puppet モジュールリポジトリーは必要ありません。この例では、PostgreSQL RPMs の ID に 4 を使用します。

コンテンツビューを作成し、リポジトリーに追加します。

# hammer content-view create \
--name "Database" --description "PostgreSQL Database" \
--repository-ids 4 \
--organization "ACME"

ビューを公開します。

# hammer content-view publish \
--name "Database" \
--description "Initial RPMs and Puppet module for database" \
--organization "ACME"

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

Satellite Server はここまでに 2 つのコンテンツビューを公開し、ライブラリー環境でリポジトリーが利用可能になっています。この内の 1 つのコンテンツビューをプロモートしてリポジトリーが他の環境で利用可能になるようにしましょう。

プロモート ボタンを再度クリックします。今度は Testing 環境を選択して バージョンのプロモート をクリックします。

プロモート ボタンを再度クリックします。Production 環境を選択して バージョンのプロモート をクリックします。

これでこのコンテンツビューのリポジトリーが全環境に表示されます。

# hammer content-view version promote \
--content-view "Database" \
--version 1 \
--to-lifecycle-environment "Development" \
--organization "ACME"
# hammer content-view version promote \
--content-view "Database" \
--version 1 \
--to-lifecycle-environment "Testing" \
--organization "ACME"
# hammer content-view version promote \
--content-view "Database" \
--version 1 \
--to-lifecycle-environment "Production" \
--organization "ACME"

これで Database のコンテンツが全環境で利用可能になります。

コンテンツビューでは、フィルターを使って特定の RPM コンテンツを含めたり制限したりします。フィルターを使用しないと、選択したリポジトリーからのすべてのものを含めることになってしまいます。

コンテンツフィルターは以下のいずれかのタイプになります。

また、フィルターの対象となるコンテンツには以下の 4 タイプがあります。

コンテンツフィルターの使用例を見ていきましょう。

フィルター:

フィルター:

フィルター 1:

フィルター 2:

コンテンツフィルターの機能例については、以下のアーティクルを参照してください: "How do content filters work in Satellite 6"

本ガイドのシナリオでは、ACME のベースオペレーティングシステムで特定日以降のエラータアイテムを制限するコンテンツフィルターを作成します。

保存 をクリックします。

エラータの日付範囲 画面が表示されます。ここでは、エラータのタイプと日付の範囲が選択できます。機能強化 と バグ修正 のみを選択します。

[ ] セキュリティー
[X] 機能強化
[X] バグ修正

日付タイプ では 発行日 (エラータの発行日) または 更新日 (エラータの最終更新日) を選択します。エラータが作成後に更新されていない場合は、発行日 と 更新日 は同じになります。発行日 では、エラータアイテムは発行日でフィルタリングされるだけで、そのエラータになされた更新は除外されないことに注意してください。

開始日 では、1 年前の今日の日付を選択します。

終了日 は空白にしておきます。

保存 をクリックします。

これでフィルターが完成しました。新規バージョンの公開 をクリックして、完成したリポジトリーを公開します。バージョンの詳細 では 説明 に Adding errata filter と入力します。保存 をクリックします。

コンテンツビューが公開されると、コンテンツ コラムのパッケージとエラータ (セキュリティーエラータを除く) 数が公開前のリポジトリーと比べて少なくなります。これは、フィルターが昨年からのセキュリティー以外のエラータを正常に除外したことを意味します。

このコンテンツビューを 開発、テスト、実稼働 の各環境に プロモート します。

# hammer content-view filter create \
--name "Errata Filter" \
--type erratum --content-view "Base" \
--description "Exclude errata items from the last year, with the exception of security updates" \
--inclusion false  \
--organization "ACME"

フィルターにルールを追加します。

# hammer content-view filter rule create \
--content-view "Base" \
--content-view-filter "Errata Filter" \
--start-date "2015-01-01" \
--types enhancement,bugfix \
--date-type updated \
--organization "ACME"

コンテンツビューを公開します。

# hammer content-view publish \
--name "Base" \
--description "Adding errata filter" \
--organization "ACME"

ビューを各環境にプロモートします。

# hammer content-view version promote \
--content-view "Base" \
--version 1 \
--to-lifecycle-environment "Development" \
--organization "ACME"
# hammer content-view version promote \
--content-view "Base" \
--version 1 \
--to-lifecycle-environment "Testing" \
--organization "ACME"
# hammer content-view version promote \
--content-view "Base" \
--version 1 \
--to-lifecycle-environment "Production" \
--organization "ACME"

複合コンテンツビューは、複数のコンテンツビューからコンテンツを組み合わせます。例えば、ベース OS とアプリケーションの管理に別々のコンテンツビューを使用していたとします。複合コンテンツビューを使用すると、この 2 つのコンテンツビューのコンテンツを新たなリポジトリーに統合できます。元のコンテンツビューのリポジトリーはそのまま存在しますが、組み合わされたコンテンツには新規リポジトリーが使用されます。

本ガイドのシナリオでは、企業が異なるデータベースサーバーをサポートするアプリケーションを開発しているとします。一般的なアプリケーションスタックは以下のようになります。

この企業が 以下の4 つの個別コンテンツビューを開発するとします。

すると、次に 2 つの複合コンテンツビューを作成できます。1 つ目には PostgreSQL データベースを使います。

もう 1 つには MariaDB を使います。

これで各コンテンツビューは別個に管理、公開されます。アプリケーションスタックの新バージョンを作成すると、複合コンテンツビューの新バージョンを公開することになります。

既存のコンテンツビュー 2 つを組み合わせたコンテンツビューを ACME 用に作成します。

複合コンテンツビュー用のコンテンツビュー一覧が表示されます。Base と Database の両方のコンテンツビューを選択します。Base コンテンツビューには 2 つのバージョンが含まれているので、どちらかを選択します。ここでは、エラータフィルターが含まれているバージョン 2 を選択します。コンテンツビューとバージョンを選択したら、コンテンツビューの追加 をクリックします。

新バージョンの公開 をクリックして、複合コンテンツビューを公開します。説明 に Initial version of Stack と記入して 保存 をクリックします。

公開が完了すると、コンテンツ コラムに含まれた全コンテンツビューのパッケージ、エラータ、Puppet モジュールカウントがレポートされます。

この複合コンテンツビューを 開発、テスト、実稼働 の各環境に プロモート します。

通常のコンテンツビューと同じように、複合コンテンツビューもアプリケーションライフサイクルの各環境で公開、プロモートされていることが確認できます。

# hammer content-view version list \
--full-results true \
--organization "ACME"

本シナリオでは、Database v1.0 のバージョン ID は 5 で、Base v2.0 のバージョン ID は 6 になります。Stack という名前の新規の複合コンテンツビューを作成し、--component-ids オプションでバージョン ID を渡します。

# hammer content-view create \
--composite \
--name "Stack" \
--description "A stack that includes a base operating system and a database" \
--component-ids 4,14 \
--organization "ACME"

複合コンテンツビューを公開します。

# hammer content-view publish \
--name "Stack" \
--description "Initial version of Stack" \
--organization "ACME"

複合コンテンツビューを全環境にプロモートします。

# hammer content-view version promote \
--content-view "Stack" \
--version 1 \
--to-lifecycle-environment "Development" \
--organization "ACME"
# hammer content-view version promote \
--content-view "Stack" \
--version 1 \
--to-lifecycle-environment "Testing" \
--organization "ACME"
# hammer content-view version promote \
--content-view "Stack" \
--version 1 \
--to-lifecycle-environment "Production" \
--organization "ACME"

コンテンツビューが利用可能になったので、システムを環境とビューに登録することができます。

[root@client ~]# rpm -Uvh http://satellite6.example.com/pub/katello-ca-consumer-latest.noarch.rpm

[root@client ~]# subscription-manager environments --org "acme"

[root@client ~]# subscription-manager register --org "acme" --environment "Development/Stack"

[root@atomic_client ~]# wget http://satellite.example.com/pub/katello-rhsm-consumer

[root@atomic_client ~]# chmod +x katello-rhsm-consumer

[root@atomic_client ~]# ./katello-rhsm-consumer

[root@atomic_client ~]# subscription-manager register

本章では、コンテンツビューを使用して DML の既存コンテンツから独自のリポジトリーをカスタマイズする方法について説明しました。以下の方法がありました。

次章では、アクティベーションキーと、それを使ったシステム登録およびアプリケーションライフサイクル環境からのコンテンツへのアクセスについて説明します。

保存 をクリックすると、アクティベーションキーの詳細画面が表示されます。

ここで登録においてアタッチする製品と有効にするリポジトリーを定義する必要があります。サブスクリプション タブに移動します。空の製品/サブスクリプション一覧が表示されます。追加 をクリックして Red Hat Enterprise Linux サブスクリプションと PostgreSQL 製品の両方を選択し、選択を追加 をクリックします。

製品コンテンツ ページに移動します。アクティベーションキーの製品に関連付けられている全リポジトリーが表示されます。デフォルトでは、Satellite Server が有効にしているのは以下のものだけです。

このシナリオでは以下のデフォルトセットがあります。

PostgreSQL:

Red Hat Enterprise Linux Server:

Red Hat Satellite Tools リポジトリーには設定ツール (katello-agent および puppet など) が含まれるため、これを有効にします。以下のようにします。

保存 をクリックします。

これでシステム登録に使用するアクティベーションキーの準備ができました。

# hammer activation-key create \
--name "development-stack" \
--unlimited-content-hosts true \
--description "Exampleware Stack in the Development Environment" \
--lifecycle-environment "Development" \
--content-view "Stack"  \
--organization "ACME"

サブスクリプション ID 一覧を取得します。

# hammer subscription list --organization "ACME"

Red Hat Enterprise Linux サブスクリプション UUID をアクティベーションキーに割り当てます。

# hammer activation-key add-subscription \
--name "development-stack" \
--subscription-id ff808181533518d50152354246e901aa \
--organization "ACME"

PostgreSQL 製品をアクティベーションキーに割り当てます。

#hammer activation-key add-subscription \
--name "development-stack" \
--subscription-id ff8081815239acdc015238fefaa10002 \
--organization "ACME"

アクティベーションキーに関連付けられている製品コンテンツを一覧表示します。

# hammer activation-key product-content \
--name "development-stack" \
--organization "ACME"

Red Hat Satellite Tools 6.2 リポジトリーのデフォルトの自動有効化ステータスを上書きします。デフォルトでは無効になっています。以下のコマンドで有効にします。

# hammer activation-key content-override \
--name "stack-development" \
--content-label rhel-7-server-satellite-tools-6.1-rpms \
--value 1 \
--organization "ACME"

アクティベーションキーは登録に使用されます。以下が含まれます。

アクティベーションキーはテストすることができます。既存の Red Hat Enterprise Linux 7 システムを Satellite に登録します。

まず、Satellite Server 用のコンシューマー RPM をダウンロードします。これは通常、ホストの web サーバーの pub ディレクトリーに配置されています。例えば、ホスト名が satellite6.example.com の Satellite Server の場合、以下のコマンドを登録するクライアントで実行します。

# rpm -Uvh http://satellite6.example.com/pub/katello-ca-consumer-latest.noarch.rpm

この RPM は Satellite Server 上のリポジトリーにアクセスするために必要な証明書をインストールし、Red Hat サブスクリプションマネージャーがサーバーの URL を使用するように設定します。

次に、クライアント上で Red Hat サブスクリプションマネージャーを実行します。

# subscription-manager register --activationkey="stack-development" --org="acme"
The system has been registered with id: 744fb31c-c983-00f5-ca14-bddd0f711353

Satellite Server サーバーで登録を確認します。

# hammer content-host list --organization "ACME"

# yum install katello-agent

本章では、アクティベーションキーの作成方法とそれを使用してシステムを Satellite Server に登録する方法について説明しました。

次章では、エラータをシステムに適用する方法などのエラータの管理について説明します。

Red Hat Satellite 6 では、エラータの管理と適用のために多様な方法を提供しています。「コンテンツフィルターの定義」 で説明したように、コンテンツビューとコンテンツフィルターを使ってエラータを制限することができます。フィルターには以下のものがあります。

ここでは例として、特定日より後のエラータを除外するコンテンツフィルターを作成します。これにより、アプリケーションライフサイクルの実稼働システムがある時点まで最新に保たれたことになります。その後にこのフィルターの開始日を変更し、テスト環境に新たなエラータを導入します。こうすることで、新パッケージにアプリケーションライフサイクルとの互換性があるかどうかをテストすることができます。

コンテンツフィルターの作成方法については、「コンテンツフィルターの作成」 を参照してください。

コンテンツビューにエラータが含まれたら、これをシステムに適用することができます。Red Hat Satellite 6 に登録した各システムにはエラータ管理画面があり、複数のエラータをシステムに適用することができます。Red Hat Satellite 6 にはエラータを検索、レビューして、複数のシステムに適用するエラータ管理機能もあります。

この手順では、エラータをシステムに適用します。これは 「アクティベーションキーの使用」 からの続きで、テスト用 Red Hat Enterprise Linux 7 システムをご自分の Satellite サーバーに登録していることを前提としています。この例では、以下のエラータを適用します。

Errata ID:   RHSA-2016:0008
Title:       Moderate: openssl security update
Type:        security
Severity:    Moderate
Issued:      2016-01-07
Updated:     2016-01-07
Description: OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, as well as a full-strength, general purpose cryptography library.

OpenSSL のエラータを適用していきます。検索ボックスに title ~ openssl と入力します。これでタイトルに openssl が含まれるエラータが検索されます。RHSA-2016:0008 エラータを選択し、選択を適用 をクリックします。確認メッセージが表示されるので、適用 をクリックします。

Satellite Server は、選択したエラータに関連する全パッケージの更新タスクを開始します。タスクが完了すると、詳細 セクションに更新されたパッケージとその新バージョンの一覧が表示されます。例を示します。

1:openssl-1.0.1e-51.el7_2.2.x86_64
1:openssl-libs-1.0.1e-51.el7_2.2.x86_64

クライアントシステムにログインし、エラータの更新を確認します。

[root@client ~]# yum list openssl openssl-libs

# hammer host errata list \
--host client.example.com \
--search "title ~ openssl" \
--organization "ACME"

クライアントシステムに最新のエラータを適用します。Errata ID を使用して適用するエラータを特定します。

# hammer host errata apply \
--host client.danssat.net \
--errata-ids RHSA-2016:0008 \
--organization "ACME"

クライアントシステムにログインし、エラータの更新を確認します。

[root@client ~]# yum list openssl openssl-libs

Red Hat Satellite 6 Web UI には、複数のシステムを確認してそれらにエラータを適用するエラータ管理システムがあります。この例では、「個別システムへのエラータの適用」 と同じエラータ (RHSA-2016:0008) を使用します。

単一の OpenSSL エラータをこのツールを使ってシステムに適用します。検索ボックスに title ~ openssl と入力します。これで OpenSSL に関連する全エラータが表示されます。これにはバグ修正や機能拡張が含まれますが、「コンテンツフィルターの作成」 で作成したフィルターのために、Satellite Server はこれらのエラータはテストシステムにはインストールできないことに注意してください。

最新の OpenSSL エラータをクリックします。この例では RHSA-2016:0008 になります。

このエラータの 詳細 画面が表示され、エラータが解決する問題の説明が提示されます。

コンテンツホスト のサブタブに移動すると、このエラータが適用可能な全システム一覧が表示されます。「エラータが現在ホストのライフサイクル環境でインストール可能なコンテンツホストのみを表示します。」を選択し、エラータのインストール可能なシステムのみに制限します。

テストシステムを選択して、ホストに適用 をクリックします。エラータインストールに関する確認画面が表示されます。確定します をクリックします。

Satellite Server は、選択したシステム用のエラータのパッケージ更新を開始します。タスクが完了したら、クライアントシステムにログインしてエラータ更新を確認します。

[root@client ~]# yum list openssl openssl-libs

全 OpenSSL エラータを一覧表示します。

# hammer erratum list --search "title ~ openssl" --organization "ACME"

インストール可能なエラータに限定するようにします。

# hammer erratum list \
--errata-restrict-installable true \
--search "title ~ openssl" --organization "ACME"

このエラータの詳細を表示します。

# hammer erratum info --id RHSA-2016:0008

このエラータを適用可能なシステムを一覧表示します。

# hammer host list \
--search "applicable_errata = RHSA-2016:0008" \
--organization "ACME"

エラータを単一のシステムに適用します。

# hammer host errata apply \
--host client.example.com \
--errata-ids RHSA-2016:0008

これらのコマンドは各システムごとに実行する必要があり、--host はそのシステム名で置き換えます。以下のコマンドでこれを実行できます。

# for HOST in `hammer \
--csv --csv-separator "|" host list \
--search "applicable_errata = RHSA-2016:0008" \
--organization "ACME" | tail -n+2 | awk \
-F "|" '{ print $2 }'` ; do echo \
"== Applying to $HOST ==" ; hammer host errata apply \
--host $HOST --errata-ids RHSA-2016:0008 ; done

このコマンドは RHSA-2016:0008 を適用可能なホストすべてを特定し、このエラータを各ホストに適用します。

クライアントシステムにログインし、エラータの更新を確認します。

[root@client ~]# yum list openssl openssl-libs

本章では、Red Hat Satellite 6 でエラータを管理してシステムに適用する方法について説明しました。

次章では、Red Hat Satellite 6 におけるコンテナー管理について説明します。

Red Hat Container Catalog は、Satellite Server にインポート可能なコンテナーイメージのセットを提供します。コンテンツをインポートするプロセスは、Red Hat コンテンツ用のリポジトリーを有効にするものとは異なります。プロセスは以下のようになります。

保存 をクリックします。

カスタム製品を作成したら、製品のリポジトリー画面が表示されます。リポジトリーの作成 をクリックし、新しいリポジトリー用のフォームを表示します。以下の詳細情報を入力します。

保存 をクリックすると、新規リポジトリーが記載された製品のリポジトリー画面に戻ります。同期開始 をクリックして同期プロセスを開始します。数分すると、Satellite Server が同期を完了します。Docker マニフェストの管理 をクリックして利用可能なマニフェストを一覧表示します。この一覧から必要に応じて不要なマニフェストを削除することができます。

# hammer product create \
--name "Red Hat Container Catalog" \
--sync-plan "Example Plan" \
--description "Red Hat Container Catalog content" \
--organization "ACME"

コンテナーイメージ用のリポジトリーを作成します。

# hammer repository create \
--name "RHEL7" \
--content-type "docker" \
--url "http://registry.access.redhat.com/" \
--docker-upstream-name "rhel7" \
--product "Red Hat Container Catalog" \
--organization "ACME"

次にリポジトリーを同期します。

# hammer repository synchronize \
--name "RHEL7" \
--product "Red Hat Container Catalog" \
--organization "ACME"

これでコンテナーイメージが同期されました。

Red Hat Container Catalog からコンテナーイメージをインポートする他に、Red Hat Satellite 6 ではコミュニティーベースや内部のレジストリーなどの他のイメージレジストリーからコンテンツをインポートすることもできます。サードパーティーレジストリーからインポートするプロセスは、Red Hat Container Catalog からイメージをインポートするものと同様のものです。

以下の手順では、DockerHub レジストリー (https://registry.hub.docker.com) からの公式 Fedora イメージを使ってこの手順を実行します。

保存 をクリックします。

Fedora 向けカスタム製品を作成したら、製品のリポジトリー画面が表示されます。リポジトリーの作成 をクリックし、新しいリポジトリー用のフォームを表示します。以下の詳細情報を入力します。

保存 をクリックすると、新規リポジトリーが記載された製品のリポジトリー画面に戻ります。同期開始 をクリックして同期プロセスを開始します。数分すると、Satellite Server が同期を完了します。Docker マニフェストの管理 をクリックして利用可能なマニフェストを一覧表示します。この一覧から必要に応じて不要なマニフェストを削除することができます。

# hammer product create \
--name "Fedora" \
--sync-plan "Example Plan" \
--description "Fedora content" \
--organization "ACME"

コンテナーイメージ用のリポジトリーを作成します。

# hammer repository create \
--name "Fedora/SSH" \
--content-type "docker" \
--url "https://registry.hub.docker.com" \
--docker-upstream-name "fedora/ssh" \
--product "Fedora" \
--organization "ACME"

次にリポジトリーを同期します。

# hammer repository synchronize \
--name "Fedora/SSH" \
--product "Fedora" \
--organization "ACME"

これでコンテナーイメージが同期されました。

コンテンツビューを使用して、アプリケーションライフサイクルにわたってコンテナーイメージを管理します。このプロセスでは、RPM および Puppet モジュールが使用するものと同じ公開とプロモーションのメソッドを使用します。

保存 をクリックします。

これで新規コンテンツビューエントリーが作成されます。Docker コンテンツ のサブタブに移動し、追加 をクリックします。Red Hat Enterprise Linux 7 Server イメージ用のコンテナーリポジトリーを選択します。リポジトリーの追加 をクリックします。これでこのリポジトリーからコンテナーイメージがコンテンツビューに追加されます。

これでコンテンツビューを公開する準備ができました。バージョン に移動し、新規バージョンの公開 をクリックします。Satellite Server が新規バージョン (バージョン 1) についての詳細を提供し、説明 にこのバージョンについての説明が入力できます。ここには、新規コンテンツビューの変更を記録しておくことができます。Initial content view for our container image と入力し、保存 をクリックします。

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

プロモート をクリックして、アプリケーションライフサイクルの環境にこのコンテンツビューをプロモートすることもできます。

# hammer repository list --organization "ACME"

この例では、コンテナー rhel7 のリポジトリーは ID に 8 を使用します。コンテンツビューを作成して、リポジトリーを追加します。

# hammer content-view create \
--name "Containers" \
--description "Container image for Red Hat Enterprise Linux 7" \
--repository-ids 8 \
--organization "ACME"

ビューを公開します。

# hammer content-view publish \
--name "Containers" \
--description "Initial content view for our container image" \
--organization "ACME"

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

コンテナーイメージのなかには Docker タグを使用してバージョン番号や各バージョンについての基本的な情報を特定するものもあります。

# hammer docker tag info --id 218 --organization "ACME"

タグ ID を使用して Docker タグを表示します。

# hammer docker tag info --id 218

本章では、独自のレジストリー作成やアプリケーションライフサイクルにわたるコンテナーイメージの管理方法など、Red Hat Satellite 6 におけるコンテナーイメージコンテンツの基本的な管理方法について説明しました。

次章では、OSTree コンテンツの管理方法を説明します。

デフォルトでは Satellite Server には OSTree 管理ツールは含まれていません。このため、satellite-installer を実行して必要なパッケージをインストールし、ツールを設定する必要があります。

Satellite Server に root ユーザーとしてログインし、以下のコマンドを実行します。

# satellite-installer --katello-enable-ostree=true

インストーラーが必要なパッケージ (ostree、pulp-ostree-plugins、および tfm-rubygem-katello_ostree) をダウンロードし、Satellite サーバーが OSTree 管理ツールを使用するように設定されます。

Red Hat の CDN で OSTree コンテンツを選択して同期します。

コンテンツ > 製品 に移動し、Red Hat Enterprise Linux Atomic Host をクリックします。この時点でこの製品には Red Hat Enterprise Linux Atomic Host Trees のブランチセットが含まれています。このリポジトリーを選択し、同期開始 をクリックします。

数分後には、Satellite Server が rhel7 リポジトリーに関連する全イメージのインポートを完了します。

# hammer repository-set list \
--product "Red Hat Enterprise Linux Atomic Host" \
--organization "ACME" | grep "ostree"

Red Hat Enterprise Linux Atomic Host 向けの ostree リポジトリーを有効にします。この例では、このリポジトリーの ID は 3822 になります。

# hammer repository-set enable \
--product "Red Hat Enterprise Linux Atomic Host" \
--name "Red Hat Enterprise Linux Atomic Host (Trees)" \
--organization "ACME"

自分の製品内でリポジトリーを検索し、これと同期させます。この例では、リポジトリーのこのバージョンの ID は 5 です。

# hammer repository list \
--product "Red Hat Enterprise Linux Atomic Host" \
--organization "ACME"
# hammer repository synchronize \
--name "Red Hat Enterprise Linux Atomic Host Trees" \
--product "Red Hat Enterprise Linux Atomic Host" \
--organization "ACME"

Red Hat の CDN から OSTree コンテンツをインポートするほかに、Red Hat Satellite 6 は他のソースからコンテンツをインポートすることもできます。これには、公開済みの HTTP の場所が必要になります。

保存 をクリックします。

Fedora 向けカスタム製品を作成したら、製品のリポジトリー画面が表示されます。リポジトリーの作成 をクリックし、新しいリポジトリー用のフォームを表示します。以下の詳細情報を入力します。

保存 をクリックすると、新規リポジトリーが記載された製品のリポジトリー画面に戻ります。同期開始 をクリックして同期プロセスを開始します。数分すると、Satellite Server が同期を完了します。

# hammer product create \
--name "OSTree Content" \
--sync-plan "Example Plan" \
--description "OSTree Content" \
--organization "ACME"

OSTree 用のリポジトリーを作成します。

# hammer repository create \
--name "Custom OSTree" \
--content-type "ostree" \
--url "http://www.example.com/rpm-ostree/" \
--product "OSTree Content" \
--organization "ACME"

次にリポジトリーを同期します。

# hammer repository synchronize \
--name "Custom OStree" \
--product "OSTree Content" \
--organization "ACME"

これで OSTree ブランチが同期されました。

コンテンツビューを使用して、アプリケーションライフサイクルにわたって OSTree ブランチを管理します。このプロセスでは、RPM および Puppet モジュールが使用するものと同じ公開とプロモーションのメソッドを使用します。

保存 をクリックします。

これで新規コンテンツビューエントリーが作成されます。OSTree コンテンツ のサブタブに移動し、追加 をクリックします。 Red Hat Enterprise Linux Atomic Host Trees 用の OSTree リポジトリーを選択します。リポジトリーの追加 をクリックします。これでこのリポジトリーから OSTree コンテンツがコンテンツビューに追加されます。

これでコンテンツビューを公開する準備ができました。バージョン に移動し、新規バージョンの公開 をクリックします。Satellite Server が新規バージョン (バージョン 1) についての詳細を提供し、説明 にこのバージョンについての説明が入力できます。ここには、新規コンテンツビューの変更を記録しておくことができます。Initial content view for our OSTree と入力し、保存 をクリックします。

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

プロモート をクリックして、アプリケーションライフサイクルの環境にこのコンテンツビューをプロモートすることもできます。

# hammer repository list --organization "ACME"

この例では、OSTree のリポジトリーは ID に 5 を使用します。コンテンツビューを作成して、リポジトリーを追加します。

# hammer content-view create \
--name "OSTree" \
--description "OSTree for Red Hat Enterprise Linux Atomic Host" \
--repository-ids 5 \
--organization "ACME"

ビューを公開します。

# hammer content-view publish \
--name "OSTree" \
--description "Initial content view for our OSTree" \
--organization "ACME"

Satellite Server がビューの新バージョンを作成し、ライブラリー環境に公開します。

本章では、Red Hat およびカスタムソースから OSTree コンテンツをインポートして同期する方法やそのコンテンツをアプリケーションライフサイクルにわたって管理する方法など、Red Hat Satellite 6 における OSTreeコンテンツの基本的な管理方法について説明しました。

次章では、ISO ファイルの管理方法を説明します。

Red Hat CDN では、特定製品の ISO イメージを提供しています。このコンテンツをインポートするプロセスは、RPM コンテンツのリポジトリーを有効にするプロセスと類似のものです。

コンテンツ > 製品 に移動し、Red Hat Enterprise Linux Server をクリックすると、この製品のリポジトリー画面が表示されます。この時点でこの製品には選択した ISO イメージのリポジトリーが含まれています。このリポジトリーを選択し、同期開始 をクリックします。

数分後には、Satellite Server が選択した全イメージのインポートを完了します。

# hammer repository-set list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME" | grep "file"

Red Hat Enterprise Linux 7.2 Server ISO の file リポジトリーを有効にします。

# hammer repository-set enable \
--product "Red Hat Enterprise Linux Server" \
--name "Red Hat Enterprise Linux 7 Server (ISOs)" \
--releasever 7.2 \
--basearch x86_64 \
--organization "ACME"

自分の製品内でリポジトリーを検索し、これと同期させます。この例では、リポジトリーのこのバージョンの ID は 40 です。

# hammer repository list \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"
# hammer repository synchronize \
--name "Red Hat Enterprise Linux 7 Server ISOs x86_64 7.2" \
--product "Red Hat Enterprise Linux Server" \
--organization "ACME"

本セクションでは、Satellite Server に手動で ISO コンテンツとその他のファイルをインポートする方法について説明します。この例では、bootdisk.iso という名前のファイルを Satellite Server にアップロードします。このプロセスはカスタムの Puppet モジュールをアップロードするプロセスと同様のものです。

保存 をクリックします。

ISO 用のカスタム製品を作成したら、製品のリポジトリー画面が表示されます。リポジトリーの作成 をクリックし、新しいリポジトリー用のフォームを表示します。以下の詳細情報を入力します。

保存 をクリックすると、Bootdisk リポジトリーが記載された製品のリポジトリー画面に戻ります。Bootdisk リポジトリーをクリックします。

ファイルのアップロード セクションにスクロールし、参照 をクリックします。ISO ファイル (この例では bootdisk.iso) を選択し、アップロード をクリックします。数秒すると、Satellite Server が Content successfully uploaded とレポートします。

# hammer product create \
--name "Custom ISOs" \
--sync-plan "Example Plan" \
--description "Custom ISO collection" \
--organization "ACME"

リポジトリーを作成します。

# hammer repository create \
--name "Bootdisk" \
--content-type "file" \
--product "Custom ISOs" \
--organization "ACME"

ISO ファイルをリポジトリーにアップロードします。

# hammer repository upload-content \
--path ~/bootdisk.iso \
--name "Bootdisk" \
--product "Custom ISOs" \
--organization "ACME"

これで ISO イメージを含むカスタムリポジトリーが完成しました。

Open Vulnerability and Assessment Language (OVAL) ファイルには、公開セキュリティーコンテンツについての情報が含まれています。Red Hat Satellite 6 では、OVAL ファイルを SCAP 監査プロセスの一部として使用します。Red Hat は、複数の OVAL ファイルを格納しているリポジトリー (https://www.redhat.com/security/data/oval/) を提供しています。Satellite Server がこのリポジトリーを同期することで、SCAP 監査向けのファイルにローカルでアクセスできるようになります。

保存 をクリックします。

OVAL 向けのカスタム製品を作成したら、製品のリポジトリー画面が表示されます。リポジトリーの作成 をクリックし、新しいリポジトリー用のフォームを表示します。以下の詳細情報を入力します。

保存 をクリックすると、新規リポジトリーが記載された製品のリポジトリー画面に戻ります。このリポジトリーを選択して 同期開始 をクリックします。

# hammer product create \
--name "OVAL Files" \
--sync-plan "Example Plan" \
--description "OVAL file collections" \
--organization "ACME"

OVAL リポジトリーを作成します。

# hammer repository create \
--name "Red Hat OVAL Files" \
--content-type "file" \
--product "OVAL Files" \
--publish-via-http true \
--url https://www.redhat.com/security/data/oval/ \
--organization "ACME"

OVAL リポジトリーを同期します。

# hammer repository synchronize \
--name "Red Hat OVAL Files" \
--product "OVAL Files" \
--organization "ACME"

テストの Red Hat Enterprise Linux 7 システムに openscap-scanner パッケージをインストールします。これには oscap ツールが含まれています。

# yum install openscap-scanner

Satellite Server から Red Hat Enterprise Linux 7 OVAL ファイルのコピーをダウンロードします。

# cd /tmp
# wget http://satellite.example.com/pulp/isos/ACME-OVAL_Files-Red_Hat_OVAL_Files/Red_Hat_Enterprise_Linux_7.xml

oscap ツールで Red Hat Enterprise Linux 7 のテストマシンの脆弱性をスキャンします。

# oscap oval eval \
--results results.xml \
--report report.html ./Red_Hat_Enterprise_Linux_7.xml

これでテストが実行され、各定義が順守されているかどうかについての情報を含むOVAL レポートが生成されます。

本章では、Red Hat Satellite 6 での ISO およびファイルコンテンツの管理について説明しました。

次章では、コンテンツ管理プロセスについて説明します。

本ガイドでは、ACME という架空の企業におけるエンドツーエンドのシナリオで、以下の目的を達成してきました。

本ガイドのシナリオにおける Satellite Server には、この時点でアプリケーションライフサイクルにわたって管理されているコンテンツが含まれています。これで、特定の環境にシステムをプロビジョニングすることが可能です。ここからベアメタルシステムをプロビジョニングする方法を説明していきます。

以下のガイドでは、Red Hat Satellite 6 の関連情報と次のステップの例が提供されます。