Try for 60 days: Red Hat OpenShift Dedicated.eBook: Modernize your IT with managed cloud services.Using gvproxy is entirely unique to the Podman machine scenario. The plugin sends port information to the host, where gvproxy then does the port mapping between the host and the VM/container. This step is not remarkably different from running everything on the host.įinally, if the running container has port mappings, Podman inside the VM tells the host about them using a custom CNI plugin to initiate the communication. Once the image is pulled successfully, the container runs on the VM. The only notable difference between this scenario and the scenario where Podman is running entirely on the host is that the VM routes its traffic through the host system. If the image is not already in the user's local image storage, Podman pulls (fetches) the image from an image registry. When the host computer issues this command, the command is sent to the VM's socket through ssh. This command loosely translates to: Run a container based on the nginx image with a tty in detached mode and map the host port of 8080 to the container port of 80. For example: podman run -dt -p 8080:80 nginx To see a typical flow of how Podman works with a started Podman machine, you can run a container that exposes ports. The Podman client interacts with the socket-activated services on the host VM using SSH and SSH keys generated during machine init. Once the VM is running, the Podman client on the host operating system is ready for use. And then finally, Podman socket-activated services are set up for privileged and unprivileged users (G). The gvproxy application manages port mapping between the host and VM for example, "binding" a port for an HTTP application (F). Once the VM boots, an application called gvproxy starts on the host operating system. Several configuration changes are made (E). The ignition file is injected into the VM during this first boot and then run in the boot process. Based on the configuration file, a qemu command is assembled, and the then VM runs. When the start subcommands runs, the machine configuration file is read in, and Podman then checks to ensure that this machine is not already running (D). Once the image is downloaded, the image is uncompressed, resized, and two relevant files are written: The machine description and the ignition file (C). After you run the init command (A), Podman checks for the latest version of FCOS, and if that version is not already local, it downloads it (B). I describe the init process in the illustration below. Once you've installed the client, issue podman machine init to create a Linux VM for your containers.
For example, you can do this on a Mac using Homebrew with brew install podman. The first step is to make sure you have a Podman client on your host system. Understanding how all these components work together requires a more granular inspection. SSH: The Podman client securely communicates with the Linux VM using secure shell (SSH) keys.gvisor-tap-vsock: A proxy application that sets up port mapping on the host according to instructions from a custom Container Network Interface (CNI) plugin on the VM.Ignition: Configures the FCOS VM (similar to cloud-init).Fedora CoreOS (FCOS): The virtualized Linux distribution.