Image Mode for RHEL を使用したオペレーティングシステムのビルド、デプロイ、管理

1. パッケージモード: オペレーティングシステムは RPM パッケージを使用し、dnf パッケージマネージャーを使用して更新されます。ルートファイルシステムはミュータブルです。ただし、オペレーティングシステムをコンテナー化されたアプリケーションとして管理することはできません。
2. イメージモード:RHEL の構築、デプロイ、管理を行うためのコンテナーネイティブなアプローチ。同じ RPM パッケージがベースイメージとして提供され、アップデートはコンテナーイメージとして展開されます。ルートファイルシステムは、/etc と /var を除きデフォルトではイミュータブルであり、ほとんどのコンテンツはコンテナーイメージから取得されます。

手順

1. Containerfile を作成します。

   FROM quay.io/<namespace>/<image>:latest
   RUN dnf -y install cloud-init && \
       ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \
       dnf clean all

   この Containerfile の例では、cloud-init ツールが追加されています。そのため、SSH 鍵を自動的に取得し、インフラストラクチャーからスクリプトを実行できます。このツールは、インスタンスのメタデータから設定情報とシークレット情報を収集します。たとえば、このコンテナーイメージを、事前に生成した AWS または KVM ゲストシステムに使用できます。

2. 現在のディレクトリーの Containerfile を使用して、<image> イメージをビルドします。

   $ podman build -t quay.io/<namespace>/<image>:<tag> .

手順

1. Containerfile を作成します。

   FROM registry.redhat.io/rhel10/rhel-bootc:latest
   # In this example, the custom operating system has its own
   # version scheme.
   # The operating system major version is copied
   # and a sub-version of it is added, which represents a point-in-time
   # snapshot of the base OS content.
   # This just changes the output of bootc status. A deeper level
   # of customization is available by also changing the contents of /usr/lib/os-release.
   # Define the custom version and release metadata
   LABEL org.opencontainers.image.version=”10.1.1”

2. 現在のディレクトリーの Containerfile を使用して <image> イメージをビルドします。

   $ podman build -t quay.io/<namespace>/<image>:<tag> .

手順

1. 論理的にバインドするイメージを選択します。

2. Containerfile を作成します。

   $ cat Containerfile
   FROM quay.io/<namespace>/<image>:latest
   COPY ./<app_1>.image /usr/share/containers/systemd/<app_1>.image
   COPY ./<app_2>.container /usr/share/containers/systemd/<app_2>.container
   
   RUN ln -s /usr/share/containers/systemd/<app_1>.image \
   	/usr/lib/bootc/bound-images.d/<app_1>.image && \
       ln -s /usr/share/containers/systemd/<app_2>.container \
       	/usr/lib/bootc/bound-images.d/<app_2>.container

3. .container 定義で、以下を使用します。

   GlobalArgs=--storage-opt=additionalimagestore=/usr/lib/bootc/storage

   この Containerfile の例では、/usr/lib/bootc/bound-images.d ディレクトリーに、.image ファイルまたは .container ファイルを参照するシンボリックリンクを作成することにより、論理的にバインドされるイメージが選択されます。

4. bootc upgrade コマンドを実行します。

   $ bootc upgrade

   bootc upgrade では、次の主な手順が実行されます。

   1. イメージリポジトリーから新しいベースイメージを取得します。コンテナープルシークレットの設定 を参照してください。
   2. 新しいベースイメージのルートファイルシステムを読み取り、論理的にバインドされたイメージを検出します。
   3. 新しい bootc イメージで定義されている、検出された論理的にバインドされたイメージを、bootc が所有する /usr/lib/bootc/storage イメージストレージに自動的にプルします。

5. バインドされたイメージを Podman などのコンテナーランタイムで使用できるようにします。そのためには、バインドされたイメージが "追加のイメージストア" として bootc ストレージを参照するように明示的に設定する必要があります。以下に例を示します。

   podman --storage-opt=additionalimagestore=/usr/lib/bootc/storage run <image>

   重要

   /etc/containers/storage.conf で /usr/lib/bootc/storage イメージストレージをグローバルに有効にしないでください。論理的にバインドされたイメージには bootc ストレージだけを使用してください。

   bootc image store は bootc が所有します。論理的にバインドされたイメージは、/usr/lib/bootc/bound-images.d ディレクトリー内のファイルによって参照されなくなると、ガベージコレクションされます。

手順

1. ログインして、registry.redhat.io に対する認証を行います。

   $ sudo podman login registry.redhat.io

2. bootc-image-builder ツールをインストールします。

   $ sudo podman pull registry.redhat.io/rhel10/bootc-image-builder

手順

1. オプション:QCOW2 イメージのユーザー設定を準備するために、config.toml ファイルを作成します。

   RHEL ベースイメージにはデフォルトのユーザーは含まれません。ユーザー設定を追加するには、ファイルに以下のような内容を入力します。

   [[customizations.user]]
   name = "user"
   password = "pass"
   key = "ssh-rsa AAA ... user@email.com"
   groups = ["wheel"]

   後で、このファイルを使用して、bootc-image-builder コンテナーを実行する際にユーザー設定を挿入できます。

   または、cloud-init を使用してベースイメージを設定し、初回起動時にユーザーと SSH キーを挿入することもできます。ユーザーとグループの設定 - cloud-init を使用したユーザーと SSH 鍵の注入 を参照してください。

2. コンテナーを実行する前に、出力 ディレクトリーを初期化する必要があります。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

3. 必要なイメージがシステムストレージにプルされていることを確認してください。

   $ quay.io/<namespace>/<image>:<tag>

   ローカルイメージは、以下のいずれかになります。

   • Containerfile を使用して構築したイメージ
   • ログインが必要な、アクセス制限付きのプライベートレジストリーから取得したイメージ
   • .tar ファイルから読み込んだイメージ

4. bootc-image-builder コンテナーを実行します。必要に応じて、ユーザーアクセス設定を使用する場合は、config.toml を引数として渡します。以下に例を示します。

   $ sudo podman run \
       --rm \
       -it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v /var/lib/containers/storage:/var/lib/containers/storage:Z \
       -v ./config.toml:/config.toml:Z \
       -v ./output:/output:Z \
       registry.redhat.io/rhel10/bootc-image-builder:latest \
       --type qcow2 \
       --config /config.toml \
       localhost/<local-image>:latest

手順

1. 次の内容の Containerfile を作成します。

   FROM quay.io/<namespace>/<image>:latest
   RUN dnf -y install cloud-init open-vm-tools && \
   ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \
   rm -rf /var/{cache,log} /var/lib/{dnf,rhsm} && \
   systemctl enable vmtoolsd.service

2. bootc イメージをビルドします。

   $ sudo podman build . -t localhost/rhel-bootc-vmdk

3. コンテナーを実行する前に、出力 ディレクトリーを初期化してください。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

4. 以前に作成した bootc イメージから VMDK ファイルを作成します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latest などのレジストリーからアクセスできる必要があります。

   $ sudo podman run \
       --rm \
       --privileged \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       -v ./output:/output \
       --security-opt label=type:unconfined_t \
       --pull newer \
       registry.redhat.io/rhel10/bootc-image-builder:latest \
       --type vmdk \
       --config /config.toml \
       localhost/rhel-bootc-vmdk:latest

   bootc イメージの VMDK ディスクファイルは、output/vmdk ディレクトリーに保存されます。

手順

1. オプション: ユーザーアクセスを設定するための config.toml を作成します。次に例を示します。

   [[customizations.user]]
   name = "user"
   password = "pass"
   key = "ssh-rsa AAA ... user@email.com"
   groups = ["wheel"]

2. コンテナーを実行する前に、出力 ディレクトリーを初期化してください。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

3. bootc-image-builder を実行します。必要に応じて、ユーザーアクセス設定を使用する場合は、config.toml を引数として渡します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latest などのレジストリーからアクセスできる必要があります。

   1. 以下は gce イメージを作成する例です。

      $ sudo podman run \
          --rm \
          --it \
          --privileged \
          --pull=newer \
          --security-opt label=type:unconfined_t \
          -v ./config.toml:/config.toml \
          -v ./output:/output \
          -v /var/lib/containers/storage:/var/lib/containers/storage \
          registry.redhat.io/rhel10/bootc-image-builder:latest \
          --type gce \
          --config /config.toml \
        quay.io/<namespace>/<image>:<tag>

      gce イメージは出力ディレクトリーにあります。

手順

1. bootc イメージからディスクイメージを作成します。

   • Containerfile でユーザーの詳細を設定します。このユーザーには、必ず sudo アクセス権限を割り当ててください。
   • Containerfile で設定したユーザーを使用して、カスタマイズされたオペレーティングシステムイメージをビルドします。パスワードなしの sudo アクセス権限を持つデフォルトユーザーが作成されます。

2. オプション: cloud-init を使用してマシンイメージを設定します。Image Mode for RHEL でのファイルシステムの管理 を参照してください。以下に例を示します。

   FROM quay.io/<namespace>/<image>:latest
   
   RUN dnf -y install cloud-init && \
       ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \
       rm -rf /var/{cache,log} /var/lib/{dnf,rhsm}

   注記

   cloud-init により、インスタンスメタデータを使用してユーザーや設定を追加することもできます。

3. bootc イメージをビルドします。たとえば、イメージを x86_64 AWS マシンにデプロイするには、次のコマンドを使用します。

   $ podman build -t quay.io/<namespace>/<image>:<tag> .
   $ podman push quay.io/<namespace>/<image>:<tag> .

4. コンテナーを実行する前に、出力 ディレクトリーを初期化してください。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

5. bootc-image-builder ツールを使用して、bootc コンテナーイメージからパブリックな AMI イメージを作成します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latest などのレジストリーからアクセスできる必要があります。

   $ sudo podman run \
     --rm \
     --it \
     --privileged \
     --pull=newer \
     -v ./config.toml:/config.toml \
     -v /var/home/<user>/.aws:/root/.aws \
     --env AWS_PROFILE=default \
     registry.redhat.io/rhel10/bootc-image-builder:latest \
     --type ami \
     --config /config.toml \
     --aws-ami-name rhel-bootc-x86 \
     --aws-bucket rhel-bootc-bucket \
     --aws-region us-east-1 \
   quay.io/<namespace>/<image>:<tag>

   以下のフラグはすべてまとめて指定する必要があります。フラグを指定しない場合、AMI は出力ディレクトリーにエクスポートされます。

   • --aws-ami-name - AWS の AMI イメージの名前
   • --aws-bucket - AMI を作成する際の中間ストレージのターゲット S3 バケット名

   • --aws-region - AWS アップロードのターゲットリージョン

     bootc-image-builder ツールは、お客様の AWS 認証情報を使用して、AMI イメージをビルドおよびアップロードし、AWS S3 バケットに登録します。

手順

1. オプション: ユーザーアクセスを設定するための config.toml を作成します。次に例を示します。

   [[customizations.user]]
   name = "user"
   password = "pass"
   key = "ssh-rsa AAA ... user@email.com"
   groups = ["wheel"]

2. コンテナーを実行する前に、出力 ディレクトリーを初期化してください。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

3. bootc-image-builder を実行します。ユーザーアクセス設定を使用する場合は、config.toml を引数として渡します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latest などのレジストリーからアクセスできる必要があります。

   $ sudo podman run \
       --rm \
       --it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       -v ./config.toml:/config.toml \
       -v ./output:/output \
       registry.redhat.io/rhel10/bootc-image-builder:latest \
       --type raw \
       --config /config.toml \
     quay.io/<namespace>/<image>:<tag>

   .raw イメージは出力ディレクトリーにあります。

手順

1. オプション: デフォルトの組み込みキックスタートを上書きして自動インストールを実行する config.toml ファイルを作成します。

   [customizations.installer.kickstart]
   contents = """
   text --non-interactive
   zerombr
   clearpart --all --initlabel --disklabel=gpt
   autopart --noswap --type=lvm
   network --bootproto=dhcp --device=link --activate --onboot=on
   """

2. コンテナーを実行する前に、出力 ディレクトリーを初期化してください。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

3. bootc-image-builder を実行してパブリックな ISO イメージを作成します。設定を追加しない場合は、-v ./config.toml:/config.toml 引数を省略します。このイメージは、registry.redhat.io/rhel10/bootc-image-builder:latest などのレジストリーからアクセスできる必要があります。

   $ sudo podman run \
       --rm \
       --it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       -v ./config.toml:/config.toml \
       -v ./output:/output \
       registry.redhat.io/rhel10/bootc-image-builder:latest \
       --type iso \
       --config /config.toml \
     quay.io/<namespace>/<image>:<tag>

   .iso イメージファイルは出力ディレクトリーにあります。

手順

1. キックスタートファイルを作成します。次のキックスタートファイルは、ユーザーの作成とパーティションの指示を含む、完全に自動のキックスタートファイル設定の例です。

   [customizations.installer.kickstart]
   contents = """
   lang en_GB.UTF-8
   keyboard uk
   timezone CET
   
   user --name <user> --password <password> --plaintext --groups <groups>
   sshkey --username <user> ssh-<type> <public key>
   rootpw --lock
   
   zerombr
   clearpart --all --initlabel
   autopart --type=plain
   reboot --eject
   """

2. キックスタートコンテンツを注入するために、キックスタート設定を toml 形式で保存します。たとえば、config.toml です。

3. bootc-image-builder を実行し、ISO ビルドに追加するキックスタートファイル設定を含めます。bootc-image-builder によって、コンテナーイメージをインストールする ostreecontainer コマンドが自動的に追加されます。

   $ sudo podman run \
       --rm \
       -it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       -v ./config.toml:/config.toml \
       -v ./output:/output \
       registry.redhat.io/rhel10/bootc-image-builder:latest \
       --type iso \
       --config /config.toml \
     quay.io/<namespace>/<image>:<tag>

   .iso イメージファイルは出力ディレクトリーにあります。

手順

1. config.toml ファイルを作成してカスタムマウントオプションを設定します。次に例を示します。

   [[customizations.filesystem]]
   mountpoint = "/"
   minsize = "10 GiB"
   
   [[customizations.filesystem]]
   mountpoint = "/var/data"
   minsize = "20 GiB"

2. config.toml を引数として渡して、bootc-image-builder を実行します。

   注記

   コンテナーストレージマウントがない場合は、イメージを公開する必要があります。

   以下はパブリックイメージを作成する例です。

   $ sudo podman run \
      --rm \
      -it \
      --privileged \
      --pull=newer \
      --security-opt label=type:unconfined_t \
      -v ./config.toml:/config.toml \
      -v ./output:/output \
      registry.redhat.io/rhel10/bootc-image-builder:latest \
      --type <image_type> \
      --config config.toml \
     quay.io/<namespace>/<image>:<tag>

手順

1. Containerfile を作成します。以下に例を示します。

   # Base image to point to your internal registry
   FROM example.com:1234/rhel10/rhel-bootc:10.2
   
   # Configure the local repo to use the files already present in the image
   # Assuming the repo data is located at /etc/pki/repos or similar inside the image
   RUN echo -e "[local-baseos]\n\
   name=Local RHEL 10 BaseOS\n\
   baseurl=file:///path/to/repo/in/image/BaseOS\n\
   enabled=1\n\
   gpgcheck=0" > /etc/yum.repos.d/local.repo
   
   # Install your required packages using the local file source
   RUN dnf install -y firewalld && \
      dnf clean all
   
   # Ensure the kernel and bootloader are present
   # In air-gapped bootc, BIB often fails because it expects to download these.
   # Pre-installing them ensures they are part of the 'bootc' transition.
   RUN dnf install -y kernel-bootc anaconda-dracut-modules && dnf clean all

2. bootc-image-builder ツールを使用して、Containerfile を ISO、raw、QCOW2 などのブート可能な形式に変換します。bootc-image-builder を使用した bootc 互換ベースディスクイメージの作成 を参照してください。

手順

1. Containerfile を作成します。

   FROM <internal_repository>/<image>
   # Add certificate to the input set of anchors
   COPY additional-certificate-root.pem /etc/pki/ca-trust/source/anchors
   RUN update-ca-trust

2. カスタムイメージをビルドします。

   $ sudo podman build -t <your_image> .

3. <your_image> を実行します。

   $ sudo podman run -it --rm <your_image>

手順

1. RHEL インストール ISO イメージを、HTTP サーバーにエクスポートします。これにより、PXE ブートサーバーでは、PXE クライアントにサービスを提供する準備が整いました。
2. クライアントを起動して、インストールを開始します。
3. ブートソースを指定するよう求められたら、PXE ブートを選択します。ブートオプションが表示されない場合は、キーボードの Enter キーを押すか、起動画面が開くまで待ちます。
4. Red Hat Enterprise Linux の起動画面で、必要なブートオプションを選択し、Enter キーを押します。
5. ネットワークインストールを開始します。

手順

1. metadata.yaml ファイルを作成し、このファイルに次の情報を追加します。

   instance-id: cloud-vm
   local-hostname: vmname

2. userdata.yaml ファイルを作成し、ファイルに次の情報を追加します。

   #cloud-config
   users:
   - name: admin
     sudo: "ALL=(ALL) NOPASSWD:ALL"
     ssh_authorized_keys:
     - ssh-rsa AAA...fhHQ== your.email@example.com

   ssh_authorized_keys は SSH 公開鍵です。~/.ssh/id_rsa.pub で SSH 公開鍵を確認できます。

3. 以下のように gzip で圧縮し、base64 でエンコードして metadata.yaml と userdata.yaml ファイルを環境にエクスポートします。これらのファイルは今後の手順で使用します。

   export METADATA=$(gzip -c9 <metadata.yaml | { base64 -w0 2>/dev/null || base64; }) \
   USERDATA=$(gzip -c9 <userdata.yaml | { base64 -w0 2>/dev/null || base64; })

4. metadata.yaml および userdata.yaml ファイルを使用して vSphere でイメージを起動します。

   1. .vmdk イメージを vSphere にインポートします。

      $ govc import.vmdk ./composer-api.vmdk <foldername>

   2. 電源をオンにせずに vSphere に仮想マシンを作成します。

      govc vm.create \
      -net.adapter=vmxnet3 \
      -m=4096 -c=2 -g=rhel8_64Guest \
      -firmware=bios -disk="foldername/composer-api.vmdk” \
      -disk.controller=ide -on=false \
      vmname

   3. 仮想マシンを変更して、ExtraConfig 変数の cloud-init 設定を追加します。

      govc vm.change -vm vmname \
      -e guestinfo.metadata="${METADATA}" \
      -e guestinfo.metadata.encoding="gzip+base64" \
      -e guestinfo.userdata="${USERDATA}" \
      -e guestinfo.userdata.encoding="gzip+base64"
      .. Power-on the VM:
      govc vm.power -on vmname

   4. 仮想マシンの IP アドレスを取得します。

      HOST=$(govc vm.ip vmname)

手順

1. ブラウザーで Service→EC2 にアクセスし、ログインします。
2. AWS コンソールのダッシュボードメニューで、正しいリージョンを選択します。イメージが正常にアップロードされたことを示すには、イメージが Available ステータスになっている必要があります。
3. AWS ダッシュボードでイメージを選択し、Launch をクリックします。
4. 新しく開いたウィンドウで、イメージを起動するために必要なリソースに応じて、インスタンスタイプを選択します。Review and Launch をクリックします。
5. インスタンスの詳細を確認します。変更が必要な場合は、各セクションを編集できます。Launch をクリックします。
6. インスタンスを起動する前に、インスタンスにアクセスするための公開鍵を選択します。既存のキーペアを使用するか、キーペアーを新規作成します。

7. インスタンスを起動するには、Launch Instance をクリックします。Initializing と表示されるインスタンスのステータスを確認できます。

   インスタンスのステータスが Running になると、Connect ボタンが有効になります。

8. Connect をクリックします。ウィンドウが表示され、SSH を使用して接続する方法の説明が表示されます。

9. 次のコマンドを実行して、自分だけが読み取れるように秘密鍵ファイルのパーミッションを設定します。Connect to your Linux instance を参照してください。

   $ chmod 400 <your-instance-name.pem>

10. パブリック DNS を使用してインスタンスに接続します。

    $ ssh -i <your-instance-name.pem>ec2-user@<your-instance-IP-address>

    注記

    インスタンスは停止しない限り実行され続けます。

手順

1. bootc-image-builder を使用して、カスタムインストーラー ISO ディスクイメージを作成します。bootc-image-builder を使用した ISO イメージの作成 を参照してください。
2. ISO ディスクイメージを USB フラッシュドライブにコピーします。
3. USB スティック内のコンテンツを使用して、非接続環境でベアメタルインストールを実行します。

手順

1. インスタンスが起動したら、インスタンスの作成時に選択したキーを使用して SSH でインスタンスに接続します。

   $ ssh -i <ssh-key-file> <cloud-user@ip>

2. system-reinstall-bootc サブパッケージがインストールされていることを確認します。

   # rpm -q system-reinstall-bootc

   そうでない場合は、system-reinstall-bootc サブパッケージをインストールします。

   # dnf -y install system-reinstall-bootc

3. bootc イメージを使用するようにシステムを変換します。

   # system-reinstall-bootc <image>

   Red Hat Ecosystem Catalog のコンテナーイメージ、または Containerfile から構築された bootc カスタマイズイメージを使用できます。

4. a キーを押して、bootc イメージにインポートするユーザーを選択します。
5. 選択内容を 2 回確認し、イメージがダウンロードされるまで待ちます。

6. システムを再起動します。

   # reboot

7. 指定された <ip> の保存されている SSH ホストキーを /.ssh/known_hosts ファイルから削除します。

   # ssh-keygen -R <ip>

   bootc システムは、新しい公開 SSH ホストキーを使用しています。ローカルに保存されているキーとは異なるキーを使用して同じ IP アドレスに接続しようとすると、SSH は警告を発するか、ホストキーの不一致により接続を拒否します。この変更は想定されているため、次のコマンドを使用して、既存のホストキーエントリーを ~/.ssh/known_hosts ファイルから安全に削除できます。

8. bootc システムに接続します。

   # ssh -i <ssh-key-file> root@<ip>

手順

1. システムにすでに接続されているストレージデバイスを確認します。

   $ lsblk
   NAME          MAJ:MIN     SIZE   RO TYPE  MOUNTPOINTS
   zram0           251:0       8G    0 disk  [SWAP]
   nvme0n1         259:0   476.9G    0 disk
   ├─nvme0n1p1    259:1     600M    0 part  /boot/efi
   ├─nvme0n1p2    259:2       1G    0 part  /boot
   └─nvme0n1p3    259:3   475.4G    0 part

2. 外部ストレージを接続して、同じコマンドを実行します。2 つの出力結果を比較して、システム上の外部ストレージデバイスの名前を確認します。

   $ lsblk
   NAME        MAJ:MIN   SIZE   RO TYPE  MOUNTPOINTS
   sda             8:0   28.9G    0 disk
   └─sda1         8:1   28.9G    0 part
   zram0         251:0      8G    0 disk  [SWAP]
   nvme0n1       259:0  476.9G    0 disk
   ├─nvme0n1p1  259:1    600M    0 part  /boot/efi
   ├─nvme0n1p2  259:2      1G    0 part  /boot
   └─nvme0n1p3  259:3  475.4G    0 part

   この場合、sda という名前の USB ドライブには sda1 パーティションがあります。

   MOUNTPOINTS 列には、外部ストレージ上のパーティションのマウントポイントがリスト表示されます。システムが外部ストレージを自動的にマウントする場合、有効なマウントポイントはすでに存在します。ただし、マウントポイントがない場合は、デバイスに保存する前に、自身分でマウントする必要があります。

3. パーティションをマウントするには、空のディレクトリーを作成するか、既存のディレクトリーを使用します。

   $ sudo mkdir /mnt/usb/

   1. デバイスのパーティションをマウントします。

      $ sudo mount /dev/sda1 /mnt/usb

   2. オプション: パーティションが正しく作成されたか確認します。

      $ lsblk
      NAME         MAJ:MIN    SIZE   RO TYPE  MOUNTPOINTS
      sda              8:0   28.9G    0 disk
      └─sda1          8:1   28.9G    0 part  /mnt/usb
      [...]

      外部ストレージデバイスにファイルをコピーする準備が整いました。

4. skopeo コマンドを使用して、ローカルに保存されているコンテナーをマウントされたデバイスにコピーし、コンテナーのパスと名前を自身の環境に合わせて変更します。

   • ローカルストレージの場合:

     $ sudo skopeo copy --preserve-digests --all \
       containers-storage:localhost/rhel-container:latest \
       oci://mnt/usb/

   • リモートレジストリーに保存されているコンテナーの場合:

     $ sudo skopeo copy --preserve-digests --all \
       docker://quay.io/example:latest \
       oci://mnt/usb/

     注記

     コンテナーのサイズによっては、これらのコマンドが完了するまで数分かかる場合があります。

5. 外部ストレージをアンマウントし、取り出します。

   $ sudo umount /dev/sda1
   $ sudo eject /dev/sda1

6. オフラインシステムのコンテナーに更新を適用します。
7. 外部ストレージデバイスをオフラインシステムに接続します。ストレージデバイスが自動的にマウントされない場合は、mkdir と mount コマンドを使用して外部ストレージの場所を特定し、マウントします。

8. コンテナーを外部デバイスからオフラインシステムのローカルコンテナーレジストリーにコピーします。コンテナーをオフラインマシンのローカルコンテナーストレージにコピーします。

   $ skopeo copy --preserve-digests --all \
     oci://mnt/usb \
     containers-storage:rhel-update:latest

   この場合、外部ストレージのマウントポイントが OCI セクションへのパスとなります。containers-storage セクションの内容は、コンテナーに付ける名前やタグによって異なります。

9. Podman を使用して、コンテナーがローカルに存在することを確認します。

   $ podman images
   REPOSITORY			        TAG     IMAGE ID  CREATED  SIZE
   example.io/library/rhel-update   latest  cdb6d...  1 min    1.48 GB

10. bootc を使用して、オフラインシステムのコンテナーに更新をデプロイします。

    $ bootc switch --transport containers-storage \
    example.io/library/rhel-update:latest

    1. コンテナーをローカルストレージにコピーできない場合は、代わりに oci transport フラグとストレージデバイスへのパスを使用します。

       $ bootc switch --transport oci /mnt/usb

       bootc switch コマンドの --transport フラグを使用すると、コンテナーの代替ソースを指定できます。

       デフォルトでは、bootc はレジストリーからイメージをプルしようとします。これは、bootc-image-builder がレジストリーを使用して元のイメージをビルドするためです。bootc upgrade を使用する場合、更新の場所を指定できません。bootc switch を使用し、ローカルコンテナーストレージを使用することを指定することで、リモートレジストリーの必要性を排除できるだけでなく、将来的にこのローカルコンテナーを使用して更新をデプロイすることも可能になります。

       ローカルのコンテナーと更新が同じ場所に配置されている場合、bootc upgrade を正常に実行できるようになりました。今後、リモートリポジトリーの更新に切り替えたい場合は、再度 bootc switch を使用する必要があります。

検証

1. 更新が正しくデプロイされたことを確認します。

   $ bootc status
   Staged image: containers-storage:example.io/library/rhel-update:latest
     Digest: sha256: 05b1dfa791...
     Version: 10.0 (2025-07-07 18:33:19.380715153 UTC)
   Booted Image: localhost/rhel-intel:base
     Digest: sha256: 7d6f312e09...
     Version: 10.0 (2025-06-23 15:58:12.228704562 UTC)

   出力には、現在起動中のイメージと、適用が予定されているステージングされた変更内容が表示されます。以前使用したコンテナーは表示されますが、ステージングされた変更は次回の再起動まで反映されません。出力結果から、更新がコンテナーストレージからプルされることも確認できます。

2. システムを再起動します。

   $ bootc status
   Booted image: containers-storage:example.io/library/rhel-update:latest
   	Digest: sha256: 05b1dfa791...
   	Version: 10.0 (2025-07-07 18:33:19.380715153 UTC)
   Rollback image: localhost/rhel-intel:base
   	Digest: sha256: 7d6f312e09...
   	Version: 10.0 (2025-06-23 15:58:12.228704562 UTC)

   正しいイメージで起動したか確認できます。

   • 起動したイメージは、更新されたイメージです。
   • ロールバックイメージは、以前のイメージです。オフラインイメージモードの更新が正常に完了しました。

検証

1. イメージを保存してビルドします。

   $ podman build -t quay.io/<namespace>/<image>:<tag> . --cap-add=all --security-opt=label=type:container_runtime_t --device /dev/fuse

2. カレントディレクトリーにある Containerfile を使用して <_image_> イメージをビルドします。

   $ podman build -t quay.io/<namespace>/<image>:<tag> .

手順

1. お使いのディストリビューションのリポジトリーを有効にしてください。たとえば、AppStream の場合:

   $ sudo subscription-manager repos --enable=rhel-10-for-x86_64-appstream-rpms

2. Red Hat Enterprise Linux (RHEL) Extra Packages for Enterprise Linux (EPEL) リポジトリーを有効にします。

   $ sudo dnf install epel-release

3. bcvk パッケージをインストールしてください。

   $ sudo dnf install bcvk

検証

1. インストールを確認します。

   $ bcvk --version

2. オプション: 永続的な仮想マシン管理に libvirt を使用している場合は、libvirtd サービスを開始してください。

   $ sudo systemctl enable --now libvirtd

   このコマンドは仮想化デーモンを初期化し、仮想マシンオーケストレーションのためのバックエンドインフラストラクチャーがアクティブであることを保証します。

手順

1. ローカルシステム上で、bootc で使用するために明示的にラベル付けされているイメージをリスト表示してください。

   $ bcvk images list

   このコマンドは、すべてのローカルイメージのメタデータをスキャンし、containers.bootc=1 ラベルを含むイメージのリストを返します。

   • コマンドがイメージをリスト表示した場合、それらはブート可能であることが検証され、bcvk ephemeral、bcvk libvirt、または bcvk to-disk コマンドで使用できます。

   • コマンドを実行してもイメージが表示されない場合は、互換性のあるイメージ (たとえば、registry.redhat.io/rhel10/rhel-bootc) をプルしたか、カスタムビルドしたイメージの Containerfile に必要なラベルが含まれていることを確認してください。

     LABEL containers.bootc=1

2. オプション: 特定のイメージが欠落している場合は、そのラベルを手動で確認してください。

   $ podman inspect --format '{{.Config.Labels}}' <image_name>

手順

1. bootc コンテナーを一時的な仮想マシンとして実行する:

   $ bcvk ephemeral run -d --rm -K --name my-test-vm registry.redhat.io/rhel10/rhel-bootc:latest

   -d

   仮想マシンをデタッチモード (バックグラウンド) で実行します。

   --rm

   仮想マシンが停止すると、自動的に削除され、リソースがクリーンアップされます。

   -K

   ホストの SSH キーを仮想マシンに自動的に挿入し、即座にアクセスできるようにします。

   --name

   インスタンスにカスタム名 (my-test-vm) を割り当てます。

2. オプション: run-ssh コマンドを使用して、仮想マシンを起動して一度にログインすることもできます。

   $ bcvk ephemeral run-ssh registry.redhat.io/rhel10/rhel-bootc:latest

   このモードでは、仮想マシンはセッションベースのリソースとして扱われます。SSH シェルを終了すると、自動的に終了します。

3. 仮想マシン環境内で必要なタスクを実行してください。

4. セッションを終了する:

   $ exit

   注記

   終了時には、一時的な仮想マシン内のすべての変更は破棄され、リソースはホストによって解放されます。

手順

1. 以下のいずれかの方法を使用して、永続的な libvirt 仮想マシンを作成します。

   • デフォルト設定で基本的な仮想マシンを作成するには:

     libvirt run コマンドは、ネットワーク設定や SSH 設定を含む仮想マシンのプロビジョニングを自動化します。

     $ bcvk libvirt run registry.redhat.io/rhel10/rhel-bootc:latest

   • 特定のリソース制約を持つカスタマイズされた仮想マシンを作成するには:

     フラグを使用して、名前、メモリー容量 (MB 単位)、CPU 数、およびディスクサイズ (GB 単位) を定義します。

     $ bcvk libvirt run --name dev-vm --memory 4096 --cpus 4 --filesystem btrfs --disk-size 50G registry.redhat.io/rhel10/rhel-bootc:latest

2. 仮想マシンのプロビジョニングが完了したら、bcvk libvirt サブコマンドを使用してその状態を管理します。

   Expand

   タスク	コマンド
   仮想マシンのリストを表示	bcvk libvirt リスト
   仮想マシンを起動する	bcvk libvirt start <vm_name>
   仮想マシンを停止する	bcvk libvirt stop <vm_name>
   仮想マシンを削除する	bcvk libvirt rm -f <vm_name>
   SSH 経由でアクセス	bcvk libvirt ssh <vm_name>

   Show more

1. 前提条件

   • ホストシステムに bcvk ユーティリティーをインストールしました。
   • ローカルまたはリモートの bootc コンテナーイメージが利用可能です。
   • 生成されたイメージを保存するのに十分なディスク容量がホストマシン上にあります。
   • ブロックデバイスやシステムパスに直接書き込むには、root 権限 または sudo 特権が必要です。

2. 手順

   • 以下のいずれかの方法を使用してディスクイメージを生成します。

     • 仮想ディスクイメージを作成する:

       $ bcvk to-disk --format=qcow2 localhost/my-image output-disk.qcow2

   • --format: 出力ディスクの種類を指定します。サポートされているフォーマット: qcow2、raw (デフォルト)。

   • output-disk.qcow2: 生成されたディスクイメージの保存先ファイル名を指定します。

     • 物理デバイスに直接書き込む:

       $ bcvk to-disk registry.redhat.io/rhel10/rhel-bootc:latest /path/to/disk.img

       警告

       たとえば /dev/sdX の ようなブロックデバイスに直接書き込むと、そのデバイス上の既存のデータはすべて上書きされます。コマンドを実行する前に、ターゲットパスが正しいことを確認してください。

手順

1. 01-fips.toml を作成して FIPS の有効化を設定します。次に例を示します。

   # Enable FIPS
   kargs = ["fips=1"]

2. 次の指示を含む Containerfile を作成して、fips=1 カーネル引数を有効にし、暗号化ポリシーを調整します。

   FROM quay.io/<namespace>/<image>:latest
   # Enable fips=1 kernel argument: https://bootc-dev.github.io/bootc/building/kernel-arguments.html
   COPY 01-fips.toml /usr/lib/bootc/kargs.d/
   # Install and enable the FIPS crypto policy
   RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS

3. コンテナーを実行する前に、output フォルダーを初期化します。ディレクトリーがすでに存在する場合にコマンドが失敗しないようにするには、-p 引数を使用します。

   $ mkdir -p ./output

4. カレントディレクトリーの Containerfile を使用して、bootc <image> と互換性のあるベースディスクイメージを作成します。

   $ sudo podman run \
       --rm \
       -it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v ./config.toml:/config.toml \
       -v ./output:/output \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       registry.redhat.io/rhel10/bootc-image-builder:latest \
       --type iso \
       quay.io/<namespace>/<image>:<tag>

5. システムのインストール中に FIPS モードを有効にします。

   1. RHEL Anaconda インストーラーを起動するときに、インストール画面で TAB キーを押して、fips=1 カーネル引数を追加します。インストール後に、システムは FIPS モードで自動的に起動します。

手順

1. Containerfile を作成します。

   FROM quay.io/<namespace>/<image>:latest
   
   # Install OpenSCAP scanner and security content to the image
   RUN dnf install -y openscap-utils scap-security-guide && dnf clean all
   
   # Run scan and hardening
   RUN oscap-im --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
   
   # Because certain profiles prevent ssh root logins, add a separate sudo user with a password
   # Alternatively, you can add users with Kickstart, cloud-init, or other methods
   RUN useradd -G wheel -p "<password_hash>" <admin_user>

   <admin_user> はユーザー名に、<password_hash> は、選択したパスワードのハッシュに置き換えます。

   この Containerfile は次のタスクを実行します。

   • oscap-im ツールを提供する openscap-utils パッケージと、Security Content Automation Protocol (SCAP) コンテンツを含むデータストリームを提供する scap-security-guide パッケージをインストールします。
   • SSH ルートログインを阻止するプロファイルに sudoer 権限を持つユーザーを追加します。
   • 選択されたプロファイルに準拠して、イメージのスキャンと修復を行います。

2. カレントディレクトリーにある Containerfile を使用してイメージをビルドします。

   $ podman build -t quay.io/<namespace>/<image>:<tag> .

手順

1. Containerfile を作成します。

   FROM quay.io/<namespace>/<image>:latest
   
   # Copy a tailoring file into the Containerfile
   COPY tailoring.xml /usr/share/
   
   # Install OpenSCAP scanner and security content to the image
   RUN dnf install -y openscap-utils scap-security-guide && dnf clean all
   
   
   # Add sudo user 'admin' with password 'admin123'.
   # The user can be used with profiles that prevent
   # ssh root logins.
   RUN useradd -G wheel -p "\$6\$Ga6Zn
   IlytrWpuCzO\$q0LqT1USHpahzUafQM9jyHCY9BiE5/ahXLNWUMiVQnFGblu0WWGZ1e6icTaCGO4GNgZNtspp1Let/qpM7FMVB0" admin
   
   # Run scan and hardening including the tailoring file
   RUN oscap-im --tailoring-file /usr/share/tailoring.xml --profile stig_customized /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

   この Containerfile は次のタスクを実行します。

   • イメージにテーラリングファイルを注入します。
   • oscap-im ツールを提供する openscap-utils パッケージと、Security Content Automation Protocol (SCAP) コンテンツを含むデータストリームを提供する scap-security-guide パッケージをインストールします。
   • SSH ルートログインを阻止するプロファイルに sudoer 権限を持つユーザーを追加します。
   • 選択されたプロファイルに準拠して、イメージのスキャンと修復を行います。

2. カレントディレクトリーにある Containerfile を使用してイメージをビルドします。

   $ podman build -t quay.io/<namespace>/<image>:<tag> .

手順

1. transient-root-example.service サービスを作成し、read および write 権限を持つディレクトリーを作成します。次の例では、/etc/afs が存在するものとします。

   [Unit]
   Description=Transient Root Example - Dynamic Mount Point Creation
   After=local-fs.target
   ConditionPathExists=/etc/afs
   DefaultDependencies=no
   
   [Service]
   Type=oneshot
   RemainAfterExit=yes
   MountFlags=slave
   # LIBMOUNT_FORCE_MOUNT2=always is required for mount command compatibility
   # See: https://github.com/util-linux/util-linux/issues/3171
   Environment=LIBMOUNT_FORCE_MOUNT2=always
   ExecStart=/usr/bin/bash -c "echo 'Transient root example: Detected /etc/afs, remounting root as read-write'; mount -o remount,rw /; mkdir -p /afs; echo 'Created /afs directory for AFS mount point'"
   
   [Install]
   WantedBy=multi-user.target

2. ContainerFile に次の設定を追加します。

   # Copy the systemd service unit that demonstrates dynamic mount point creation
   # The service will:
   # 1. Check for existence of /etc/afs (ConditionPathExists)
   # 2. Use MountFlags=slave for proper mount propagation
   # 3. Set LIBMOUNT_FORCE_MOUNT2=always for mount command compatibility
   # 4. Remount root as read-write and create /afs directory when triggered
   COPY transient-root-example.service /usr/lib/systemd/system/
   
   # Enable the service to start automatically on boot
   RUN systemctl enable transient-root-example.service

3. コンテナービルドプロセス中に transient-ro オプションを有効にするには、イメージ内の /usr/lib/ostree/prepare-root.conf ファイルに次の設定を作成します。

   RUN echo -e '[root]\ntransient=true' > /usr/lib/ostree/prepare-root.conf && \
       set -x; kver=$(cd /usr/lib/modules && echo *); dracut -vf /usr/lib/modules/$kver/initramfs.img $kver

   注記

   ファイルシステムの設定を変更する場合は、initramfs イメージを再生成する必要があります。

4. 一時的なルートファイルシステムを使用して bootc イメージをビルドします。

   $ podman build --cap-add SYS_ADMIN -t transient-root-ro:test .

   これにより、ビルド中の ostree 操作において bootc が必要とする SYS_ADMIN ケーパビリティーが追加されます。

検証

1. ビルドしたイメージで transient-ro = true 設定ファイルが正しく設定されていることを確認します。

   $ sudo podman run --rm transient-root-ro:test cat /usr/lib/ostree/prepare-root.conf

   以下のような出力が表示されます。

   [root]
   transient-ro = true

2. 稼働中のシステムで、実行時の機能を検証します。

   1. イメージを起動します。

   2. /etc/afs テストディレクトリーを作成します。

      $ sudo mkdir -p /etc/afs

   3. サービスを再起動し、動的マウントポイントの作成をトリガーします。

      $ systemctl restart transient-root-example.service

      サービスにより、ルートが read-write として再マウントされ、/afs ディレクトリーが作成されます。

3. systemd サービスなしで機能をテストするために、実行中のシステムで root としてテストディレクトリーを作成します。

   $ sudo export LIBMOUNT_FORCE_MOUNT2=always
   $ sudo unshare -m -- /bin/sh -c 'mount -o remount,rw / && mkdir /transient-test'

4. ディレクトリーが作成されたかどうかを検証します。

   $ sudo ls -d /transient-test /transient-test

5. ルートファイルシステムへの書き込みを試行して、他のプロセスにとっては read-only ステータスであることを検証します。

   $ touch /another-test-file
   touch: cannot touch '/another-test-file': Read-only file system

手順

1. 工場出荷時設定にリセットしてください。目的に応じて、以下のいずれかのコマンドを実行してください。

   • 現在実行中のイメージと同じイメージにリセットするには:

     $ sudo bootc install reset --experimental

   • リセットして別のイメージに切り替えるには:

     $ sudo bootc install reset --experimental --target-imgref quay.io/example/myimage:latest

   • リセットしてすぐに再起動するには:

     $ sudo bootc install reset --experimental --apply

   • カスタムカーネル引数を追加するには:

     $ sudo bootc install reset --experimental --karg=console=ttyS0,115200n8

   • ルートファイルシステムのカーネル引数の継承をスキップするには:

     $ sudo bootc install reset --experimental --no-root-kargs

     新しいデプロイメントに再起動した後でも、/sysroot/ostree/deploy/<old-stateroot>/ 内のファイルを調べることで、古いシステムのデータにアクセスできます。

     注記

     工場出荷時設定にリセットして新しいステートルートに再起動した後も、古いステートルートは /sysroot/ostree/deploy/<old-stateroot>/ にディスク上に残ります。必要であれば、以前のシステムからファイルにアクセスできます。詳細は、古いステートルートのクリーンアップを 参照してください。

手順

1. カーネル引数を使用して /usr/lib/bootc/kargs.d 内にファイルを作成します。

   $ sudo tee /usr/lib/bootc/kargs.d/console.kargs << EOF
   console=tty0 console=ttyS0,115200n8
   EOF

2. コンテナーイメージを取得して OSTree コミットを取得します。

   $ podman pull quay.io/<your_org>/<your_bootc_image>:latest

3. OSTree コミットを使用してファイルツリーを返します。

   # bootc install to-filesystem --karg=root=<UUID>=<uuid of /mnt> --imgref $self /mnt

4. /usr/lib/bootc/kargs.d カーネル引数ディレクトリーに移動します。

   cd /usr/lib/bootc/kargs.d

5. カーネル引数ディレクトリー内の各ファイルを読み取ります。

   $ find /usr/lib/bootc/kargs.d -name ".kargs" -exec cat {} \;*

6. 各 kargs ファイルの内容を、必要なすべての kargs を含むファイルにプッシュします。

   $ CONSOLIDATED_KARGS="/tmp/all-kargs.txt"

7. kargs を stage() 関数に渡します。

   $ bootc kargs --append="$KARGS_STRING"

8. 運用中に、切り替え、アップグレード、または編集操作に対してカーネル引数を適用します。

   $ bootc switch --transport=registry quay.io/<your_org>/<your_bootc_image>:latest

手順

1. ビルドホスト上で、ドライバーをコンパイルし、RPM パッケージをビルドします。

   1. 仕様を確認し、パッケージをビルドします。

      $ cat SPECS/hello.spec

   2. ドライバー RPM をビルドします。

      $ rpmbuild -ba SPECS/hello.spec

2. オペレーティングシステムイメージにドライバーを追加するための Containerfile を作成します。rhel-bootc ベースイメージを使用します。以下に例を示します。

   # Copy the pre-built RPM into the build context
   COPY rpms/hello-<version>-<release>.el10.<arch>.rpm /tmp/

   または、ネットワーク上の場所から取得することもできます。

   # Install the RPM.
   # The %post scripts in the RPM triggers 'depmod' automatically inside the image.
   RUN dnf install -y /tmp/hello-<version>-<release>.el10.<arch>.rpm && \
      	dnf clean all && \
       	rm /tmp/hello-<version>-<release>.el10.<arch>.rpm

3. コンテナーイメージをビルドして実行します。コンテナーのビルド を参照してください。

検証

1. システムを再起動します。

   $ sudo reboot

2. カーネルモジュールがシステム上で利用可能であることを確認します。

   $ sudo uname -r
   <kernel_version>
   
   $ sudo ls -l /lib/modules/<kernel_version>/extra/
   total 12
   -rwxr-xr-x. 1 root root 8512 Jan  1  1970 hello.ko

3. イメージを確定する前にモジュールの依存関係が計算されていることを確認してください。そうしないと、modprobe が最初の起動時に失敗する可能性があります。

   $ sudo depmod -a <kernel-version>

4. モジュールをロードできることを確認します。

   $ sudo modprobe /lib/modules/<kernel_version>/extra/hello.ko
   $ sudo lsmod | grep hello
      hello        12288  0
   $ sudo rmmod hello
   $ sudo dmesg
    ..snip..
   [   84.738633] hello: loading out-of-tree module taints kernel.
   [   84.738684] hello: module verification failed: signature and/or required key missing -tainting kernel.
   [   84.740548] Hello, world!
   [  138.206978] Goodbye!

手順

1. bootc ツールを使用して新しいコンテナーイメージをステージングし、更新、切り替え、またはロールバック操作を実行します。実行しない場合は、ソフトウェアは現在のユーザー空間で再度実行されます。

   $ sudo bootc update --soft-reboot=required --apply

2. たとえば、bootc スイッチの実行中にソフトリブートを開始します。

   $ sudo bootc switch --soft-reboot=required --apply quay.io/test_rh/soft-reboot:1

手順

1. bootc が認証の必要なレジストリーから更新を取得するには、ファイルにプルシークレットを含める必要があります。次の例では、creds シークレットにレジストリープルシークレットが含まれています。

   FROM quay.io/<namespace>/<image>:<tag>
   COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf
   RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \
     chmod 0600 /usr/lib/container-auth.json && \
     ln -sr /usr/lib/container-auth.json /etc/ostree/auth.json

2. podman build コマンドを使用してイメージをビルドします。

   $ podman build --secret id=creds,src=$HOME/.docker/config.json

   コンテナーイメージに埋め込まれた共通の永続ファイル (例: /usr/lib/container-auth.json) へのシンボリックリンクを両方の場所に対して使用することで、bootc と Podman に単一のプルシークレットを使用します。

   コンテナービルドにシークレットを埋め込むことによるシークレットの注入

   レジストリーサーバーが適切に保護されている場合は、コンテナーイメージにシークレットを含めることができます。場合により、ブートストラップシークレットのみをコンテナーイメージに埋め込むことが実行可能なパターンになることがあります。特に、マシンをクラスターに対して認証するメカニズムと併用した場合が該当します。このパターンでは、プロビジョニングツールは、ホストシステムの一部として実行されるか、コンテナーイメージの一部として実行されるかに関係なく、ブートストラップシークレットを使用して SSH 鍵や証明書などの他のシークレットを注入または更新します。

   クラウドメタデータを使用したシークレットの注入

   実稼働環境の Infrastructure as a Service (IaaS) システムのほとんどは、シークレット (特にブートストラップシークレット) をセキュアにホストできる、メタデータサーバーまたは同等のものをサポートします。コンテナーイメージには、これらのシークレットを取得するための cloud-init や ignition などのツールを含めることができます。

   ディスクイメージにシークレットを埋め込むことによるシークレットの注入

   bootstrap secrets は、ディスクイメージにのみ埋め込むことができます。たとえば、AMI や OpenStack などの入力コンテナーイメージからクラウドディスクイメージを生成する場合、ディスクイメージには、実質的にマシンローカル状態であるシークレットが含まれることがあります。これらをローテーションするには、追加の管理ツールを使用するか、ディスクイメージを更新する必要があります。

   ベアメタルインストーラーを使用したシークレットの注入

   インストーラーツールは通常、シークレットを使用した設定の注入をサポートします。

   systemd 認証情報を使用したシークレットの注入

   systemd プロジェクトには、認証情報のデータをセキュアに取得してシステムやサービスに渡すための認証情報の概念があります。これは、一部のデプロイメント方法に適用されます。1 つ以上の認証情報が設定された状態でサービスが呼び出されると、環境変数 $CREDENTIALS_DIRECTORY が設定されます。この変数には、認証情報が格納されているディレクトリーへの絶対パスが含まれており、システムは設定された認証情報ごとに 1 つのファイルをこのディレクトリーに配置します。

   さらに、ユニットファイル内の %d 指定子は、サービスの認証情報ディレクトリーに解決され、システムはそれを $CREDENTIALS_DIRECTORY 環境変数と共にサービスプロセスに渡します。

手順

1. プルシークレットを設定します。

   %pre
   mkdir -p /etc/ostree
   cat > /etc/ostree/auth.json << 'EOF'
   {
           "auths": {
                   "quay.io": {
                           "auth": "<your secret here>"
                   }
           }
   }
   EOF
   %end

   この設定では、システムが /etc/ostree/auth.json に保存されている指定の認証情報を使用して、quay.io からイメージをプルします。

2. セキュアでないレジストリーの TLS を無効にします。

   %pre
   mkdir -p /etc/containers/registries.conf.d/
   cat > /etc/containers/registries.conf.d/local-registry.conf << 'EOF'
   
   [[registry]]
   location="[IP_Address]:5000"
   insecure=true
   EOF
   %end

   この設定では、システムが TLS で保護されていないレジストリーからコンテナーイメージをプルします。この設定は開発や社内ネットワークで使用できます。

   %pre は次の目的でも使用できます。

   • インストール環境に含まれているバイナリー (curl など) を使用して、ネットワークからデータを取得する。

   • update-ca-trust コマンドを使用して、信頼された認証局をインストール環境 /etc/pki/ca-trust/source/anchors に注入する。

     同様に、/etc/containers ディレクトリーを変更することで、セキュアでないレジストリーを設定できます。auth.json ファイルの形式と設定の詳細は、containers-auth.json(5) を参照してください。

手順

1. 単一のプルシークレットを使用するために、bootc と Podman の間にシンボリックリンクを作成します。シンボリックリンクを作成することにより、コンテナーイメージに埋め込まれる共通の永続ファイルに対する両方の場所を確保できます。

   FROM quay.io/<namespace>/<image>:<tag>
   COPY containers-auth.conf /usr/lib/tmpfiles.d/link-podman-credentials.conf
   RUN --mount=type=secret,id=creds,required=true cp /run/secrets/creds /usr/lib/container-auth.json && \
     chmod 0600 /usr/lib/container-auth.json && \
     ln -sr /usr/lib/container-auth.json /etc/ostree/auth.json

2. containers-auth.conf ファイルを作成します。

   # Make /run/containers/0/auth.json (a transient runtime file)
   # a symlink to our /usr/lib/container-auth.json (a persistent file)
   # which is also symlinked from /etc/ostree/auth.json.
   d /run/containers/0 0755 root root -
   L /run/user/0/containers/auth.json - - - - ../../../../usr/lib/container-auth.json

3. podman build コマンドを使用してイメージをビルドします。

   $ podman build --secret id=creds,src=$HOME/.docker/config.json

   Containerfile を実行すると、次の操作が実行されます。

   • この Containerfile は、containers-auth.conf を一時的なランタイムファイルとします。
   • containers-auth.conf へのシンボリックリンクを作成します。

   • また、永続ファイルも作成されます。このファイルにも、/etc/ostree/auth.json からのシンボリックリンクが設定されます。

     Podman にはシステム全体の認証情報がありません。Podman は、次のディレクトリー配下にある containers-auth の場所を受け付けます。

   • /run: このディレクトリーの内容は再起動時に消去されますが、不要なため消去されても問題ありません。

   • /root: root のホームディレクトリーの一部。デフォルトではローカルで変更可能な状態です。

     bootc と Podman の認証情報を統合するには、bootc と Podman の両方に単一のデフォルトのグローバルプルシークレットを使用します。次のコンテナービルドは、bootc と Podman の認証情報を統合する例です。この例では、creds という名前のシークレットに、ビルドするレジストリープルシークレットが含まれていることを想定しています。