Improvements in the integration of Red Hat Podman and HashiCorp Nomad make it suitable for high-value applications and workflows.
One of the core goals of the HashiCorp Nomad team is to enable users to run workloads the way they like.
That goal extends to the Red Hat Podman container engine for running OCI Linux containers. Through community-driven efforts, running Podman tasks in Nomad has been possible with the Podman task driver plugin for some time.
Thanks to recent community efforts, we’ve made progress maturing the Podman and Nomad integration for high-value applications and workflows. This post shares some of the new features of the Nomad-Podman integration.
The latest enhancements to the Nomad-Podman integration add support for:
Although there is still work to be done, the progress made opens doors to new Podman use cases that were tedious, if not impossible, before.
Nomad 1.7, released in GA this month, takes advantage of these developments to provide a more seamless experience when using Podman in conjunction with our HashiCorp Consul service mesh integration.
Consul service mesh requires the use of an Envoy sidecar proxy for each task participating in
the network mesh. Since its inception, the Nomad integration for Consul service mesh has defaulted to a Docker-specific task configuration for these Envoy sidecars. Now, Nomad will automatically detect if Podman is the most suitable task driver and generate an Envoy task configuration that runs Envoy as a Podman container. Job submitters no longer need to specify a custom connect.sidecar_task
block.
There are substantial advantages to using Podman as a task driver instead of Docker:
dockerd
and containerd
as root processes on every node.systemd
socket activation to launch containers. Most mainstream Linux distributions are based on systemd, providing widespread out-of-the-box support.Earlier in this post, we discussed how Envoy containers run alongside each Nomad task when using the Consul service mesh integration. With Docker, each task group with one of those Envoy containers actually requires a second sidecar — the pause container — which is necessary due to the special way Docker creates network namespaces.
Since Podman works with the conventional network namespaces created and managed by the Nomad client, there is no need for that extra sidecar. In a cluster with thousands of tasks participating in a service mesh, the savings on CPU, memory, disk, and bandwidth can be significant.
These improvements to the Nomad-Podman integration story are only the beginning. Going forward, we intend to provide first-class support for rootless Podman, address outstanding bug reports, enhance our Podman integration test coverage, and update the plugin-packaging.
To find out more about the Nomad-Podman integration, please visit our Podman task driver page.
Do cloud right with The Infrastructure Cloud from HashiCorp. Unlock developer potential while controlling cloud costs and risk.
Learn the installation and verification workflow for any Linux distribution that does not include HashiCorp software in its package repository.
Learn how JWT-based authentication works in HashiCorp Nomad using a custom GitHub Action as an example of machine-to-machine authentication.