Much like virtual machines, the principle behind containers is to provide guest operating systems that run within a host operating system.
However, unlike virtual machines, the operating system kernel used by the guest systems inside containers is the single kernel of the host operating system.
This kernel uses isolation mechanisms to properly separate the resources (network, storage, etc.) of the various guest systems.
This container-based approach is intended to be less resource-intensive for the host system than running multiple virtual machines.

In this field, the most well-known and widely used tool remains Docker.
However, Podman is a very similar tool that offers a significant security advantage: it can be run without any privileges on the host machine.
This helps prevent damage to the host system in the event of a mistake, which is particularly important on the shared workstations provided by ENIB.
As most podman commands are identical to docker commands, this tutorial will use podman commands throughout.
On ENIB workstations, the docker command remains available; it simply invokes podman✍.

This tutorial no longer requires the use of the virtual machines that we used in the previous tutorials. Try the commands docker --version and podman --version, and observe that they refer to the same software in both cases.
The resources most commonly managed are: Notice that all these commands follow the format podman resource_category action...; this will also be the case for all subsequent commands✍.

Normally, none of these resources are present initially✍, except for the implicit podman network.
If resources remain from a previous attempt and you wish to remove them completely, you can use the command podman system prune -af to delete everything except volumes, then podman volume prune -f to remove all volumes.

Try the command podman run --name A -it alpine and observe carefully what happens✍.
You should notice that Podman first downloads the alpine:latest image from the docker.io registry and then starts an interactive shell at the root of the guest system. A registry is a service that provides images for many operating systems or applications ready to run in containers; docker.io is the default registry.
Alpine Linux is an extremely lightweight Linux distribution, particularly well suited to the deployment of multiple guest systems.

From another terminal, run the commands podman image ls and podman container ls -a to verify that the alpine:latest image is indeed present and that the container named A has the Up status, and is running the /bin/sh command from that image.
If the --name A option had not been specified, a random name would have been assigned automatically.
If the -it option had not been specified, the session would not have been interactive (that is, connected to the terminal), which would have caused the shell to exit immediately and the container to stop.

In the container's interactive shell, run the ls command to view the existing directories, then execute echo 'Hello World!' >HELLO.TXT and verify that the newly created file is present.
Exit the interactive shell using the exit command.
From your other terminal, run podman container ls -a again and observe that the container now has the Exited status; this means that it is no longer running, but it still exists✍.

Using the command podman start -ai A✍, you restart this container in interactive mode.
The shell that opens allows you to verify that the file HELLO.TXT is still present; the container has preserved the state of its file system between being stopped and restarted✍.
From your other terminal, verify that container A once again has the Up status.
Exit this container using exit in its shell and verify that its has returned to Exited.
Using the command podman container rm A✍, you remove this container; the command podman container ls -a should now show no containers.
On the other hand, the command podman image ls shows that the alpine:latest image is still present in case it is needed to start other containers that use it.

Preserving a container's state after it has been stopped can be useful for experimentation, but in practice the intended use of containers very often relies on starting from a stable initial state.
It is therefore very common to want the container to be removed as soon as it exits.
Try the command podman run --name A --rm -it alpine and observe that startup is now immediate, since the image is already present and does not need to be downloaded from the registry.
Within the container shell, verify that the HELLO.TXT file created earlier is not present; we are starting again from the original image, and that file belonged to the previous container.
Exit the container and verify that, thanks to the --rm option, it immediately disappears from the list of containers; this is much more convenient than having to remove it manually.

We have just seen that deleting a container causes its data to be lost.
However, there are situations where it is necessary to preserve certain data, either to use it on the host system or to make it available to another container.
This is the purpose of volumes.

Ensure a directory that will be used for storage exists with mkdir -p /tmp/podman_${USER}/STORAGE✍.
Using the command podman volume create -o type=none -o o=bind -o device=/tmp/podman_${USER}/STORAGE my_storage, you create a volume named my_storage that corresponds to this directory.
Verify its presence with podman volume ls and inspect its details with podman volume inspect my_storage; you should find the specified directory.

Start a new container, specifying that the my_storage volume should be mounted in its /mnt directory: podman run --name A --rm -v my_storage:/mnt -it alpine.
In the container shell, enter the commands echo 'local file' >/LOCAL_FILE.TXT and echo 'volume file' >/mnt/VOLUME_FILE.TXT, then verify that the files have been created.
Exit the shell and verify that the container no longer exists.
Check the contents of /tmp/podman_${USER}/STORAGE and add a few words to the VOLUME_FILE.TXT file that you find there.
Start a new container in the same way and verify whether the two files are present.
The LOCAL_FILE.TXT file should be absent, since a new container has been created from the original image, but the VOLUME_FILE.TXT file should be present and reflect the changes made from the host, since it belongs to the volume, not to the container.

After the container has terminated, you can remove the volume with podman volume rm my_storage.
Verify that it has disappeared by running podman volume ls.
Although the volume has disappeared from Podman's perspective, the directory to which it referred still exists on the host; verify its contents.

Start a container with podman run --name A --rm -it alpine and, in its interactive shell, check its network configuration using ip addr, ip route and cat /etc/resolv.conf.
Depending on the host platform or the version of Podman, you will find that a network interface is configured either like the host or within a dedicated network.
This situation is not clear, so the aim is to make the network configuration more explicit.
You can then terminate the container.

Using the command podman network create my_network, you create a network named my_network, internal to the host system but dedicated to Podman.
Verify its presence with podman network ls and inspect its details with podman network inspect my_network; you should find the subnet and its default route.

Start a first container with podman run --name A --rm --network my_network -it alpine in one terminal, and a second with podman run --name B --rm --network my_network -it alpine in another terminal.
Containers A and B both have access to the my_network network.
On each of them, inspect the network configuration using ip addr, ip route, and cat /etc/resolv.conf; observe that they are indeed on a dedicated subnet.
Verify connectivity between them with ping B and ping A; in particular, note that DNS resolution includes the names assigned to the containers.

On container A, emulate a TCP server with the command nc -lp 9988✍.
In a third terminal, run the command podman exec -it A netstat -pant; this executes the command netstat -pant✍ in the already running container A.
Observe the output of this command to confirm that nc has indeed created a TCP socket listening on the chosen port.
On container B, emulate a TCP client that connects to the previous server with the command nc A 9988.
From your third terminal, run the netstat -pant command again on containers B and then A to observe the establishment of the TCP connection between the two nc commands.
Notice that the nc commands in both containers can exchange lines of text.
The virtual network my_network that you created can be used by your containers just like any other network.
You can now terminate containers A and B.

Start a container with the command podman run --name A --rm --network my_network -p 8877:9988 -it alpine nc -lp 9988.
Notice that after the image name, the command to be executed is specified; this container is therefore dedicated to running that command rather than a shell.
Also note that the -p 8877:9988 option has been added to indicate that port 8877 on the host is exposed to correspond to port 9988 in the container✍.
Verify that under these conditions, running the command ncat localhost 8877 on the host system allows you to interact from the host with the server running inside the container.

You can now terminate the container.
Also remove the network with podman network rm my_network and verify that it has been removed using podman network ls.

The objective is to use a PostgreSQL database running in a container.
First, visit the site exposing the docker.io registry and search for the preconfigured Postgres image; verify that a postgres:alpine variant exists✍.

The database container will be used by another container on a dedicated network.
To do this, recreate the my_network network as previously described.
It is reasonable to want to preserve the contents of the database beyond the lifetime of the container running it.
To do this, recreate the my_storage volume as previously described.

Start a container named DB with the following command: In addition to using my_network, the my_storage volume is mounted in the directory where PostgreSQL stores its data.
Since it is based on an image dedicated to running the PostgreSQL software, the container executes at startup a script specifically designed to initialise the database and then start it.
This script relies on environment variables that influence its behaviour; they are described on the presentation page of the Postgres image that you consulted at the beginning of this step.
The command uses these variables to specify the name of the database and an identity authorised to manage it.
Notice that the -it option has been replaced by the -d option in order to let the container run in the background.
Indeed, the database service being executed does not require interaction with the keyboard and terminal as was previously the case for a shell.
Since the selected image has never been used before, starting the container begins by downloading it.

Check that this container is running with the command podman container ls -a.
These startup and runtime messages can be viewed with podman container logs DB✍; verify that a message indicating database creation appears (roughly in the middle), along with another announcing that IPv4 connections are being accepted on a specific port.
Observe that new content has indeed appeared in the /tmp/podman_${USER}/STORAGE directory on the host system✍.
Using the command podman exec -it DB netstat -pant, verify that in the running DB container, there is indeed a socket listening on the TCP port used by the database.

The command podman run --name A --rm --network my_network -it alpine starts a new container named A, connected to the same network and providing an interactive shell.
From the shell of this minimal Linux system, the command apk add --no-cache postgresql-client installs the client software package used to interact with a PostgreSQL database.
Still from this shell, verify that the database provided by container DB is accessible, using the dedicated credentials, from container A: PGPASSWORD='demo_secret' psql -h DB -U demo_user -d demo_db.
At the client prompt, use these PostgreSQL-specific commands and standard SQL queries:

You can terminate container A, but keep the DB container running, as well as my_network and my_storage, since they will all be used again immediately in the next step.

Until now, containers have only used pre-built images directly.
The new objective is to build our own image.
This process generally does not start from scratch, but from an existing image to which we apply modifications in order to produce a new image tailored to a specific requirement.
Each modification constitutes a layer containing the differences introduced relative to the previous image layer✍.

In your working directory on the host system, create a directory named sh_db_demo and move your shell into it.
Create a file named sh_db_demo.sh with the following initial content:

The goal is now to start from an Alpine system image and ensure that it implicitly executes this script.
To do so, create a file named Dockerfile in the same directory with the following content: This is essentially a “recipe” describing the steps required to build the image✍.
The image is built with the command podman build -t sh_db_demo . ; it follows the instructions in the Dockerfile found in the current directory and builds the image whose name is specified by the -t option.
Verify with podman image ls that this image is now present among those that were previously downloaded.

Try to use it interactively with podman run --name A --rm --network my_network -it sh_db_demo.
Observe that the initial script executed by this container reports an error about an undefined environment variable, causing the container to terminate immediately.
Then start it again, this time specifying the expected environment variables: Observe that this time the variables are correctly received by the script and that it launches the expected interactive shell; simply type exit to terminate this container.

Replace the contents of the sh_db_demo.sh file with the following: This time, the variables are used to connect to the database.
After checking that the database is available, the table that we created in the previous step is used and the shell provides an interactive session.
Rebuild your sh_db_demo image; examine the messages carefully and observe that the layers preceding the script copy step do not need to be rebuilt (Using cache...), since the change only affects the script.
List the images with podman image ls and observe that this new image has the chosen name, while the previous one has lost its name (as it was the same).
The command podman image prune -f can be used to remove images and layers that are no longer needed.

Run container A once again as before and observe the script's new behaviour.
It interacts with the database in container DB and displays the few entries that we inserted during the previous step.
The overall situation can be described as follows:
        
Once again, terminate container A.

Replace the last three lines of sh_db_demo.sh with the following: The interactive shell has been replaced by a loop that waits for a connection on port 9988.
For each connection, the script sh_db_commands.sh is executed to communicate with the client (nc redirects the standard input/output of this script through the connection).
The sh_db_commands.sh script is a new file in the current directory with the following content: Depending on the lines sent by the client, actions are performed on the database.
Naturally, this new script will also be included in the built image, thanks to the COPY command in the Dockerfile.
Rebuild the sh_db_demo image and remove the old one with podman image prune -f.

Since this new version waits for connections on a chosen port, that port must be made accessible.
Container A must be started again as follows: The -d option starts it in the background because the new script does not require direct interaction with the terminal or keyboard.
Check its startup messages with podman container logs A.

The overall situation can be described as follows:
        
From the host system, it now becomes possible to interact with this application through the exposed 9988 port.
Using the command ncat localhost 9988, verify that you receive the messages from the sh_db_commands.sh script executed inside the container and that it responds to your commands✍.

Terminate container A with podman stop A✍ and then do the same for container DB. Verify with the command podman container ls -a that they have indeed been removed.
Also remove the network with podman network rm my_network and the volume with podman volume rm my_volume.

If you wish to remove the contents of the directory associated with your volume, it is likely that the Podman permissions model will prevent you from doing so directly.
The Podman-specific command podman unshare ... allows the directory to be accessed while taking this permissions model into account.
You can, for example, use podman unshare chown -R 0:0 /tmp/podman_${USER}/STORAGE to regain ownership of this content so that you can copy or delete it.
If you wish to remove the /tmp/podman_${USER} directory yourself in order to reset everything, simply run /tmp/podman_${USER}/remove_all.