I'm looking for a robust and reliable strategy to apply my database migrations once per application of my Deployment yaml file to use in my CI/CD pipeline.
The initial (no pun intended) plan was to use initContainers to perform the migration. The difficulty I'm encountering has to do with the method of connecting to the CloudSQL database--since I'm using the gcr.io/cloudsql-docker/gce-proxy:1.11 sidecar container to let my application containers connect, I'm not sure how to provide the database access to the initContainers because they appear to only support single containers pods. Is it possible to run the proxy container as a sidecar on the initContainers?
If that is not possible, what is the preferred approach? Should the entrypoint of the application containers apply the migrations before launching the application itself? My concern is that in an initial launch of the deployments might create race conditions with multiple pods trying to apply migrations simultaneously?
Just for clarification (due to question's wording): Although initContainers can support more than one, they are syncronous resources so, you can't run two at once.
In your specific scenario, you might want to try another way to connect to Cloud SQL, like using a private IP. This approach can replace the need for using the sidecar proxy in the containers following the initContainer.
However, it has some drawbacks such as, it only works on VPC-native clusters and 2nd generation MySQL servers.
Another approach could be using a postStart handler to start the migrations right after container creation. This has the advantage that will let you preveserve your current model using the sidecar, but it can't guarantee that the container's entrypoint is going to be executed before the handler, so it might fail. For that, you may consider using a restartPolicy to track failed pods.