We’ve spent the last few months containerizing ERPNext and scaling it up to its full potential. What we got out of it are the current Docker Images and Swarm support. Since then, we’ve been working hard to step it up a notch by adding enterprise-grade orchestration.
Today, we’re excited to announce Kubernetes for ERPNext!
With this, you will now be able to infinitely scale and orchestrate your ERPNext instance by setting up a Kubernetes cluster on a provider of your choice.
This installation is an alternative to the bench setup and requires you to be familiar with Kubernetes and Helm. We’ve also replaced the bench and its core functionalities with Kubernetes Jobs.
For more information on getting started with ERPNext on Kubernetes, check out helm.erpnext.com. The charts are also available on the Helm Hub and ArtifactHub.
As of now, we only offer the latest stable version of ERPNext. There are no plans to add support for the older versions, or the development branch. For setting up versions not supported by us, please refer to the FAQs.
If you would like to contribute towards this project, feel free to raise an issue or a pull request on GitHub.
First of all congratulations! I am sure this was a ton of work.
I am really curious who is going to actually use this in production. Are you having any plans for this on any of the Frappe Pvt products (erpnext.com, frappe.cloud)?
I don’t quite understand this as the ability to spin up any version of ERPNext in an exact same way would be super useful. This feels a bit like turning around just one meter below the peak after a very long climb.
This is great addition to the rich feature set already available with Frappe/ERPNext. This will allow for unlocking the full potential of the framework and definitely help adaption at enterprise scale.
We have been using Dockerized Frappe/ERPNext for some time now and have been running production workloads on kubernetes for most part, without any issues. This has provided a lot of flexibility and has allowed seamless scale up/down without any manual intervention.
The overall rationale behind this and the approach was presented during the ERPNext conference 2019 - here is the recorded presentation.
Versions of frappe docker container project along with helm charts used are also available on GitHub here and here.
Congratulations to the team and the community. This will play an important role in adaption of the great framework.
Good going Team Frappe and Chinmay for spearheading this. It was long overdue. We truely feel that K8S & containerisation compliments the otherwise functional monolith of ERPNext and it just unlocks that monolith at fundamental runtimes/infra level.
We at Elasticrun have been reaping the benefits of these 2 best opensources (K8S and ERPNext/Frappe) for months now and it has saved a huge amount of admin efforts and provided good flexibility.
We would be happy to connect and share our learnings and tweaks … you can also reach out anytime to @ajit.pendse … who is the brain for making this happen at Elasticrun.
We do have documentation to help setup any version that is required. It is just that we want to focus on ironing out issues specific to containerization and orchestration before moving on to supporting more versions. We’d eventually want to get there, but it’s not in our plans right now.
I self host frappe-bench to use ERPNext and I build small, focused non-frappe apps and services.
I extensively use ERPNext ReST API for achieving this.
I already had kubernetes cluster, apps deployed on it and basic knowledge about the platform.
Because of this, ERPNext on Kubernetes made sense to me.
Currently my production sites and few staging/development sites for my customers are on kubernetes.
What I needed? What I Achieved?
Easy management of ERPNext sites on Kubernetes: New site creation, backup, push backups to S3 compatible storage and restore from cloud are basic operations required for stress free use of ERPNext.
Consistent and reliable deployments: Docker commands that are built into production containers are tested daily as well as on PRs. This ensures reliability and better ability to debug when things are not working on production. I have caught a few migration, site creation bugs and reported them to core team due to these automated tests.
Database on Cluster: As MariaDB can be installed on cluster in Master-Slave configuration, Reports generation can benefit from it.
Storage on Cluster: Single sites volume is shared across cluster as Deployment pods can be spawned on any node and share the sites volume.
Horizontal Scale for single “frappe-bench” like environment: Single “frappe-bench” needs to add or remove workers across nodes as per need. Use case where multiple apps concurrently fire automated request to ERPNext more than users using the system.
Easy access to logs and database for developers: Create kubernetes service-account/token for namespace, generate kubeconfig.yaml and revoke after use.
Why make it official vs keeping it third party?
I had my set of docker images and helm charts being built in CI pipeline. Shared here before.
Keeping it open but not on upstream is not beneficial for improvement of code and features.
Many more community members will review official PRs / git repositories over any third party code repositories.
Contribution to core will be used and improved by many people. Improvements are beneficial to everyone including me. Check the repositories, there are PRs and reviews by community contributors.
Last but not least, I can plug my company castlecraft for ERPNext + Cloud Native magic! Any opportunities are welcome!
Ok, then I got the "we do not have plans" part wrong. I guess you mean you actually have ambitions to support older stable versions as well, but will get to working on this only after the general construction works on the current stable branch.
Amazing work! These steps forward are why I went with ERPNext + Frappe over anything else.
After briefly reviewing the repos (both Docker and Helm Chart), will there be resources on how to install apps onto the K8s “bench” via Jobs? I see that both Frappe and ERPNext are almost two different deployments.
For custom apps you need to build a custom image. Refer custom-apps section of README.
Use the wrapper script install_app to install custom app. You can choose any base image frappe-* or erpnext-* depending on your app. ERPNext images are built using this wrapper script.
