Search the Community

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 Nomad-Podman integration has matured The latest enhancements to the Nomad-Podman integration add support for: Running Podman containers in task groups with bridge networking enabled Authentication options in the task driver config Specifying a credentials helper or external credentials configuration file for working with private registries (via Podman driver support) 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. Podman and Consul service mesh 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. Why use Podman instead of Docker? There are substantial advantages to using Podman as a task driver instead of Docker: Podman does not require running dockerd and containerd as root processes on every node. Podman makes clever use of systemd socket activation to launch containers. Most mainstream Linux distributions are based on systemd, providing widespread out-of-the-box support. Unlike Docker, Podman does not require pause containers to support the bridge networking use case 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. More maturity on the way 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. View the full article