In what order does Skaffold start up deployments and is there a way to specify order?

Question

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:

1. How is the deployment order determined in Skaffold?
2. Is there a way to set the order?

Unthrone

github.com/GoogleContainerTools/skaffold/issues/2645 – Mason

@Mason Says it should be in the order of the manifests... apparently that isn't the case given what I am experiencing. – Unthrone

Preferably what you want to do is to create init container for your api-server to wait for db to startup. In such case you can make sure db is always running before starting api-server. Also consider what is going to happen when db suddenly becomes unreachable. Maybe it would be nice to add some code to api so it would be able to handle such cases. – Frequency

@HelloWorld Thanks for the feedback! This got me going in the right direction. It turns out readiness, liveness, and startup probes would be a better fit for my application. Init container and probes weren't even on my radar as I'm learning Kubernetes, but you got me moving in the right direction. – Unthrone

Answer 1

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.

Unthrone