ERPNext docker discussion

welcome to this discussion @ramantalkin

I am a complete novice with docker but what “they” recommend it’s to separate services and only run 1 process per container. Naturally such a single-service architecture is much less complex, but well I am not sure (without much knowledge of the matter as mentioned) whether it pays off to simplify things maybe on the wrong end.

To start a discussion …

  1. can you draw a line up to which load the one-in-all image architecture you prefer is still fine?
  2. if in the end we came to the conclusion that the single-service setup is most desirable … would you have the knowledge (and would be willing) to build such a complex structure?

@frahergal @alex_melkoff @ArtemBraga @mikhail.s sorry, to launching a blunt attack on you … I have noted that you @semilimes have started remarkable coding activities for the ERPNext universe recently (which I think has been welcomed highly in the Community).

Now the selfish part … I’d like to cannibalize on your expertize (which I lack) for a project I am a little stuck with. Feel free to just say ‘no’ if your priorities are different ones.

I am trying to get a docker micro service environment# going for ERPNext since a while but don’t see myself getting anywhere in the foreseeable future due to lack of expertize and time to gather such. Just a thought … would you be able and willing to assign some resources on this effort? I am sure the ERPNExt ecosystem would greatly benefit from it and maybe for someone who knows his docker it’s not even such a big thing to create.

#with `micro service environment’ I mean separate containers serving only one service bundled together with docker compose (or maybe Vagrant which seems to be popular here) to serve ERPNext to the user. I think those would be MariaDB, Nginx, redis, python 2.7, ERPNext, … plus some datacontainers probably

Hello @vrms! Thank you for your kind words about Semilimes activity. I would like to share my opinion about docker and microservices architecture.

As a developer I absolutely love concept of microservice architecture as it allows to build complex, stable and easily maintainable applications. Docker is a great tool that helps to manage such applications and provides clean, top notch solution for deployment.

I would be happy to see docker-based microservice solution for ERPNext and Frappe but unfortunately I think that it’s currently imposible to achieve. Microservice architecture is software development pattern, not just a feature of docker. In order to be be packaged to separated docker containers application’s architecture should be designed in such a way that allows that separation. And I think that it’s currently not true for ERPNext and Frappe. Maybe I’m wrong, I have only basic understanding of Frappe’s architecture so far.

It would be nice to see some comments from Frappe’s developers about that. They are the only one who can break down the whole stack into microservices.

1 Like

thanks @alex_melkoff for your feedback. I am not sure whether you are right about ERPNext being the monolithic block you suspect it is.

If you look at the manual install instructions you can at least clearly see which components it is build from (you are probably aware if those). I would assume it should be possible to have those function together as separate services should be possible.

In this topic ERPNext in 2014 and in 2016 - #9 by chlarsen such separation (not docker specific though) is being discussed (and at least partially solved) I think.
@chlarsen @anand where the main contributors to that issue. Can you two maybe share some insight on the separation of services here?

Actually, existence of this topic about redis quite vividly illustrates my point.
Configs are all over the place, sometimes hardcoded here and there, a lot of undocumented behavior under the hood… This partially achieved solution you were talking about looks more like a hack and proves that Frappe’s architecture was not intended to be used like that. And it’s just redis: we also have SocketIO and Celery workers…

We have solved the hardcoding problem in our new install logic:

We set default values for various ports, but you are free to change them via common_site_config.json

Even before this, only the socketio port was hardcoded. The rest were configurable.

Frappe/ERPNext’s installer was designed for a novice user to get started quickly. But we neglected the advance user. So, if you can start a single thread about manual install, I can pitch in and then the community can build a readme about manual install?

1 Like

@alex_melkoff I was afraid you where going to say something like that. Does the response from @anand change anything in that light?

@vrms well, readme about manual install would be very helpful, that’s for sure. However I still think that solution based on microservices is a question of system architecture and it’s up to developers to provide that. Maybe I’ll give it a try some time, when I’ll be more familiar with Frappe/ERPNext. For now it seems to me that it will require some deeply invasive actions.

Basically, there is a file called “Procfile” in bench directory and it contains list of processes to be run on “bench start”. For multiservice solution we should be able to safely configure and run each process (+ nginx as reverse proxy) on different machines. I would also prefer to have RESTful API as a separated microservice.

@anand I found an article about high availability for ERPNext. There is a section called “The Ideal Architecture”. Do you think it’s possible to achieve that setup with current version of Frappe/ERPNext?

@alex_melkoff it is possible to run everything on different machines, but we haven’t tried it

@anand, sweet! Is it safe to decouple and web server into different machines? How and web server interact with each other?

socketio and webserver interact using redis and http requests: frappe/socketio.js at develop · frappe/frappe · GitHub


But yes, there’s a problem. It looks for configuration files in a particular folder: frappe/socketio.js at develop · frappe/frappe · GitHub

@alex_melkoff thanks so far for engaging in this discussion (also thanks @anand)

Even though the technicalities are beyond my level understanding it seems this is a little more tricky then imagined.

How about taking an Agile approach? I mean looking at which services are easy to separate right now, separating those and leaving the rest of the pack in a remaining ERPNext image rather then putting efforts to halt until the ‘big solution’ is possible?

something (just from the top of my head) like …

  1. MariaDB
  2. Nginx
  3. ERPNext (incl. all the rest needed)

wouldn’t that be a way to make progress right away even if the ideal case can’t be achieved yet?

Naturally the simple approach of the ERPNext setup makes sense on some level and therefore shouldn’t be abandoned. Still I think that aiming at being able to separate services (and putting a dockerized environment in place) might be something to pursue (and with such also maybe start at opening new possibilities for deployment scenarios.

Is docker-frappe/Dockerfile at master · donysukardi/docker-frappe · GitHub a good starting point? It uses Alpine Linux as base image, but MariaDB is built-in rather than linked from an separate container.

1 Like

Just general good reads for the ones who wanna know more about Docker in development:

Oh and for your amusement about Docker in production. :slight_smile:


@ganas that was epic :laughing:

CC @anand @pdvyas @vjFaLk




I have just tried this with success after a lot of wrangling. The images haven’t been updated in a couple of month so the latest version is still version 7 in beta, but I was able to make it work with each service in a different container (with the multi-container images based on alpine).

I’m having a problem to update the image right now because bench update --ugrade expects to have access to the redis-server which isn’t the case in a multi-container setup.

I got around the bench update --upgrade redis error by emptying the /home/frappe/bench-repo/bench/patches/patches.txt file for now.

We are going to start to build some containers for this in our hosted environment. It will be on openshift origin so when it is done i will share the repos with you guys. They will be a centos base. I am also thinking of using this too GitHub - africlouds/erpaas


@woakes070048 have u tested saas app?