Meant for updates too?

[rept]

Is Kuby meant for updates too? Let me explain: in our current setup we have a cluster with Postgres, Nginx, Redis, Ruby etc...

Tagging a commit automatically starts of Jenkins that builds the new image. This image is pushed to Docker hub and then pushed to staging. This spins up a second Ruby pod and as soon as the liveness and readinessProbe of that pod is OK it shuts down the old pod. Works fantastic.

Your tutorial and video clearly explain how you can easily spin up a complete cluster that even takes care of the certificates. But is Kuby aimed at doing updates (to the Ruby pod) later on too?

Something like:

bundle exec kuby -e production update

Since you know the port of each pod you could include a liveness and readinessProbe to do the basic checks on the ports.

These are the probes we currently use for our Ruby pod.

        livenessProbe:
          httpGet:
            path: /
            port: 80
          # Give the node some time to startup. Replace by startupProbe once it leaves alpha state.
          initialDelaySeconds: 180
          failureThreshold: 2
          periodSeconds: 40
          timeoutSeconds: 2
        readinessProbe:
          httpGet:
            path: /
            port: 80
          periodSeconds: 10
          timeoutSeconds: 2

[camertron]

@rept yes, Kuby deployments currently have readiness probes, here's where that's configured in code. Kuby also comes with a railtie and bit of health check middleware that it inserts automatically into your app's middleware stack. Kuby doesn't distinguish between first-time deploys and updates - they're handled the same way. Behind the scenes, Kuby builds up a series of Kubernetes resources and applys them on deploy. Kubernetes then does all the heavy lifting to cut traffic over to the new pods (and stop the old ones).

Currently Kuby doesn't add any liveness probes to deployments, but that would certainly be a welcome feature if you're feeling up to contributing it :) Even just filing an issue would be great too.

[rept]

Fantastic work, well though through! I looked in the code and saw DB migrations are also handled, can the readiness probe timeout be customised? We had to increase it because sometimes migrations that impacted data took some time.

I'll definitely create an issue for the liveness and will try to explain as good as I can.

[camertron]

Thank you! Yes, the readiness probe (along with basically everything else) can be customized, although in this case it's not super easy or discoverable. Here's how you would do it in your kuby.rb:

Kuby.definition('myapp') do
  environment(:production) do
    kubernetes do
      add_plugin(:rails_app) do
        deployment.spec.template.spec.container(:web).readiness_probe do
          timeout_seconds 1  # custom value goes here
        end
      end
    end
  end
end

Eventually I would like to make these settings easier to access and modify, because ^ this is ridiculous. I'll file an issue.

[camertron]

See: #22

I think it would be a good idea to describe how Kuby deploys work in the docs, so I added the "documentation" label.

[camertron]

@rept is it ok if I close this issue?