What Is New in Podman 4.6
Podman 4.6 delivers significant enhancements across container management, networking, and security. This update focuses on improving the developer experience with new commands and tighter integration with existing tools.
| Category | Key Changes |
|---|---|
| New Features | New podman events commands, container checkpoint/restore improvements, enhanced secret management |
| Networking | New podman network reload command, DNS resolution improvements for rootless containers |
| Security | Support for FIPS-enabled containers, improved SELinux handling for named volumes |
| Improvements | Better Docker Compose integration, new container output formats, image handling optimizations |
| Bug Fixes | Numerous fixes for networking, storage, and container lifecycle management |
What new commands were added for managing container events?
Podman 4.6 introduces powerful new subcommands for the podman events system. You can now use podman events wait to block until a specific event occurs and podman events replay to re-fire past events from the journal.
This is particularly useful for scripting and automation. You can write scripts that wait for a container to enter a specific state before proceeding, making your automation more robust and event-driven.
# Wait for a container to start
podman events wait --filter container=my_app --filter event=start
# Replay all events from the last hour
podman events replay --since 1h
How does the new network reload command improve operations?
The new podman network reload command allows you to update a container's network configuration without a full restart. This applies new DNS settings and network resolutions immediately.
In practice, this means you can change a container's DNS server or hostfile entries on the fly. It eliminates the need for disruptive container restarts when you need to update network parameters, which is a big win for maintaining service availability.
# Update network settings for a running container
podman network reload my_container
What enhancements were made for rootless container DNS?
DNS resolution for rootless containers has been significantly improved. The slirp4netns resolver now handles scenarios where the host's DNS resolver is running on a local IP address, not just 127.0.0.1.
This fixes a common pain point for developers using local DNS resolvers or VPNs that bind to non-standard local addresses. Your rootless containers will now reliably respect the host's DNS configuration in more complex networking setups.
How was checkpoint and restore functionality enhanced?
Container checkpoint and restore capabilities now work with the --tcp-established flag for Podman pods. This allows you to preserve active TCP connections when checkpointing entire application pods.
For stateful services with persistent connections, this means you can migrate or update entire application stacks with minimal disruption. The connections remain active through the checkpoint/restore process, maintaining session state.
What improvements were made for Docker Compose users?
Podman's Docker Compose integration now includes a new --replace-uid flag for the podman compose up command. This allows you to change the user ID that containers run as without modifying the Compose file.
This is useful for testing and development where you might need to run containers with different user contexts. It provides more flexibility while maintaining compatibility with existing Docker Compose workflows.
# Run compose with a different user ID
podman compose up --replace-uid 1000:1000
What security enhancements does 4.6 include?
Podman 4.6 adds support for running FIPS-enabled containers when the host system is in FIPS mode. This ensures cryptographic compliance for containers in regulated environments without additional configuration.
Additionally, SELinux handling for named volumes has been improved. The system now properly applies SELinux labels when using named volumes with rootless containers, maintaining security boundaries in more deployment scenarios.
FAQ
How do I use the new events wait command in automation scripts?
Use podman events wait with specific filters to block your script until a desired event occurs. For example: podman events wait --filter container=db --filter event=start will pause execution until the 'db' container starts, then continue with the next steps in your script.
Does the network reload command work with all network types?
The podman network reload command primarily works with containers using the slirp4netns networking stack, which is common for rootless containers. For root containers with different network configurations, the behavior may vary depending on the network driver in use.
What happens to established TCP connections during pod checkpoint?
When using --tcp-established with pod checkpoint, active TCP connections are preserved through the checkpoint process. The connections remain open and are restored exactly as they were, allowing for seamless migration of stateful applications without dropping connections.
Can I use the new FIPS support without a FIPS-enabled host?
No, the FIPS container support requires that the host system is already running in FIPS mode. Podman detects the host's FIPS mode and automatically applies the appropriate cryptographic policies to containers without needing additional flags or configuration.
How does the --replace-uid flag differ from user field in compose?
The --replace-uid flag overrides the user field specified in your Docker Compose file at runtime without modifying the file itself. This is useful for temporary changes or testing different user contexts, while the user field in the compose file remains the permanent configuration.