-
Getting help
- podman --help
- podman <subcommand> --help
- man podman
- man podman-<subcommand>
-
Searching, pulling & listing images
- podman search <search_term>
- You can also enhance your search with filters:
- podman search httpd --filter=is-official
-
Downloading (Pulling) an image
- podman pull docker.io/library/httpd
-
List all images, present on your machine
- podman images
Note: Podman searches in different registries. Therefore it is recommend to use the full image name (docker.io/library/httpd instead of httpd) to ensure, that you are using the correct image.
-
Remove an image on your machine
- List all images and copy the IMAGE ID of the image you want to remove, then execute the command below
- podman rmi <image_id>
Note: Replace <image_id> with the ID of the image you copied from the output of listing all images
- List all images and copy the IMAGE ID of the image you want to remove, then execute the command below
-
Running a container
- podman run -dt -p 8080:80/tcp docker.io/library/httpd
Note: Because the container is being run in detached mode, represented by the -d in the podman run command, Podman will print the container ID after it has executed the command. The -t also adds a pseudo-tty to run arbitrary commands in an interactive shell.
Note: We use port forwarding to be able to access the HTTP server. For successful running at least slirp4netns v0.3.0 is needed.
- Listing running containers
- podman ps
Note: If you add -a to the podman ps command, Podman will show all containers (created, exited, running, etc.).
-
Inspecting a running container
-
You can "inspect" a running container for metadata and details about itself
-
podman inspect
- podman inspect -l
Note: The -l is a convenience argument for latest container. You can also use the container's ID or name instead of -l or the long argument --latest.
Note: If you are running remote Podman client, including Mac and Windows (excluding WSL2) machines, -l option is not available.
-
-
Viewing the container's logs
- podman logs -l
view logs for the latest container
- podman logs <container_id>
view logs for the container with the specified <container_id>
- podman logs -l
-
Viewing the container's pids
- podman top -l
view pids for the latest container
- podman top <container_id>
view pids for the container with the specified <container_id>
- podman top -l
-
Stopping the container
- podman stop -l
- podman stop <container_id>
-
Removing the container
- podman rm -l
- podman rm <container_id>
-
Networking https://github.com/containers/podman/blob/main/docs/tutorials/basic_networking.md
-
Checkpoint, Migration and Restoring containers
-
Checkpointing a container stops the container while writing the state of all processes in the container to disk. With this, a container can later be migrated and restored, running at exactly the same point in time as the checkpoint. For more details, see https://podman.io/docs/checkpoint
-
This capability requires CRIU 3.11 or later installed on the system. This feature is not supported as rootless; as such, if you wish to try it, you'll need to re-create your container as root, using the same command but with sudo.
-
To checkpoint the container use:
sudo podman container checkpoint <container_id>- Restoring a container is only possible for a previously checkpointed container. The restored container will continue to run at exactly the same point in time it was checkpointed. To restore the container use:
sudo podman container restore <container_id>-
After being restored, the container will answer requests again as it did before checkpointing.
-
To live migrate a container from one host to another the container is checkpointed on the source system of the migration, transferred to the destination system and then restored on the destination system. When transferring the checkpoint, it is possible to specify an output-file.
-
On the source system:
sudo podman container checkpoint <container_id> -e /tmp/checkpoint.tar.gz scp /tmp/checkpoint.tar.gz <destination_system>:/tmp- On the destination system:
sudo podman container restore -i /tmp/checkpoint.tar.gz- After being restored, the container will answer requests again as it did before checkpointing. This time the container will continue to run on the destination system.
-
-
Integration Tests
- For more information on how to setup and run the integration tests in your environment, checkout https://github.com/containers/podman/blob/main/test/README.md
-
More information
- For more information on Podman and its subcommands, checkout the asciiart demos on https://github.com/containers/podman/blob/main/commands-demo.md
https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md
Prior to allowing users without root privileges to run Podman, the administrator must install or build Podman and complete the following configurations.
The cgroup V2 Linux kernel feature allows the user to limit the amount of resources a rootless container can use. If the Linux distribution that you are running Podman on is enabled with cgroup V2 then you might need to change the default OCI Runtime. Some older versions of runc do not work with cgroup V2, you might have to switch to the alternative OCI runtime crun.
The alternative OCI runtime support for cgroup V2 can also be turned on at the command line by using the --runtime option:
podman --runtime crun
or for all commands by changing the value for the "Default OCI runtime" in the containers.conf file either at the system level or at the user level from runtime = "runc" to runtime = "crun".
https://podman.io/getting-started/installation
The slirp4netns package provides user-mode networking for unprivileged network namespaces and must be installed on the machine in order for Podman to run in a rootless environment. The package is available on most Linux distributions via their package distribution software such as yum, dnf, apt, zypper, etc. If the package is not available, you can build and install slirp4netns from GitHub.
The majority of the work necessary to run Podman in a rootless environment is on the shoulders of the machine’s administrator.
Once the Administrator has completed the setup on the machine and then the configurations for the user in /etc/subuid and /etc/subgid, the user can just start using any Podman command that they wish.
The Podman configuration files for root reside in /usr/share/containers with overrides in /etc/containers. In the rootless environment they reside in ${XDG_CONFIG_HOME}/containers (usually ~/.config/containers) and are owned by each individual user.
The three main configuration files are containers.conf, storage.conf and registries.conf. The user can modify these files as they wish.
Podman reads
- /usr/share/containers/containers.conf
- /etc/containers/containers.conf
- $HOME/.config/containers/containers.conf
if they exist in that order. Each file can override the previous for particular fields.