はじめに
巷では docker コマンドの使い方であったり、コンテナ基盤上での開発の記事はよく見かけますが、「そもそもコンテナって何？」というところを説明した記事はあまり見かけないような気がしたので、そちらをメインに書いてみました。皆様の学習の一助になれば幸いです。
コンテナは「ただのプロセス」
コンテナについてなんとなく難しそうと感じでいる方も多いかもしれませんが、コンテナはホストOS上で動くただのプロセスにすぎないので、そこまで身構える必要はありません。
通常のプロセスとの最大の違いは 「ホストとは異なる実行環境を持つプロセス」 であるということ。
では、ホストとは異なる実行環境を持つプロセスとはどういうことなのか、実際に検証環境を作成してみていこうと思います。
検証環境
OS : CentOS9
ISO は こちら から入手、CPU/MEM/Disk サイズ等はテキトーに決めて、ブラウザを使いたかったのでGUIインストールで仮想マシンを作成しました。
検証環境からはインターネットに出られるようにしてあります。
そもそも「プロセス」とは？
プロセスとは「実行中のプログラム」のことです。 作成した検証環境で確認すると、ただCentOSをインストールしただけで裏でたくさんのプロセスが動いていることがわかります。
[root@localhost ~]# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 11:02 ? 00:00:00 /usr/lib/systemd/systemd --switched-root --system --deserialize 31 rhgb
root 2 0 0 11:02 ? 00:00:00 [kthreadd]
root 3 2 0 11:02 ? 00:00:00 [pool_workqueue_]
root 4 2 0 11:02 ? 00:00:00 [kworker/R-rcu_gp]
root 5 2 0 11:02 ? 00:00:00 [kworker/R-sync_wq]
＜以下略＞
TeraTerm で SSH 接続してみると、sshd のプロセスの子プロセス（正確には子の子の子）としてログインシェル（bash）が実行されていて、ログインシェルの子プロセスとして実行したコマンド（ps と grep）のプロセスが実行されていることがわかります。
[root@localhost ~]# ps -ef --forest | grep sshd -A 2
root 1039 1 0 11:57 ? 00:00:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root 1242 1039 0 11:57 ? 00:00:00 \_ sshd-session: root [priv]
root 1278 1242 0 11:57 ? 00:00:00 \_ sshd-session: root@pts/0
root 1279 1278 0 11:57 pts/0 00:00:00 \_ -bash
root 4941 1279 0 15:03 pts/0 00:00:00 \_ ps -ef --forest
root 4942 1279 0 15:03 pts/0 00:00:00 \_ grep --color=auto sshd -A 2
コンテナ実行環境の作成
今回はコンテナ実行環境として Podman を使用するので、Podman をインストールします。
※ Podman のほうが Kubernetes や OpenShift との相性がいいため Podman を使用していますが、Docker に慣れている方は Docker に読み替えていただいてもかまいません。
[root@localhost ~]# dnf update -y
CentOS Stream 9 - BaseOS 3.3 MB/s | 9.0 MB 00:02
CentOS Stream 9 - AppStream 5.4 MB/s | 29 MB 00:05
CentOS Stream 9 - Extras packages 39 kB/s | 22 kB 00:00
依存関係が解決しました。
行うべきことはありません。
完了しました!
[root@localhost ~]# dnf install -y podman
メタデータの期限切れの最終確認: 0:00:30 前の 2026年08月20日 11時23分09秒 に実施しました。
パッケージ podman-6:5.8.5-1.el9.x86_64 は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!
最初からインストールされてた。。
実際にコンテナを動かしてみよう
準備が整ったところで早速コンテナを実行していきますが、冒頭に述べたようにコンテナはただのプロセスです。通常のプロセスとコンテナプロセスを比較した方がわかりやすいと思うので、nginx を「通常のプロセスで上げた場合」と「コンテナプロセスで上げた場合」を見ていこうと思います。
まずは通常のプロセスで nginx を動かす
nginx のパッケージをインストールしサービスを起動させると、PID 1708 で nginx のプロセスが起動していることがわかります。
[root@localhost ~]# dnf install -y nginx
＜中略＞
インストール済み:
centos-logos-httpd-90.9-1.el9.noarch nginx-2:1.20.1-31.el9.x86_64 nginx-core-2:1.20.1-31.el9.x86_64 nginx-filesystem-2:1.20.1-31.el9.noarch
完了しました!
[root@localhost ~]#
[root@localhost ~]# systemctl status nginx.service
○ nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; preset: disabled)
Active: inactive (dead)
[root@localhost ~]#
[root@localhost ~]# systemctl start nginx.service
[root@localhost ~]#
[root@localhost ~]# systemctl status nginx.service
● nginx.service - The nginx HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; preset: disabled)
Active: active (running) since Thu 2026-08-20 11:58:06 JST; 33min ago
Process: 1705 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Process: 1706 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Process: 1707 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Main PID: 1708 (nginx)
Tasks: 5 (limit: 101903)
Memory: 6.4M (peak: 6.9M)
CPU: 20ms
CGroup: /system.slice/nginx.service
tq1708 "nginx: master process /usr/sbin/nginx"
tq1709 "nginx: worker process"
tq1710 "nginx: worker process"
tq1711 "nginx: worker process"
mq1712 "nginx: worker process"
ps コマンドで確認してみるとこんな感じ。（1708 を親にして 1709~1712 の子プロセスが動いていることが確認できます。）
[root@localhost ~]# ps -ef --forest | grep -E "PID|1708" | grep -v grep
UID PID PPID C STIME TTY TIME CMD
root 1708 1 0 11:58 ? 00:00:00 nginx: master process /usr/sbin/nginx
nginx 1709 1708 0 11:58 ? 00:00:00 \_ nginx: worker process
nginx 1710 1708 0 11:58 ? 00:00:00 \_ nginx: worker process
nginx 1711 1708 0 11:58 ? 00:00:00 \_ nginx: worker process
nginx 1712 1708 0 11:58 ? 00:00:00 \_ nginx: worker process
リッスンポートを確認するとホストの80番ポートで受け付けていることがわかるので、テキトーなファイルを作ってアクセスしてみます。
[root@localhost ~]# ss -nltp | grep nginx
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1712,fd=6),("nginx",pid=1711,fd=6),("nginx",pid=1710,fd=6),("nginx",pid=1709,fd=6),("nginx",pid=1708,fd=6))
LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=1712,fd=7),("nginx",pid=1711,fd=7),("nginx",pid=1710,fd=7),("nginx",pid=1709,fd=7),("nginx",pid=1708,fd=7))
[root@localhost ~]# cat << EOF > /usr/share/nginx/html/hello.html
> This is Normal Process
> EOF
[root@localhost ~]#
[root@localhost ~]# cat /usr/share/nginx/html/hello.html
This is Normal Process
[root@localhost ~]#
[root@localhost ~]# curl http://localhost/hello.html
This is Normal Process
「This is Normal Process」 が返ってきますね。一応、ブラウザからも確認してみます。
次にコンテナプロセスで nginx を動かす
通常のプロセスで nginx を動かせたところで次はコンテナプロセスで動かしてみます。ホストにインストールした nginx のバージョンが 1.20.1 だったので、せっかくなので違うバージョンの nginx をコンテナで動かしてみましょう。
[root@localhost ~]# nginx -v
nginx version: nginx/1.20.1
コンテナを起動する際はコンテナイメージを指定します。コンテナイメージとは、コンテナを起動するために必要なファイル一式をまとめたテンプレートであり、コンテナイメージを実行することでコンテナが起動します。インターネット上にどんなコンテナイメージが公開されているかは podman search コマンドで調べることができます。
[root@localhost ~]# podman search nginx
NAME DESCRIPTION
registry.redhat.io/rhel8/nginx-114 Platform for running nginx 1.14 or building...
registry.redhat.io/rhel8/nginx-118 Platform for running nginx 1.18 or building...
registry.redhat.io/rhel8/nginx-120 Platform for running nginx 1.20 or building...
registry.redhat.io/ubi8/nginx-120 Platform for running nginx 1.20 or building...
registry.redhat.io/ubi9/nginx-120 Platform for running nginx 1.20 or building...
＜中略＞
docker.io/library/nginx Official build of Nginx.
docker.io/nginx/nginx-ingress NGINX and NGINX Plus Ingress Controllers fo...
docker.io/nginx/nginx-prometheus-exporter NGINX Prometheus Exporter for NGINX and NGIN...
docker.io/nginx/nginx-ingress-operator NGINX Ingress Operator for NGINX and NGINX P...
docker.io/nginx/nginxaas-loadbalancer-kubernetes
＜以下略＞
ずらっとたくさんのイメージがあることが確認できますが今回は、docker が公式に提供している docker.io/library/nginx を使います。
docker.io から始まるイメージは dockerhub で公開されているコンテナイメージであり、ブラウザからも調べることができます。
https://hub.docker.com/
nginx で検索すると、上記の podman search で表示されたイメージがブラウザからも確認できることがわかります。
では、nginx のコンテナを起動してみましょう。
[root@localhost ~]# podman run -d docker.io/library/nginx
Trying to pull docker.io/library/nginx:latest... #latest のタグが補完されて、インターネット上からダウンロードしてきている
Getting image source signatures
Copying blob 128fcc7b23b0 done |
Copying blob 746b934a8960 done |
Copying blob 5d480233f531 done |
Copying blob 26c307b5e35a done |
Copying blob 5508f6432d3e done |
Copying blob f530c3e421fc done |
Copying blob 7eb55399d6de done |
Copying config f075e3f949 done |
Writing manifest to image destination
ac22be2830ef0b6db5d14dc077eb45fdf5900f75a8e6e4c54124e664b74086ce
上記のコマンドは「docker.io/library/nginx のコンテナイメージを実行してください」という意味になります。
※ -d はプロセスをバックグラウンドで実行するためのオプションで、これをつけないとターミナルが奪われてしまうのでつけています。
docker.io/library/nginx と特にタグを指定しないと自動で latest のタグが補完されます。
（なんなら docker.io/library/ も補完してくれるので、nginx と指定するだけで docker.io/library/nginx:latest のイメージを pull してきます。）
docker.io/library/nginx:1.20.1 のように特定のタグを指定することももちろん可能で、イメージにどんなタグが付いているかは dockerhub から確認できます。実行するコンテナイメージがホスト上に存在しなければインターネットから pull してくる動きをします。
上記の出力からも「Trying to pull docker.io/library/nginx:latest」とインターネットから pull してきていることが見て取れます。
ホスト上に存在するコンテナイメージは podman images で確認でき、先ほど podman run したときに pull してきた nginx:latest のイメージが存在することが確認できます。
[root@localhost ~]# podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/nginx latest f075e3f94986 9 hours ago 165 MB
podman ps でホスト上のコンテナの一覧を確認でき、正常に起動していると STATUS が Up になります。※ -a は停止しているコンテナを含めたすべてを表示させるオプション
[root@localhost ~]# podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ac22be2830ef docker.io/library/nginx:latest nginx -g daemon o... 9 seconds ago Up 8 seconds 80/tcp festive_rhodes
ホストからコンテナプロセスを見てみる
ではここで実行したコンテナプロセスはホストからはどう見えるのでしょうか？podman inspect <コンテナID> で実行中のコンテナの詳細を見ることができ、ホストから見たときに PID 4242 で実行されていることがわかります。
[root@localhost ~]# podman inspect ac22be2830ef | jq '.[0].State'
{
"OciVersion": "1.2.1",
"Status": "running",
"Running": true,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 4242, #ホストから見たときに、PID 4242 で実行されている。
"ConmonPid": 4240,
"ExitCode": 0,
"Error": "",
"StartedAt": "2026-08-20T13:15:13.866579524+09:00",
"FinishedAt": "0001-01-01T00:00:00Z",
"CgroupPath": "/machine.slice/libpod-ac22be2830ef0b6db5d14dc077eb45fdf5900f75a8e6e4c54124e664b74086ce.scope",
"CheckpointedAt": "0001-01-01T00:00:00Z",
"RestoredAt": "0001-01-01T00:00:00Z"
}
ps コマンドでも確認してみましょう。通常のプロセスで nginx を実行したときと同じように、ホスト上で nginx のプロセスが起動していることがわかります。（4242 を親にして 4266~4269 の子プロセスが動いていることが確認できます。）
[root@localhost ~]# ps -ef --forest | grep -E "PID|4242" | grep -v grep
UID PID PPID C STIME TTY TIME CMD
root 4242 4240 0 13:15 ? 00:00:00 \_ nginx: master process nginx -g daemon off;
101 4266 4242 0 13:15 ? 00:00:00 \_ nginx: worker process
101 4267 4242 0 13:15 ? 00:00:00 \_ nginx: worker process
101 4268 4242 0 13:15 ? 00:00:00 \_ nginx: worker process
101 4269 4242 0 13:15 ? 00:00:00 \_ nginx: worker process
これが「コンテナはただのプロセス」とずっと言ってきた意味になります。
「ホストとは異なる実行環境を持つプロセス」の意味
では、「ホストとは異なる実行環境を持つ」とはどういう意味なのでしょうか？
コンテナの中に入って確認してみましょう。
ホストに対しターミナル接続するのと同じように、コンテナに対しても podman exec -it <コンテナID> bash でコンテナ内で bash を起動しターミナル接続することができます。
[root@localhost ~]# podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ac22be2830ef docker.io/library/nginx:latest nginx -g daemon o... 2 hours ago Up 2 hours 80/tcp festive_rhodes
[root@localhost ~]#
[root@localhost ~]# podman exec -it ac22be2830ef bash
root@ac22be2830ef:/#
実行環境の違い① ルートファイルシステム
コンテナ内で nginx のバージョンを確認すると 1.31.4 でした。
上記でホストの nginx のバージョンを確認したときは 1.20.1 だったので、ホストとは異なるバージョンの nginx が動いていることがわかります。
root@ac22be2830ef:/# nginx -v
nginx version: nginx/1.31.4
コンテナに入れたところで ps コマンドを打とうと思ったら、ps コマンドがなかったのでインストールします。
[root@localhost ~]# podman exec -it ac22be2830ef bash
root@ac22be2830ef:/# ps
bash: ps: command not found
root@ac22be2830ef:/#
root@ac22be2830ef:/# apt update
＜中略＞
9 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@ac22be2830ef:/#
root@ac22be2830ef:/#
root@ac22be2830ef:/# apt install -y procps
Installing:
procps
Installing dependencies:
libgpm2 libncursesw6 libproc2-0 linux-sysctl-defaults psmisc
＜以下略＞
ホスト上では普通に使えていた ps コマンドがコンテナ内からは見えない、ということからもホストとは異なる実行環境で動いているプロセスであることが実感できると思います。
また、ホストOSはRedHat系のCentOSですが、nginx のコンテナイメージのベースがDebian系なのでパッケージをインストールする際のコマンドも dnf ではなく apt になっています。
これらは、ホストとコンテナではルートファイルシステムが異なるために起こっている現象です。どういうことかというと、ホストが認識している / とコンテナが認識している / が異なる 、ということです。
podman inspect で表示される {{.GraphDriver.Data.MergedDir}}
のディレクトリがコンテナ内から見たときの / となっています。
※正確には MergedDir がコンテナ内の / のベースになっていますが、そのままコンテナの / のわけではありません。
コンテナ実行時にマウントのオプションを指定した場合や、/etc/resolv.conf, /etc/hosts, /etc/hostname 等の一部の設定ファイル、/proc, /dev, /sys といった特殊なファイルシステムについてはコンテナ起動時に別の場所からマウントされて上書きされます。
[root@localhost ~]# podman inspect ac22be2830ef | jq '.[0].GraphDriver.Data'
{
"LowerDir": "/var/lib/containers/storage/overlay/b9416de9266e0d4798358d4c1bd61b61aa56bf362ce3107ac519738e9de4d594/diff:/var/lib/containers/storage/overlay/3eef69ef5bc2e7e06401d3854a7ea92f81b241ac7158c5553a997212e00aee07/diff:/var/lib/containers/storage/overlay/fb4f9ad370bb3a656edabaab74c03ac0842fb60f4d7f2454ee9d3eac7366a6ad/diff:/var/lib/containers/storage/overlay/573d63347e27f04e35e127e8e06a5721a186215898796ae684aba86325a60d61/diff:/var/lib/containers/storage/overlay/88e3a90b3584a6e8413237037168ff0a1035f1896d3383bc5dc6f221c169ea1f/diff:/var/lib/containers/storage/overlay/5881f3656e1d942c4baf670d3ff54f81a210a1837660bfcf9b2aa1730cca363e/diff:/var/lib/containers/storage/overlay/6f94328331290cbd81edab450664d42da7b64c191416c9346cd5d28c84f76035/diff",
"MergedDir": "/var/lib/containers/storage/overlay/225c6b5c3bdee02c3b8f5c9e56e9f4d21f16a2f3f75f82af2c6c5dccb024b5b2/merged", #ここがコンテナにとっての / のベースになる
"UpperDir": "/var/lib/containers/storage/overlay/225c6b5c3bdee02c3b8f5c9e56e9f4d21f16a2f3f75f82af2c6c5dccb024b5b2/diff",
"WorkDir": "/var/lib/containers/storage/overlay/225c6b5c3bdee02c3b8f5c9e56e9f4d21f16a2f3f75f82af2c6c5dccb024b5b2/work"
}
なので、通常のプロセスで nginx を動かしたときにホスト上に作成した
/usr/share/nginx/html/hello.html は当然コンテナ内からは確認できません。
逆にコンテナ内で /usr/share/nginx/html/hello.html を作成すると、ホスト上の
＜MergedDirのパス＞/usr/share/nginx/html/hello.html
にファイルが作成されていることがわかります。
root@ac22be2830ef:/# ls -l /usr/share/nginx/html/hello.html
ls: cannot access '/usr/share/nginx/html/hello.html': No such file or directory
root@ac22be2830ef:/#
root@ac22be2830ef:/# cat << EOF > /usr/share/nginx/html/hello.html
> This is Container Process
> EOF
root@ac22be2830ef:/#
root@ac22be2830ef:/# cat /usr/share/nginx/html/hello.html
This is Container Process
root@ac22be2830ef:/#
root@ac22be2830ef:/# exit # 一度コンテナから出てホストに戻る
exit
[root@localhost ~]# #ホストからコンテナ内で作った/usr/share/nginx/html/hello.htmlを確認
[root@localhost ~]# ls -l /var/lib/containers/storage/overlay/225c6b5c3bdee02c3b8f5c9e56e9f4d21f16a2f3f75f82af2c6c5dccb024b5b2/merged/usr/share/nginx/html/hello.html
-rw-r--r-- 1 root root 26 8月 20 18:00 /var/lib/containers/storage/overlay/225c6b5c3bdee02c3b8f5c9e56e9f4d21f16a2f3f75f82af2c6c5dccb024b5b2/merged/usr/share/nginx/html/hello.html
[root@localhost ~]#
[root@localhost ~]# cat /var/lib/containers/storage/overlay/225c6b5c3bdee02c3b8f5c9e56e9f4d21f16a2f3f75f82af2c6c5dccb024b5b2/merged/usr/share/nginx/html/hello.html
This is Container Process
[root@localhost ~]#
これは linux カーネルの overlay filesystem という機能によって実現されていますが、そこまで説明しだすと収拾がつかなくなるのでここでは割愛します。気になる人は調べてみてください。
実行環境の違い② PID
ps コマンドがインストールできたところでコンテナ内で ps コマンドを打ってみましょう。
root@ac22be2830ef:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 04:15 ? 00:00:00 nginx: master process nginx -g daemon off;
nginx 24 1 0 04:15 ? 00:00:00 nginx: worker process
nginx 25 1 0 04:15 ? 00:00:00 nginx: worker process
nginx 26 1 0 04:15 ? 00:00:00 nginx: worker process
nginx 27 1 0 04:15 ? 00:00:00 nginx: worker process
root 30 0 0 06:33 pts/0 00:00:00 bash
root 157 30 0 06:48 pts/0 00:00:00 ps -ef
nginx のプロセス、exec したときに実行した bash 、実行した ps コマンドのプロセスしか確認できないですね。
このようにホストからはコンテナプロセスが見える一方で、コンテナ内からはコンテナ内のプロセスしか見えずホスト側を見ることができないようになっている、というのがコンテナがコンテナたる所以となっています。
※あくまで通常のコンテナでは見れないというだけなので、見えるようにすることもできます（通常はしませんが）
また、先ほどホストから確認したときに nginx のメインプロセスの PID が 4242 だったのに対し、コンテナ内から確認すると PID 1 として実行されていることがわかります。
実行環境の違い③ ネットワーク
ルートファイルシステムとPIDの観点でコンテナプロセスがホストとは異なる実行環境を持っていることを見てきましたが、ネットワークもホストとコンテナでは異なります。確認してみましょう。
podman inspect でコンテナの詳細を見てみると、ホストのネットワークとは全く異なるネットワークのIPアドレスが付与されていることがわかります。
このようにホストとコンテナで別のIPアドレスを使用しているため、同じ80番ポートで待ち受けていても、通常のプロセスで起動した nginx と競合せずに共存できるわけです。
[root@localhost ~]# podman inspect ac22be2830ef | jq '.[0].NetworkSettings'
{
"EndpointID": "",
"Gateway": "10.xx.xx.xx",
"IPAddress": "10.xx.xx.xx", #コンテナプロセスのIP
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "xx:xx:xx:xx:xx:xx",
"Bridge": "",
"SandboxID": "",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": {
"80/tcp": null
},
＜以下略＞
ホスト側でネットワークを確認してみると、podman0 という仮想ブリッジが作成されており、podman0 を通って 10.xx.0.0/16 のコンテナネットワークに接続されていることがわかります。
[root@localhost ~]# nmcli con show
NAME UUID TYPE DEVICE
ens192 11da2940-eed6-3e7b-a55d-0e81dbb1215d ethernet ens192
lo 82ac4f0b-cca9-41a8-a364-92fca1a42c76 loopback lo
podman0 894439e7-8c57-4c1e-a9bb-589e6f109763 bridge podman0
[root@localhost ~]#
[root@localhost ~]# ip route
10.xx.0.0/16 dev podman0 proto kernel scope link src 10.xx.xx.xx
192.xx.xx.0/24 dev ens192 proto kernel scope link src 192.xx.xx.xx metric 100
では実際にコンテナのIPを指定して接続してみましょう。先ほどコンテナ内に作成した hello.html にアクセスしてみます。
[root@localhost ~]# curl http://10.xx.xx.xx/hello.html
This is Container Process
「This is Container Process」 が返ってきますね。コンテナ内に入って localhost 向けに通信することも可能です。
[root@localhost ~]# podman exec -it ac22be2830ef bash
root@ac22be2830ef:/#
root@ac22be2830ef:/# curl http://localhost/hello.html
This is Container Process
root@ac22be2830ef:/#
ホスト側から localhost 向けに投げると当然 「This is Normal Process」が返ってきます。
[root@localhost ~]# curl http://localhost/hello.html
This is Normal Process
しかし、10.xx.0.0/16 のコンテナネットワークはあくまでこのホスト上に存在する内部の仮想ネットワークにすぎないので、ホスト以外の外部から nginx コンテナにアクセスすることが通常できません。
そこで外からコンテナに対してアクセスできるようにするために、ホストとポートバインドを行います。
なのですが。。ポートバインドは podman run の時に指定してあげないと後から設定できませんでした。。
書きたいこと書いていたら思いのほか長くなってしまったため、この先は 次回の記事 に回そうかと思います。ここまででもだいぶコンテナの概要は掴めたのではないでしょうか。
この記事が皆さんの学習の一助になれば幸いです。