Basically, I need the database deployment to spin up before the API deployment. If the database isn't running, it throws an error in the API.
I've messed with the order in artifacts:
and also in:
deploy:
kubectl:
manifests:
- manifests/ingress.yaml
- manifests/postgres.yaml
- manifests/client.yaml
- manifests/api.yaml
But it doesn't seem to have any bearing on the order they startup.
The only thing I can think is that it is alphabetical. I used to not have an issue: the database would startup 49/50 before the api. Now it is about the opposite. The only thing I've changed is a new computer and I renamed the server
to api
which puts it first alphabetically.
So two questions:
What I had to do was setup a readinessProbe
(livenessProbe
is optional, for continuous life check) in the containers
section of the *.yaml
files.
livenessProbe:
tcpSocket:
port: 5000
initialDelaySeconds: 2
periodSeconds: 2
readinessProbe:
tcpSocket:
port: 5000
initialDelaySeconds: 2
periodSeconds: 2
This looks for Django to fail (i.e. can't connect to the database) and if it does it keeps trying to redeploy it until it doesn't. This was the only way that I could find.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With