NVIDIA Container ToolkitとDocker/Podmanでディープラーニング開発環境を構築する（1）- NVIDIA Container Toolkit & コンテナエンジンのインストール

このシリーズでは、ローカルにNVIDIA Container Toolkitを用いてコンテナベースのディープラーニング開発環境を構築し、リモートサーバーとして活用できるようSSHおよびJupyterLabを設定する方法を解説します。本記事は第1回として、NVIDIA Container Toolkitとコンテナエンジンのインストール手順を紹介します。

投稿日 12024/08/26 HE 更新日 12026/01/07 HE

投稿者 Yunseo Kim

回閲覧 41 分で読めます

NVIDIA Container ToolkitとDocker/Podmanでディープラーニング開発環境を構築する（1）- NVIDIA Container Toolkit & コンテナエンジンのインストール

概要

このシリーズではNVIDIA Container ToolkitとDockerまたはPodmanをインストールし、Docker Hubのnvidia/cudaリポジトリで提供されるCUDAおよびcuDNNイメージをベースにDockerfileを作成して、ディープラーニング開発環境を構築する過程を扱う。必要な方が自由に利用できるよう、この過程を経て完成したDockerfileとイメージをGitHubとDocker Hubで共有し、加えてリモートサーバーとして活用するためのSSHおよびJupyterLab設定ガイドを提供する。
シリーズは3本の記事で構成する予定で、いま読んでいる本記事はその第1回である。

第1回：NVIDIA Container Toolkit & コンテナエンジンのインストール（本文）
第2回：GPU活用のためのコンテナランタイム構成、Dockerfileの作成およびコンテナイメージのビルド
第3回（アップロード予定）

x86_64 Linux環境でCUDAをサポートするNVIDIAグラフィックカードを搭載したシステムであることを前提に進める。UbuntuまたはFedora以外のディストリビューションでは直接テストしていないため、いくつかの細部は多少異なる可能性がある。
（12026.1.6. 改訂）

開発環境の構成

ホストOSおよびアーキテクチャ：x86_64、Linux環境（Ubuntu 22.04/24.04 LTS、RHEL/Centos、Fedora、openSUSE/SLES 15.x など）
構築する技術スタック（言語・ライブラリ）
- Python 3
- NVIDIA Container Toolkit
- Docker Engine / Podman
- CUDA 12.4 / 12.8 / 13.0
- cuDNN 9
- OpenSSH
- tmux
- JupyterLab
- NumPy & SciPy
- CuPy（optional, NumPy/SciPy-compatible Array Library for GPU-accelerated Computing with Python）
- pandas
- cuDF（optional, to accelerate pandas with zero code changes with the GPU accelerator）
- Matplotlib & Seaborn
- cuxfilter（optional, to quickly visualize and filter through large datasets, with a few lines of code, using best in class charting libraries）
- DALI（optional, a high-performance alternative to built-in data loaders and data iterators using GPU）
- scikit-image
- cuCIM（optional, an accelerated n-dimensional image processing and image I/O alternative to scikit-image）
- scikit-learn
- XGBoost
- cuML（optional, to execute machine learning algorithms on GPUs with an API that closely follows the scikit-learn API）
- cuVS（optional, optimized algorithms for approximate nearest neighbors and clustering, along with many other essential tools for accelerated vector search）
- RAFT（optional, CUDA accelerated primitives which is used by other RAPIDS libraries）
- PyTorch
- cuGraph（optional, a GPU-accelerated graph analytics library which includes a zero-code-change accelerator for NetworkX）
- tqdm
状況や好みによっては、pandasの代わりにPolarsのDataFrameライブラリを使用することも検討できる。Rustで書かれており、大規模データ処理ではcuDF + pandasの組み合わせには劣るものの、素のpandasパッケージと比べるとかなり優れた性能を示し、Queryにより特化した文法を提供する。公式のPolarsブログとcuDFドキュメントによれば、PolarsとNVIDIA RAPIDSチームが協力してcuDFベースのGPU加速エンジンをオープンベータで提供しており、急速に開発が進んでいるという。
Docker CEとPodmanのどちらを使うか迷っているなら、後述の比較表が参考になる。

以前に作成した機械学習開発環境構築ガイドとの比較表

以前このブログにアップロードした機械学習開発環境構築ガイドも存在するが、変更点が多いため新たに本記事を書いた。相違点は以下の表の通り。

相違点	既存記事（12021バージョン）	本文（12024執筆、12026改訂バージョン）
Linuxディストリビューション	Ubuntu基準	Ubuntuに加えてFedora/RHEL/Centos, Debian, openSUSE/SLESなどでも適用可能
開発環境の構築方式	ホストシステムに直接インストール venvを用いたPython仮想環境	NVIDIA Container Toolkitを用いた Dockerコンテナベースの環境 uvによるPython仮想環境およびパッケージ管理
NVIDIAグラフィックドライバのインストール	O	O
ホストシステムに CUDAおよびcuDNNを直接インストール	O（Aptパッケージマネージャ使用）	X（Docker HubでNVIDIAが提供する事前インストールイメージを使うため、直接作業不要）
移植性	別システムへ移行するたびに開発環境を再構築する必要がある	Dockerベースのため、作成済みDockerfileから必要に応じて新規イメージをビルドしたり、既存イメージ（追加ボリュームやネットワーク設定を除く）を容易に移植可能
cuDNN以外の追加 GPU加速ライブラリ活用	X	CuPy、RAPIDS、DALIを導入
Jupyter Notebookインターフェース	Jupyter Notebook（classic）	JupyterLab（Next-Generation）
SSHサーバー設定	扱わない	基本的なSSHサーバー設定構成を含む

0. 事前確認事項

NVIDIA Container ToolkitはApt、YumまたはDnf、ZypperパッケージマネージャをサポートするLinuxディストリビューションで利用できる。リンク先ページで対応ディストリビューション一覧を確認できる。公式サポート表には明記されていないが、FedoraもRHELと同じRed Hat Linux系であるため問題なく利用可能だ。Linuxに不慣れでどのディストリビューションを使うべきか分からないなら、Ubuntu LTS版が無難である。オープンソースではないプロプライエタリドライバも自動インストールされ、初心者でも比較的使いやすい。また利用者が多いため、多くの技術文書がUbuntu基準で書かれている。
- 使用中のシステムアーキテクチャおよびLinuxディストリビューションのバージョンは、ターミナルでuname -m && cat /etc/*releaseで確認できる。
システムに搭載されたグラフィックカードが、使用予定のCUDAおよびcuDNNバージョンをサポートしているモデルかを先に確認する必要がある。
- 現在のGPUモデル名はターミナルでlspci | grep -i nvidiaにより確認できる。
- https://docs.nvidia.com/deeplearning/cudnn/latest/reference/support-matrix.html で、cuDNNバージョンごとの対応NVIDIAグラフィックドライババージョンおよび要求されるCUDA Compute Capability条件、そして対応NVIDIAハードウェア一覧を確認しよう。
- https://developer.nvidia.com/cuda-gpus のGPU一覧から該当モデルを探し、Compute Capabilityの値を確認しよう。この値が先に確認したCUDA Compute Capability条件を満たす必要がある。満たしていればCUDAおよびcuDNNを問題なく利用できる。

ディープラーニング作業用のグラフィックカードを新規購入する予定なら、GPU選定基準は次の記事にうまく整理されている。筆者が不定期に更新している記事である。
Which GPU(s) to Get for Deep Learning
GPUだけでなく全体的なハードウェア構成ガイドが必要なら、同じ方が書いたA Full Hardware Guide to Deep Learningも非常に有益だ。

上で言及したすべての条件を満たしたら、作業環境の構成を開始しよう。

1. NVIDIAグラフィックドライバのインストール

まずNVIDIAグラフィックドライバをホストシステムにインストールする必要がある。NVIDIAドライバダウンロードページから.runインストーラをダウンロードして使ってもよいが、可能であればシステムのパッケージマネージャを用いてインストールするほうが、バージョン管理・保守の観点で望ましい。https://docs.nvidia.com/cuda/cuda-installation-guide-linux/#driver-installation の公式ドキュメントを参照し、システム環境に合ったグラフィックドライバをインストールする。

プロプライエタリモジュール vs オープンソースモジュール

NVIDIAのLinuxドライバはいくつかのカーネルモジュールで構成される。バージョン515ドライバおよびそれ以降のリリースから、NVIDIAは2種類のドライバカーネルモジュールを提供している。

Proprietary：従来NVIDIAが提供してきた独占ソフトウェアドライバ。
Open-source：MIT/GPLv2のデュアルライセンスで提供されるオープンソースドライバ。https://github.com/NVIDIA/open-gpu-kernel-modules でソースコードを公開している。

ProprietaryドライバはMaxwellアーキテクチャからBlackwell以前までのアーキテクチャ向けに提供され、Blackwellアーキテクチャ以降ではサポート終了予定である。
一方、Open-sourceドライバはTuringおよびそれ以降のアーキテクチャでサポートされる。

NVIDIAは可能であればオープンソースのカーネルモジュールを使用することを推奨している。
利用中のGPUがオープンソースドライバと互換性があるかは、このリンクで確認できる。

本記事ではオープンソースドライバをインストールする前提で説明する。

Debian & Ubuntu

UbuntuまたはDebianの場合は、ターミナルで次のコマンドを入力してインストールする。

  
sudo apt update
sudo apt install nvidia-open

Fedora

Fedora 40を基準に、RPM Fusionが提供する事前ビルド済みパッケージをダウンロードしてインストールする方法を紹介する。

1-Fedora-1. RPM Fusionリポジトリの構成

RPM Fusion公式ガイドを参照して進める。
ターミナルで次のコマンドを実行する。

  
sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
sudo dnf config-manager setopt fedora-cisco-openh264.enabled=1

DNF旧バージョン（Fedora 40およびそれ以前）では、2行目のopenh264ライブラリリポジトリを有効化するコマンドは次の形だった。
1 sudo dnf config-manager --enable fedora-cisco-openh264
しかしDNF 5（Fedora 41+）からは上記の代わりに
1 sudo dnf config-manager setopt fedora-cisco-openh264.enabled=1
を入力する必要があるため、それを反映して本文を更新した。

1-Fedora-2. akmod-nvidiaパッケージのインストール

RPM Fusionが提供するNVIDIAドライバインストールガイドを参照し、akmod-nvidiaパッケージをインストールする。

  
sudo dnf update  # この段階でカーネル更新があった場合は、最新カーネルで再起動してから続行する
sudo dnf install akmod-nvidia
sudo dnf mark user akmod-nvidia

同様に、DNF旧バージョン（Fedora 40およびそれ以前）では、3行目のautoremove時にNVIDIAドライバが削除されるのを防ぐコマンドは次の形だった。
1 sudo dnf mark install akmod-nvidia
しかしDNF 5（Fedora 41+）からは上記の代わりに
1 sudo dnf mark user akmod-nvidia
を入力する必要があるため、それを反映して本文を更新した。

一方、過去のRPM FusionはNVIDIAオープンソースカーネルモジュールに対して否定的な立場を示してきて、特に指定しない限りProprietaryドライバをデフォルト提供していた。しかし最近（12025年12月）変更されたRPM Fusion側の指針によれば、重複サポート対象ハードウェア（TuringからBlackwell以前までのアーキテクチャ）については、両者のうちより良いバージョンを自動選択して提供するようになったため、どちらを使うかを手動で選ぶ必要はないとのことだ。Turing以前の旧アーキテクチャや、Blackwellおよびそれ以降の新アーキテクチャについては、もともと選択肢が1つしかないため変更はない。これに伴い、/etc/rpm/macros.nvidia-kmodによるオープンソースカーネルモジュール使用オプション指定に関する内容が削除されたことを確認した。
またakmod-nvidia-openパッケージについては、カーネル空間ドライバにダウンストリーム変更を直接適用する必要がある場合を除き、使用しないようにとのことだ。
これらの点も本文に新たに反映した。

1-Fedora-3. セキュアブート（Secure Boot）時にドライバを正常ロードするための鍵登録

以下で説明する多少の追加手順を踏めば、セキュアブート機能を有効にしたままNVIDIAグラフィックドライバを利用できる。セキュアブートを無効化するとシステムのセキュリティはかなり脆弱になるため、無効化しないことを推奨する。少なくとも12020年代に入って以降、よほどの事情がない限りセキュアブートを無効化する理由はない。

まず次のツールをインストールする。

sudo dnf install kmodtool akmods mokutil openssl

次に、以下のコマンドを実行して鍵を生成する。

sudo kmodgenca -a

続いて、UEFIファームウェアのMOKに生成した鍵を登録する必要がある。

sudo mokutil --import /etc/pki/akmods/certs/public_key.der

上記コマンドを実行すると、鍵登録用パスワードの入力を求められるはずだ。しばらく後に鍵登録手続きを完了するため再起動するが、そのときに使うワンタイムパスワードなので、適度に覚えられるものを入力する。

次のコマンドでシステムを再起動する。

systemctl reboot

起動時に自動でMOK管理画面が表示される。「Enroll MOK」を選択し、「Continue」「Yes」を続けて選ぶと、先ほど設定したパスワードの入力を求める画面が出る。パスワードを入力すれば鍵登録手続きは完了する。あとはrebootを入力して再起動すれば、NVIDIAドライバが正常にロードされる。

NVIDIAドライバのインストール確認

ターミナルで次のコマンドを実行すると、現在ロードされているNVIDIAカーネルモジュールを確認できる。

cat /proc/driver/nvidia/version

以下のような形式のメッセージが出力されれば正常にインストールできている。

  
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64  555.58.02  Release Build  (dvs-builder@U16-I3-B03-4-3)  Tue Jun 25 01:26:03 UTC 2024
GCC version:  gcc version 14.2.1 20240801 (Red Hat 14.2.1-1) (GCC) 

また、Linux界隈で多くの場合にデフォルト採用されているオープンソースのグラフィックドライバであるnouveauカーネルモジュールは、NVIDIAドライバインストール後に無効化されている必要があり、そうでない場合は問題を引き起こすことがある。NVIDIAドライバをインストールして再起動した後は、次のコマンドを実行して何も出力されないことが正常である。

lsmod |grep nouveau

2. NVIDIA Container Toolkitのインストール

次にNVIDIA Container Toolkitをインストールする。NVIDIA Container Toolkit公式インストールガイドを参照して進めればよいが、Fedoraの場合はインストール過程で注意点があるため、このセクションの内容を最後まで確認してから進めてほしい。

Aptを使用する場合（Ubuntu、Debianなど）

2-Apt-1. パッケージダウンロード用リポジトリの構成

  
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
&& curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

2-Apt-2. パッケージリストの更新

sudo apt update

2-Apt-3. パッケージのインストール

sudo apt install nvidia-container-toolkit

YumまたはDnfを使用する場合（Fedora、RHEL、Centosなど）

Fedora 40でテストしたところ、Ubuntuとは異なりnvidia-smiコマンドおよびnvidia-persistencedパッケージがNVIDIAグラフィックドライバに標準では含まれていなかったため、xorg-x11-drv-nvidia-cudaパッケージを追加でインストールする必要があった。RHELおよびCentosでは直接テストしていないが、Fedoraとシステム構成がかなり近いため、以下のガイド通りに進めて問題が出た場合は同様の方法を試すことが助けになるかもしれない。

Fedora 40で上記の方法でxorg-x11-drv-nvidia-cudaをインストールし、サンプルワークロードを実行してテストしたところ、私の環境では正常動作した。もしSELinuxなどの理由で依然として問題が発生する場合は、FedoraのAI-MLグループが提供するFedora専用のnvidia-container-toolkitパッケージおよびガイドが役に立つ可能性がある。

2-Dnf-1. パッケージダウンロード用リポジトリの構成

  
curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo

2-Dnf-2. パッケージのインストール

sudo dnf install nvidia-container-toolkit

または

sudo yum install nvidia-container-toolkit

Zypperを使用する場合（openSUSE、SLES）

2-Zypper-1. パッケージダウンロード用リポジトリの構成

sudo zypper ar https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo

2-Zypper-2. パッケージのインストール

  
sudo zypper --gpg-auto-import-keys install nvidia-container-toolkit

3. コンテナエンジンのインストール

次に、コンテナエンジンとしてDocker CEまたはPodmanをインストールする。利用環境と好みに合わせてどちらかを選んでインストールすればよい。Docker公式ドキュメントとPodman公式ドキュメントを参照する。

以下の表はDockerとPodmanの主要な違いと長所・短所をまとめたものだ。

比較項目	Docker	Podman
アーキテクチャ	クライアント-サーバーモデル、デーモン（daemon）ベース	デーモンレス（daemonless）構造
セキュリティ	基本的にroot権限で動作するデーモンに依存するため潜在的なセキュリティリスクがある（12020年に公開されたバージョン20.10からルートレスモードをサポートするが追加設定が必要）	デーモンに依存しないため、別途指定しない限り基本的にルートレスで動作し、 SELinuxにより保護される
リソース使用量	デーモンベース構造の特性上、バックグラウンドプロセスが常時動作するため、一般により多くのリソースを使用	一般により少ないオーバーヘッド（overhead）
コンテナ起動時間	相対的に遅い	簡素化されたアーキテクチャにより最大50%程度高速に起動
エコシステム・文書化	広範なエコシステムとコミュニティ支援、豊富な関連ドキュメント	相対的に小規模なエコシステムと関連ドキュメント
ネットワーキング	Docker Bridge Networkを使用	CNI（Container Network Interface）プラグインを使用
Kubernetes YAML ネイティブサポート	X（変換が必要）	O

参考資料:

Dockerは歴史が長く、業界で事実上の標準的地位を享受してきたため、広いエコシステムと豊富な関連ドキュメントが存在する点が最大の利点だ。
PodmanはRed Hatにより比較的最近開発され、設計段階からデーモンレス（daemonless）・ルートレス（rootless）を志向する先進的な構造であるため、セキュリティ、システム資源使用量、コンテナ起動時間など多方面で利点を持つ。デーモンに問題が生じて停止すると全コンテナがまとめて落ちるDockerと異なり、各コンテナが完全に独立しているため、特定コンテナの停止が他コンテナに影響しない点もPodmanの強みである。

各自の状況に合わせてツールを選ぶことが何より重要だが、入門者であればPodmanから始めるのが良い選択に思える。Dockerに比べてエコシステム規模は小さいものの、前述の利点により急速に成長して差を縮めており、Dockerfile文法やDockerイメージ、CLI（コマンドラインインターフェース）など多くの点で既存のDockerと互換性がある。既にDockerベースで大規模システムを構築済みで、Podman採用に大きな移行コストがかかる、といった事情がないなら、最初からPodmanを採用するのが合理的だ。

Podman

主要なLinuxディストリビューションの多くで、システム標準リポジトリから提供されるため簡単にインストールできる。

Ubuntuの場合

sudo apt install podman

Fedoraの場合

sudo dnf install podman

openSUSEの場合

sudo zypper install podman

正常に設定されているか確認

ターミナルで次のコマンドを実行してみる。

podman run --rm hello-world

以下のようなメッセージが出力されれば成功だ。

  
!... Hello Podman World ...!

         .--"--.           
       / -     - \         
      / (O)   (O) \        
   ~~~| -=(,Y,)=- |         
    .---. /`  \   |~~      
 ~/  o  o \~~~~.----. ~~   
  | =(X)= |~  / (O (O) \   
   ~~~~~~~  ~| =(Y_)=-  |   
  ~~~~    ~~~|   U      |~~ 

Project:   https://github.com/containers/podman
Website:   https://podman.io
Desktop:   https://podman-desktop.io
Documents: https://docs.podman.io
YouTube:   https://youtube.com/@Podman
X/Twitter: @Podman_io
Mastodon:  @[email protected]

12025-12-18T00:43:00+09:00時点で、podmanバージョン5.7.1、passt 20251215.gb40f5cd-1.fc43.x86_64、fedora 43環境を基準にテストしたところ、上記hello-worldを含め、コンテナ実行またはイメージビルド時に次のエラーが発生した。
1 2 Error: pasta failed with exit code 1: Couldn't set IPv6 route(s) in guest: Operation not supported
現在私はIPv6を使用しておらずIPv4ネットワーク環境にいるにもかかわらず、コンテナネットワーク構成段階でpasta（passtライブラリに含まれる）がIPv6ルーティングを試みることで発生する問題に見える。コンテナ実行や後述のイメージビルド段階で、以下のように--net=pasta:-4オプションを明示してIPv4を使うようにすると問題が発生しないことを確認した。
1 podman run --net=pasta:-4 --rm hello-world
調べてみると、同様の症状で以前に登録されたイシューが存在した。当該イシューは2024_06_24.1ee2ecaで修正されたとあるが、観測された症状が同一である点、Proton VPN使用中に発生した問題である点など、多くの部分が非常によく似ているため、類似のイシューが再発したのではないかと推測している。

Docker CE

Ubuntuの場合

3-Ubuntu-1. パッケージ競合防止のため旧版または非公式パッケージを削除

  
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt remove $pkg; done

3-Ubuntu-2. リポジトリの構成

  
# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

3-Ubuntu-3. パッケージのインストール

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3-Ubuntu-4. `Docker`グループを作成してユーザーを登録

non-rootユーザーでもsudoなしでDockerを管理できるようにするには、Dockerグループを作成し、Dockerを利用するユーザーを登録すればよい。ターミナルで次のコマンドを実行する。

  
sudo groupadd docker
sudo usermod -aG docker $USER

その後、ログアウトして再ログインすれば変更が適用される。UbuntuまたはDebianの場合、特に追加作業をしなくてもシステム起動時にDockerサービスが自動起動する。

Fedoraの場合

3-Fedora-1. パッケージ競合防止のため旧版または非公式パッケージを削除

  
sudo dnf remove docker \
                docker-client \
                docker-client-latest \
                docker-common \
                docker-latest \
                docker-latest-logrotate \
                docker-logrotate \
                docker-selinux \
                docker-engine-selinux \
                docker-engine

3-Fedora-2. リポジトリの構成

  
sudo dnf install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo

3-Fedora-3. パッケージのインストール

sudo dnf install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

パッケージインストール中にGPGキーを承認するかの確認が出るはずだ。GPGキーが060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35と一致するなら、yを入力して承認すればよい。

もしGPGキーが一致しない場合、サプライチェーン攻撃により偽造パッケージをダウンロードした可能性があるため、インストールを中止すべきである。

3-Fedora-4. Dockerデーモンの起動

Dockerのインストールは完了しているが未起動の状態なので、次のコマンドでDockerを起動できる。

sudo systemctl start docker

システム起動時にDockerサービスを自動起動させたい場合は、次を実行する。

  
sudo systemctl enable docker.service
sudo systemctl enable containerd.service

3-Fedora-5. `Docker`グループにユーザーを登録

non-rootユーザーでもDockerを管理できるようにするには、DockerグループにDockerを利用するユーザーを登録する。Fedoraの場合、前述のパッケージインストール時にDockerグループが自動作成されるため、ユーザー登録のみ行えばよい。

  
sudo usermod -aG docker $USER

その後ログアウトして再ログインすれば変更が適用される。

正常に設定されているか確認

ターミナルで次のコマンドを実行してみる。

docker run hello-world

以下のようなメッセージが出力されれば成功だ。

  
Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

概要

開発環境の構成

以前に作成した機械学習開発環境構築ガイドとの比較表

0. 事前確認事項

1. NVIDIAグラフィックドライバのインストール

プロプライエタリモジュール vs オープンソースモジュール

Debian & Ubuntu

Fedora

1-Fedora-1. RPM Fusionリポジトリの構成

1-Fedora-2. akmod-nvidiaパッケージのインストール

1-Fedora-3. セキュアブート（Secure Boot）時にドライバを正常ロードするための鍵登録

NVIDIAドライバのインストール確認

2. NVIDIA Container Toolkitのインストール

Aptを使用する場合（Ubuntu、Debianなど）

2-Apt-1. パッケージダウンロード用リポジトリの構成

2-Apt-2. パッケージリストの更新

2-Apt-3. パッケージのインストール

YumまたはDnfを使用する場合（Fedora、RHEL、Centosなど）

2-Dnf-1. パッケージダウンロード用リポジトリの構成

2-Dnf-2. パッケージのインストール

Zypperを使用する場合（openSUSE、SLES）

2-Zypper-1. パッケージダウンロード用リポジトリの構成

2-Zypper-2. パッケージのインストール

3. コンテナエンジンのインストール

Podman

Ubuntuの場合

Fedoraの場合

openSUSEの場合

正常に設定されているか確認

Docker CE

Ubuntuの場合

3-Ubuntu-1. パッケージ競合防止のため旧版または非公式パッケージを削除

3-Ubuntu-2. リポジトリの構成

3-Ubuntu-3. パッケージのインストール

3-Ubuntu-4. Dockerグループを作成してユーザーを登録

Fedoraの場合

3-Fedora-1. パッケージ競合防止のため旧版または非公式パッケージを削除

3-Fedora-2. リポジトリの構成

3-Fedora-3. パッケージのインストール

3-Fedora-4. Dockerデーモンの起動

3-Fedora-5. Dockerグループにユーザーを登録

正常に設定されているか確認

Further Reading

トレンドのタグ

3-Ubuntu-4. `Docker`グループを作成してユーザーを登録

3-Fedora-5. `Docker`グループにユーザーを登録