Chapter 1. Starting with containers

• Running in rootless mode - rootless containers are much more secure, as they run without any added privileges
• No daemon required - these tools have much lower resource requirements at idle, because if you are not running containers, Podman is not running. Docker, conversely, have a daemon always running
• Native systemd integration - Podman allows you to create systemd unit files and run containers as system services

• Podman, Buildah, and the CRI-O container engine all use the same back-end store directory, /var/lib/containers, instead of using the Docker storage location /var/lib/docker, by default.
• Although Podman, Buildah, and CRI-O share the same storage directory, they cannot interact with each other’s containers. Those tools can share images.
• To interact programmatically with Podman, you can use the Podman v2.0 RESTful API, it works in both a rootful and a rootless environment. For more information, see Using the container-tools API chapter.

• You can install the podman-docker package, every time you run a docker command, it actually runs a podman command.
• Podman also supports the Docker Socket API, so the podman-docker package also sets up a link between /var/run/docker.sock and /var/run/podman/podman.sock. As a result, you can continue to run your Docker API commands with docker-py and docker-compose tools without requiring the Docker daemon. Podman will service the requests.
• The podman command, like the docker command, can build container images from a Containerfile or Dockerfile. The available commands that are usable inside a Containerfile and a Dockerfile are equivalent.
• Options to the docker command that are not supported by podman include network, node, plugin (podman does not support plugins), rename (use rm and create to rename containers with podman), secret, service, stack, and swarm (podman does not support Docker Swarm). The container and image options are used to run subcommands that are used directly in podman.

• AMD64 and Intel 64 (base and layered images; no support for 32-bit architectures)
• PowerPC 8 and 9 64-bit (base image and most layered images)
• 64-bit IBM Z (base image and most layered images)
• ARM 64-bit (base image only)

Prerequisites

• You need to become a root user to set up your RHEL system to allow non-root user accounts to use container tools.

• If you set up multiple rootless container users, use unique ranges for each user.
• Use 65536 UIDs and GIDs for maximum compatibility with existing container images, but the number can be reduced.
• Never use UIDs or GIDs under 1000 or reuse UIDs or GIDs from existing user accounts (which, by default, start at 1000).

Prerequisites

• The user account has been created.

Procedure

• Run the usermod command to assign UIDs and GIDs to a user:

  # usermod --add-subuids 200000-201000 --add-subgids 200000-201000 <username>

  • The usermod --add-subuid command manually adds a range of accessible user IDs to the user’s account.
  • The usermod --add-subgids command manually adds a range of accessible user GIDs and group IDs to the user’s account.

Verification

• Check that the UIDs and GIDs are set properly:

  # grep <username> /etc/subuid /etc/subgid
   /etc/subuid:<username>:200000:1001
   /etc/subgid:<username>:200000:1001

• The path to the host container storage is different for root users (/var/lib/containers/storage) and non-root users ($HOME/.local/share/containers/storage).
• Users running rootless containers are given special permission to run as a range of user and group IDs on the host system. However, they have no root privileges to the operating system on the host.
• If you change the /etc/subuid or /etc/subgid manually, you have to run the podman system migrate command to allow the new changes to be applied.
• If you need to configure your rootless container environment, create configuration files in your home directory ($HOME/.config/containers). Configuration files include storage.conf (for configuring storage) and containers.conf (for a variety of container settings). You could also create a registries.conf file to identify container registries that are available when you use Podman to pull, search, or run images.

• There are some system features you cannot change without root privileges. For example, you cannot change the system clock by setting a SYS_TIME capability inside a container and running the network time service (ntpd). You have to run that container as root, bypassing your rootless container environment and using the root user’s environment. For example:

  # podman run -d --cap-add SYS_TIME ntpd

  Note that this example allows ntpd to adjust time for the entire system, and not just within the container.

• A rootless container cannot access a port numbered less than 1024. Inside the rootless container namespace it can, for example, start a service that exposes port 80 from an httpd service from the container, but it is not accessible outside of the namespace:

  $ podman run -d httpd

  However, a container would need root privileges, using the root user’s container environment, to expose that port to the host system:

  # podman run -d -p 80:80 httpd

• The administrator of a workstation can allow users to expose services on ports numbered lower than 1024, but they should understand the security implications. A regular user could, for example, run a web server on the official port 80 and make external users believe that it was configured by the administrator. This is acceptable on a workstation for testing, but might not be a good idea on a network-accessible development server, and definitely should not be done on production servers. To allow users to bind to ports down to port 80 run the following command:

  # echo 80 > /proc/sys/net/ipv4/ip_unprivileged_port_start

• For rootless users: $HOME/.config/containers/containers.conf.modules
• For root users: /etc/containers/containers.conf.modules, or /usr/share/containers/containers.conf.modules

• You can specify modules multiple times by using the --module option.
• If <your_module_name> is the absolute path, the configuration file will be loaded directly.
• The relative paths are resolved relative to the three module directories mentioned previously.
• Modules in $HOME override those in the /etc/ and /usr/share/ directories.