There are two major Containers used, docker and podman. Docker however require root access, but podman does not. We can install any Operating system image using the command:
docker/podman pull Os_image_name
once it is installed, we will start the image by following command:
Running a container without mounting any directory:
podman run -d -t --name rocky9.2 rockylinux/rockylinux:9.2
here rocky9.2 can be any name you assign to image rockylinux:9.2
once it runs, we can see the processes using the command
podman ps
and run the command
podman exec -it rocky9.2 bash
```
- podman images (to see list of all pulled images)
- podman stop rocky9.2 ( to stop the container from running )
- podman start rocky9.2 ( to start it once again_)
```
To run a container with mounted host directories using Podman, you can use the -v or --volume option to create bind mounts. Bind mounts allow you to link directories on your host system to directories inside the container. Here's how you can do it:
```bash
podman run -it --name my-container -v /path/to/host/directory:/path/in/container IMAGE_NAME
```
-
-it: This runs the container in interactive mode with a terminal. -
--name my-container: You can give the container a name of your choice. -
-v /path/to/host/directory:/path/in/container: This is where the bind mount is defined. Replace/path/to/host/directorywith the absolute path to the directory on your host system that you want to mount and/path/in/containerwith the path within the container where you want to mount it. -
IMAGE_NAME: This is the name of the container image you want to run.
For example, if you want to mount a directory named my_data located in your home directory on the host to the /data directory in the container, you can run:
```bash
podman run -it --name my-container -v ~/my_data:/data my-image
```
Once the container is running with the bind mount, any changes made to the /data directory inside the container will be reflected in the ~/my_data directory on your host system, and vice versa. This allows for easy sharing of files and data between the host and the container.
Here I have installed rockylinux 9.2 image and made an container named as virat, I have mounted the /home/vishal of host to /home/vishal of container.
To exit form container, simply type "exit" and hit enter.
To enter again the intereactive bash shell to the container, simply use the alias created , just type "virat" and hit enter in command prompt. You can check it.
To unmount the directories, use : podman stop rockybalboa
to restart, use : podman start virat && virat
To list all containers, use "podman ps -a", use
podman rm container_name.
To remove the images: first we have to stop container podman stop container_name and then remove the container by podman rm container_name, and then only we can remove the images by podman rmi image_name.
- Backup the container
the below command will create an updated image:
podman commit container_name image_name
To save to .tar file and download it to local system or transfer to some ssd drive, we can :
podman save -o output.tar image1 image2 ...
To load the image from the .tar file on another system, you can use the podman load command:
podman load -i image_name.tar
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/cdi-support.html
follow above or simply execute the below command:
podman run -d -t --device nvidia.com/gpu=all --security-opt=label=disable --name sachin cuda_virat:latest
In above command, -d means run in background, -t means tty support, --name is nickname for container and cuda_virat:latest is name of image we commited by:
podman commit cuda_vira virat
podman run -d -t --device nvidia.com/gpu=all --security-opt=label=disable -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --net=host --name virat cuda_vim:latest
- To add all gpu(--device nvidia.com/gpu=all --security-opt=label=disable)
- To have graphic access (--net=host -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix) + (use podman cp ~/.Xauthority CONTAINER_name:/root/.Xauthority)
- == After restarting cluster , containers are gone, ==
-
to get back them, use
- nvidia-smi
- podman start container_name
- use "loginctl enable-linger username" or "loginctl enable-linger" to keep the gpu/background jobs running.
In the context of Podman containers on a server, the concept of user sessions and lingering is typically associated with the host system rather than individual containers. Containers are isolated environments that run on the host, and their lifecycle is managed by the container runtime (such as Podman or Docker).
If you want certain processes or services to continue running even when the user logs out of the host system, you generally need to manage that at the host level, not within the container. The container itself doesn't have direct control over the host's user sessions.
If you have specific processes or services within a Podman container that you want to keep running persistently, you may want to consider approaches such as:
-
*Run the Container in the Background:*
When you start a container with Podman, you can use the
-doption to run it in the background. This allows the container to continue running even after the terminal session is closed. ```bash podman run -d your_image ``` -
*Use Systemd Service:*
You can create a systemd service on the host system that manages the lifecycle of your container. This allows you to start, stop, and manage the container as a system service.
Create a systemd service file, for example,
mycontainer.service: ```ini [Unit] Description=My Container [Service] ExecStart=/usr/bin/podman run your_image Restart=always User=your_username Group=your_groupname [Install] WantedBy=default.target ``` Adjust theExecStart,User, andGroupparameters according to your setup. Then, enable and start the service: ```bash sudo cp mycontainer.service /etc/systemd/system/ sudo systemctl enable mycontainer.service sudo systemctl start mycontainer.service ```
Remember that these approaches are host-centric. If you need more fine-grained control within the container itself, you may need to manage the processes or services directly within the container using tools appropriate for your containerized application.