Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Red HatとNutanix間の戦略的提携によるNutanix AHV（以下、AHV）がRed Hat認定ハイパーバイザーになりました。 この件については以前の記事でもご紹介しています。 rheb.hatenablog.com 上記記事を書いた時はまだ virt-who がAHVに未対応でしたが、その後正式サポートされるようになりました！下記のKCSではRed Hat Subscription Management（以下、RHSM）と連携するAHV向けvirt-whoの設定方法が紹介されています。 How to configure virt-who for Nutanix AHV to work with RHSM - Red Hat Customer Portal （参考）実はNutanixは以前からAHV対応をしたコードをvirt-whoのアップストリームに提供していましたが、FedoraとRHEL向けのRPMにはAHV対応は取り除かれてビルドされていました。今回正式にAHVがRed Hat認定ハイパーバイザーになったことで取り除かれていた機能が使えるようになったということです。 *1 Simplified Subscription Management for AHV with Red Hat Satellite Server 今回はRed Hat Enterprise Linux(以下、RHEL) のVirtual Data Center (以下、VDC) サブスクリプションをAHV上で使用する場合のvirt-whoの設定方法とRHSMと連携したサブスクリプションの適用方法についてステップバイステップで紹介します *2 。 -目次- [はじめに] RHEL VDCとvirt-whoについて virt-whoインスタンスの構築 前提条件 全体構成図 作業手順 1. 一時的なサブスクリプションのアタッチ 2. virt-whoのインストール 3. virt-whoの設定 4. virt-whoの起動 AHVホストのサブスクリプションのアタッチ RHEL仮想マシンへのサブスクリプションのアタッチ 1. virt-whoインスタンスへのサブスクリプションのアタッチ 2. そのほかのRHEL仮想マシンへサブスクリプションのアタッチ Tips virt-whoの動作テスト virt-whatコマンド使用して稼働するハイパーバイザーを確認する まとめ リンク [はじめに] RHEL VDCとvirt-whoについて RHEL VDCとvirt-whoについては下記の公式の情報が参考になります。 Using RHEL Virtual Data Center Subscription [Master Article] - Red Hat Customer Portal また、日本語の情報としては下記の森若さんの記事で詳細に解説されています。 rheb.hatenablog.com 上記の日本語記事でも書かれていますがvirt-whoは少し独特な仕組みです。AHVでRHEL VDCを使う場合でもその上で稼働するRHELに適切にサブスクリプションをアタッチするためには必要となります。 次の項目ではvirt-whoインスタンスの構築方法について解説いたします。 virt-whoインスタンスの構築 AHV上のRHEL仮想マシンにvirt-whoを導入し、virt-whoインスタンスとして構築します。 前提条件 AHVが構築済みでPrismにログインが可能であること RHEL 8.2/8.4のいずれかのOSバージョンの仮想マシンがAHV上に構築済み （注意）AHV上ではRHEL 7.9のOS自体はサポートされますが、virt-whoを動かすにはRHEL 8.2または8.4が必要です。 使用するRed HatアカウントにRHEL VDCサブスクリプションがAHVホストの台数分登録されていること Red Hatアカウントに登録されたRHEL VDCサブスクリプション一覧 全体構成図 virt-whoとAHV連携後の全体構成は下記のようになります virt-whoとAHV連携の全体構成図 今回はNutanixの最小構成である3ノードクラスタ上で全てのRHEL仮想マシンを動かす構成とします。 作業手順 一時的なサブスクリプションのアタッチ virt-whoのインストール virt-whoの設定 virt-whoの起動 以降はvirt-whoをインストールするRHEL仮想マシン（ホスト名:virt-who）で作業します *3 。 1. 一時的なサブスクリプションのアタッチ RHELにvirt-whoをインストールするためには dnf コマンドの実行が必要ですが、そのためにはサブスクリプションをアタッチする必要があります。しかしながらRHEL VDCはAHVホストに対応したサブスクリプションのためRHEL仮想マシンには適用できません。 dnf コマンドを実行したいのにできないという「Chicken-and-Egg」な状態になってしまいます。これを解消するためにRHEL VDCサブスクリプションをRHEL仮想マシンにアタッチすることで 一時的なサブスクリプションとして使用することが可能 となっています。 subscription-manager コマンドでホストの登録を行い、RHEL VDCサブスクリプションを指定してアタッチします。使用するサブスクリプションを指定する為、先にプールIDを確認します。 # subscription-manager list --available | grep -A 2 -B 2 "RH00001" サブスクリプション名: Red Hat Enterprise Linux for Virtual Datacenters, Premium. 提供: SKU: RH00001 契約: 12135536 プール ID: 8a99f9af7b36770d017b85a10d383e29 # subscription-manager register # subscription-manager attach --pool 8a99f9af7b36770d017b85a10d6c3e2b RHEL VDCサブスクリプションをアタッチするとサブスクリプションタイプが Standard (Temporary) となっていることが確認できます。 # subscription-manager list --consumed +-------------------------------------------+ 割り当て済みのサブスクリプション +-------------------------------------------+ サブスクリプション名: Red Hat Enterprise Linux for Virtual Datacenters, Premium ...（省略）... 状態の詳細: Guest has not been reported on any host and is using a temporary unmapped guest subscription. For more information, please see https://access.redhat.com/solutions/1592573 サブスクリプションタイプ: Standard (Temporary) 開始: 2021年08月27日 終了: 2021年09月03日 エンタイトルメントタイプ: 仮想 Note: 一時的なサブスクリプションの有効期間は7日間です *4 # subscription-manager status +-------------------------------------------+ システムのステータス詳細 +-------------------------------------------+ 全体のステータス: 不十分 Red Hat Enterprise Linux for Virtual Datacenters, Premium: - Guest has not been reported on any host and is using a temporary unmapped guest subscription. For more information, please see https://access.redhat.com/solutions/1592573 システムの目的の状態: 指定されていません RHSMのシステム一覧に表示されたvirt-who仮想マシン 「一部サブスクライブ済み」と表示され警告表示になっている このようにステータスは警告表示になっていますが一時的なサブスクリプションがアタッチすることで dnf コマンドが使用できるようになります。 # dnf repolist Updating Subscription Management repositories. repo id repo の名前 rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) この状態でvirt-whoのインストールを行います 2. virt-whoのインストール dnf コマンドでvirt-whoパッケージをインストールします # dnf install virt-who 3. virt-whoの設定 virt-who設定ファイルに記載するための 組織ID の確認を行います。 subscription-manager コマンドで組織IDを確認します # subscription-manager identity システム ID: 408b0d30-0445-45bc-b7bd-7450c67cec3a 名前: virt-who 組織名: 13278380 組織 ID: 13278380 次に、virt-whoユーザーのパスワードの暗号化を行います。ここで言うvirt-whoユーザーとは Prism ElementまたはPrism Centralに接続するユーザー のことです。 設定ファイルに password= を指定することで平文でのパスワードを使用することも可能ですが、セキュリティ上の観点から暗号化したパスワード encrypted_password= の設定が推奨されます。 virt-who-password コマンドを実行して暗号化したパスワードを取得します *5 。 # virt-who-password Password: # ←ここにPrism接続ユーザーのパスワードを入力 Use following as value for encrypted_password key in the configuration file: 0693dff7817da5e4620ddc2c0801dc76 # ←暗号化されたパスワードが出力されるので内容を控える virt-who設定ファイルを作成します。 # vi /etc/virt-who.d/virt-who.conf ＜virt-who設定ファイルのサンプル記入例＞ [ahv] type=ahv server=192.168.1.70 username=admin encrypted_password=0693dff7817da5e4620ddc2c0801dc76 owner=13278380 hypervisor_id=hostname prism_central=false update_interval=60 internal_debug=false Note: サンプルは KCS に記載のものを流用 パラメーター解説 type= ハイパーバイザーにAHVを使用するので ahv を指定 server= Prism ElementまたはPrism Centralに接続するIPアドレスを入力（FQDNは非対応） username= Prism ElementまたはPrism Centralに接続するユーザー名 encrypted_password= Prism ElementまたはPrism Centralに接続するパスワードを暗号化したもの owner= RHSM上の組織ID hypervisor_id= RHSM上の登録名をAHVホスト名にするため hostname を指定 prism_central= Prism Centralに接続する場合は true 、Prism Elementに接続する場合は false を指定 update_interval=60 ホストとVMのマッピングをチェックする間隔。単位は秒。 internal_debug= デバッグ出力する場合に true を指定。APIの応答が出力される。 4. virt-whoの起動 systemdでvirt-whoデーモンの登録および起動を行います # systemctl enable virt-who --now Created symlink /etc/systemd/system/multi-user.target.wants/virt-who.service → /usr/lib/systemd/system/virt-who.service. systemctl status を実行し、virt-who.serviceが正常に起動していることを確認します。 # systemctl status virt-who.service 出力結果を開く ● virt-who.service - Daemon for reporting virtual guest IDs to subscription-manager Loaded: loaded (/usr/lib/systemd/system/virt-who.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2021-08-31 02:30:33 JST; 9s ago Main PID: 9606 (virt-who) Tasks: 4 (limit: 11385) Memory: 28.1M CGroup: /system.slice/virt-who.service └─9606 /usr/libexec/platform-python /usr/bin/virt-who 8月 31 02:30:33 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:33,366 [virtwho.main INFO] MainProcess(9606):Thread-2 @ahv_interface.py:login:179 - Successfully logged into the AHV REST server 8月 31 02:30:33 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:33,367 [virtwho.main INFO] MainProcess(9606):Thread-2 @ahv_interface.py:get_vms_uuid:507 - Getting the list of available vms 8月 31 02:30:33 virt-who virt-who[9606]: [169B blob data] 8月 31 02:30:33 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:33,452 [virtwho.main INFO] MainProcess(9606):Thread-2 @ahv_interface.py:get_vms_uuid:558 - Total number of vms uuids found and saved fo> 8月 31 02:30:33 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:33,453 [virtwho.main INFO] MainProcess(9606):Thread-2 @ahv_interface.py:build_host_to_uvm_map:746 - Processing hosts for each vm. 8月 31 02:30:33 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:33,732 [virtwho.main INFO] MainProcess(9606):Thread-2 @virt.py:_send_data:981 - Report for config "ahv" gathered, placing in datastore 8月 31 02:30:34 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:34,040 [virtwho.destination_-1311589272434698800 INFO] MainProcess(9606):Thread-3 @subscriptionmanager.py:_connect:159 - X-Correlation-> 8月 31 02:30:37 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:37,815 [virtwho.destination_-1311589272434698800 INFO] MainProcess(9606):Thread-3 @virt.py:_send_data:651 - Hosts-to-guests mapping for> 8月 31 02:30:37 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:37,816 [virtwho.destination_-1311589272434698800 INFO] MainProcess(9606):Thread-3 @virt.py:_send_data:682 - Sending updated Host-to-gue> 8月 31 02:30:37 virt-who /usr/bin/virt-who[9606]: 2021-08-31 02:30:37,816 [virtwho.destination_-1311589272434698800 INFO] MainProcess(9606):Thread-3 @subscriptionmanager.py:_connect:159 - X-Correlation-> 以上でvirt-whoインスタンスの構築は完了です。 次の項目ではRHSM上でAHVホストにサブスクリプションをアタッチする方法を解説します。 AHVホストのサブスクリプションのアタッチ RHSM上でAHVホストにRHEL VDCサブスクリプションをアタッチします。そのためにはvirt-whoからRHSMへ使用しているAHVホストの情報が正しく報告される必要があります。 [注意] virt-whoによってAHVホストの情報がRHSMへ報告されるためには 各AHVホスト上に少なくとも1台以上のパワーオン状態のRHEL仮想マシンが必要 です。仮想マシンホストアフィニティを使用すると簡単に指定したAHVホスト上に仮想マシンを配置できます。 各AHVホスト上に起動済みRHEL仮想マシンを配置する サブスクリプションをアタッチしたいホストを選択します（今回はntnx-ahv01） サブスクリプションをアタッチするホストを選択。ステータスが「正しくサブスクライブ済み」になっていることを確認。 Note: virt-whoからRHSMへ報告直後はホストのステータスが不明な状態になっていることがあります。しばらく待って「正しくサブスクライブ済み」になった後、サブスクリプションのアタッチを実行します。 「サブスクリプション」タブを選択し「サブスクリプションのアタッチ」ボタンを押します。 「サブスクリプションのアタッチ」ボタンを押す 一覧に表示されたサブスクリプションからホストに適用したいRHEL VDCを選択し「サブスクリプションのアタッチ」ボタンを押します。 使用するサブスクリプション選択しアタッチを実行します アタッチ完了後の画面 AHVホストの詳細画面に戻り、アタッチ済みサブスクリプションが0から1に変更されたことを確認します アタッチ済みサブスクリプション数が1になっている 同じ手順で残りのAHVホストにサブスクリプションのアタッチを実行します。AHVホストにサブスクリプションをアタッチすることで、その上で稼働するRHELにも適切なサブスクリプションのアタッチができるようになります。 全てのAHVホストにサブスクリプションがアタッチが完了したら次は各RHEL仮想マシンにサブスクリプションをアタッチします。 RHEL仮想マシンへのサブスクリプションのアタッチ RHEL仮想マシンへのサブスクリプションのアタッチは下記の作業を実施します。 virt-whoインスタンスへのサブスクリプションのアタッチ そのほかのRHEL仮想マシンへサブスクリプションのアタッチ 1. virt-whoインスタンスへのサブスクリプションのアタッチ virt-whoインスタンスで再度サブスクリプションのアタッチを行うことで、一時的なサブスクリプションが削除され 正式なサブスクリプション が適用されます virt-whoインスタンス上で subscription-manager コマンドを実行します # subscription-manager attach --auto 1 件のローカル証明書が削除されました。 インストールしているすべての製品に、有効なエンタイトルメントが付与されています。 現時点では、サブスクリプションを更新する必要はありません。 インストール済み製品の現在の状態: 製品名: Red Hat Enterprise Linux for x86_64 状態: サブスクライブ済み サブスクリプション管理のステータスが「正しくサブスクライブ済み」に変更されている 2. そのほかのRHEL仮想マシンへサブスクリプションのアタッチ RHEL仮想マシン内から通常の手順でホストの登録およびサブスクリプションのアタッチが行えます。登録の方法は下記のいずれの方法でも可能です。 「ホスト登録」→「アタッチ」を順に実行する 「ホスト登録」と同時に「auto-attach」を使用してサブスクリプションのアタッチを実行する 「アクティベーションキーを使用してホストの登録」→「アタッチ」を順に実行する 例1.「ホスト登録」→「アタッチ」を順に実行する [root@rhel01 ~]# subscription-manager register 登録中: subscription.rhsm.stage.redhat.com:443/subscription ユーザー名: tnk4on-stage パスワード: このシステムは、次の ID で登録されました: a840a3c4-401c-4435-974f-e5d2af156148 登録したシステム名: rhel01 [root@rhel01 ~]# subscription-manager attach --auto インストール済み製品の現在の状態: 製品名: Red Hat Enterprise Linux for x86_64 状態: サブスクライブ済み 例2.「ホスト登録」と同時に「auto-attach」を使用してサブスクリプションのアタッチを実行する [root@rhel02 ~]# subscription-manager register --auto-attach 登録中: subscription.rhsm.stage.redhat.com:443/subscription ユーザー名: tnk4on-stage パスワード: このシステムは、次の ID で登録されました: 6238007e-4153-494a-9157-ae85640cd0c3 登録したシステム名: rhel02 インストール済み製品の現在の状態: 製品名: Red Hat Enterprise Linux for x86_64 状態: サブスクライブ済み 例3.「アクティベーションキーを使用してホストの登録」→「アタッチ」を順に実行する [root@rhel03 ~]# subscription-manager register --activationkey RHEL_VDC --org 13278380 このシステムは、次の ID で登録されました: bb730c9a-0b16-49b6-a13a-5a90983cab2f 登録したシステム名: rhel03 インストール済み製品の現在の状態: 製品名: Red Hat Enterprise Linux for x86_64 状態: サブスクライブ済み [root@rhel03 ~]# subscription-manager attach --auto インストールしているすべての製品に、有効なエンタイトルメントが付与されています。 現時点では、サブスクリプションを更新する必要はありません。 インストール済み製品の現在の状態: 製品名: Red Hat Enterprise Linux for x86_64 状態: サブスクライブ済み Note: アクティベーションキーを使用したサブスクリプションのアタッチは下記のドキュメントを参照ください 3.2. コマンドラインでアクティベーションキーを使用したサブスクリプションのアクティブ化 Red Hat サブスクリプション管理 1 | Red Hat Customer Portal AHVホスト、virt-whoインスタンス、その他RHEL仮想マシン、全てが正常にサブスクリプションのアタッチが完了すると、RHSMで下記のように表示されます。 全ての登録システムのサブスクリプションのステータスが正常表示 システムに登録した仮想マシンおよびハイパーバイザー数が正しく表記。RHEL VDCサブスクリプションが正しく消費されている。 Tips virt-whoの動作テスト トラブルシュートなどでvirt-whoの動作テストをしたい場合は virt-who -od コマンドを使用します。通常はvirt-whoは定期的に実行されるますが、 virt-who -od コマンドを使用するとワンショットで実行することができます。 virt-whoインスタンス上でvirt-whoデーモンを停止し、 virt-who -od コマンドを実行します。 # systemctl stop virt-who # virt-who -od 同時にNutanix側のログを確認します。SSHでNutanixクラスターのVIPへログインし下記のログファイルを確認します。 api_audit.log はREST APIのログが記録されるファイルです。 $ ssh nutanix@192.168.1.70 $ tail -f ~/data/prism/api_audit.log 出力結果を開く INFO 2021-08-31 00:21:41,417Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/clusters||entityUuid=||queryParams=||payload= INFO 2021-08-31 00:21:41,467Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/vms||entityUuid=||queryParams=||payload= INFO 2021-08-31 00:21:41,502Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/vms||entityUuid=||queryParams=||payload= INFO 2021-08-31 00:21:41,537Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/vms/e0b78d2a-9370-47a8-acfa-f8588951219b||entityUuid=e0b78d2a-9370-47a8-acfa-f8588951219b||queryParams=||payload= INFO 2021-08-31 00:21:41,564Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/d4cdfda2-2ed8-498d-965c-0341dd4538cc||entityUuid=d4cdfda2-2ed8-498d-965c-0341dd4538cc||queryParams=||payload= INFO 2021-08-31 00:21:41,593Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/d4cdfda2-2ed8-498d-965c-0341dd4538cc||entityUuid=d4cdfda2-2ed8-498d-965c-0341dd4538cc||queryParams=||payload= INFO 2021-08-31 00:21:41,617Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/vms/185b3fd7-1697-4850-8ddc-ac233b09c6ff||entityUuid=185b3fd7-1697-4850-8ddc-ac233b09c6ff||queryParams=||payload= INFO 2021-08-31 00:21:41,687Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/fae51b97-3cc5-4752-beab-6cc7df7b2374||entityUuid=fae51b97-3cc5-4752-beab-6cc7df7b2374||queryParams=||payload= INFO 2021-08-31 00:21:41,713Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/fae51b97-3cc5-4752-beab-6cc7df7b2374||entityUuid=fae51b97-3cc5-4752-beab-6cc7df7b2374||queryParams=||payload= INFO 2021-08-31 00:21:41,743Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/vms/6a8b8a98-ed0a-4712-b5c2-fc48a6b23ace||entityUuid=6a8b8a98-ed0a-4712-b5c2-fc48a6b23ace||queryParams=||payload= INFO 2021-08-31 00:21:41,773Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/b36d16cc-5526-45e6-9ac0-a63001e38b4c||entityUuid=b36d16cc-5526-45e6-9ac0-a63001e38b4c||queryParams=||payload= INFO 2021-08-31 00:21:41,796Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/b36d16cc-5526-45e6-9ac0-a63001e38b4c||entityUuid=b36d16cc-5526-45e6-9ac0-a63001e38b4c||queryParams=||payload= INFO 2021-08-31 00:21:41,821Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/vms/c5408ff2-dc36-499c-aeee-49fe20ac373c||entityUuid=c5408ff2-dc36-499c-aeee-49fe20ac373c||queryParams=||payload= INFO 2021-08-31 00:21:41,889Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/b36d16cc-5526-45e6-9ac0-a63001e38b4c||entityUuid=b36d16cc-5526-45e6-9ac0-a63001e38b4c||queryParams=||payload= INFO 2021-08-31 00:21:41,913Z clientType=External||userName=admin||NutanixApiVersion=2.0||httpMethod=GET||restEndpoint=/v2.0/hosts/b36d16cc-5526-45e6-9ac0-a63001e38b4c||entityUuid=b36d16cc-5526-45e6-9ac0-a63001e38b4c||queryParams=||payload= virt-whatコマンド使用して稼働するハイパーバイザーを確認する virt-whoをインストールすると virt-what コマンド *6 もインストールされます。 virt-what コマンドを使用すると仮想マシンが稼働するハイパーバイザーの名前を確認することができます。 virt-what コマンドはAHVホスト上のRHEL仮想マシンで実行します。 [root@rhel03 ~]# virt-what nutanix_ahv rhel03仮想マシンは nutanix_ahv 上で動作しているという結果が返ってきます。 まとめ RHEL VDCをAHV上で使用するためのvirt-whoの設定方法からRHSMと連携したサブスクリプションの登録方法まで解説しました。 virt-whoインスタンスに一時的なサブスクリプションを割り当てる仕組みなどは実際にやってみないと理解しづらい点もありますので、本記事を参考になんとなくのイメージを掴んでいただけたらと思います。今回は紹介しませんでしたがvirt-whoはRHSMの代わりに Red Hat Satellite と連携することも可能です。RHELの台数が増えて管理コストの低減やパッチ適用の効率化が必要な場合はRed Hat Satelliteの導入をご検討ください。 RHEL VDCを正しく登録すればリソースのある限りRHEL仮想マシンを数の制限なく稼働することができます。クラスターのリソースが不足した場合はNutanixクラスターにノードを追加して容易にクラスターの拡張を行えるのがNutanixの利点です。virt-whoが追加分のノードの検出も行うのでノード追加時も本記事と同じ手順でサブスクリプションの適用ができます。 RHEL VDCとvirt-whoを利用してAHV上で気兼ねなくどんどんRHELを使っていきましょう！ リンク OpenShift on Nutanix AHV - 赤帽エンジニアブログ How to configure virt-who for Nutanix AHV to work with RHSM - Red Hat Customer Portal Add patch to remove AHV bits for RHEL builds by wottop · Pull Request #269 · candlepin/virt-who · GitHub https://www.nutanix.com/uk/blog/simplified-subscription-management-for-ahv-with-red-hat-satellite-server Using RHEL Virtual Data Center Subscription with Customer Portal [Master Article] - Red Hat Customer Portal virt-whoとはなにか - 赤帽エンジニアブログ virt-whoとは何か - Speaker Deck 【RHEL】virt-who設定前に割り当てられる一時的なサブスクリプションの有効期間は7日間 - あとがきのようなもの 1.3. 各仮想化プラットフォーム向けの virt-who の設定 Red Hat Satellite 6.14 | Red Hat Customer Portal *1 : アップストリームの GitHubリポジトリのPull Request でAHV対応を取り除くパッチを確認できる *2 : 基本的な内容は KCS の内容に準拠 *3 : 今回はRHEL 8.4を最小構成でインストールしたものを使用 *4 : 参考： 【RHEL】virt-who設定前に割り当てられる一時的なサブスクリプションの有効期間は7日間 - あとがきのようなもの *5 : virt-who-passwordコマンドはvirt-whoをインストールすると同時にインストールされる *6 : プログラムが仮想マシンで実行中かどうかを検出するシェルスクリプト

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 これまでにも何度かこちらのブログでROSA（Red Hat OpenShift on AWS）についての記事を扱ってきましたが、今回はAWS STSを使ったROSAのデプロイについてご紹介したいと思います。 過去のROSA関連記事はこちら rheb.hatenablog.com rheb.hatenablog.com rheb.hatenablog.com AWS STSとは？ AWS STSとはAWS Security Token Serviceの略称です。STSの説明としてAWSの こちらのドキュメント には以下のように記載されています。（一部抜粋） AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、 信頼されたユーザーを作成および提供することができます。 つまり特定のAWSのリソースを使用するために、一時的な認証情報を発行する事ができるサービスです。 またSTSによる一時的な認証情報の利点について、ドキュメントには以下のように記載されています。 これらの違いから、一時的認証情報を使用する利点は次のようになります。 ・アプリケーションの長期の AWS セキュリティ認証情報を配布したり埋め込んだりする必要がありません。 ・ユーザーに対して AWS ID を定義せずに AWS リソースへのアクセスを許可できます。 　一時的認証情報はロールおよび ID フェデレーションの基本となります。 ・一時的セキュリティ認証情報の有効期限は限られているので、認証情報が不要になった際に 　ローテーションしたり、明示的に取り消したりする必要がありません。一時的セキュリティ認証情報の 有効期限が切れると、再利用することはできません。認証情報が有効な期間を、最大限度まで指定できます。 AWS STSを利用することで、永続的ではない一時的な認証情報によりAWSをよりセキュアに使うことが可能となります。 ROSAにおいてはSTSを使用することで利用者のアカウントにIAMユーザーを新規追加することなく、クラスタを作成、運用することができるようになります。そのため社内のポリシー等でユーザー作成が難しい場合でもROSAをお使い頂くことができるようになります。 ROSAでのSTS活用 過去記事でも紹介されているように、ROSAのクラスタ作成はrosa CLI使用して行います。 STSを使用しない場合、クラスタ作成のrosaコマンド実行時にIAMユーザー『osdManagedAdmin』が作成され、そこに『AdministratorAccess』というポリシーが付与されます。 またクラスタ作成が完了すると、ROSAクラスタのOperatorが使用する複数のユーザーが作成され、それぞれ必要なポリシーが付与されます。 STSを使用する場合のIAMロール、ポリシーの作成 STSを使用する場合、クラスタ作成に際してIAMユーザーの作成は行いません。 通常のROSAクラスタ作成ではまず rosa init コマンドを実行しますが、STSの場合以下のコマンドを実行し、必要なIAMロールとポリシーの作成を行います。 rosa create account-roles --version 4.8 --prefix ManagedOpenShift 作成されたロール 作成されたポリシー 作成されるロールとポリシーの詳細については以下のドキュメントをご参照下さい。 access.redhat.com IAMロールの確認 作成されたロールのうち、ROSAのインストールに用いられるロール『ManagedOpenShift-Installer-Role』を見てみましょう。 こちらのロールにはポリシー『ManagedOpenShift-Installer-Role-Policy』がアタッチされています。このポリシーでROSAクラスタのインストールに必要なアクションを定義しています。 またここで信頼関係タブを開くと、このロールを利用してインストールを行うRed Hatのアカウントと、STSを利用するための"sts:AssumeRole"が設定されているのが確認できます。 ユーザーアカウントとRed Hatアカウント、STSの関係性を図示すると以下のようなイメージとなります。 Red HatアカウントがSTSを介して一時的な認証情報を得ることで、ROSAクラスタの構築や運用が可能となります。 STSを使ったクラスタの作成 必要なロールとポリシーが作成された状態で以下のコマンドを実行すると、STSを使用したクラスタ作成が開始されます。 rosa create cluster --cluster-name ${name} --sts クラスタ作成の開始後、追加で以下二つのコマンドを実行します。 それぞれROSAクラスタのOperatorが利用するIAMロールの作成と、OIDCプロバイダの設定を追加するコマンドとなっています。 rosa create operator-roles -c $name --mode auto --yes rosa create oidc-provider -c $name --mode auto --yes STSを使用しない場合、Operator用に専用のIAMユーザーが追加されていましたが、STSを使うことで、ユーザーを追加せずに必要なアクションを実行可能なロールのみ作成することとなります。 上記のコマンドを実行するとSTSを使ったROSAクラスタの作成に必要な操作は完了です。あとは以下のコマンドを実行し、構築の状況を見ながら40分程度待つとクラスタ作成が完了します。 クラスタ作成完了後は通常のROSAと同様に使い始めることができます。 rosa logs install --cluster=$name --watch クラスタを削除する場合は、以下のコマンドを実行します。 rosa delete cluster -c $name この際、IAMロール、ポリシーについては自動的に削除されないため、AWSのコンソールかCLIから削除を実施して下さい。 まとめ AWS STSを使ったROSAのデプロイいかがだったでしょうか。 AWSに慣れていないとIAMやSTSの仕組みを理解するのが中々大変ですが、ROSAのデプロイ自体は今回ご紹介したコマンドから簡単に実施することができます。 是非一度デプロイしてみてSTSを使ったROSAを体験してみて下さい。 参考ドキュメント access.redhat.com access.redhat.com

Red Hatのソリューションアーキテクトをしている暮林です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/10月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: SREのためのMetrics-driven transformation(MDT) その1 Digital Transformationを成功させるための鍵は組織にある、というのは徐々に理解が広まっているかと思いますが、では組織を変えるためにはどうすれば？という方法論は難しいと考える方は多いのではないでしょうか。組織を変えるためには計測からはじめるべきだ！というのがMetrics-driven transformatonという考え方で、数回の連載でMetrics-driven transformatonを紐解いていきます。 rheb.hatenablog.com 特集2: Red HatのManaged KafkaにQuarkusアプリケーションで接続してみよう！ 先日の赤帽のブログ記事 では、Red Hatが提供するManaged Kafka、Red Hat OpenShift Streams for Apache Kafka (RHOSAK)を試してみる方法として、Kafkaの環境を数分で構築し、ローカルマシンのkafkacatからクラウド上に構築されたKafkaインスタンスにアクセスする手順を書きましたが、今回はQuarkusベースのKafkaクライアントからRed HatのManaged Kafka (RHOSAK) に接続する方法について紹介しています。 rheb.hatenablog.com 特集3: OpenShift Pipeline で行うデシジョンサービスのデプロイの自動化 クラウドネイティブなCI/CDを実現する手段として、OpenShift Pipelines（Tekton）という機能が今年の5月にGAとなりました。 Red Hat Decision Manager / Process Automation Manager においても、OpenShift Pipelinesと連携し、CI/CDパイプラインを構築して開発・リリースサイクルの自動化をよりお手軽に行うことが可能となっています。 今回は、OpenShift Pipelines を使用して、デシジョンサービスのデプロイを自動化する仕組みを実際に動かしてみたいと思います。 rheb.hatenablog.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat DataGrid 8.2

こんにちは。Red Hatでソリューションアーキテクトをしている杉本です。 先日の赤帽のブログ記事 では、Red Hatが提供するManaged Kafka、Red Hat OpenShift Streams for Apache Kafka (RHOSAK)を試してみる方法として、Kafkaの環境を数分で構築し、ローカルマシンのkafkacatからクラウド上に構築されたKafkaインスタンスにアクセスする手順を書きました。今回はQuarkusベースのKafkaクライアントからRed HatのManaged Kafka (RHOSAK) に接続する方法について書いていきたいと思います。 Quarkusのサンプルアプリケーション まず、OpenShift Streams for Apache Kafka のガイドやサンプルコードが格納されているGitリポジトリからQuarkusのサンプルアプリケーションをダウンロードしていきます。以下のコマンドでサンプルのソースコードをクローンしてみましょう。 git clone https://github.com/redhat-developer/app-services-guides app-services-guides ローカルへのコピーが完了したら、app-services-guidesの下にあるcode-examples/quarkus-kafka-quickstartフォルダをIDEで開いてコードを確認してみましょう。ここで使用するquarkus-kafka-quickstartのQuarkusアプリケーションは以下の3つのソースコードから構成されています。 PriceConverter.java PriceGenerator.java PriceResource.java アーキテクチャとしては以下の図のように、Price Generatorコンポーネントがランダムな価格 (price) を生成するメッセージのプロデューサーとなり、価格をKafkaトピック (prices) に送信し、Price Converterコンポーネントが コンシューマーとなってpricesトピックからメッセージを取得します。 図1 アーキテクチャ ブラウザがクライアントとして5秒間隔で更新される価格情報を以下のように表示しますが、仕組みとしては、Price Resourceコンポーネントがブラウザからのリクエストを受け付け、SSE (Server-Sent Events) を使ってPrice Converterコンポーネントから受け取った価格情報をブラウザに返して画面を更新しています。 図2 ブラウザ画面1 このアプリケーションの詳細については、 Quarkusのサイトのドキュメント をご参照ください。 なお、QuarkusとKafkaのメッセージの送受信には SmallRye Reactive Messaging フレームワークとそれに含まれるKafkaコネクター (smallrye-kafka) が使用されています。このフレームワークは Eclipse MicroProfile Reactive Messaging の仕様を実装したものとなっており、以下のようにCDIのアノテーション (@Outgoing/@Incoming) でメッセージの送受信を行うチャネル名を指定します(チャネルはMicroProfile Reactive Messagingの仕組みの中でメッセージの送受信で使われるもので、必ずしもKafkaトピックとは限りません)。 PriceGenerator.java public class PriceGenerator { ... @Outgoing("generated-price") PriceConverter.java public class PriceConverter { ... @Incoming("prices") @Outgoing("my-data-stream") 接続先となるKafkaトピックは以下のようにapplication.propertiesの中で指定されています (*.topicプロパティ)。outgoingとincomingの後に記述されているのがアノテーションで指定されているチャネル名です。 # Configure the Kafka sink (we write to it) mp.messaging.outgoing.generated-price.connector=smallrye-kafka mp.messaging.outgoing.generated-price.topic=prices mp.messaging.outgoing.generated-price.value.serializer=org.apache.kafka.common.serialization.IntegerSerializer # Configure the Kafka source (we read from it) mp.messaging.incoming.prices.connector=smallrye-kafka mp.messaging.incoming.prices.topic=prices mp.messaging.incoming.prices.value.deserializer=org.apache.kafka.common.serialization.IntegerDeserializer RHOSAKにアクセスする場合の認証方式 KafkaクライアントであるQuarkusアプリケーションからRHOSAKのKafkaインスタンスにアクセスする場合の認証方法として、以下の2つがサポートされています。 SASL/PLAIN: クライアントアプリケーションの認証にサービスアカウントのクレデンシャル（Client IDとClient secret）をユーザ名/パスワードとして使用し、Kafkaインスタンスに接続します。 SASL/OAUTHBEARER: RHOSAKはKafkaが提供するSASL/OAUTHBEARERを通じてOAuth2を使用した認証・認可をサポートしており、Kafkaクライアントの認証にサービスアカウントのクレデンシャルとトークンエンドポイントURLを使用してKafkaインスタンスに接続します。 RHOSAKでは後者のSASL/OAUTHBEARERを使用する方式を推奨しており、このサンプルアプリケーションでもSASL/OAUTHBEARERを使用するための設定をおこなっていきます。 このKafkaのクライアントアプリケーションがRHOSAKにアクセスできるようにするためには、以下の情報が必要となります。 Bootstrap Serverのエンドポイント Kafka用に作成されたサービスアカウントのクレデンシャル (Client IDとClient secret) OAuthのトークンエンドポイント このサンプルアプリケーションではこれらの設定情報の環境変数がapplication.propertiesの中で設定されています。 Bootstrap ServerのエンドポイントとOAuthのトークンエンドポイントの値については、RHOSAKのWebコンソールで、Streams for Apache Kafka > Kafka Instancesのページを開き、そこに表示されるKafkaインスタンスを選択して接続情報を表示すると確認することができます。ここでは、以前作成したKafkaインスタンスと同じ名前の my-kafka-instance を使用しています。 図3 接続情報画面 Kafka用に作成したサービスアカウントのクレデンシャル (Client IDとClient secret) の作成方法は以前の赤帽ブログの記事に作成の仕方が書かれていますので、もしまだ作成されていない場合には 以前のブログ記事 を参考にして作成してください。 上記の値が取得できたら、以下のコマンドで環境変数として設定しておきましょう。それぞれの値は実際の値に置き換えてください。 $ export BOOTSTRAP_SERVER=<bootstrap_server> $ export CLIENT_ID=<client_id> $ export CLIENT_SECRET=<client_secret> $ export OAUTH_TOKEN_ENDPOINT_URI=<oauth_token_endpoint_uri> このQuarkusサンプルアプリケーションでは、SASL/OAUTHBEARERを使用してKafkaインスタンスに接続するために、application.propertiesにおいて以下のプロパティが設定済みとなっています (devプロファイルを使用しています)。 %dev.kafka.bootstrap.servers=${BOOTSTRAP_SERVER} %dev.kafka.security.protocol=SASL_SSL %dev.kafka.sasl.mechanism=OAUTHBEARER %dev.kafka.sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \ oauth.client.id="${CLIENT_ID}" \ oauth.client.secret="${CLIENT_SECRET}" \ oauth.token.endpoint.uri="${OAUTH_TOKEN_ENDPOINT_URI}" ; %dev.kafka.sasl.login.callback.handler.class=io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler QuarkusアプリケーションでのKafkaに関するプロパティの設定については、こちらのリファレンスガイド Quarkus - Apache Kafka Reference Guide に詳細な情報がありますので、アプリケーションを開発する際にはぜひ参考にしてください。 サンプルアプリケーション用のKafkaトピックの作成 このQuarkusのサンプルアプリケーションでは、pricesという名前のKafkaトピックを使用していますので、RHOSAKのKafkaインスタンスにその名前のトピックを作成しておきましょう。 Kafka Instancesのページで、先ほど作成したKafkaインスタンスの名前をクリックします。Topicsタブで、[Create topic]をクリックし、ガイドに従ってトピックに関する情報を設定していきます。ここではトピック名を prices とし、あとはデフォルトの値のまま設定をしていきます。 図4 トピック作成画面1 設定が完了すると、以下のようにトピックの一覧に prices トピックが作成されます。 図5 トピック作成画面2 サンプルアプリケーションの実行 では、ダウンロードしたQuarkusのサンプルアプリケーションを実行してみましょう。上のステップで環境変数を設定したら、以下のコマンドでQuarkusアプリケーションをデベロッパーモードで起動してください。 $ cd ~/code-examples/quarkus-kafka-quickstart $ ./mvnw quarkus:dev 正常に起動すると以下のような画面が表示されます。 図6 コマンド実行画面 ブラウザで http://localhost:8080/prices.html にアクセスすると、以下の画面のように、価格情報が5秒間隔で更新されるのが確認できると思います。 図7 ブラウザ画面2 動作が確認できたらぜひこのサンプルアプリケーションのソースコードをもう一度よく確認してみることをおすすめします。 まとめ このように、RHOSAKを使用することでKafkaの環境を簡単に構築することができるだけでなく、Kafkaを利用するリモートのクライアントアプリケーションからも簡単に接続させることができるようになります。さらにQuarkusにはKafkaのクライアントとなるリアクティブなアプリケーションを効率的に開発するための機能が用意されており、 Quarkusのサイト では日本語の情報も多く提供されているので、ぜひQuarkusを使った開発にもトライしてみることをおすすめします。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この記事は Podman.io の Podman on Macs Update を、許可を受けて翻訳したものです。 本ブログに掲載されているその他のPodman関連の翻訳記事は下記のリンクを参照ください。 Podman関連 翻訳記事 By Brent Baude GitHub Podmanチームはローカルでの開発体験を大切にしており、コンテナはそのための重要な要素であると考えています。 私たちは素晴らしいPodmanの体験をMacとWindowsにもたらすために、ブレインストーミング、ディスカッション、そしてソリューションのテストを行ってきました。 また、それを改善する方法を常に模索しています。 特に、Podmanの最新リリースでは、Intel Macに対応しています。 数週間前から良いフィードバックをいただいていますが、これまでは多くのドキュメントを公開していませんでした。 最近、PodmanやPodmanのデスクトップでの使用に関する質問が、特にMac周辺で多く寄せられるようになりました。 偶然にも、非常にエレガントな解決策がありますのでご紹介します。 最近リリースされたPodman-3.3.1では、IntelベースのMacに対応しました。 これはコマンドラインで動作し、brew（ Homebrew ）でインストールすることができます。 *1 macOSでのユーザーエクスペリエンス ユーザーエクスペリエンスは非常にシンプルです。 brewをインストールする（ Homebrew に記載されている通り） brewからpodmanをインストールする： brew install podman podman machineを初期化する: podman machine init マシンの起動： podman machine start 通常通り、podmanを使用します。 podman machine --help を実行して、マシンの管理に使用する他のコマンドに慣れることをお勧めします。 Podman machineはまだ開発中ですのでご注意ください。MacやLinuxでのポートフォワーディングはサポートしていますが、ファイル共有やバインドマウントのソリューションは実装していません。 現在、パフォーマンスの高いアプローチを選択したいと考えているため、そのための様々な技術を研究しています。 Podman machineは現時点でLinuxとIntel Macでのみサポートされています。 Apple Siliconをベースにした新しいMacに関しては現在2つのことを待っています。 まず、アップストリームのqemuでパッチがマージされてリリースされるのを待っています。 アップストリームのパッチを待つ間、私たちはqemuの回避策を検討しています。 これが成功すれば、PodmanのM1サポートを再び有効にして、brewをアップデートする予定です *2 。 2つ目は、 Fedora CoreOS aarch64 イメージをインデックス化する必要がありますが、これはまもなく行われるはずです *3 。 Windowsでのユーザーエクスペリエンス 現在、私たちはWindowsプラットフォームをサポートしており、リモートクライアントは GitHubのリリースページ からダウンロードすることができます。 このリモートクライアントには、Podmanと(Podmanの)サービスが動作しているLinuxサーバーが必要です。 また、WSLでPodmanを動作させるのは非常に便利だというユーザーの報告もあります。 PodmanがインストールされたLinuxサーバーが利用できない場合は、WSLの利用をご検討ください。 私たちはPodmanのMacとWindows用のデスクトップエクスペリエンスを開発する予定です。 初期のデザイン作業は検討中です。タイムラインはまだ特定されていません。 質問はありますか？ 私たちの開発チームは、 libera IRC の#podmanチャンネルにブリッジされた Matrix room や、 Discord server にいることを覚えておいてください。 また、私たちの プロジェクトページ を通じて、Issue、PR、Discussionを開始することができます。皆様からのご意見をお待ちしております。 Podmanはオープンソースのプロジェクトです。Podmanとコンテナの世界で機能を加速させるために協力していただける方を常に募集しています。 *1 : macOS用パッケージマネージャーであるHomebrewを操作するコマンドがbrew *2 : M1に対応したbrewのパッケージの更新は間もなく行われる見込み。 https://github.com/Homebrew/homebrew-core/pull/85173 *3 : 34.20210821.3.0から公式にaarch64イメージが提供されるようになりました。 https://github.com/coreos/fedora-coreos-tracker/issues/13

レッドハットのソリューションアーキテクトの森です。 クラウドネイティブなCI/CDを実現する手段として、OpenShift Pipelines（Tekton）という機能が今年の5月にGAとなりました。 Red Hat Decision Manager / Process Automation Manager においても、OpenShift Pipelinesと連携し、CI/CDパイプラインを構築して開発・リリースサイクルの自動化をよりお手軽に行うことが可能となっています。 今回は、OpenShift Pipelines を使用して、デシジョンサービスのデプロイを自動化する仕組みを実際に動かしてみたいと思います。 OpenShift Pipelines の詳細については、こちらの記事も合わせて参照ください。 rheb.hatenablog.com rheb.hatenablog.com 事前準備 1) 使用するプロジェクトを自分のGithubのリポジトリに Fork する こちらのリポジトリ から Fork してください。 プロジェクトの構成について decisions-showcase : DMN で実装するデシジョンサービス business-application-service : SpringBoot で実装されるデシジョンサービスの実行サーバー business-application-webclient : デシジョンサービスを実行するためのWebアプリケーション cicd : アプリケーションへのデプロイを自動化するためのCI/CDパイプラインを実装するためのリソース 2) Fork したリポジトリを、ローカルPCに Clone する git clone https://github.com/${yourgithubuser}/business-automation-showcase.git cd business-automation-showcase 3) シェルスクリプトを実行して、環境をセットアップする 先に oc login コマンドを使用して CLI にログインした状態にしておき、ローカルに Clone したフォルダにある以下のシェルスクリプトを実行してください。 ./provision.sh namespace rhdm-kieserver-cicd の作成 OpenShift Pipelines (Tekton) と リソースのインストール Webアプリケーションのデプロイ が行われます。 以下のような出力が表示されればOKです。 出力される2つのURLは、GithubからのWebhookを受け付けるエンドポイントと、WebアプリケーションへのURLになります。 ****************************************************************** Use this URL in your GitHub Webhook configuration for automatic deployment http://el-ba-cicd-event-listener-rhdm-kieserver-cicd.apps.cluster-81aa.81aa.sandbox453.opentlc.com Use this URL to access the front-end application: http://business-application-webclient-rhdm-kieserver-cicd.apps.cluster-81aa.81aa.sandbox453.opentlc.com ****************************************************************** Provisioning done! (Completed in 0 min 25 sec) Webhook の設定 次に、Github のリポジトリ側で、Webhookの設定を行います。先ほど Fork した自分のGitリポジトリにアクセスし、"Settings" -> "Webhooks" から新規のWebhookを設定します。 以下の情報をフォームに入力します: Payload URL: provision.sh 実行後に出力される1つ目のURL (以下のコマンドを実行することで取得も可能 oc get route el-ba-cicd-event-listener --template='http://{{.spec.host}}' ) Content type: application/json Secret: 空欄 Which events would you like to trigger this webhook?: Just the push event パイプラインによるデプロイを試してみる 1) ローカルPCに clone をしたプロジェクトフォルダに、ターミナルからアクセスをします。 2) とりあえず commit をして push をします。必要に応じて、以下の空のコミットサンプルを使用してください. git commit -m "an empty commit to test the pipeline" --allow-empty git push origin master 3) OpenShfit の Webコンソールを開き、"Developerパースペクティブ" -> "Pipeline" -> "ba-cicd-pipeline の最終実行の Pipeline Run" を開きます。 Webhook の設定が正しくできていれば、Github への push をトリガーにして、パイプラインが実行されているはずです。 ※ 初回実行時には、Mavenの必要なプラグインや依存関係で必要なものをダウンロードするため少々時間がかかります。 4) デプロイが完了したら、Webアプリケーションを開き、デシジョン実行サーバのURLと認証情報を入力して接続テストをします。 まずはデシジョン実行サーバのURLを取得します。OpenShfit の Webコンソールを開き、"トポロジー" -> " business-application-service-d" -> "Routes" のURLをコピーしておきます。 次に、Webアプリケーションを開いてください。（"トポロジー" -> "business-application-webclient" -> "Routes"） 右上の歯車アイコンの設定を開きます。 出てきたフォームに、以下の情報を入力して、接続のテストを行ってください。 Successと表示されればOKです。コピーした実行サーバのURLは、末尾に /rest/server をつけるのを忘れないでください。 Kie Server Base URL : {route URL}/rest/server Kie Server Username : kieserver Kie Server Paseeword : kieserver1! 5) それでは、実際にデプロイしたサービスを実行してみましょう。Webアプリケーションの左メニューの Decision Models(DMN) を選択し、Decision Name は car-insurance-premium を選択します。入力データのフォームが表示されるので、試しに以下のように入力してみてください。 Grade: 7 Age: 40 Licence: Gold Annual mileage: 8000 入力したら、下部の Submit を入力します。入力したデータと共に、基本保険料、各種割引率と、割引後の保険料が表示されます。 デシジョンの内容を変更してデプロイしてみる 1) 今回の自動車保険の保険料算出のルールを解説していきます。 年齢に応じて基本保険料を決定し、等級や免許証の色（ゴールド免許／ブルー免許）、年間走行距離に応じて割引を行い、割引適用後の保険料を算出します。 （実際のルールは、車種や車両保険有無など、色々な条件がありますが、ここでは簡略化して表現しております） DMNのダイアグラム 年齢による基本保険料 年齢 35歳未満 35〜49歳 50〜54歳 55〜59歳 60〜65歳 65歳以上 基本保険料 42,000 35,000 32,000 34,000 36,000 40,000 等級による割引率 等級 1等 2等 3等 4等 5等 6等 7等 8等 9等 10等 11等 12等 13等 14等 15等 16等 17等 18等 19等 20等 割引率 +64% +28% +12% -2% -13% -19% -30% -40% -43% -45% -47% -48% -49% -50% -51% -52% -53% -54% -55% -63% 免許証の色による割引率 免許証の色 Gold Blue 割引率 -11% 0% 年間走行距離による割引率 年間走行距離 3,000km以下 7,000km以下 11,000km以下 11,000km以上 割引率 -24% -12% -6% 0% 2) VSCode で Clone したプロジェクトを開き、 {$workspace_path}/business-automation-cicd-showcase/decisions-showcase/src/main/resources/com/redhat/demos/dmn フォルダの、 car-insurance-premium.dmn を開きます。 ※ VSCode で DMN ファイルを編集する方法については、以下の記事を参照してください。 rheb.hatenablog.com grade discount rate のデシジョンを選択して、編集アイコンをクリックします。 3) 等級に応じた割引率が、デシジョンテーブルで設定されています。7行目の grade（等級）が 7等 の場合の割引率を、 "-0.30" -> "-0.35" に変更をしてみましょう。 4) 変更を保存し、変更内容を commit して push します。デプロイのパイプラインがスタートしますが、テストが失敗してパイプラインの実行が中断してしまいます。 5) 等級による割引率のルールを変更したので、シナリオテストの期待値と結果が不一致となったことでテスト失敗となりました。テストに合格するために、出力の期待値を変更する必要があります。 {$workspace_path}/business-automation-cicd-showcase/decisions-showcase/src/test/resources/com/redhat/demos/tests フォルダ内の、 car-insurance-premiumTest.scesim を開きます。 1行目のテストが、grade:"7" を入力としています。テストの1行目の期待値を、変更した内容に応じた出力と一致するように、期待値を変更しましょう。以下のように変更しておきます。 discounted premium : 17543.68 -> 16290.56 grade discount rate : -0.30 -> -0.35 6) 変更したら、commit して push します。デプロイのパイプラインがスタートするので、完了まで待ちましょう。 7) 完了したら、Webアプリケーションを開き、先ほどと同じ入力でデシジョンルールを実行してみます。 変更したルールの内容に応じて、出力結果が変わっていることを確認することができます。 終わりに いかがでしたでしょうか？ OpenShift Pipelines で CI/CD開発環境を構築し、デプロイの自動化を行うことで、Red Hat Decision Manager / Process Automation Manager の開発をより効率的に行うことができるようになります。ぜひ試してみてください。

みなさんこんにちは、レッドハットでソリューションアーキテクトをしている暮林といいます。 SREのためのMetrics-driven transformation(MDT) というタイトルで数回の連載をしたいと思います。 Metrics-driven transformationとは？ Pelorusとは Pelorusのアーキテクチャー Pelorusのインストール 次回予告 Metrics-driven transformationとは？ 聞き慣れない方が多いかと思いますがこちらに英語の短いビデオがあって説明されています。 www.redhat.com このビデオでは、Digital TransformationのためにDevOpsをするぞ！となっても、いざやってみると何をどうかえていけばわからないという問題に直面するよね、ということを述べた後に、では組織として計測するべきKPIは何でしょう？というところを少しだけ語って終わってしまいます。 計測すべきKPIについては少し先で解説しますが、そもそもなんのためにKPIを計測するのか？ということを紐解くと、ビデオの登場者はこういうことであるといっています。 MetricsはPractice（習慣の意味が近い）に情報を与える （さもなくばどうやってPracticeを評価するのか？） PracticeはCultureを変化させる（Cultureはトップダウンでは変化させられない） Cultureの変化がTransformationをUnlockする きれいかつ少々強引とも言える3段論法ですが、もし自分の所属している組織の文化改革はむずかしい！と考えている方がいらっしゃるのであれば、まずは数値として組織の状態を計測するところから始める、ということを頭の片隅においてみてください。（ダイエットの開始も体重を測るところからですよね！？） Pelorusとは PelorusはKonveyerのProjectの1つで、Kubernetes上でのSoftware Delivery Performanceを計測するためのツールです。 github.com 本連載では「SREのための」と銘打ってますが、本来の意味でPelorusが目指すのは組織全体のTransformationの可視化なので、SRE組織に限定せず経営可視化用のダッシュボードを目指しています。 PelorusのダッシュボードはCloud Native界隈では有名なGrafanaを用いており、下記のような姿をしています。 PelorusがKPIとしている数値は以下の4つです。 Lead Time for Change Deploy Frequency Mean Time to Restore Change Failure Rate ここで思い出していただきたいのはSREの本来の役割です。SREは経営に対して約束したSLAを維持しつつ、Error Buggetの消費を極力抑えながら高速Deploymentを行い続ける集団です。従来の分業体制ではSLAを維持する係とDeploymentを行う係は分業されており、両者には利害関係が発生するためSLAの維持と高速Deploymentは相反する要素になってしまっていました（OpsのSLAがDevのDeploymentを阻害する）。これを解決していく考え方がSREです。 SREについてはちょっとしたまとめが下記のサイトにあります。ここで登場するSLI（サービスレベルインジゲーター）の役割の一部を担うのがPelorusです。 www.redhat.com Pelorusのアーキテクチャー Pelorusのアーキテクチャーは下記のドキュメントで解説されています。 pelorus.readthedocs.io Pelorusが主に利用しているのは、Grafana、Prometheus、Thanosの３つですが、このなかではThanosに聞き覚えがない方が多いと思います。 ThanosはCNCFのIncubation ProjectでPrometheusするMetricsを収集するための高可用性メトリックシステムのコンポーネントです。 github.com Thanosのアーキテクチャーもなかなか興味を惹かれる部分ではありますが、一旦脇において話をすすめていきましょう。 Pelorusのインストール pelorus.readthedocs.io Pelorusのインストールには以下の条件が必要です。 OpenShift 3.11 以上の環境 インストールを行えるPC OpenShift Command Line Tool (oc) Helm3 jq git これらに加えて、Software Delivery PerformanceをGithubやJiraから取得する場合は、それらのAccess Tokenが必要になります。 次回予告 次回は実際のOpenShift環境でPerolusをインストールして、下記の簡単なデモの様子をみていきます。 pelorus.readthedocs.io このデモでは、Pelorusがアプリケーションの配信サイクルを通じてどのように変更を捉えていくするかを見ることができます。 Pelorusを初期化すると、既存の保存されたデータを確認してベースラインが設定されます デモスクリプトを実行すると、パイプラインを実行するための新しいコミットが作成されます 新しいバージョンが公開されるたびに、MetricsとTrendが変化するのを見てください 次回につづく

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 この記事は Red Hat Developer の Red Hat CodeReady Containers 1.31.2 makes the leap を、許可を受けて翻訳したものです。 -目次- OpenShift 4.8へのアップグレード インストーラー システムトレイ 新しいネットワークスタック ディスク拡張 まとめ Red Hat CodeReady Containersは、ローカル環境での開発とテストをサポートしたRed Hat OpenShiftクラスタです。私たちは最近、CodeReady Containers 1.31.2をリリースしましたが、これはOpenShift 4.8のメジャーリリースに基づく最初のバージョンになります。CodeReady Containersチームは定期的に我々の進歩を公表していないので、この記事は過去数ヶ月間のCodeReady Containersの最大の変更点を知る良い機会となります。 OpenShift 4.8へのアップグレード このリリースでは、OpenShift 4.8を使用するようにCodeReady Containersを更新しました。このリリースではデベロッパープレビューとしてシングルノードのサポートが提供されています。 また、OpenShiftのMachine Config Operatorを有効にしたことで、ユーザーはレジストリやプロキシの設定、あるいはMachine Config Operatorを使用してクラスタを変更するその他の変更について、OpenShiftのドキュメントに従って行うことができるようになりました。以前のリリースでは、これらの変更にはCodeReady Containers固有の手順が必要でした。次のビデオでは、Machine Config Operator（MCO）を有効にする方法を紹介しています。 youtu.be インストーラー macOSとWindows 10ではネイティブなインストーラー（それぞれ、.pkgファイルと.msiファイル）の提供を開始しています。 ネイティブインストーラーでは要件チェックがより統合され、インストール手順がさらに簡単になりました。 次のビデオでは、macOSでのインストールが30秒以内で完了する様子を紹介しています。 youtu.be インストーラーはインストールの前にオペレーティングシステムにより正しく検証できるように署名されています。これは最近のサプライチェーン攻撃を踏まえると、特に重要です。 macOSとWindowsにCodeReady Containersをインストールして使用する方法としてインストーラーは唯一のサポートされている方法です。 システムトレイ macOSとWindowsの新しいインストーラーにはシステムトレイアイコンが付属しています。 このアイコンを使用して、クラスターの起動や停止といったCodeReady Containersの直接操作が可能です。 OpenShiftインスタンスを管理するために、シェルプロンプトに戻る必要がなくなりました。 新しいネットワークスタック 長年にわたるCodeReady Containersの最大の問題点の1つは、特に企業環境におけるネットワークでした。 crc.testing ドメインをCodeReady Containers仮想マシンへリダイレクトするようにホストシステムのDNSを構成するには、多くの場合スーパーユーザーの特権が必要でした。 さらに、企業のVPNやファイアーウォールが邪魔をしてこの設定が機能せず、エンドユーザーのクラスター接続の問題が発生することもありました。 数リリース前に、gvisorに基づくユーザーランドのネットワークスタックに移行を開始しました。 仮想マシンによる全てのネットワーク通信は、ホスト上で実行するCodeReady Containersデーモンを経由するようになりました。 DNS解決のための /etc/hosts ファイルの使用が改善されたことに加えて、この変更によりネットワーク設定がホスト構成の変更にあまり依存しなくなりました。 また企業ネットワークにおける前述のような問題も回避されています。 この新しいネットワークスタックはWindowsとmacOSでデフォルトとなっています。 ディスク拡張 CodeReady Containersインスタンスはデフォルトで31GBのディスクイメージを使用しますが、これは重いワークロードをデプロイしたいユーザーにとっては十分ではありません。 crc start を実行する際に、 --disk-size または -d コマンドラインオプションを使用して、ディスクのサイズを動的に希望のサイズに拡張可能になりました。 ディスクサイズの変更は拡張のみ可能で、縮小はできません。 次の例はCodeReady Containersインスタンスを40GBに変更しています $ crc start --disk-size 40 macOSやWindowsでは、システムトレイのアイコンを使って簡単にディスクサイズを変更することもできます。 まとめ この記事では、CodeReady Containersチームが過去数ヶ月の間に行った最も注目すべき変更点をまとめましたが、それ以外にもたくさんの細かい改良やバグ修正が行われました。 CodeReady Containers 1.31.2をお試しいただき、何か問題があればご報告いただくことを強くお勧めします。 私たちはこれからもCodeReady Containersの改良、改善をしていきます。 ロードマップには、Podmanの統合やリモートのCodeReady Containersインスタンスとの統合の改善などが含まれていますので、ご期待ください。

こんにちは、Red Hat Specialist Solutions Architect の小杉です。 本日は「マイクロサービスへの上手な分割手法」ということで戦略的 DDD をご紹介します。 一部、戦術的 DDD も含まれております。 kenta-kosugi.medium.com Red Hat のプロダクトには一切触れておりませんが、ご一読ください。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 今回はmacOS上で Podman の実行を可能にする podman machine をご紹介します。 Podmanについては本ブログで以前から多く記事が書かれています。 podman というキーワードで検索して他の記事も是非参照ください。 https://rheb.hatenablog.com/search?q=podman Podmanの使用方法についてはRHEL 8のドキュメントにも日本語で詳細に解説があります。日本語で読めるリファレンスドキュメントですので、Podmanを使用する際のドキュメントとして活用ください。 第1章 コンテナーの使用 Red Hat Enterprise Linux 8 | Red Hat Customer Portal -目次- podman machine とは 非推奨のOSSプロジェクト、boot2podman(podman-machine) podman machine のインストールと実行コマンド Podman for macOSのインストール podman machineの実行 1. podman machineの初期セットアップ 2. podman machineの起動 3. podmanコマンドの実行 自動ポートフォワード podman machineの今後 まとめ podman machine とは PodmanはLinux上での動作を基本とし、Windows版/macOS版はリモートクライアントのみが提供されています。これはつまり、WindowsおよびmacOS上でPodmanを使ってコンテナの各種操作を行うにはリモート接続先となる Linux環境が必須 ということです。Podmanリモートクライアントの詳細な解説については下記記事を参照ください。 www.redhat.com 昨今Windows環境ではWindows Subsystem for Linux(以下、WSL)がOS標準機能として使えるようになり、Windows OS上でLinux環境を実行することが容易になっています。実際にWSL2上のLinux環境でPodmanを動かす事例も公開されています。 www.redhat.com macOSではWSLのようなOS標準で提供されるLinux実行環境はありません *1 。 Hypervisor.framework や Virtualization.framework といったmacOS上で使えるAPIは提供されていますがLinux仮想マシンを実行する機能は別途必要です。 例えば Docker for Mac では Hyperkit というハイパーバイザー上でDocker用のLinux仮想マシンを実行しています。 Podmanでも同様のアプローチでmacOS上でLinux仮想マシンを実行する機能が podman machine です。 podman machine では QEMU を使って仮想マシンを実行します。 podman machine は2021年4月のPodman Community Meetingで動作デモがAshley Cuiによって行われました。Community Meetingのログと録画は下記リンクから参照できます。 https://podman.io/community/meeting/notes/2021-04-06/ この時のデモではうまくいかない部分もありましたが、すでにM1 Mac上で動作しており後述する Fedora CoreOS の仮想マシンを使った基本的な機能は整っていたことが分かります。 その後、 Podman v3.2.0 のリリースで podman machine という新しいサブコマンドとして使えるようになりました。 Podman v3.2.0のリリースノートより抜粋 An experimental new set of commands, podman machine, was added to assist in managing virtual machines containing a Podman server. These are intended for easing the use of Podman on OS X by handling the creation of a Linux VM for running Podman. （翻訳）Podmanサーバーを含む仮想マシンの管理を支援する実験的な新しいコマンドセット「podman machine」が追加されました。これらは、Podmanを実行するためのLinux VMの作成を処理することで、OS X上でのPodmanの使用を容易にすることを目的としています。 podman machineの全体構成は下記のようになります（Podman v3.3.x以降対応）。 podman machineの全体概要 非推奨のOSSプロジェクト、boot2podman(podman-machine) podman machine がリリースされる以前にもmacOS上でPodmanコマンドを使えるようにする試みがありました。それが boot2podman(podman-machine) です。過去形で記載したのはboot2podmanはすでに終了したプロジェクトであり非推奨になっているからです。boot2podmanに関しては下記サイトに一連のポストとして詳細がまとめられています。 https://boot2podman.github.io/ 2020年11月のPodman Community Meetingでは作者のAnders F Björklundによりプレゼンがあり、コンテナの歴史からboot2podmanのベースになったTiny Core Linuxについて、非推奨になった理由（Podman v2からVarlink APIからREST APIへ変更）などについて解説されています。Comunity Meetingの録画やプレゼン資料のリンクは下記から。 https://podman.io/community/meeting/notes/2020-11-03/ [※ 注意 ※] boot2podmanは podman-machine という名前のコマンド（ハイフンあり）でした。Podmanの新しいサブコマンドの podman machine とは ハイフンあり無しの違い しかないですが全くの別物となります。ご注意ください。 podman machineとは別物のboot2podman(podman-machine)は非推奨 podman machine のインストールと実行コマンド macOSへのPodmanのインストールと podman machine の実行方法について解説します。以降はIntel版のmacOS(Big Sur 11.5.2)上での動作になります。 Podman for macOSのインストール macOSへのPodmanのインストールは brew を使うのが簡単でおすすめです *2 。 brewでPodmanをインストール $ brew install podman Podmanのインストールの依存関係でQEMUも同時にインストールされます Podmanの依存関係パッケージ（qemu）の確認 $ brew deps --1 podman qemu Podman v3.3.0以降、Podmanコマンドと同時に gvproxy コマンドもインストールされます（ gvproxy については後述）。それぞれのコマンドは下記にインストールされます。 $ which podman gvproxy /usr/local/bin/podman /usr/local/bin/gvproxy [Note:] Podmanの新しいバージョンがリリースされた直後はすぐにbrewで更新ができない場合があります。そうした場合は brew unlink コマンドを実行することでパッケージをアンインストールすることなく一時的にbrew版のPodmanの使用を停止できます。その後、GitHubのリリースページより入手したパッケージをコピーして使用することできます。元に戻す場合は brew link を実行します。 $ brew unlink podman Unlinking /usr/local/Cellar/podman/3.3.1... 165 symlinks removed. $ cp ./podman /usr/local/bin/ $ which podman /usr/local/bin/podman ※ 現時点(2021年9月6日、時点)ではmacOS用リリースアーカイブには gvproxy は含まれていませんので、別途下記より入手して実行パスへコピーしてください https://github.com/containers/gvisor-tap-vsock podman machineの実行 podman machin の実行は下記の手順で行います。 podman machine の初期セットアップ podman machine の起動 podman コマンドの実行 なお、環境によってはPodmanコマンドの初回実行時に通信の許可を求めるポップアップが表示されます。 Allow を押してPodmanコマンドによる通信を許可します。 Podmanコマンド初回実行時に通信の許可を求めるポップアップ 1. podman machine の初期セットアップ podman machine init コマンドを使用して初期セットアップを行います。この作業の中で podman machin で実行するFedora CoreOSの仮想マシンイメージ(qcow2)がダウンロードされます。 $ podman machine init Downloading VM image: fedora-coreos-34.20210821.1.1-qemu.x86_64.qcow2.xz: done Extracting compressed file イメージのダウンロードは初回のみ行われ、二回目以降のセットアップはダウンロード済みイメージから行われます Fedora CoreOSは定期的にアップデートが行われており、初期セットアップの実行タイミングによっては新しいイメージのダウンロードが行われます ダウンロード済みのイメージは下記に保存されています。 *.qcow2.xz がダウンロードしたアーカイブで *.qcow2 が展開された実行用の仮想マシンイメージです。 $ ls -l ~/.local/share/containers/podman/machine/qemu/ total 4327440 -rw-r--r-- 1 shtanaka staff 630260008 9 6 04:59 fedora-coreos-34.20210821.1.1-qemu.x86_64.qcow2.xz -rw------- 1 shtanaka staff 1561722880 9 6 05:00 podman-machine-default_fedora-coreos-34.20210821.1.1-qemu.x86_64.qcow2 2. podman machine の起動 podman machine の起動は podman machine start を実行します。 $ podman machine start INFO[0000] waiting for clients... INFO[0000] listening tcp://0.0.0.0:7777 INFO[0000] new connection from to /var/folders/df/vy1htn753fd_w4420rltfg0w0000gn/T/podman/qemu_podman-machine-default.sock Waiting for VM ... qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2] v3.3.1時点では podman machine start 最終行にwarningが表示されますが、これについては無視しても問題ありません。詳細は下記Issueを参照。 https://github.com/containers/podman/issues/11421 podman machine が正常に起動しているか確認します。 $ podman machine ls NAME VM TYPE CREATED LAST UP podman-machine-default qemu About an hour ago Currently running Currently running となっていればOKです。 なお、 podman machine を停止する場合は podman mahcine stop を実行します。 $ podman machine stop $ podman machine ls NAME VM TYPE CREATED LAST UP podman-machine-default qemu About an hour ago About a minute ago 停止した podman machine を再開する場合は podman machine start を再度実行します 3. podman コマンドの実行 busyboxコンテナイメージを使った「hello world!」の実行 $ podman run --rm -it docker.io/library/busybox echo -e '\n hello world!' Trying to pull docker.io/library/busybox:latest... Getting image source signatures Copying blob sha256:8ec32b265e94aafb0d43ab71f1d8f786122c19afb37d25532aea169f414f8881 Copying blob sha256:8ec32b265e94aafb0d43ab71f1d8f786122c19afb37d25532aea169f414f8881 Copying config sha256:42b97d3c2ae95232263a04324aaf656dc80e7792dee6629a9eff276cdfb806c0 Writing manifest to image destination Storing signatures hello world! このようにmacOS上であたかもローカルでPodmanコマンドを実行しているかのようにコンテナの実行ができます。 自動ポートフォワード Podman v3.3.0 から gvpoxy を使った自動ポートフォワード機能が追加されました。 Podman v3.3.0のリリースノートより抜粋 Containers inside VMs created by podman machine will now automatically handle port forwarding - containers in podman machine VMs that publish ports via --publish or --publish-all will have these ports not just forwarded on the VM, but also on the host system. （翻訳）podman machine で作成された VM 内のコンテナは、ポートフォワーディングを自動的に処理するようになりました。--publish または --publish-all でポートを公開した podman machine VM 内のコンテナは、これらのポートが VM 上だけでなく、ホストシステム上にも転送されます。 Podman v3.2.xではコンテナで公開したポートごとに手動でポートフォワードを追加する必要がありましたが、v3.3.0以降は gvproxy を使用して自動で行われるようになってより便利になりました。このため、v3.3.0以降で podman machine を実行するにはmacOSホストの実行パスに gvproxy コマンドが必要となります *3 。 macOSホスト上に自動的にポートフォワードが行われることをテストしてみます。 $ podman pull docker.io/library/nginx $ podman run --rm -d --name nginx -p 8888:80 --network bridge nginx $ curl http://localhost:8888 |head -n 4 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 612 100 612 0 0 76500 0 --:--:-- --:--:-- --:--:-- 76500 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> $ netstat -an |grep 8888 tcp46 0 0 *.8888 *.* LISTEN このようにTCP:8888で公開したnginxコンテナにローカルホストのmacOS上からcurlでアクセスできました。また、 netstat コマンドで待ち受けポートを確認すると、TCP:8888でリッスンしていることが確認できます。 [Note:] Podman v3.3.1時点でこの機能には不具合があり、上記のように --network bridge をつけるか、他にも事前に podman network create で作成したネットワークを指定する方法や containers.conf ファイルの [containers] セクションに rootless_networking = "cni" を追加する、などのワークアラウンドがあります。 この不具合については私の上げた下記Issue（すでにClose済み）で対応がなされており、次のバージョン（v3.3.2？）に修正が適用される見込みです。 [podman machine] Port auto-forwarding does not work in rootless mode and macOS · Issue #11396 · containers/podman podman machineの今後 podman machine はリリースされて間もないため下記のような点で機能が整っていない部分もあります。 M1 Mac上での実行 ボリュームマウントの改善 macOS版VS Code上でのRemote Containers実行 現時点（2021年9月6日、時点）ではM1 Macで実行するためにはQEMUにパッチを当てる必要があります。QEMUのアップストリームでパッチがマージされるまでは手動で適用するなどの回避策が必要です。問題については下記Issueで対応が続いています。 [macos] podman machine start on Apple M1 uses qemu with hvf which is not yet supported by qemu on aarch64 · Issue #10577 · containers/podman macOS上のディレクトリをコンテナにマウントしたり、VS CodeのRemote Containersを起動したりすることは今のところできませんが、これらの機能についてもコミュニティ上で議論が続いており今後の機能改善が期待されます。 Support native source folder for volume mount in remote model · Issue #8016 · containers/podman On macOS Remote-Container (Visual Studio Code) doesn't work · Issue #11436 · containers/podman まとめ macOS上で簡単に仮想マシンを立ち上げてPodmanコマンドを実行できるサブコマンドの podman machine についてご紹介しました。 macOSではOS標準で使えるLinux環境が無いためこれまではPodmanの使用は非常に限られた方法しかありませんでしたが、Podmanの標準機能の podman machine を使うことでmacOS上で簡単にPodmanコマンドが使用できるようになりました。 しかしながら podman machine 自体もまだまだ発展途上で実用的に使うにはまだまだ不足している機能は多くあります。でも、そこはOSS。開発途中のバージョンを入手して実行したり、フィードバックをコミュニティに直接送って改善に寄与することができます。これを機にOSS活動に興味を持たれましたら是非様々な手段でPodmanの開発コミュニティに参加してみてください。 Join Our Community *1 : Limaのような先進的なOSSプロジェクトは別途ありますがAppleから提供されるOS標準機能は今のところありません *2 : GitHubのリリースページからバイナリをダウンロードしてインストールも可。その場合はアップデートなども手動で行う必要あり *3 : gvproxyが無い場合はエラーとなってpodman machineが起動しない

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。 去年こんな記事を書きました。 rheb.hatenablog.com 最近アーリーアクセス版としてリリースされた Ansible Automation Platform 2.0 を使って、Red Hat Insights との連携を改めて紹介しようと思います。 Red Hat Insights は SaaS として提供しているサービスで、RHEL のサブスクリプションをお持ちであれば追加費用なくご利用いただけます。Insights について詳しく知りたい方は、こちらをご覧ください。 Insights を使うことで、例えばよくご質問いただく「この新しく発行された CVE はいま使っているシステムにどのような影響がありますか」というような問題の対応状況を、お客さま側から能動的に確認していただくことができます。 www.redhat.com 全体像を大まかに説明するとこのような図になります。 RHEL を登録 RHEL をインストールしたら、subscription-manager と insights-client で登録します。インストーラの処理の中で登録することもできますが、改めてコマンドラインから進めるとこのようになります。sed のエラーは気にしないでください。 [sugimura@localhost ~]$ sudo -s [sudo] sugimura のパスワード: [root@localhost sugimura]# [root@localhost sugimura]# hostnamectl set-hostname myrhel82 [root@localhost sugimura]# hostname myrhel82 [root@localhost sugimura]# [root@localhost sugimura]# subscription-manager register 登録中: subscription.rhsm.redhat.com:443/subscription ユーザー名: xxxxxxxxxxxx@example.com パスワード: このシステムは、次の ID で登録されました: XXXXXXXXXXXXXXXXXXXXXXXXXXX 登録したシステム名: myrhel82 [root@localhost sugimura]# [root@localhost sugimura]# dnf install insights-client -y ... [root@localhost sugimura]# insights-client --register You successfully registered XXXXXXXXXXXXXXXXXXXXXXXXXXX to account 999999999. Successfully registered host myrhel82 Automatic scheduling for Insights has been enabled. Starting to collect Insights data for myrhel82 sed: /sys/kernel/debug/sched_features を読み込めません: 許可されていない操作です Uploading Insights data. Successfully uploaded report from myrhel82 to account 999999999. View the Red Hat Insights console at https://cloud.redhat.com/insights/ [root@localhost sugimura]# RHEL 8.2 と 8.4 のものをそれぞれ1台ずつ登録してみました。 カスタマーポータルから見るとこのようになっています。 以前は https://cloud.redhat.com として提供されていた Insights のサイトですが、最近 https://console.redhat.com になりました。Red Hat Hybrid Cloud Console という名前になったようです。 Hybrid Cloud Console にアクセスしてみると、このようになっていました。RHEL の欄で 2 Connected systems と認識されていることがわかります。 数字の 2 のところが inventory へのリンクになっていて、クリックすると先ほどの RHEL 2台が登録されていることがわかります。 Dashboard をクリックするといまどのように Insights が判断しているかを知ることができます。他のメニューもあちこち覗いてみてください。 Insights Dashboard の画面ではいま登録している RHEL には既知の問題はあるものの、インストールされているパッケージの状況から判断すると修復を推奨するような問題はなかったことがわかります。右側の Advisor recommendations です。 Advisor からやれることがないので、Vulnerability -> CVEs を見てみます。いまインストールされている状況には影響がないものではありますが、既知の問題としてはたくさん見つかりました。 右の方にある Ansible のマークがある欄にチェックが入っているものは、問題を修復するためのプレイブックをここで生成できるものです。試しに一つ CVE-2021-3621 をクリックしてみます。RHEL 8.2 と 8.4 の両方に適用できるものであることはわかりました。チェックを入れると　Remediate のボタンが押せるようになります。この CVE は RHSA-2021:3151 で更新されるということもわかります。 Remediate ボタンを押すと、修復のためのプレイブックを作成します。適当に名前をつけて保存しておきます。一度作ったプレイブックに追加していくこともできます。 メニューから Remediations を開くと、プレイブックが作られて保存されていることがわかります。ダウンロードすることもできます。 ここからプレイブックをダウンロードしてきて Ansible を起動するサーバから実行して実際の適用作業を実施していただくことができるのですが、せっかくなので Ansible Automation Platform と連携して実行しようというのが今回の記事の目的です。 Ansible Automation Platform 2.0 Ansible Automation Platform 2.0 は7月半ばにリリースされました。 こちらに情報がまとまっていますので、ご興味ある方はご覧ください。従来の Ansible Tower と呼ばれていたものは、Ansible Controller 4.0 として生まれ変わりました。 access.redhat.com docs.ansible.com Ansible Automation Platform 2.0 と Insights の連携 ようやくここからが本題です。 Ansible Tower の時代でもできたことではあるのですが、Ansible Automation Platform 2.0 (AAP 2.0) では機能が改善され、より簡単に使いやすくなりました。 まずは認証情報として、Insights にアクセスするためのものと、今回対象としている2台のRHELサーバのためのものをそれぞれ作ります。 Insights と連携するためのインベントリを作ります。この時点では空っぽです。 このインベントリで、Insights から構成を取得するためのインベントリーソースを定義します。これは AAP 2.0 での新機能です。この検証環境では名前解決ができないので、compose: の定義を使って ansible_host 変数をIPアドレスに置き換えています。 定義したら Sync を押してみます。ジョブが実行されて、Insights からホスト情報をインベントリに取り込みました。 先ほど定義したインベントリに2台登録されていることがわかります。 この2台にチェックを入れて、Run Command から ad hoc コマンドとして ping を実行してみます。 Module は ping を選びます。Enable privilege escalation にもチェックを入れておきます。 Execution Environment を選びます。今回は Default にしてみます。Default EE では、ansible-core 2.11 を使います。 認証情報を選んで起動します。 正しく疎通確認できました。ping モジュールでの疎通ができたということは、このインベントリ情報と認証情報を使って対象の RHEL サーバに Ansible から操作ができるということが確認できたということです。 Insights のインベントリについて連携できることがわかりました。次に、プレイブックについても連携してみます。 Projects から Insights 用のプロジェクトを作ります。Source Control として Red Hat Insights を選びます。設定を保存するとすぐに同期します。 この同期したプロジェクトを利用するジョブテンプレートを作成します。インベントリとプロジェクトを指定すると、プレイブックのプルダウンリストに Insights の Console 画面で作ったものが取り込まれていることがわかります。 Ad hoc コマンドを実行したときと同じように Execution Environment や認証情報、Privilege Escalation のチェックを入れて、ジョブテンプレートを保存します。 Launch ボタンを押して実行すると実際にアップデートが走ります。再起動も必要だったこともあり、2分弱ほどで終わりました。 この対象の RHEL にログインしてみると、Insights で作った CVE-2021-3621 のための修正がきちんと反映されていることがわかります。 [sugimura@myrhel84 ~]$ sudo dnf history [sudo] sugimura のパスワード: Updating Subscription Management repositories. ID | コマンドライン | 日時 | 動作 | 変更さ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 5 | upgrade -v -y --cve CVE-2021-3621 | 2021-08-26 17:00 | Upgrade | 9 … [sugimura@myrhel84 ~]$ [sugimura@myrhel84 ~]$ sudo dnf history info 5 Updating Subscription Management repositories. トランザクション ID : 5 開始時間 : 2021年08月26日 17時00分02秒 開始 rpmdb : 605:88810ebe1e6466fbbdc177ac243764aa0e6f2576 終了時間 : 2021年08月26日 17時00分03秒 (1 秒) 終了 rpmdb : 605:694a2971837161a7a95ac54bff516b0b93ccabe5 ユーザー : <sugimura> 終了コード : 成功 Releasever : 8 コマンドライン : upgrade -v -y --cve CVE-2021-3621 コメント : 変更されたパッケージ: Upgrade libsss_autofs-2.4.0-9.el8_4.2.x86_64 @rhel-8-for-x86_64-baseos-rpms ... 正しく実行できたら、Insights 側でアーカイブしておきます。 振り返り 設定手順を一通り説明したため、大変なように感じられたかもしれません。 一度一通り流れる方法が確立できれば、あとは普段はこのように運用していくことができます。 更新のメールを受け取る Hybrid Cloud Console の Insights で Dashboard から影響を確認する 修正が必要であれば Advisor recommendations や CVEs からプレイブックを作成する Automation Controller で同期して実行する 終わったらアーカイブする おわりに 今回は Ansible Automation Platform 2.0 を使った Red Hat Insights との連携について紹介しました。以前の Ansible Tower と比べると画面やアーキテクチャが一新されており、より簡単に実行できるようにもなりました。 Developer Subscription でもお試しいただけますので、ご興味持たれましたら試してみてください。 rheb.hatenablog.com Happy Automation!

Red Hatのソリューションアーキテクトをしている杉本 拓です。 Red Hat にはクラウドネイティブアプリの開発に役立つ、ソフトウェアのラインナップが充実していることをご存知ですか？ ここでは、それらのソフトウェア [Red Hat Application Services] に関する注目ニュースを、各製品技術に特化したソリューションアーキテクトが、ご紹介します。 今回は 2021/9月号となります。 想定読者 エンタープライズアーキテクト アプリケーション開発者 システムの提案をするSIerの方 特集1: Red Hat Data Grid 8.2 新機能 先日Red Hat Data Grid 8.2 がリリースされました。このバージョンでは拠点横断レプリケーションの機能拡張の他、コンソールやData Grid Operator、Grafanaダッシュボードなど運用監視をするために便利なツール群が拡張されました。 ぜひご一読いただき、高い可用性もつシステムを実現するための参考にして下さい Red Hat Data Grid 8.2 新機能 from Chihiro Ito www.slideshare.net 特集2: Avro スキーマを使用した Apache Kafka クライアント開発 #2 アプリケーション開発編 マイクロサービスを考慮する上で、非同期メッセージングミドルウェアは重要なポジションを占めるようになってきました。非同期メッセージングミドルウェアのうちの一つに Apache Kafka があります。Apache Kafka に投入できるメッセージをバイナリに変換するためのフレームワークとして Apache Avro や Protocol Buffers 等がありますが、今回は Red Hat Integration に含まれる Service Registry を利用して Apache Kafka に投入するメッセージのスキーマを Apache Avro で定義し、Apache Kafka のコンシューマー/プロデューサー(Quarkus で開発) から Service Registry 上に登録したスキーマを利用してマーシャリング/アンマーシャリングを自動実行するコードを記述してみました。 Service Registry には後方互換性や前方互換性が用意されていて、コンシューマーやプロデューサーがスキーマを変更しても影響が極力でないような仕組みを持たせることができます。 kenta-kosugi.medium.com 特集3: ”ルール駆動開発”において業務ルールの抽出は実際どうやるんですか？ ブラックボックス化したレガシーアプリのモダナイズ手法として、また、ビジネス変化に迅速に対応可能なアプリケーションの開発手法として、「ルール駆動開発」という手法があります。 ルール駆動開発は、業務ルールの実装に主眼をおいた開発手法ですが、皆さんから寄せられる質問で、 「膨大な既存システムの要件から、どうやって業務ルールを抽出するのか、そこがよくわからない」という質問が多くあります。 そこで、今回は、ルール駆動開発では、どのように業務ルールを抽出していくのか、その方法について解説しました。 qiita.com 好評開催中！クラウドネイティブアプリ開発関連のWebinar全６回 Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション コンテナ時代の開発ツールチェインと開発プロセスのベストプラクティス クラウド/コンテナを前提とした時代のアプリケーション実行環境の選択 マイクロサービス/サーバーレス実践入門 これからのシステム連携を実現するデジタル基盤とアプローチ Cloud Nativeなデータパイプラインの作り方とオープンハイブリッドクラウドへの展開 各回とも、オンデマンドで視聴出来ます。（お名前とメールアドレス等の登録のみで視聴可能です） 下記リンクよりぜひご登録ください。 www.redhat.com 直近GAになった製品群 最近リリースとなった Application Services 製品群のリストをご紹介します。 見逃している製品が無いか、是非一度ご確認ください。 Red Hat Fuse 7.9 Red Hat Integration 2021 Q3 Camel K AMQ Streams 1.8 Red Hat build of Quarkus 1.11 Red Hat JBoss Web Server 5.5 Red Hat support for Spring Boot 2.3 Red Hat build of Eclipse Vert.x 4.1 Red Hat JBoss Enterprise Application Platform 7.4

Red Hat エンジニアリングの佐藤匡剛です。 先日 ApacheCon Asia 2021 にて、 Integration as a Script -- Integration made easy with Apache Camel and JBang という発表を行いました。 発表は英語でしたが、同じ内容を日本語で記事にしたのでこちらに紹介します。 JBang は、Javaをスクリプトのように実行できるツールです。日本での知名度はまだまだ低いですが、Quarkusのエンジニアが開発していることもありモダンなJava開発環境との連携が充実しており、非常に将来性があるツールです。この発表／記事では、そのJBangとApache Camelを組み合わせることで、どんな面白いことができるかを紹介しています。 zenn.dev

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 最近色々なカンファレンスやWebの記事などでトランクベース開発について目にする機会が増えてきました。 トランクベース開発とは、一言で言えばGitを使った開発におけるブランチ戦略の一種です。Gitのブランチ戦略というと有名なものであれば、Git FlowやGitHub Flowなどがありますが、トランクベース開発は、CICDと組み合わせた開発の効率化や高頻度のデプロイという点で昨今注目を集めています。 本記事ではそんなトランクベース開発についてご紹介したいと思います。 そもそもなぜブランチ戦略が必要か？ トランクベース開発の説明をする前に、そもそもブランチ戦略とは何かについて考えてみましょう。 例えば、一人で個人的なプロジェクトに取り組む場合、Gitで複数のブランチを使う動機はほぼ無いでしょう。アプリケーションを開発するのもレビューするのも自分自身であるため、Gitリポジトリ上の一本のブランチに対し直接変更をPushしていっても特に問題はありません。 一方で複数人が一本のブランチで開発する場合はどうなるでしょうか。 別々の開発者が任意のタイミングで変更を次々にPushしていくとなると、メインブランチには複数の変更が常に入り乱れた状態となりコード品質の担保や、コードの全体像の把握が難しくなります。 こうした状況を防ぐにはある開発者が実施した作業箇所に対し別の開発者がレビューするなど、品質担保の仕組みが必要となります。 メインブランチ以外のブランチが必要となるのはまさにこの理由からです。 一本のブランチで開発を進める代わりに、個々人が行う開発はメインブランチから分岐したブランチ（featureブランチなど）で実施し、開発が完了したらメインブランチへのマージリクエストを投げます。このマージリクエストの中でレビューを行い、問題が無ければマージを承認、メインブランチに統合するというプロセスを踏むことで、コード品質を保ちながらメインブランチへ変更を追加することが可能になります。 上の図は非常に単純な例ですが、実際の開発では複数のfeatureブランチが併存したり、またこれ以外にもリリースやバグフィックスなどのタイミングでブランチが作成されるケースがあります。そうしたことから自分たちの開発プロセスに合ったブランチ戦略を採用する必要があります。 代表的なブランチ戦略 よく利用されるブランチ戦略として、Git Flow、GitHub Flowなどがあります。 様々なサイトで詳細な解説がなされているため、ここではそれぞれの概要と特徴を見てみましょう。 Git Flow 基本5種類ブランチが存在（main, develop, feature, release, hotfix） 開発者は各々developからfeatureを作成し作業 あるタイミング（スプリントの区切りなど）でdevelopからreleaseを切り出し、ステージング環境で商用リリース前の試験を実施 試験が完了したらreleaseをmainにマージし、商用環境へデプロイ 商用バグが発生した場合hotfixを作成し修正 メリット ：ブランチを環境と紐付けて管理しやすい（develop>開発環境、release>ステージング環境、main>本番環境） デメリット ：ブランチのマージのパターンが複雑となり、コンフリクトが起きやすい。またそれらのブランチ運用を開発者が理解する必要がある GitHub Flow 基本2種類のブランチが存在（main, feature） 開発者はfeatureブランチで作業（実際のブランチ名は開発内容を反映するものにする） 開発者はコードレビューをしてもらうためマージリクエストを作成 作業途中で有識者の意見が欲しい場合、マージリクエストのタイトルに『WIP:』を付けたり、draft pull requestの機能を利用する (GitHub Flowでのデプロイについては諸説あるため以下は一例) マージリクエストが承認されたらステージング環境にデプロイし、商用リリース前の試験を実施 試験が完了したらmainブランチ上でリリース用のタグを作成し、そこから商用環境へデプロイ メリット ：利用されるブランチの種類が少なく、またそれに伴いマージリクエストのパターンもGit Flowと比べ理解しやすい デメリット ：ブランチと環境を紐付けることが出来ない（上の図だとステージングと商用環境は両方mainからデプロイされる）。商用バグ対応時にタグから別ブランチを作成し、そこからバグフィックス版をリリースする場合がある GitHub Flowについてより詳しく知りたい方は こちら の公式ページを参照してみて下さい。 トランクベース開発の概要 ここまでで代表的なブランチ戦略についてご紹介しました。 それではそれらと比較しトランクベース開発がどういったものか見ていきましょう。 トランクベース開発では、開発者は一つのメインブランチ（trunk）上で作業を行い変更を直接Pushするか、1〜2日以内にマージすることを前提とした作業用ブランチ（short-lived branch）を作成しそこで作業を行います。Git FlowやGitHub Flowでは開発用のブランチが長期間存在することがあり得ましたが、それを許容しないのがトランクベース開発の一つの特徴です。これによりマージに伴うコンフリクトの発生を抑止することが可能となります。 また変更が加えられたtrunkブランチは常に商用提供可能とし、速やかに商用環境にデプロイされます。 トランクベース開発では開発単位を小さく保ち頻繁にturnkに対しPushすること、またそれに伴いCICDを実行し、自動テストや脆弱性診断などのフィードバックを素早く得ることで、開発スピードの向上とデプロイまでの時間短縮を実現しています。 DORA（DevOps Research and Assessment）が公開している過去のレポート（ 2016年 、 2017年 ）でも、ハイパフォーマーの共通点としてブランチの短命化が挙げられています。 トランクベース開発の実現 トランクベース開発は開発者に対しメリットをもたらす一方で、それを実現するには単にブランチ戦略を変更するだけでなく、開発の体制やリリースの考え方についても見直していく必要があります。 例えば、trunkブランチに対し直接開発者がPushを行うとなると、マージリクエスト以外の品質担保の仕組みが必要となります。 マージリクエストでは、開発者が一定期間作業をした後に高スキル者がレビューをするという方法でコードの品質を担保していましたが、この場合特定のレビュアーに負担が集中し、せっかく開発した機能が中々マージされず、ビジネス価値を発揮出来ないというケースが考えられます。 トランクベース開発ではそうした空白期間を発生させないために、マージリクエストの代わりにペアプログラミングやモブプログラミングの仕組みがよく採用されています。これらにおいては、開発期間中、継続的に他者の目でコードの内容が客観的に評価されるため、作業完了時に既に一定の品質が確保されるものと考えられます。 また商用提供しているアプリケーションにバグが見つかった場合はどうなるでしょうか。 アプリケーションのリリースをバージョニングして管理している場合、次期バージョンのcommitを含まないよう、バグが見つかったバージョンのリリースタグから新たにブランチを作成し、修正の変更を加えるなどのアプローチが必要となります。 一方でトランクベース開発においてはtrunkブランチを常にリリース可能なものであると位置付けるため、次バージョンという考え方を気にすることなく、バグ修正についてもその他の機能開発と同じように扱うことが可能となります。 銀の弾丸ではない ここまでトランクベース開発の考え方や実現方法について取り上げて来ましたが、注意したいのはトランクベース開発が全ての開発チームに有効な手法ではないということです。 例えば、ペアプログラミングを採用することで生産性が向上するチームもあれば、それらが上手く馴染まないチームも存在します。ペアで開発をしていても、開発の当事者となることで見えづらくなる問題もあるため、あえて個別にレビューのプロセスを導入したいという要望もあるかもしれません。 リリースのバージョニングについても同じで、プロジェクトにより常に最新のcommitをデプロイするという方法が、プロジェクトを取り巻く環境によっては適切でないケースも存在します。 トランクベース開発は、開発スピードを早め、デプロイまでのサイクルを短くするための一つの手段です。 そのためトランクベース開発を実現する、ということを大上段に掲げるのではなく、自身の開発チームの効率化を達成するためにそこに適用可能なアイディアをトランクベース開発から取り入れていくことが重要だと考えられます。 まとめ 今回はトランクベース開発やその他のブランチ戦略についてご紹介しました。 Gitのブランチ戦略はCICDの設計を考える上でも非常に重要となってきます。 自分や自分のチームが置かれた状況を踏まえた上で、開発を効率化していくため適切な方法を選択していきましょう。

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。今回はRed Hatの新しい最軽量なコンテナーイメージについて紹介します。 UBI Microのリリース リリース版イメージのバグ （参考）UBIについて UBI Microとは UBI 8のイメージ一覧 DistrolessなUBI Microの特徴 UBI Microを使ってみる UBI Microにパッケージを追加する UBI Microを使ったマルチステージビルド まとめ リンク UBI Microのリリース 2021年5月18日にRed Hat Enterprise Linux(以下、RHEL) 8.4がリリースされたのと同時に新しいRed Hat Universal Base Image (以下、UBI)、 UBI Micro がリリースされました。 リリース情報はこちら RHBA-2021:1999 - Bug Fix Advisory - Red Hat カスタマーポータル RHEL 8.4のリリースに先立って投稿されたRed Hat公式ブログ記事にもUBI Microについての記載があります。 www.redhat.com 上記ブログ記事より抜粋 With RHEL 8.4, we're announcing the Red Hat Universal Base Image (UBI) Micro to help reduce the attack surface, and deliver smaller footprint images of your containerized applications. UBI Micro joins the Standard, Minimal, and Multi-service images to provide the right options for you to build your applications on. (翻訳)RHEL 8.4 では、Red Hat Universal Base Image (UBI) Micro が発表され、攻撃対象を減らし、コンテナ化されたアプリケーションのより小さなフットプリントのイメージを提供します。UBI Micro は Standard、Minimal、Multi-service の各イメージに加えて、アプリケーションを構築するための適切なオプションを提供します。 UBI Microはすでに公開済みのUBI(Standard)、UBI Minimal、UBI Init(Multi-service)に加えて、4つ目の種類のUBIコンテナーイメージとなります。 リリース版イメージのバグ 以前からこのUBI Microの紹介をしようと思っていたのですが、実はリリース版の ubi8-micro:8.4-72 イメージにバグがあり、修正が完了するまで保留にしていました。 このバグは、 /etc/yum.repos.d ディレクトリにRed Hat社内向けのURLが含まれた *.repo ファイルが含まれており、それらのファイルを取り除かないと dnf コマンドが使えないという内容でした。詳細な内容については下記Bugzilla IDのコメントで確認することができます。 1966837 – ubi8-micro image includes internal compose repo configurations これからUBI Microを使う場合は ubi-micro:8.4-84 以降をお使いください。 （参考）UBIについて UBIについては詳細がまとまった電子書籍 Red Hat's Universal Base Image ebook があります。下記の記事では電子書籍についての紹介と翻訳した目次を掲載しています。 rheb.hatenablog.com UBI Microとは UBI Micro UBI Microはこれまでに公開されているUBIの中で 最軽量サイズ のコンテナイメージになります。UBI Microの詳細はRed Hatの認定コンテナーカタログページから確認できます。 ubi8-micro - Certified Container Image - Red Hat Ecosystem Catalog 上記カタログページより抜粋 Universal Base Image Micro (UBI Micro) is a stripped down image that uses the package manager on the underlying host to install packages, typically using Buildah, or Multi-stage builds with Podman. (翻訳)Universal Base Image Micro (UBI Micro)は、基盤となるホスト上のパッケージマネージャーを使用してパッケージをインストールするストリップダウンされたイメージで、通常はBuildah、またはPodmanを使用したマルチステージビルドを使用します。 UBIにはRHEL 7をベースにしたUBI 7とRHEL 8をベースにしたUBI 8がありますが、UBI Microは UBI 8のみ になります。 UBI 8のイメージ一覧 公開済みのUBI 8と並べてみるとUBI Microのサイズの小ささが小ささがよくわかります。 UBI 8の種類 イメージ名 サイズ Red Hat Universal Base Image 8 ubi8/ubi 79.5 MB (215.2 MB uncompressed) Red Hat Universal Base Image 8 Minimal ubi8/ubi-minimal 37.7 MB (98.2 MB uncompressed) Red Hat Universal Base Image 8 Init ubi8/ubi-init 85.3 MB (235.2 MB uncompressed) Red Hat Universal Base Image 8 Micro ←🆕 ubi8/ubi-micro 12.9 MB (35.0 MB uncompressed) UBI Microをコンテナのベースイメージ使用することでUBI Minimalよりさらにサイズを抑えたコンテナイメージの作成が可能です。 DistrolessなUBI Microの特徴 UBI MicroにはUBI/UBI Minimal/Initにあるようなパッケージマネージャー（dnf/microdnf）がありません。パッケージマネージャーと関連する依存関係を除外することでサイズを抑えることができています。このようにディストリビューションのパッケージ管理ツールを使用せずにコンテナイメージを構築するのは Distroless とも呼ばれます *1 。UBI MicroはホストOSの dnf コマンドを使ってパッケージの追加を行います（詳細は後述）。UBI Microは他のUBIイメージと同様の品質を保ちながらサイズを最小化したい場合に有効です。コンテナのサイズが小さくなるといことは悪意のある攻撃者から攻撃範囲を減らすことにもなりセキュリティ面でも有利です。 UBI Microを使ってみる UBI MicroはこれまでのUBIと同様の方法でコンテナの操作が可能です。UBI Microのイメージ取得はRed Hatのサイトだけでなく Docker Hubからも可能 です。 # podman pull registry.access.redhat.com/ubi8/ubi-micro # podman images --filter label=name=ubi8/ubi-micro REPOSITORY TAG IMAGE ID CREATED SIZE registry.access.redhat.com/ubi8/ubi-micro latest c5ba898d3645 2 weeks ago 38.9 MB # podman run --rm -it ubi-micro sh-4.4# sh-4.4# dnf;microdnf sh: dnf: command not found sh: microdnf: command not found UBI Micro上のシェルに入ることはできますが、 dnf や microdnf などのパッケージマネージャーは存在しないことが確認できます UBI Microにパッケージを追加する UBI Microにパッケージを追加するにはBuildahを使用します。事前にBuildahまたはContainer Toolsモジュールをインストールしておいてください。 手順についてはRHEL 8のドキュメントに記載があります。下記も参考にしてください。 2.8. UBI マイクロイメージの使用 Red Hat Enterprise Linux 8 | Red Hat Customer Portal 下記の例ではUBI Microに python39 を追加します。なお下記例で実行はrootモードで行っていますが、ルートレスモードで実行する場合は事前に buildah unshare を実行して名前空間に入ってから作業してください。 また、ホストOSにRHEL(またはCentOS Stream)が必要です *2 。 # containername=ubi-micro-python # microcontainer=$(buildah from --name ${containername} registry.access.redhat.com/ubi8/ubi-micro) # micromount=$(buildah mount ${microcontainer}) # dnf install \ > --installroot ${micromount} \ > --releasever 8 \ > --setopt install_weak_deps=false \ > --nodocs -y \ > python39 # dnf clean all \ --installroot ${micromount} # buildah umount ${microcontainer} # buildah commit ${microcontainer} ${containername} # buildah rm ${containername} ビルド後のイメージの確認 # podman images --filter label=name="ubi8/ubi-micro" REPOSITORY TAG IMAGE ID CREATED SIZE localhost/ubi-micro-python latest 82921a06b57c 9 minutes ago 104 MB registry.access.redhat.com/ubi8/ubi-micro latest c5ba898d3645 2 weeks ago 38.9 MB # podman run --rm ubi-micro-python python --version Python 3.9.2 これまでのUBIイメージと同様にベースイメージ上にパッケージの追加を行うことができました。ただし、最小限のパッケージ追加にも関わらずパッケージ自体の依存関係により多数のパッケージが追加されるのでどうしても出来上がったイメージのサイズは元のサイズに比べると膨らんでしまいます *3 。 UBI Microのサイズの小ささを生かす場合は極力パッケージの追加を行わないような シングルバイナリ を実行するような用途に向いていると考えられます。 次のマルチステージビルドの例ではGoのシンプルなバイナリを追加してコンテナイメージを作成してみます。 UBI Microを使ったマルチステージビルド マルチステージビルドを用いてビルド済みのシングルバイナリをUBI Microにコピーすることでサイズの増加を抑えたコンテナイメージの作成が可能です。マルチステージビルドではContainerfileやDockerfile（以下、Containerfile）を使用した通常手順でのビルドが可能です。 今回はGoで書いた実行すると「Hello,World!」返すシンプルなアプリを使います。なお、Podmanを使ったGoのサンプルバイナリのビルド方法については下記の記事を参照ください。 zenn.dev Containerfileは下記を使用します FROM docker.io/library/golang as go-build ENV APP_ROOT /go/src WORKDIR ${APP_ROOT} COPY ./hello.go . RUN go mod init hello && go build FROM registry.access.redhat.com/ubi8/ubi-micro COPY --from=go-build /go/src/hello /usr/local/bin/ CMD ["hello"] Buildah（またはPodman）を使用してビルドします # ls Containerfile hello.go Containerfile hello.go # buildah bud -t ubi-micro-hello-world . # podman run --rm ubi-micro-hello-world Hello, World! # podman images --filter label=name=ubi8/ubi-micro REPOSITORY TAG IMAGE ID CREATED SIZE localhost/ubi-micro-hello-world latest 56fcfe57af0e 6 minutes ago 40.7 MB localhost/ubi-micro-python latest 3bb4998a2f2c 29 minutes ago 104 MB registry.access.redhat.com/ubi8/ubi-micro latest c5ba898d3645 2 weeks ago 38.9 MB このように出来上がった ubi-micro-hello-world という名前のコンテナイメージは元のイメージとほぼ変わらないサイズに抑えられています。 まとめ Red Hatの新しい軽量なコンテナベースイメージであるUBI Microについて紹介しました。パッケージマネージャが搭載されていないDistrolessなイメージでサイズが小さいだけでなくセキュリティ面でも有利なイメージとなっています。パッケージを追加する場合はホストOSの dnf コマンドを使用するなどこれまでのUBIとは若干使い方が異なる点が注意です。また従来通りのContainerfileを使ったマルチステージビルドも可能で、シングルバイナリを配置するようなイメージであれば十分に元のサイズを保った小さなコンテナイメージを作成することが可能です。 UBI/UBI Minimal/UBI Init/UBI Microと多彩な種類のイメージが揃ったことでUBIを使ったコンテナイメージ作成の幅が広がりました。UBIは無料で使用、配布可能(一部制限あり)が可能となっていますので是非UBIを活用したコンテナイメージの作成に取り組んでみてください。 リンク RHEL 8.4 brings continuous stability plus innovation RHBA-2021:1999 - Bug Fix Advisory - Red Hat カスタマーポータル Universal Base Images (UBI): イメージ、リポジトリー、パッケージ、およびソースコード - Red Hat Customer Portal 1966837 – ubi8-micro image includes internal compose repo configurations ubi-micro:8.4-84 Red Hat's Universal Base Image ebook （電子書籍）Red Hat's Universal Base Image ebookの紹介【UBI】 - 赤帽エンジニアブログ Introduction to Red Hat's UBI Micro Red Hat Brings Red Hat Universal Base Image to Docker Hub 2.8. UBI マイクロイメージの使用 Red Hat Enterprise Linux 8 | Red Hat Customer Portal 【Podman】Goのビルドをコンテナ内で実行する *1 : UBI Microを紹介したRed Hatのブログ記事でも同様の記載あり → https://www.redhat.com/ja/blog/introduction-ubi-micro *2 : Fedoraのdnfでは /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release が取得できずエラー *3 : UBI Minimalに同様に追加した場合は151MBほどなので十分に小さいサイズとも言える

Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 Red Hat Enterprise Linux(以下、RHEL) 8向けPodmanの新しいパッケージ(v3.2.3)が公開され、 ルートレスモードでdocker-composeが使用できるようになりました 。 以前の記事 ではrootモードでdocker-composeを動かす方法を紹介しました。 rheb.hatenablog.com 今回はPodman v3.2以降で対応したルートレスモードでdocker-composeを実行する方法について紹介します。 Podman v3.2.3のアップデート ルートレスでpodman.socketサービスを起動する （参考）RHEL 8製品ドキュメントの該当項目について docker-composeコマンドをコンテナで実行する ルートレスでdocker-composeを実行してみる SELinuxエラーの対応 ルートレスモードとpodman network ルートレスモードにおける所有権の問題 再現手順 まとめ Podman v3.2.3のアップデート 2021年8月10日にRHEL 8 向けのcontainer-toolsのアップデートが公開されています。 RHBA-2021:3070 - Bug Fix Advisory Podman v3.2.3のパッケージ情報はこちら。 podman-3.2.3-0.10.module+el8.4.0+11989+6676f7ad.x86_64.rpm - Red Hat カスタマーポータル アップデート後のPodmanのバージョンは下記のようになっています。 $ podman version Version: 3.2.3 API Version: 3.2.3 Go Version: go1.15.7 Built: Tue Jul 27 16:29:39 2021 OS/Arch: linux/amd64 Podman v3.2.3へアップデートするにはdnfコマンドでcontainer-toolsまたはpodman単体のアップデートを実施して下さい。 $ sudo dnf update podman または $ sudo dnf module update container-tools ルートレスで podman.socket サービスを起動する ルートレスでdocker-composeを実行する場合もrootモードと同じくPodman APIソケット( podman.socket サービス)の起動が必要です。起動するには一般ユーザーで下記コマンドを実行します。 パッケージのアップデート後、念の為systemd マネージャー設定を再読み込み $ systemctl --user daemon-reload podman.socket サービスを有効にし、すぐにサービスを起動 $ systemctl --user enable --now podman.socket Created symlink /home/user/.config/systemd/user/sockets.target.wants/podman.socket → /usr/lib/systemd/user/podman.socket. サービスが起動しているか確認 $ systemctl --user status podman.socket ● podman.socket - Podman API Socket Loaded: loaded (/usr/lib/systemd/user/podman.socket; enabled; vendor preset: enabled) Active: active (listening) since Mon 2021-08-16 01:16:36 JST; 26s ago Docs: man:podman-system-service(1) Listen: /run/user/1000/podman/podman.sock (Stream) CGroup: /user.slice/user-1000.slice/user@1000.service/podman.socket 8月 16 01:16:36 localhost.localdomain systemd[12425]: Listening on Podman API Socket. Podman APIの動作確認 $ curl -s --unix-socket /run/user/1000/podman/podman.sock http://d/v3.0.0/libpod/info | jq .version 出力結果を開く { "APIVersion": "3.2.3", "Version": "3.2.3", "GoVersion": "go1.15.7", "GitCommit": "", "BuiltTime": "Tue Jul 27 16:29:39 2021", "Built": 1627370979, "OsArch": "linux/amd64" } ルートレスモードのPodman APIソケットのパスは systemctl --user status podman.socket の出力内容を参照 Podman APIソケットの詳細については 以前の記事 を参考にしてください 次はdocker-composeコマンドの準備を行います。 （参考）RHEL 8製品ドキュメントの該当項目について RHEL 8の製品ドキュメントにも該当項目がありますが内容が古いのであまり参考になりません。現時点では参考程度にご参照下さい。 14.2. ルートレスモードで systemd を使用した Podman API の有効化 Red Hat Enterprise Linux 8 | Red Hat Customer Portal RHEL 8.4 + Podman v3では podman.socket や podman.service の手動作成は不要 検証手順の podman-remote の導入不要 docker-composeコマンドをコンテナで実行する 以前の記事ではdocker-composeのインストールにpipを使用しましたが、Python/pipの環境に余計なものを入れたくない場合もあると思います。また、Docker公式ドキュメントではGitHubリポジトリからdocker-composeバイナリを入手して使用する方法が紹介されています。 *1 Install Docker Compose | Docker Documentation これらの方法に代わり、 docker-compose自体をコンテナで実行する ことで不要なものを追加せずにdocker-composeコマンドを実行することが可能となります。コンテナイメージはDocker公式が公開しているものがあるのでそちらを利用します。 docker/compose - Docker Image | Docker Hub コンテナでdocker-composeを実行する時の構成は下記のようになります。 コンテナ実行のdocker-composeの構成 下記の内容を ~/.bashrc に追記することで、コンテナ実行のコマンドを docker-compose のエイリアスとして使用できます。 alias docker-compose='podman run --rm \ -v /run/user/1000/podman/podman.sock:/var/run/docker.sock:z \ -v "$PWD:/$PWD:z" \ -w "/$PWD" \ docker/compose:1.29.2' オプションの補足 -v /run/user/1000/podman/podman.sock:/var/run/docker.sock:z ：ルートレスモードのAPIソケットをコンテナ内の docker.sock にマウントする -v "$PWD:/$PWD:z" ：カレントディレクトリをコンテナ内のWORKDIRにマウントする -w "/$PWD" ：コンテナ内のWORKDIRを指定 docker/compose:1.29.2 :実行するdocker-composeのイメージタグを指定。最新は1.29.2。 編集後、ファイルの再読み込み $ source ~/.bashrc 初回実行時のみコンテナイメージを先に取得しておく（2回目以降の実行は不要） $ podman pull docker.io/docker/compose:1.29.2 docker-composeの動作確認 1) 作業ディレクトリを作成し、SELinuxコンテキストを変更する $ mkdir test && cd test $ chcon -R -t container_file_t . $ ls -lZ ../ 合計 0 drwxrwxr-x. 2 user user unconfined_u:object_r:container_file_t:s0 6 8月 16 21:02 test docker-composeのエイリアス実行時にカレントディレクトリをマウントするため、 container_file_t のラベルが設定されていることが必要です 2) docker-compose version を実行し、正常にコマンドが実行できることを確認 $ docker-compose version docker-compose version 1.29.2, build 5becea4 docker-py version: 5.0.0 CPython version: 3.7.10 OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021 これでルートレスでdocker-composeを実行する環境が整いました。 ルートレスでdocker-composeを実行してみる 以前の記事と同じくdocker-composeでWordPressを実行します。 docker-compose.ymlも同様に Docker Hubに記載のサンプル を使用します。 作業ディレクトリを作成し、docker-compose.ymlファイルを作成 $ mkdir wordpress && cd wordpress $ chcon -R -t container_file_t . $ vi docker-compose.yml docker-compose.ymlの内容 version: '3.1' services: wordpress: image: wordpress restart: always ports: - 8080:80 environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: exampleuser WORDPRESS_DB_PASSWORD: examplepass WORDPRESS_DB_NAME: exampledb volumes: - wordpress:/var/www/html db: image: mysql:5.7 restart: always environment: MYSQL_DATABASE: exampledb MYSQL_USER: exampleuser MYSQL_PASSWORD: examplepass MYSQL_RANDOM_ROOT_PASSWORD: '1' volumes: - db:/var/lib/mysql volumes: wordpress: db: docker-compose up の実行（※SELinuxのエラーが出た場合は次項の対応を実施） $ docker-compose up -d Creating network "wordpress_default" with the default driver Creating volume "wordpress_wordpress" with default driver Creating volume "wordpress_db" with default driver Pulling wordpress (wordpress:)... Pulling db (mysql:5.7)... Creating wordpress_wordpress_1 ... Creating wordpress_db_1 ... Creating wordpress_db_1 ... done Creating wordpress_wordpress_1 ... done エイリアスコマンドにPodman APIソケット（及びdocker.sock）を直接指定しているので事前にDOCKER_HOST環境変数の設定は不要です 起動したコンテナの確認 $ podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6098cc19a0d7 docker.io/library/mysql:5.7 mysqld 8 seconds ago Up 7 seconds ago wordpress_db_1 6f6d0aa34eb0 docker.io/library/wordpress:latest apache2-foregroun... 8 seconds ago Up 7 seconds ago 0.0.0.0:8080->80/tcp wordpress_wordpress_1 ブラウザで http://<ホストのIPアドレス>:8080 へアクセスしてWordPressのインストール画面が表示されたらOKです。 SELinuxエラーの対応 docker-compose up 時に下記のようなエラーが出た場合はSELinuxのポリシーに引っかかっています $ docker-compose up -d [8] Failed to execute script docker-compose Traceback (most recent call last): File "urllib3/connectionpool.py", line 677, in urlopen File "urllib3/connectionpool.py", line 392, in _make_request File "http/client.py", line 1277, in request File "http/client.py", line 1323, in _send_request File "http/client.py", line 1272, in endheaders File "http/client.py", line 1032, in _send_output File "http/client.py", line 972, in send File "docker/transport/unixconn.py", line 43, in connect PermissionError: [Errno 13] Permission denied （以下省略） audit2allow コマンドを使ってモジュールの作成とインストールを行います $ sudo ausearch -c 'docker-compose' --raw | audit2allow -M my-dockercompose $ sudo semodule -i my-dockercompose.pp my-dockercompose.te の内容 $ cat my-dockercompose.te module my-dockercompose 1.0; require { type container_t; type container_runtime_t; class unix_stream_socket connectto; } #============= container_t ============== allow container_t container_runtime_t:unix_stream_socket connectto; 再度 docker-compose up を実行してエラーが出ないことを確認します。 ルートレスモードとpodman network ルートレスモードでdocker-composeが使えるようになった背景には、ルートレスモードでのネットワーク構成機能の追加があります（下記のRFEを参照）。 github.com ルートレスモードでdocker-compose実行時のネットワーク構成の変化を確認してみます。 docker-compose起動前 $ podman network ls NETWORK ID NAME VERSION PLUGINS docker-compose起動後 $ podman network ls NETWORK ID NAME VERSION PLUGINS b089aa3ab1f2 wordpress_default 0.4.0 bridge,portmap,firewall,tuning $ podman network inspect wordpress_default 出力結果を開く [ { "args": { "podman_labels": { "com.docker.compose.network": "default", "com.docker.compose.project": "wordpress", "com.docker.compose.version": "1.29.2" } }, "cniVersion": "0.4.0", "name": "wordpress_default", "plugins": [ { "bridge": "cni-podman1", "hairpinMode": true, "ipMasq": true, "ipam": { "ranges": [ [ { "gateway": "10.89.0.1", "subnet": "10.89.0.0/24" } ] ], "routes": [ { "dst": "0.0.0.0/0" } ], "type": "host-local" }, "isGateway": true, "type": "bridge" }, { "capabilities": { "portMappings": true }, "type": "portmap" }, { "backend": "", "type": "firewall" }, { "type": "tuning" } ] } ] このように docker-compose up と同時に新しくネットワーク構成が作成されたことが確認できます。なお、 docker-compose down を実行するとこのネットワーク構成は削除されます。 ルートレスモードにおける所有権の問題 ルートレスモードでコンテナ実行時の課題として、コンテナ内にホストのディレクトリをマウントして使用する場合の 所有権の問題 があります。 なお、PodmanのルートレスモードにおけるUIDの取り扱いについてはこの記事では詳細には触れませんが、過去の翻訳記事が参考になります。 rheb.hatenablog.com 例えばWordPressを使用する場合、wordpressおよびmysqlコンテナにマウントするディレクトリをホスト上に作成し、再度 docker-compose up してみると作成したフォルダのパーミッションがユーザー自身のものから変更されていることが確認できます。 再現手順 先程のwordpressフォルダの中に wordpress と db の2つのフォルダを作成する $ mkdir wordpress db $ chmod 777 wordpress db $ vi docker-compose.yml docker-compose.ymlの内容 version: '3.1' services: wordpress: image: wordpress restart: always ports: - 8080:80 environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: exampleuser WORDPRESS_DB_PASSWORD: examplepass WORDPRESS_DB_NAME: exampledb volumes: - ./wordpress:/var/www/html db: image: mysql:5.7 restart: always environment: MYSQL_DATABASE: exampledb MYSQL_USER: exampleuser MYSQL_PASSWORD: examplepass MYSQL_RANDOM_ROOT_PASSWORD: '1' volumes: - ./db:/var/lib/mysql #volumes: # wordpress: # db: docker-compose up 後のカレントディレクトリの所有権を確認 $ ls -l 合計 12 drwxrwxrwx. 6 100998 user 4096 8月 17 01:15 db -rw-rw-r--. 1 user user 585 8月 17 01:12 docker-compose.yml drwxr-xr-x. 5 100032 100032 4096 8月 17 01:15 wordpress この場合、UIDの 100998 と 100032 はコンテナ内で実行しているプロセスのホスト上のUIDです。下記では www-data と mysql が該当します。 $ podman top wordpress_wordpress_1 user huser USER HUSER root 1000 www-data 100032 www-data 100032 www-data 100032 www-data 100032 www-data 100032 $ podman top wordpress_db_1 user huser USER HUSER mysql 100998 ホスト上では一般ユーザーとして user 、 UID:1000 で実行されていますので異なる所有権のファイル/フォルダは直接操作が不可となります。 $ rm -rf db wordpress rm: 'db/mysql' を削除できません: 許可がありません rm: 'db/performance_schema' を削除できません: 許可がありません rm: 'db/sys' を削除できません: 許可がありません rm: 'db/exampledb' を削除できません: 許可がありません rm: 'wordpress/.htaccess' を削除できません: 許可がありません （以下、省略） ホスト側とファイルのやり取りを行うにしても都度 sudo コマンドを使用すればできなくも無いですが、所有権を意識しながらの操作となるのでかなり手間です。 対処としてはPodmanには podman unshare という便利なコマンドが用意されています。 $ podman unshare # ls -l 合計 12 drwxrwxrwx. 6 systemd-coredump root 4096 8月 17 01:15 db -rw-rw-r--. 1 root root 585 8月 17 01:12 docker-compose.yml drwxr-xr-x. 5 33 tape4096 8月 17 01:15 wordpress podman unshare コマンドを使用する実行する一般ユーザーのUser Namespaceに入った状態になる 先程のUID 100998 と 100032 から所有者の表示が変更されていることが確認できる このように podman unshare を使うことで sudo を使わずにUser Namespace内で直接ファイル、ディレクトリの操作が行うことができるようになります。 podman unshare については下記のブログも参考にしてください。 Running rootless Podman as a non-root user | Enable Sysadmin Dealing with user namespaces and SELinux on rootless containers | Enable Sysadmin まとめ Podman v3.2以降で対応したルートレスでdocker-composeを実行する方法を紹介しました。 RHEL 8向けのPodmanパッケージもv3.2.3へと更新されたのでRHEL 8でもすぐに使うことが可能です。 docker-composeの実行についてはコンテナとして実行する方法を紹介しました。これにより実行元ホストに追加でインストール作業が不用になります。 また、ルートレスモードの課題としてディレクトリマウント時に所有権の問題を紹介しました。 podman unshare を使うことで一般ユーザーのままホスト側とコンテナ間でのファイル操作などが容易になります。 なお、docker-composeを使用せずに podman run で直接コンテナを起動する場合は --userns keep-id という便利なオプションが使えます。しかしながらこれはPodman固有のオプションのためDockerのためのアプリであるdocker-composeでは実装されておらず使用できません。複数のコンテナを実行しつつホスト側のディレクトリをマウントする場合は Podman pods の利用を推奨します。 docker-compose から Podman pods へ移行する方法についてはまた別の機会に紹介したいと思います。 *1 : pipでのインストールは代替え手段として書かれているので、本来はこちらがメインのインストール方法の模様

IBM Z Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 最近セールス活動の中でIBM ZでOpenShiftを動かす案件に携わったのでそこで得られた情報などをシェアします。 -目次- (IBM Zは)神でも悪魔にでもなれる 動く、動く、OpenShiftが（IBM Zの上で）動く！ ユースケース リファレンスアーキテクチャー （IBM Z上に) UPIインストール、オン！ まとめ (IBM Zは)神でも悪魔にでもなれる IBM Zって何？メインフレームって？ IT業界に居ればメインフレームという言葉は聞いたことがある人も多いと思います。写真のイメージからはまさに（ITの）「 鉄（くろがね）の城 」。 そんなIBM Zの製品ページはIBMのサイトのITインフラストラクチャーのカテゴリにあります。IBM Zのハードウェア、z/OSやその上で動くソフトウェア、などなどIBM Zが提供するものは様々です。詳細は下記ページを参照ください。 IBM Z メインフレーム・サーバーおよびソフトウェア - Japan | IBM 上記ページを読んでもいまいちIBM Zが何かピンとはこない…。そんな時はIBM Zを知るヒントとして「 IBM Z憲章 」が参考になりそうです。 IBM Zに関するIBMの戦略的取り組み（IBM Z憲章：2020年版） | THINK Blog Japan IBM Z憲章を読む限り、IBM Zは「こういった製品」や「こういうシステム」と規定するものではなく、「IBMがデジタルで課題に取り組むテクノロジーの体現」といった印象を受けます。 IBM Z憲章には下記のような記述があります。 約3兆5000億円を投入してRed Hatを買収したことは、ハイブリッドクラウドへのIBMのコミットメントを反映しています。これは全社規模の取り組みで、IBM Zはその戦略の重要部分です IBM Zで「クラウド・ジャーニー」を歩み始めるお客さまのために、Red HatポートフォリオがIBM Zの製品ロードマップに緊密に組み込まれています。OpenShift はすでに IBM Z上のLinuxで稼働しz/OSからも連携可能です。 これを読むだけでもIBM Zの重要性がよく分かりますし、OpenShiftがそれを担う存在であることも確認できます。IBMとRed Hatという異質な両社がタッグ組んだ姿はまさに「 東映まんがまつり 」のような夢の共演、胸が熱くなりますね。 次は、IBM Zの上で動くOpenShiftについて。 動く、動く、OpenShiftが（IBM Zの上で）動く！ 今日時点ではすでにOpenShiftをIBM Zの上で動かすことができます。 www.redhat.com サポートプラットフォームに登場したのは OCP v4.4のリリースノート から。 UPIインストール自体はv4.2からテストされていました OpenShift Container Platform 4.x Tested Integrations (for s390x) - Red Hat Customer Portal IBM Zの上でOpenShiftを実行する方法はIBMのドキュメントの多くで確認することができます。 リファレンスアーキテクチャー Red Hat OpenShift Container Platform on IBM Z and IBM LinuxONE - Reference Architecture - IBM Documentation リファレンスアーキテクチャー紹介のウェビナー動画と資料へのリンク 2021-05-12 The Reference Architecture for Red Hat OpenShift Container Platform on IBM Z and IBM LinuxONE is for you OpenShift on IBM Zのパフォーマンスに関する資料 Red Hat OpenShift on IBM Z and IBM LinuxONE - Performance - IBM Documentation インストールガイド Install Red Hat OpenShift 4 on IBM Z and IBM LinuxONE – IBM Developer IBM Redbooks Red Hat OpenShift on IBM Z Installation Guide | IBM Redbooks また、IBM Z and LinuxONE Communityのページにも多くの動画と資料が公開されていますのでこちらも参考になります。 Linux on IBM Z and LinuxONE - IBM Z and LinuxONE Community ユースケース こちらの動画と資料 では、OpenShiftをIBM Zの上で動かすユースケースとして下記の5つが挙げられています Data gravity on IBM Z（IBM Z上のデータグラビティ） Application Development Consistency（アプリケーション開発の一貫性） Consolidation and TCO Reduction(統合とTCO削減) Blockchain and Digital Asset Management with RHOCP（RHOCPによるブロックチェーンとデジタルアセット管理） Business Continuity（ビジネス継続性） この中でも1番は、 コンテナ化されたアプリケーションと、z/OSやLinux上のDatalakes、Enterprise Database、Transactional Servicesなどの従来のワークロードをIBM Z上で共存させること とあり、IBM Zの上でOpenShiftを動かす目的を非常に分かりやすく表しています。 OCP on IBMの構成概要（資料: RHOCP on Z Best Use Casesより抜粋） リファレンスアーキテクチャー IBM Z上でOpenShiftを実行する際に一番参考になる資料が先に紹介した リファレンスアーキテクチャー です。この資料はIBMだけでなくRed Hatのコンサルタント・エンジニア・プロダクトチームの共作で、まさに双方のトップノッチエンジニアによる賜物です。 アーキテクチャーデザイン、運用、アプリケーション、それぞれの面での考慮事項について非常に詳細に記述されています。 特にコンテナプラットフォームで重要なストレージに関する部分には、OpenShift Container Storage（以下、OCS）、現名称:OpenShift Data Foundation（以下、ODF）についてバッチリ書かれています。 OCP/OSC on IBM Z（資料：RHOCP-reference-architectureより抜粋） OCS/ODFはOCPと実データ格納ストレージとの間にSoftware-Definedなレイヤーを提供し、OCPと統合されたインターフェイスからブロック/ファイル/オブジェクトストレージを動的に切り出すことができ、さらにプラットフォームを超えたOCPクラスター間でのデータフェデレーションを提供します。アプリケーションの可搬性にデータの可搬性も加わることにより、あらゆる場所でのアプリケーションの実行が可能になり、これこそがまさにハイブリッドクラウドの体現、Red Hatの掲げる Open Hybrid Cloud のアプローチです。 なお、OCS/ODF v4.8時点においてIBM Z上での稼働は サポート対象です *1 OCS/ODFについて OpenShift on IBM Zのリファレンスアーキテクチャーにしっかり記載がある ことは非常に意義があることと感じます。 （参考）IBMによるOCS on IBM Zのウェビナーの録画と資料は下記より参照できます Installing Red Hat OpenShift Container Platform with User-Provisioned Infrastructure via IBM Cloud Infrastructure Center - IBM Z and LinuxONE Community 次はIBM Z上にOpenShiftをインストールする方法について。 （IBM Z上に) UPIインストール、オン！ IBM Zは以前の OpenShift on Nutanix AHV の時のように簡単に自宅ラボで用意してテスト…とはいかないので、今回はドキュメントベースで解説します。 IBM ZへのOpenShiftインストール方法でサポートされているのはUPIインストールのみです。 OCP v4.8対応のIPIとUPIサポートプラットフォーム OCPインストーラーの openshift-install バイナリは s390x アーキテクチャーのものを選択します。同様にRed Hat Enterprise Linux CoreOS（以下、RHCOS）のバイナリも s390x アーキテクチャーを使用します。 Red Hat の製品ドキュメントの該当部分は下記になります（OCP v4.8） 第9章 z/VM を使用した IBM Z および LinuxONE へのインストール OpenShift Container Platform 4.8 | Red Hat Customer Portal 第10章 RHEL KVM を使用した IBM Z および LinuxONE へのインストール OpenShift Container Platform 4.8 | Red Hat Customer Portal UPIインストールする際にRHCOSをIBM Z上に仮想マシンとして用意する必要がありますが、その際の方法が2種類あるため該当ドキュメントが2つ用意されています。 どちらの方法でもUPIインストールとしては標準的な手順であり、前提条件なども同じです（IBM Z固有のものは除く）。懸命な本ブログ読者であれば「まぁいつものアレか」くらいで流せると思います。実機で試したわけではないのでIBM Z特有のハマりどころなどはあるかもしれませんが、ドキュメント上はOCPのUPIインストール自体は同じだと確認できます。 まとめ IBM ZはIBMの戦略にとって重要でありハイブリッドクラウドを実現するためにはOpenShiftが必要です。これらのことはIBM Z憲章から確認できます。 また、IBM Z上でOpenShiftを動かすこと自体はすでに可能であり、非常に詳細なリファレンスアーキテクチャーやインストールガイドが用意されています。 なお、IBM Z上へのOpenShiftのインストール方法は現在ではUPIインストールのみがサポートされています。IPIインストール時のようなAPIを利用した動的なノード追加などはできない点は注意です。 IBMから非常に多くの資料が公開されており、またOpenShift on IBM Zに関するウェビナーなども継続して行われています（英語のみ）。IBMにとってIBM Zが重要な存在である限り、OpenShift on IBM Zの機能追加や改善などは今後も十分に期待ができ、そのことがますますIBM、Red Hat双方にとってOpenShift on IBM Zの重要性を高めていくのではないでしょうか。 なお、マジンガーのストーリでは代わりにグレートマジンガーが出てくるのですが、現実における主役交代はどうなっていくのか。今後も目が離せませんね。 *1 : 古いv4.6までを対象としたドキュメントにはTech Previewの記載があるため念の為記載

Red Hat's Universal Base Image ebook Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 今回は無料で入手可能な電子書籍「Red Hat's Universal Base Image ebook」を紹介します。 Red Hat's Universal Base Image ebook Red Hat Universal Base Images （以下、UBI）は、Red Hatが提供、メンテナンスをしている自由に使用可能で再配布可能(一部条件有り)なコンテナイメージです。 このUBIに関して詳細に解説した電子書籍が無料で公開されていて、下記から入手可能です。 connect.redhat.com サブタイトルも「 Red Hatの自由に再配布可能なコンテナベースイメージについて知っておくべきすべてのこと 」とあり、UBIに関する内容が網羅されています。 UBI以外の内容も多くあり、パート2では 標準化された運用環境(SOE) とコンテナを比較したアーキテクチャーの解説や、パート5ではオープンなコンテナツールとしてPodman、Buildah、SkopeoなどのRed Hatのcontainer-toolsの紹介もあります。 残念ながら現在は英語版のみとなりますが、気になるセクションからピックアップして読んでいくのでも十分読み応えがあります。UBIを使う/使わない問わず非常に勉強になるのでオススメです。 どんな内容が書いてあるのか把握しやすいように目次を翻訳したものを下記に載せておきます。 読書の参考にご利用ください。 （目次翻訳）Red Hat's Universal Base Image ebook タイトル：Red Hat's Universal Base Image ebook サブタイトル：Red Hatの自由に再配布可能なコンテナベースイメージについて知っておくべきすべてのこと 序文 パート1 1 Red Hat Universal Base Images の紹介 1.1 はじめに この本を読むことで得られること 1.2 Red Hat Universal Base Imagesのモチベーション コンテナベースイメージとは？ コンテナベースイメージに何が含まれているかは重要ですか？ Red Hat Enterprise Linuxを使用するためのサブスクリプション要件 1.3 Red Hat Universal Base Imagesの紹介 UBIの中には何がありますか？ UBIに対応した追加RPM 1.4 UBI の今後の強化点 パート2 2 ベースイメージのソースを選択することが戦略的な決定である理由 2.1 標準化された運用環境(SOE)とコンテナ 2.2 コンテナのベースイメージを標準化しない場合の影響 バージョンの爆発：何種類のバージョンを実行しているのか？ 2.3 コンテナイメージ内のソフトウェアスタックを維持する責任 2.4 ベースイメージのソースを選択する際の検討事項 2.5 SOEとしてのUBIのメリット パート3 3 UBIのサポートとライセンス 3.1 UBIのライフサイクルとアップデート UBI 8 UBI 7 3.2 UBIのコンテナイメージとRPMのアップデートポリシー 3.3 コンテナの互換性とサポータビリティの限界 異なるRed Hatバージョン間の互換性 3.4 UBIサポート情報 コンテナイメージとコンテナホストOSのバージョンが混在する場合のRed Hatのサポート コンテナ互換性マトリクスに基づく推奨事項 Red Hat のサポート文書 3.5 UBIのライセンスと再配布 パート4 4 Red Hatとの連携 4.1 Red Hatのサポートを受ける 4.2 Red Hat リソースへのアクセスのための無償サブスクリプションの取得 4.3 UBI の機能強化を依頼する 4.4 Red Hatエコシステムカタログ Red Hat公開UBIイメージのRed Hatエコシステムカタログ Red Hat認定パートナー製品のRed Hatエコシステムカタログ 4.5 コンテナヘルスインデックス 4.6 Red Hat Vulnerability Scanner 認証 4.7 Red Hatとのパートナーシップ Red Hatとの構築 認証されたアプリケーションの Red Hat Ecosystem Catalogへの掲載 認証されたアプリケーションの Red Hat Marketplaceへの掲載 4.8 Red Hat コンテナ認証 パート5 5 Red Hatとオープンコンテナツール 5.1 UBIはOCIに準拠したコンテナツール(Dockerを含む)で動作します。 5.2 Red HatシステムでのDocker Docker Inc.のDocker-ceまたはDocker-eeはRed Hat Enterprise Linuxにインストール可能 PodmanとBuildahを使ったdocker CLIコマンドの使用 5.3 オープンコンテナツールのモチベーション 5.4. Red Hatのオープンコンテナツールの概要 Podman: コンテナやポッドを管理するためのツール Buildah: コンテナイメージを構築するためのツール Skopeo: コンテナレジストリとイメージを扱うツール Udica: コンテナ用のSELinuxポリシーを生成するツール CRIU: ユーザ空間でのコンテナのチェックポイントとリストア CRI-O: Kubernetes用の軽量コンテナランタイム 5.5 オープンコンテナツールの使用開始 Red Hat Enterprise Linux 8 のコンテナツール Red Hat Enterprise Linux 7 のコンテナツール その他の Linux ディストリビューション コンテナツールのチュートリアル パート6 6 UBIとの連携 6.1 UBIコンテナイメージの入手先 Red Hatのコンテナレジストリ Red Hatの認証されたコンテナレジストリでの作業 6.2 UBIによるガイド付きオンラインチュートリアル 6.3 Windows、macOS、LinuxでのUBIとDockerの併用 6.4 Podmanを使ったRed Hat Enterprise LinuxおよびシステムでのUBIの利用 6.5 UBIのベースイメージの選択 UBI Minimalイメージ マルチサービスUBIイメージ 6.6 UBIイメージへのソフトウェアの追加 UBI と Red Hat Enterprise Linux リポジトリ UBI 8 へのパッケージの追加 UBI 7 へのパッケージの追加 詳細情報 （目次翻訳、ここまで）

OpenShift on Nutanix AHV Red Hatでソリューションアーキテクトをしている田中司恩( @tnk4on )です。 2021年7月29日にRed HatとNutanixの戦略的パートナーシップの発表がありました。 www.redhat.com Red Hat OpenShiftおよびRed Hat Enterprise Linuxと、Nutanix AOSおよびAHVを含むNutanix Cloud Platformのインストール、相互運用性、管理を可能にします。 Nutanix AHV(以下、AHV)がRed Hat認定ハイパーバイザーになったことで、Nutanix Cloud Platform上のRed Hat Enterprise Linux(以下、RHEL)とOpenShiftのサポートが可能となりました。 Nutanix社のブログ記事はこちら。 www.nutanix.com 前職でNutanix導入の経験もあり、これはやるしかない！ってことで久々にNutanixの構築を行ってその上でOpenShiftを動かしてみました。 -目次- 認定ハイパーバイザーリスト、サポート情報 AHVへのOCPのインストール方法 （参考）AHV上にUPIでOpenShiftをインストールするデモ動画 Single Node OpenShift をインストールする Nutanix CSI Operator （注意）Nutanix CSI Operatorの導入にはOCP v4.6/4.7が必要 PVCの作成 まとめ 認定ハイパーバイザーリスト、サポート情報 まず、OpenShiftとAHVのサポート情報について確認してみます。 OpenShift Container Platform(以下、OCP) 4.xのテスト済みのプラットフォームやインフラの情報は下記のTested Integrationsにまとまっています。 OpenShift Container Platform 4.x Tested Integrations (for x86_x64) - Red Hat Customer Portal Tested Integrationsより抜粋 Red Hat Provides support for Red Hat Enterprise Linux based on the Hypervisors listed in https://access.redhat.com/certified-hypervisors as such OpenShift as a platform is supported on these hypervisors but may not be explicitly listed as a tested Infrastructure Layer 認定ハイパーバイザーリスト ではRHELについて記載されていますが、プラットフォームとしてのOpenShiftについても同様にリストされているハイパーバイザーでサポートされる、ということのようです。OpenShiftのベースOSとなるRHEL CoreOS（以下、RHCOS）はRHELベースのOSですので、RHELのサポートによってRHCOSもサポートされるようになるというのは特に違和感はありません。 なお、現時点（2021/8/2、時点）ではAHVはTested Integrations にまだ記載がありません。 *1 認定ハイパーバイザーについては下記も参考にしてください。 [OpenShift 4] Is Nutanix AHV a supported hypervisor? - Red Hat Customer Portal Which hypervisors are certified to run Red Hat Enterprise Linux? - Red Hat Customer Portal Explore Certified Servers - Red Hat Ecosystem Catalog AHVへのOCPのインストール方法 現在サポートされているAHVへのOpenShiftのインストール方法はUPIの「 任意のプラットフォームへのインストール 」のみです。いわゆる ベアメタルUPI 、 べアメタルメソッド と言われる方法です。このブログでも何度もご紹介している方法です。 OCP v4.8対応のIPIとUPIサポートプラットフォーム この方法を使えば事実上どんな環境でもOCPのインストールは可能であり、実際に過去にすでにNutanixのコミュニティにAHVへのインストール情報もありました。 Running Red Hat Openshift on Nutanix AHV | Nutanix Community インストール手順においてAHV特有の作業などは特に無く、Web GUIの Prism を通してRHCOSのISOを登録、各ノードのVMの作成さえできれば後はOpenShiftのインストール手順に沿って構築が可能です。 PrismでのISOイメージの登録画面 （参考）AHV上にUPIでOpenShiftをインストールするデモ動画 YouTubeのOpenShiftチャンネルにインストール方法の解説動画がアップされています。 UPIでAHVにOpenShiftをインストール Nutanix CSI Operatorのインストール www.youtube.com Single Node OpenShift をインストールする Nutanixを実行する実機は手元のラボ環境には無いので Nutanix Community Edition（Nutanix CE） を使用してAOS/AHV環境を構築します。さらに、Nutanix CEで占有できるハードウェアも無いので、今回はESXi上の仮想マシンとしてNested環境でAOS/AHVを実行します。 なお、 AHVはホストメモリのオーバーコミットができない ため、 このNested環境でOCP用のノードを複数実行するにはホストとなる物理サーバーにかなりのメモリ容量が必要です。そこで、最小構成でOCPを実行するためにシングルノードで実行する Single Node OpenShift(以下、SNO) でインストールします。 SNO on AVH on ESXi 構成図 SNOを実行する方法はいくつかありますが、一番お手軽な方法として OpenShift Cluster Manager 上で提供されている Assited Installer を使います。Assisted InstallerにSNOのオプションがあるのでこれを利用します *2 。なお、現時点でSNOで選択できるOCPのバージョンは「v4.8.2」のみです *3 。 Assisted InstallerのSNOオプション SNO構成のハードウェア要件は下記です（物理、仮想マシン共通） 8 CPU（8 vCPU) 32GiB RAM 120GB のストレージ インストール時に32GBのメモリが必要ですが *4 、OCPのインストール完了後は割り当てメモリ量を減らすことは可能です。16GBあれば実用性は置いておいてSNOでクラスターの起動は可能です。 Prism上のSNO仮想マシン （参考）Nested構成のためAHV上のVMを起動するには下記オプションの追加が必要 CVM$ acli vm.update SNO cpu_passthrough=true CVM$ acli vm.get SNO |grep cpu_passthrough cpu_passthrough: True インストールが完了すれば後は普通にOpenShiftとして利用できます。「コントロールプレーンの高可用性」が「なし(単一マスター)」となっていることが確認できます。 OpenShift Webコンソール画面 続いてCSIを通してPVを使うためにNutanix CSI Operatorの導入を行います。 Nutanix CSI Operator OCPにNutanix CSI Operatorを導入するとNutanix VolumesとNutanix Filesを使用したPVの動的プロビジョニングが可能となります。Nutanix VolumesはiSCSI、Nutanix FilesはNFSでのボリューム提供方式となります。 導入手順は下記のGitHubリポジトリを参照ください。 github.com Nutanix CSI Operator導入前に事前にAHV側で設定を行います。 iSCSI用データサービスのIPアドレス追加 Storage Containerの作成 Storage Classの作成の中で「iSCSI用データサービスのIPアドレス」と「Storage Container名」を指定するのでこれらの値が必要となります。 OCP側の手順概要は下記の通りです。 Nutanix CSI Operatorのインストール Nutanix CSI Operatorでインスタンスの作成 Secretの作成 Storage Classの作成 OperatorHubからNutanis CSI Operatorの導入が可能 GitHubリポジトリの手順ではNutanix Volumesを使用した方法が紹介されていますが、詳細なCSI Volume DriverのパラメーターやNutanix Filesの構成方法は、下記のNutanixのドキュメントを参照ください。 Third-Party Integrations 2.3 - Creating a Storage Class (Nutanix Volumes) （注意）Nutanix CSI Operatorの導入にはOCP v4.6/4.7が必要 OCP v4.8にNutanix CSI OperatorをインストールするとエラーとなりOperatorのインストールが完了しません。 Nutanix CSI Operator v0.1.3はOCP v4.8に非対応 別立てしたOCP v4.7（v4.7.22）では問題なく手順通りにOperatorのインストールが完了します。 Nutanix CSI Operator v0.1.3 on OCP v4.7.22 PVCの作成 Nutanix CSI Operator導入の完了後、OpenShift上でPVCを作成するとAHV上に自動でボリューム作成→PV作成が行われます。 OpenShift上でPVC作成 AHV上のストレージを確認すると、PVCで作成したボリューム（pvc-で始まる名前）が作成されていることが確認できます。 AHV上に自動作成されたPV用のボリューム まとめ Red HatとNutanixの戦略的パートナーシップによりRHEL及びOpenShiftのAHV上での実行がサポートされるようになりました。 AHV上へのOpenShiftのインストールはベアメタルUPIに従えば特に難しい点はなく、これまでの技術やノウハウが流用できます。さらにNutanix CSI Operatorを通したPVの動的プロビジョニングも可能ですのでVMのワークロードからストレージまでNutanixのHCIで統合して提供することが可能です。 今後、OpenShift v4.8以降の対応や、AHVのIPIサポートで自動インストールができるようになるとさらにオンプレ上のOpenShift導入先としてAHVが候補に上がることが期待できますね！ *1 : Tested Integrationsは、サポートしている環境全てについて記載があるわけではないので今後どのタイミングで追記されるかは不明… *2 : Assited InstallerおよびSNOについてはまた別記事で詳しく紹介 *3 : 技術的にSNOのインストールを実現するBootstrap-Inplaceに対応しているのがv4.8以降のため *4 : Assisted Installerのウィザード内のチェックがあり足りないとインストールが開始できない

こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 前回の記事 ではクラウドネイティブなCI/CDを実現するOpenShift Pipelinesの機能のうち、パイプライン構築のためのコンポーネントであるTekton Pipelinesに焦点を挙げ、その概要をご紹介させて頂きました。 今回の記事では、Tekton Triggersという仕組みを使い、構築したパイプラインを開発の一連の流れの中で自動的に実行する方法をご紹介したいと思います。 Tekton TriggersはTekton Pipelinesと同様に、OpenShift Pipelines Operatorをインストールすることですぐに使い始めることが出来ます。 ユースケース Tekton Triggersについての説明に入る前にユースケースについておさらいしたいと思います。 前回の記事では、開発者が自身の作業用ブランチからメインブランチに対しプルリクエストを行い、それが承認されたタイミング（merge commitが作成されたタイミング）で、アプリケーションの静的診断、コンテナイメージの作成、レジストリへのプッシュなどを自動的に実施するというパイプラインを考えました。 Tekton Pipelinesでは実行する個々のアクションをTask、それらの実行順を定義するものとしてPipelineというカスタムリソースを作成しました。 これに対しTekton Triggersは開発者のGitへのアクションを契機に、定義されたPipelineを、文字通りトリガーし実行する役割を担っています。 上の図を違う角度から見てみましょう。 GitHubやGitlabなど、一般的なGitリポジトリでは開発者のアクションに応じてWebhookを設定することが出来ます。このWebhookを受け取り、定義されたPipelineを実行するためのPipelineRunリソースを作成するのがTekton Triggersとなります。 Tekton Triggersで登場する概念 Tekton Triggersでは以下の3つカスタムリソースを使用することで上記の動きを実現しています。 TriggerTemplate : Webhookを受け取った際に作成するリソース（PipelineRun、TaskRun、等）の定義 TriggerBinding : 受け取ったWebhookのヘッダーやボディ部からPipelineRunに渡すパラメータの定義 EventListner : Webhookの受け口（Service＋Pod）の作成と、使用するTriggerTemplate/TriggerBindingの指定 それぞれの関係性を表すと以下のような図になります。 GitリポジトリからのWebhookはEventListnerが作成したServiceを経由して、同じく作成されたPodが受け取ります。このPodはTriggerBindingの中で定義された通りに受信したWebhookのJSONを加工し必要なパラメータを抜き出すと共に、TriggerTemplateで指定されたリソース（PipelineRun）を作成します。 カスタムリソースの作成 ここからは実際に使用されるカスタムリソースを作成していきたいと思います。 まず初めにTriggerBindingでWebhookから受け取る情報を定義します。 TriggerBinding apiVersion: triggers.tekton.dev/v1alpha1 kind: TriggerBinding metadata: name: test-trigger-binding spec: params: - name: gitrevision value: $(body.head_commit.id) - name: gitrepositoryurl value: $(body.repository.url) TriggerBindingでは上記のように、 spec.params 以下でWebhookから受け取った情報のうち、何をこの後のステップで利用していくかを定義します。 Webhookからどのような形でデータが受け渡されるかについては、使用するGitリポジトリによって異なりますが、例えばGitHubの場合 こちらのページ からイベント種類ごとの内容を確認することが出来るので参考にしてみて下さい。 TriggerTemplate apiVersion: triggers.tekton.dev/v1alpha1 kind: TriggerTemplate metadata: name: test-pipeline-template spec: params: - name: gitrevision description: The git revision default: master - name: gitrepositoryurl description: The git repository url resourcetemplates: - apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: generateName: test-run- spec: pipelineRef: name: test-pipeline params: - name: url value: $(tt.params.gitrepositoryurl) - name: SONAR_HOST_URL value: 'http://sonarqube:9000' - name: SONAR_PROJECT_KEY value: 'test-project' - name: IMAGE value: 'jpishikawa/mkdocs-test' workspaces: - name: shared-workspace volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi - name: sonar-settings emptyDir: {} 続いてTriggerTemplateです。 spec.params にはTriggerBindingで定義したパラメータの情報を記載し、 spec.resourcetemplates 以下でWebhookを受けた際に作成するリソースの情報を記載します。上記の例では kind: PipelineRun のリソースを作成するようにしていますが、単一のTaskだけを動かしたい場合などはTaskRunを設定することも可能となります。 EventListner apiVersion: triggers.tekton.dev/v1alpha1 kind: EventListener metadata: name: test-event-listener spec: serviceAccountName: sample-sa triggers: - bindings: - ref: test-trigger-binding template: ref: test-pipeline-template interceptors: - github: secretRef: secretName: github-webhook secretKey: webhook-secret eventTypes: - push - cel: filter: "body.ref == \"refs/heads/master\"" 最後にEventListnerです。 これまで作成したTriggerBinding、TriggerTemplateを参照するよう、 spec.triggers 以下に記述します。 spec.triggers[].interceptors という項目では、Webhookに設定された値を検証し、条件を満たさない場合PipelineRunを作成しないというフィルタリングの設定を行っています。上記の例ではWebhookのシークレットを使った送信元リポジトリの認証を行い、トリガー実行をmasterブランチへのpushイベントに対してのみ制限しています。 EventListnerではServiceAccountの設定が必須となっています。前述の通り、EventListnerはTriggerTemplateで指定したリソースを作成することになるため、以下のように必要な権限を持ったService Accountを作成します。 apiVersion: v1 kind: ServiceAccount metadata: name: sample-sa secrets: - name: github-webhook --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: sample-role rules: - apiGroups: - triggers.tekton.dev resources: - eventlisteners - triggers - triggerbindings - triggertemplates verbs: - get - list - watch # PipelineRunを作成可能な権限を付与 - apiGroups: - tekton.dev resources: - pipelineruns verbs: - create - apiGroups: - "" resources: - configmaps verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: sample-role-binding subjects: - kind: ServiceAccount name: sample-sa roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: sample-role ここまででTrigerBinding、TriggerTemplate、EventListnerのマニフェストを作成出来ました。 実際にこれらを実行してみると、Webhookを受けるためのEventListnerのService、Podの作成を確認することが出来ます。 ❯ oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE el-test-event-listener ClusterIP 172.30.244.201 <none> 8080/TCP 4m48s ❯ oc get pod NAME READY STATUS RESTARTS AGE el-test-event-listener-58dd7f786c-ql5dz 1/1 Running 0 4m33s 一点注意するポイントとして、Serviceは type: ClusterIP として作成されるため、デフォルトではクラスター外部からの通信を受け付けることが出来ません。GitHubなど外部からのWebhookを受け付ける場合には oc expose などのコマンドを実行しエンドポイントを作成してあげましょう。 ❯ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD el-test-event-listener el-test-event-listener-cicd.apps.mycluster.193b.sandbox80.opentlc.com el-test-event-listener http-listener None これでEventListnerがGitリポジトリのWebhookを受け付ける準備が完了しました。 Webhookの設定 次にGitリポジトリ側でWebhookの設定をしましょう。 今回はGitHubで設定を行いたいと思います。 Webhookを設定したいGitHubのリポジトリにアクセスし、"Settings"→"Webhooks"から新規のWebhookを設定します。 Payload URLには先ほど作成したWebhookのエンドポイントのURLを設定、Content typeを application/json 、Secretには認証に使用するシークレットキーを入力します。 今回はpushイベントを対象としWebhookを作成しますが、より詳細な設定を行うことも可能です。 Pipelineの実行 ここまででGitのpushイベントに応じてPipelineを実行する準備が整いました。 最後に実際に新規のcommitを作成し、正しくPipelineが動くか確認してみましょう。 リポジトリ上で新規ファイルを作成するなどの操作を行い新規のcommitを作成すると、それに応じて先ほど設定したWebhookが作成されます。 作成されたWebhookの履歴は設定画面から確認出来ます。 これまでの設定が正しく行われていればTekton Triggersにより新たなPipelineRunが作成されます。 OpenShiftのコンソールを見ると新たなPipelineRunが作成され、Pipelineが実行されていることを確認することが出来ます。 これでGitのアクションからPipeline実行までの一連の動きについて確認することが出来ました。 まとめ 前回から2回に分けてOpenShift Pipelinesについての内容をご紹介しました。 昨今では開発を高速に、かつセキュアにしていくためにはCI/CDによる自動化の仕組みが不可欠となっています。Tektonには複数のカスタムリソースが存在するため、初めは取っ付きづらさを感じるかもしれませんが、一つ一つの役割を理解すると、シンプルで拡張性を持ったパイプラインを構築することが出来るということが理解出来たのではないでしょうか。 皆さんも是非OpenShift Pipelinesを使ったCI/CDパイプラインの構築にチャレンジしてみて下さい。