Continous delivery of frappe docker on kubernetes

ERPNext
1

I am currently building a bitbucket pipeline to build images of custom frappe apps with erpnext, I look into the frappe_docker GitHub - frappe/frappe_docker: Docker images for production and development setups of the Frappe framework and ERPNext and custom_containers repo GitHub - castlecraft/custom_containers and there are a lot of great work on these repos. I followed along with the documentation of Kubernetes, I made the same logic of the ci of GitLab and made it works with bitbucket pipelines. I have confused does the building process triggers the cd part or it is not included in these repositories, I am a newbie to the Kubernetes world and I need your help with the cd part so I can deploy it on GKE

Thanks

2

Integration:

Delivery:

  • Build images. Covered in various posts. You achieved it by reading docs.
  • Version. Use some kind of versioning for image. DO NOT use rolling tags like latest, version-14, v14. Use immutable tags like v14.14.0. Come up with versioning that suits your need. Bump up the version.txt of image each time you change anything in it. e.g. change in apps.json. Versioning of apps is different from versioning of image.
  • Make sure your apps.json changes or you will end up with cached image. If nothing else changes then only the bench init part of the image building will change according to apps.json. It means you need to bump up the apps.json with some kind of "branch". Either version tag, or commit hash. Assuming you use kaniko and set --cache=true.

Deployment:

  • Depends on platform and strategy.
  • For Docker swarm, portainer can be used for both push and pull strategy. GitOps with Portainer - Deploy to Docker using simple compose file - YouTube. Portainer also has webhooks.
  • For Kubernetes:
    • push is adding a secret KUBECONFIG or something like google-github-actions/get-gke-credentials access in your CI and executing kubectl rollout, kustomize or helm upgrade or script a combination of all tools. For AWS there is aws-cli and aws-sso, each provider will have their tool for cluster access that needs to be configured during CI run.
    • pull is using FluxCD or ArgoCD. Remains same across vendors. (Old repo needs updates, castlecraft / Fluxcd Starter · GitLab)
  • In general pull fits in even under VPN and secured environments where k8s or portainer api is not exposed for public access.
3 Likes