Container dependencies using `podman play kube` about podman HOT 7 OPEN

@ygalblum @umohnani8 @haircommander PTAL

from podman.

Is this the function of an init container? I think there is a special one that continues to run after init is complete.

from podman.

yeah initContainers are started and run to completion before the main containers. There's also the notion of sidecar containers which are also initContainers, but have restartPolicy Always, so they're started before the main containers but don't complete before the others are started

from podman.

yeah initContainers are started and run to completion before the main containers. There's also the notion of sidecar containers which are also initContainers, but have restartPolicy Always, so they're started before the main containers but don't complete before the others are started

If we added a sidecar container under initContainers that was able to check the health of the database container in the postStart lifecycle using a script, would that be able to halt only the application container from attempting to start while the database container is starting? One thing to note, is that the k8s yaml that is generated from the podman generate kube puts the database and application containers in the same pod.

Our generated Kubernetes yaml file for reference:
https://github.com/candlepin/candlepin/blob/main/dev-container/candlepin-deployment.yaml

from podman.

Hi,
There's a pull request addressing sidecar containers. While it is not yet merged, @joshmalbrecht is this what you are looking for?

from podman.

@ygalblum are you suggesting to run the application image as a sidecar container? I think that would work with the pull request you linked and the added restart functionality. I believe the sidecar container would first startup and fail and then continue retrying to restart until the database container in the same pod is healthy and the application can make a database connection.

I'm not very familiar with Kubernetes, so please let me know if this isn't correct, but it seems like the database container and the application container should be in two separate pods. To get similar functionality to the docker-compose depends_on, you would need an init container in the application pod that waits until the database pod is healthy before completing and allowing the application container to start. From doing some reading it seems like this is the Kubernetes equivalent of the docker compose depends_on functionality, so maybe this is the pattern we should follow?

Both of these options should work for this use case!

from podman.

@joshmalbrecht first, my suggestion was the other way around (that is having the DB as a sidecar to the application). Having said that, I agree that ideally they should be in different pods. However, as you've mentioned podman does not handle dependencies between pods.

The second option you suggested does look promising. Podman will not start the main container until the init container has returned successfully (regular init containers, not the ones supported by the PR I linked). So, having an init container wait until the DB connection is up should do the trick.

Another option is to use Quadlet which allows you to define dependencies between containers (or pods) using Systemd. I actually wrote a blog post about it: https://www.redhat.com/sysadmin/multi-container-application-podman-quadlet which also has some code accompanying it: https://github.com/ygalblum/quadlet-demo along

from podman.