2

We are using CircleCI to automate the building of images when merges are detected on our release branch. Those images are then being pushed to ECR, but I am unsure of the best way to refresh some or all of the pods running the outdated images, and additionally how to do it in a way that does not disrupt service, ie: rolling restarts etc.

We are looking into using Flux for this, but I'm not sure if that is the best approach.

I was hoping to get some insight from people running this or similar pipelines in production.

Improve this question
2
  • [ Container team member here ] I am not posting this as an answer because I am not a "running this" but I observe mixed patterns among people: those that want to use a GitOps style use Flux/Flux2 (or Argo) to do this (e.g. they configure Flux to monitor for image tag changes". Those that use traditional CD use whatever tools/mechanism the CI/CD platform offers (e.g. this is an example of many)
    – mreferre
    Commented Oct 1, 2021 at 6:43
  • Our approach - store image metadata on Reliza Hub, then Reliza Hub serves as a database which has information about approved images per each environment. Then you are able to query it with whatever tooling you choose and pull right image to the right environment.
    – taleodor
    Commented Oct 1, 2021 at 20:33

3 Answers 3

Reset to default
2

The 'best approach' in a theory (coming from the perspective of k8s) would be GitOps: Cloud-native Continuous Deployment. Your question lack some important information, how are you doing your deployments right now ? Do you have some limitations in terms of security and auditability ?

Sharing my personal 2 cents, using GitOps with ArgoCD outsource and guarantees the continious-running of all of your workloads(pods as an example). Argo will take care for them, even if somebody deletes a pod, it will re-store the previous number of pods, essentially maintaining the desired vs real state. Another benefit is that you could really easily track your appps by version, commit, tag ... you could even roll-back(this works only under a specific circumstance). Going in an example, by simply changing the image inside a pod spec in a directory that Argo keeps track of it is enough for the new version to be roll out as safe as possibble.

In our case we have a separate service (it's just a repo with tags) that acts as a wrapper for all the services, once we have a new release we deploy under a pattern of a directory layout and Argo catches it, everything is re/deployed automatically. The UI is great and they even expose a REST API.

Now once you have Argo(or some other tool), you get additional efforts in tracking the releases of the tool, versions, backward-comptability, helm metadata support, security, access, password rotations, best way to drop Argo in the cluster ... but this is another story that comes naturally, once you decide to go this path.

Improve this answer
0

We are using https://github.com/stakater/Reloader The work of the reloader is that when someone update the configmap/secrets then it will keep watch the deployment and it will automatically restart the deployments. This is the best way we have find out till now

Improve this answer
0

Still the most proper way is to update tags of your docker image and update yourapp.yaml script , there's no other way and then just kubectl -f yourapp.yaml. For this purpose GitOps is used. For me who has small cluster using something as ArgoCD is too much. I've went with Gitlab free service called AutoDevops which deploys read and tested docker container straight to your EKS.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.