Podman 是 Docker 的直接替代品吗？

在许多地方，你可以读到Podman是Docker的替代品。但是，真的像听起来那么简单吗？在这篇文章中，你将从一个可以立即投入生产使用的Dockerfile开始，并执行Podman命令，就像你使用Docker时会做的那样。让我们看看这是否可以无任何问题地工作！

引言

Podman是一个容器引擎，就像Docker一样。然而，Podman是一个无守护进程的容器引擎，它默认运行的是无根容器（rootless containers）。这比作为根用户运行容器更安全。现在，Docker守护进程也可以作为非根用户运行。

Podman在其网站上宣传，Podman是Docker的替代品。只需添加alias docker=podman ，你就会没问题。让我们看看是否就那么简单。

在本文的余下部分，你将尝试构建一个用于运行Spring Boot应用程序的生产就绪的Dockerfile。你将把它作为一个单独的容器来运行，并且你将尝试运行两个容器并进行一些容器间的通信。最后，你将验证如何挂载卷。本文的一个先决条件是使用Linux操作系统。Podman不适用于Windows。本文使用的源代码可以在GitHub上找到。

你将使用的Dockerfile运行一个Spring Boot应用程序。这是一个基础的Spring Boot应用程序，包含一个返回欢迎消息的控制器。

构建jar文件：

$ mvn clean verify

运行jar文件：

$ java -jar target/mypodmanplanet-0.0.1-SNAPSHOT.jar

检查端点：

$ curl http://localhost:8080/hello
Hello Podman!

文件1-Dockerfile-starter可以在Dockerfiles目录中找到。

FROM eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f AS builder
WORKDIR application
ARG JAR_FILE
COPY target/${JAR_FILE} app.jar
RUN java -Djarmode=layertools -jar app.jar extract

FROM eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f
WORKDIR /opt/app
RUN addgroup --system javauser && adduser -S -s /usr/sbin/nologin -G javauser javauser
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
RUN chown -R javauser:javauser .
USER javauser

ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

先决条件

本文的先决条件是：

• 基本的Linux知识，本篇文章中使用的是Ubuntu 22.04；
• 基本的Java和Spring Boot知识；
• 基本的Docker知识。

安装

安装Podman非常简单。只需运行以下命令。

$ sudo apt-get install podman

验证正确的安装。

$ podman --version
podman version 3.4.4

你还可以安装podman-docker，当你在命令中使用docker时，它会创建一个别名。建议等到本篇文章的结论部分再安装这个。

构建Dockerfile

首先要做的是构建容器镜像。从仓库的根目录执行以下命令。

$ podman build . --tag mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT -f Dockerfiles/1-Dockerfile-starter --build-arg JAR_FILE=mypodmanplanet-0.0.1-SNAPSHOT.jar
[1/2] STEP 1/5: FROM eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f AS builder
[2/2] STEP 1/10: FROM eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f
Error: error creating build container: short-name "eclipse-temurin@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

这会在检索基础镜像时返回一个错误。错误信息引用了/etc/containers/registries.conf。这个文件中写明了以下内容。

# For more information on this configuration file, see containers-registries.conf(5).
#
# NOTE: RISK OF USING UNQUALIFIED IMAGE NAMES
# We recommend always using fully qualified image names including the registry
# server (full dns name), namespace, image name, and tag
# (e.g., registry.redhat.io/ubi8/ubi:latest). Pulling by digest (i.e.,
# quay.io/repository/name@digest) further eliminates the ambiguity of tags.
# When using short names, there is always an inherent risk that the image being
# pulled could be spoofed. For example, a user wants to pull an image named
# `foobar` from a registry and expects it to come from myregistry.com. If
# myregistry.com is not first in the search list, an attacker could place a
# different `foobar` image at a registry earlier in the search list. The user
# would accidentally pull and run the attacker's image and code rather than the
# intended content. We recommend only adding registries which are completely
# trusted (i.e., registries which don't allow unknown or anonymous users to
# create accounts with arbitrary names). This will prevent an image from being
# spoofed, squatted or otherwise made insecure.  If it is necessary to use one
# of these registries, it should be added at the end of the list.

总的来说，建议使用全限定的镜像名称。这意味着你需要将含有以下内容的行：

eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f

更改为：

docker.io/eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f

你只需要在镜像名称前添加docker.io/。这是一个微小的改变，但已经是与Docker的一处不同了。

镜像名称在文件2-Dockerfile-fix-shortname中已经被修正，所以我们再试一次构建镜像。

$ podman build . --tag mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT -f Dockerfiles/2-Dockerfile-fix-shortname --build-arg JAR_FILE=mypodmanplanet-0.0.1-SNAPSHOT.jar
[1/2] STEP 1/5: FROM docker.io/eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f AS builder
Trying to pull docker.io/library/eclipse-temurin@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f...
Getting image source signatures
Copying blob 72ac8a0a29d6 done 
Copying blob f56be85fc22e done 
Copying blob f8ed194273be done 
Copying blob e5daea9ee890 done 
[2/2] STEP 1/10: FROM docker.io/eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f
Error: error creating build container: writing blob: adding layer with blob "sha256:f56be85fc22e46face30e2c3de3f7fe7c15f8fd7c4e5add29d7f64b87abdaa09": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/shadow): Check /etc/subuid and /etc/subgid: lchown /etc/shadow: invalid argument

现在有一个关于用户命名空间中可能的UID或GID不足的错误。你可以在这里找到更多关于此错误的信息。这篇文章非常详细地解释了这个问题，重复所有内容太过繁琐。总的来说，试图拉取的镜像，其文件所属的UID超过了65,536。由于这个问题，镜像无法适应无根Podman的默认UID映射，后者限制了可用的UID和GID数量。

那么，如何解决这个问题呢？

首先，检查/etc/subuid 和 /etc/subgid 的内容。在我的情况下，输出如下。对于你来说，可能会有所不同。

$ cat /etc/subuid
admin:100000:65536
$ cat /etc/subgid
admin:100000:65536

输出中列出的admin用户有100,000作为第一个可用的UID或GID，并且大小为65,536。格式为user:start:size。这意味着admin用户可以访问从100,000到包括165,535在内的UID或GID。

我的当前用户在这里没有列出，这意味着我的用户只能为容器分配1个UID和1个GID。这1个UID/GID已经被容器中的root用户使用了。如果一个容器镜像需要一个额外的用户，就会出现问题，如你在上面所看到的。

这个问题可以通过为你的用户添加UID和GID来解决。让我们给你的用户添加从200,000到包括265,535的值。

$ sudo usermod --add-subuids 200000-265535 --add-subgids 200000-265535 

再次验证两个文件的内容。用户已添加到两个文件中。

$ cat /etc/subgid
admin:100000:65536
:200000:65536
$ cat /etc/subuid
admin:100000:65536
:200000:65536

其次，你需要运行以下命令。

$ podman system migrate

再次尝试构建镜像，现在它可以工作了。

$ podman build . --tag mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT -f Dockerfiles/2-Dockerfile-fix-shortname --build-arg JAR_FILE=mypodmanplanet-0.0.1-SNAPSHOT.jar
[1/2] STEP 1/5: FROM docker.io/eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f AS builder
Trying to pull docker.io/library/eclipse-temurin@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f...
Getting image source signatures
Copying blob f56be85fc22e done 
Copying blob f8ed194273be done 
Copying blob 72ac8a0a29d6 done 
Copying blob e5daea9ee890 done 
Copying config c74d412c3d done 
Writing manifest to image destination
Storing signatures
[1/2] STEP 2/5: WORKDIR application
--> d4f0e970dc1
[1/2] STEP 3/5: ARG JAR_FILE
--> ca97dcd6f2a
[1/2] STEP 4/5: COPY target/${JAR_FILE} app.jar
--> 58d88cfa511
[1/2] STEP 5/5: RUN java -Djarmode=layertools -jar app.jar extract
--> 348cae813a4
[2/2] STEP 1/10: FROM docker.io/eclipse-temurin:17.0.6_10-jre-alpine@sha256:c26a727c4883eb73d32351be8bacb3e70f390c2c94f078dc493495ed93c60c2f
[2/2] STEP 2/10: WORKDIR /opt/app
--> 4118cdf90b5
[2/2] STEP 3/10: RUN addgroup --system javauser && adduser -S -s /usr/sbin/nologin -G javauser javauser
--> cd11f346381
[2/2] STEP 4/10: COPY --from=builder application/dependencies/ ./
--> 829bffcb6c7
[2/2] STEP 5/10: COPY --from=builder application/spring-boot-loader/ ./
--> 2a93f97d424
[2/2] STEP 6/10: COPY --from=builder application/snapshot-dependencies/ ./
--> 3e292cb0456
[2/2] STEP 7/10: COPY --from=builder application/application/ ./
--> 5dd231c5b51
[2/2] STEP 8/10: RUN chown -R javauser:javauser .
--> 4d736e8c3bb
[2/2] STEP 9/10: USER javauser
--> d7a96ca6f36
[2/2] STEP 10/10: ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
[2/2] COMMIT mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT
--> 567fd123071
Successfully tagged localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT
567fd1230713f151950de7151da82a19d34f80af0384916b13bf49ed72fd2fa1

像你使用Docker一样，用Podman验证镜像列表：

$ podman images
REPOSITORY                                  TAG             IMAGE ID      CREATED        SIZE
localhost/mydeveloperplanet/mypodmanplanet  0.0.1-SNAPSHOT  567fd1230713  2 minutes ago  209 MB

Podman是否可以直接替换Docker来构建Dockerfile？

不，它不是一个直接的替代品，因为你需要在Dockerfile中为基础镜像使用全限定的镜像名称，并且你需要更改用户名称空间以便能够拉取镜像。除了这两个更改之外，构建容器镜像就正常工作了。

启动容器

现在你已经构建了镜像，是时候启动一个容器了。

$ podman run --name mypodmanplanet -d localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT

容器已成功启动。

$ podman ps
CONTAINER ID  IMAGE                                                      COMMAND     CREATED         STATUS             PORTS       NAMES
27639dabb573  localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT              18 seconds ago  Up 18 seconds ago              mypodmanplanet

你也可以查看容器日志。

$ podman logs mypodmanplanet

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v3.0.5)

2023-04-22T14:38:05.896Z  INFO 1 --- [           main] c.m.m.MyPodmanPlanetApplication          : Starting MyPodmanPlanetApplication v0.0.1-SNAPSHOT using Java 17.0.6 with PID 1 (/opt/app/BOOT-INF/classes started by javauser in /opt/app)
2023-04-22T14:38:05.898Z  INFO 1 --- [           main] c.m.m.MyPodmanPlanetApplication          : No active profile set, falling back to 1 default profile: "default"
2023-04-22T14:38:06.803Z  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2023-04-22T14:38:06.815Z  INFO 1 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2023-04-22T14:38:06.816Z  INFO 1 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.7]
2023-04-22T14:38:06.907Z  INFO 1 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext
2023-04-22T14:38:06.910Z  INFO 1 --- [           main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 968 ms
2023-04-22T14:38:07.279Z  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2023-04-22T14:38:07.293Z  INFO 1 --- [           main] c.m.m.MyPodmanPlanetApplication          : Started MyPodmanPlanetApplication in 1.689 seconds (process running for 1.911)

验证端点是否可以访问。

$ curl http://localhost:8080/hello
curl: (7) Failed to connect to localhost port 8080 after 0 ms: Connection refused

这是不行的。在Docker中，你可以查看容器以看到为容器分配了哪个IP地址。

$ podman inspect mypodmanplanet | grep IPAddress
            "IPAddress": "",

看来容器没有特定的IP地址。端点在localhost上也无法访问。

解决方案是在创建容器时添加端口映射。

停止容器并删除它。

$ podman stop mypodmanplanet 
mypodmanplanet
$ podman rm mypodmanplanet 
27639dabb5730d3244d205200a409dbc3a1f350196ba238e762438a4b318ef73

再次启动容器，但这次将内部端口8080映射到外部端口8080。

$ podman run -p 8080:8080 --name mypodmanplanet -d localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT

再次验证是否可以访问端点。这次可以了。

$ curl http://localhost:8080/hello
Hello Podman!

在继续阅读这个文章之前，请停止并删除容器。

Podman是否可以替代Docker运行容器镜像？

不，它不是可以直接替代的。尽管可以使用与Docker完全相同的命令，但你需要明确添加端口映射。如果没有端口映射，就无法访问端点。

卷挂载

卷挂载以及访问容器外部和容器内部的目录和文件常常导致Permission Denied错误。在之前的文章中，已经详细描述了Docker引擎的这种行为。使用Podman时，看看这是如何工作的会很有趣。

接下来，你将在容器中映射一个application.properties文件，这个文件位于jar文件旁边。Spring Boot应用程序将使用这个application.properties文件。该文件将服务器端口配置为8082端口，并且文件位于存储库根目录下的properties目录中。

server.port=8082

使用端口映射从内部端口8082到外部端口8083来运行容器，并将application.properties文件挂载到容器目录/opt/app中，jar文件也位于这个目录中。卷挂载具有属性ro，以表明它是一个只读文件。

$ podman run -p 8083:8082 --volume ./properties/application.properties:/opt/app/application.properties:ro --name mypodmanplanet localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT

验证是否可以访问端点以及它是否工作。

$ curl http://localhost:8083/hello
Hello Podman!

在容器中打开一个shell并列出目录内容以查看文件的所有权。

$ podman exec -it mypodmanplanet sh
/opt/app $ ls -la
total 24
drwxr-xr-x    1 javauser javauser      4096 Apr 15 10:33 .
drwxr-xr-x    1 root     root          4096 Apr  9 12:57 ..
drwxr-xr-x    1 javauser javauser      4096 Apr  9 12:57 BOOT-INF
drwxr-xr-x    1 javauser javauser      4096 Apr  9 12:57 META-INF
-rw-r--r--    1 root     root            16 Apr 15 10:24 application.properties
drwxr-xr-x    1 javauser javauser      4096 Apr  9 12:57 org

在Docker中，文件将由您的本地系统用户拥有，但在Podman中，文件由root拥有。我们来检查本地系统上的文件权限。

$ ls -la
total 12
drwxr-xr-x 2  domain users 4096 apr 15 12:24 .
drwxr-xr-x 8  domain users 4096 apr 15 12:24 ..
-rw-r--r-- 1  domain users   16 apr 15 12:24 application.properties

正如你所看到的，本地系统上的文件由拥有。这意味着，运行容器的主机用户，在容器内部被视为root用户。

在容器内打开一个shell，并尝试更改application.properties文件的内容。你会注意到，作为javauser用户，你并不被允许这样做。

$ podman exec -it mypodmanplanet sh
/opt/app $ vi application.properties 
/opt/app $ whoami
javauser

停止并删除容器。

运行容器，但这次使用属性U而不是ro。U后缀告诉Podman，根据容器内的UID和GID，使用正确的主机UID和GID来递归地改变源卷的所有者和组。

$ podman run -p 8083:8082 --volume ./properties/application.properties:/opt/app/application.properties:U --name mypodmanplanet localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT

在容器中打开一个shell，现在javauser用户是文件的所有者。

$ podman exec -it mypodmanplanet sh
/opt/app $ ls -la
total 24
drwxr-xr-x    1 javauser javauser      4096 Apr 15 10:41 .
drwxr-xr-x    1 root     root          4096 Apr  9 12:57 ..
drwxr-xr-x    1 javauser javauser      4096 Apr  9 12:57 BOOT-INF
drwxr-xr-x    1 javauser javauser      4096 Apr  9 12:57 META-INF
-rw-r--r--    1 javauser javauser        16 Apr 15 10:24 application.properties
drwxr-xr-x    1 javauser javauser      4096 Apr  9 12:57 org

在本地系统中，与我的本地用户不同的UID和GID已经取得了所有权。

$ ls -la properties/
total 12
drwxr-xr-x 2   domain  users 4096 apr 15 12:24 .
drwxr-xr-x 8   domain  users 4096 apr 15 12:24 ..
-rw-r--r-- 1    200099        200100   16 apr 15 12:24 application.properties

这次，在本地系统上更改文件是不被允许的，但在容器内的 javauser 用户却可以更改。

Podman 是否可以作为在容器内挂载卷的 Docker 的替代品？

不，它不能替代。文件权限功能与 Docker 引擎有些不同。你需要知道这些区别，以便能够在容器内挂载文件和目录。

Pod

Podman 知道 Pod 的概念，就像 Kubernetes 中的 Pod 一样。Pod 允许你将容器分组。Pod 也有一个共享的网络命名空间，这意味着 Pod 内的容器可以相互连接。有关容器网络的更多信息可以在此找到。这意味着 Pods 是分组容器的首选。当使用 Docker 时，你会使用 Docker Compose 来实现。有像 Podman Compose 这样的东西，但这值得写一篇文章。

让我们看看这是如何工作的。你将设置一个运行两个带有 Spring Boot 应用程序的容器的 Pod。

首先，你需要创建一个 Pod。你还需要暴露你希望在 Pod 之外可以访问的端口。这可以用 -p 参数来实现。并给 Pod 一个名字，在这种情况下是 hello-pod。

$ podman pod create -p 8080-8081:8080-8081 --name hello-pod

当你列出 Pod 时，你会注意到它已经包含一个容器。这就是 infra 容器。这个 infra 容器持有命名空间，以便容器可以相互连接，并且它使 Pod 中的容器启动和停止成为可能。infra 容器基于 k8s.gcr.io/pause 镜像。

$ podman pod ps
POD ID        NAME        STATUS      CREATED        INFRA ID      # OF CONTAINERS
dab9029ad0c5  hello-pod   Created     3 seconds ago  aac3420b3672  1
$ podman ps --all
CONTAINER ID  IMAGE                 COMMAND     CREATED        STATUS      PORTS                             NAMES
aac3420b3672  k8s.gcr.io/pause:3.5              4 minutes ago  Created     0.0.0.0:8080-8081->8080-8081/tcp  dab9029ad0c5-infra

创建一个名为 mypodmanplanet-1 的容器，并将其添加到 Pod 中。通过 --env 参数，你将 Spring Boot 应用的端口改为 8081。

$ podman create --pod hello-pod --name mypodmanplanet-1 --env 'SERVER_PORT=8081' localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT env

启动 Pod。

$ podman pod start hello-pod

验证是否可以在端口 8081 处访问端点，并验证在端口 8080 处的端点是否无法访问。

$ curl http://localhost:8081/hello
Hello Podman!
$ curl http://localhost:8080/hello
curl: (56) Recv failure: Connection reset by peer

将第二个容器 mypodmanplanet-2 添加到 Pod 中，这次在默认端口 8080 运行。

$ podman create --pod hello-pod --name mypodmanplanet-2 localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT

验证 Pod 状态。它显示状态为 Degraded。

$ podman pod ps
POD ID        NAME        STATUS      CREATED        INFRA ID      # OF CONTAINERS
dab9029ad0c5  hello-pod   Degraded    9 minutes ago  aac3420b3672  3

查看容器。有两个容器正在运行，而一个新容器刚被创建。这就是 Pod 状态为 Degraded 的原因。

$ podman ps --all
CONTAINER ID  IMAGE                                                      COMMAND     CREATED             STATUS            PORTS                             NAMES
aac3420b3672  k8s.gcr.io/pause:3.5                                                   11 minutes ago      Up 2 minutes ago  0.0.0.0:8080-8081->8080-8081/tcp  dab9029ad0c5-infra
321a62fbb4fc  localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT  env         3 minutes ago       Up 2 minutes ago  0.0.0.0:8080-8081->8080-8081/tcp  mypodmanplanet-1
7b95fb521544  localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT              About a minute ago  Created           0.0.0.0:8080-8081->8080-8081/tcp  mypodmanplanet-2

启动第二个容器并验证 Pod 的状态。现在的状态是运行中。

$ podman start mypodmanplanet-2
$ podman pod ps
POD ID        NAME        STATUS      CREATED         INFRA ID      # OF CONTAINERS
dab9029ad0c5  hello-pod   Running     12 minutes ago  aac3420b3672  3

现在可以访问两个端点了。

$ curl http://localhost:8080/hello
Hello Podman!
$ curl http://localhost:8081/hello
Hello Podman!

验证一下，是否可以从mypodmanplanet-2内部访问mypodmanplanet-1的端点。这同样可以实现。

$ podman exec -it mypodmanplanet-2 sh
/opt/app $ wget http://localhost:8081/hello
Connecting to localhost:8081 (127.0.0.1:8081)
saving to 'hello'
hello                100% |***********************************************************************************************************************************|    13  0:00:00 ETA
'hello' saved

清理工作

最后，你可以进行一些清理工作。

停止正在运行的Pod。

 $ podman pod stop hello-pod

现在，Pod的状态为Exited。

$ podman pod ps
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS 
dab9029ad0c5 hello-pod Exited 55 minutes ago aac3420b3672 3

Pod中的所有容器也都处于Exited状态。

$ podman ps --all
CONTAINER ID  IMAGE                                                      COMMAND     CREATED         STATUS                           PORTS                             NAMES
aac3420b3672  k8s.gcr.io/pause:3.5                                                   56 minutes ago  Exited (0) About a minute ago    0.0.0.0:8080-8081->8080-8081/tcp  dab9029ad0c5-infra
321a62fbb4fc  localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT  env         48 minutes ago  Exited (143) About a minute ago  0.0.0.0:8080-8081->8080-8081/tcp  mypodmanplanet-1
7b95fb521544  localhost/mydeveloperplanet/mypodmanplanet:0.0.1-SNAPSHOT              46 minutes ago  Exited (143) About a minute ago  0.0.0.0:8080-8081->8080-8081/tcp  mypodmanplane

删除Pod。

$ podman pod rm hello-pod

Pod和容器都被删除。

$ podman pod ps
POD ID      NAME        STATUS      CREATED     INFRA ID    # OF CONTAINERS
$ podman ps --all
CONTAINER ID  IMAGE       COMMAND     CREATED     STATUS      PORTS       NAMES

结论

关于Podman是Docker的兼容替代品的说法并不准确。Podman在构建容器镜像、启动容器、网络、卷挂载、容器间通信等方面与Docker存在一些差异。然而，Podman确实支持许多Docker命令。正确的说法应该是Podman是Docker的一种替代选择。 这是完全正确的。在切换到Podman之前，你需要了解并理解这些差异。在了解清楚之后，Podman绝对是一个很好的替代方案。

作者：Gunter Rotsaert

更多技术干货请关注公号“云原生数据库”

squids.cn，基于公有云基础资源，提供云上 RDS，云备份，云迁移，SQL 窗口门户企业功能，

帮助企业快速构建云上数据库融合生态。