I don’t really know tech differences/capabilities between Vagrant/ Docker / Bench, so I won’t go into that. But, from a user/admin (non-IT, sort of hobby-level admin ) POV I think the purpose of such “contained” deployment should be:
Ease of install, initial production-level config (AFAIK, this is already achieved using bench)
Ease of automate backup (this is also achieved using bench, I believe)
Daily backups should include all three data and config and extra modules installed (even custom ones)
So that, after a system disaster, you can install a new OS, new bench/docker/vagrant (name your pick), restore last working config and have the system up and running without (too) much hassle.
Any technology that allows a low-level geek (non-IT) to achieve all this (kind of) easily would be a hit.
P.S.: sorry if this is absolutely obvious, just bringing in the needs of a small company (which I believe are majority of ERPNext users/potential users). Not really complicated setup, not many benches, nor many sites… Ease of backup/restore after disaster is main concern.
“…The more varied deployment options available to developers of ERPNext the better.”
@abelinux true about small business being a targer group but there will be professionals offering implementation and hosting to those non IT literate businesses as well.
And it’s important for the ecosystem of ERPNext (which still seems to be relatively small (compared to odoo for example)) to enable such professionals building careers around ERPNext. Those people will drive ERPNext ro levels the coreteam will never reach on it’s own.
And a big variety of implementation method’s for mass deployment will be something such professionals will appreciate. Alone for that purpose developing a Docker environment will be worth the effort I believe.
@vrms Of course! I do see your point, and is obviously valid…
I’m not against any development on deployment options whatsoever… Even further: if anything, I support it, given that in the short run, we users might benefit from new install/maintenance options, and in the long run a wider ecosystem is a win/win situation.
But, as you stated, efforts towards developing this container might primarily be targeted towards professionals offering implementation and hosting, and most features would probably have such use case in mind.
What I meant to point out is that if this Docker/Vagrant effort is actually made, it’d be great if it could also include some features to make backup/restore as easy (and painless ) as possible.
Given this has not started yet, I thought it was good timing to bring this concern now: if planned ahead, perhaps it makes it easier for those implementing this to take both use cases into account.
I have had good succes with LXD/LXC containers. I am not a developer, and I am able to deploy a new instance very quickly with containers that I have built from remote images. I can easlly copy from one host to another, run Erpnext from the container, restore a backup etc. Apparely you can publish images from containers, and make your remote server public so that other people can use them, or build your own. It is quite easy to get up and running, without a lot of technical knowledge,since the concept is similar to VM’s, which most people understand, but its a lot more efficient. I can easily run on a portable with only 2 GB of RAM, which would not be enough for virtual box + VM’s. It might not be suitable for development, but I don’t know enough about docker or vagrant to compare. All I know is that it works well for my use cases which include evaluation, testing, demos, and disaster recovery.
Here are 12 blog posts that explain everything that you need to know about lxd/lxc:
(There is also good documentation available on the canonical site)
Once you have played around with it a little, you can just launch an instance from the Ubuntu: image site, to get started
Customize it to your taste - I install a standard user, webmin, and a few standard utilities like openssh for example.
This becomes my template on which I install Erpnext (and possibly other stacks which I might want to test or evaluate)
I publish some standard containers as images on my desktop and can access them from other machines, like a portable for example, or from outside
The concept is simiar to a VM, but much faster and more convenient. I have cheat sheets in evernote that I copy and paste from, since I wasn’t really a command line guy, but they work just fine
Hi All,
Our team (ridhosribumi) have finished renewing “erpnext docker” for erpnext version 7 from our “old erpnext-docker erpnext version 6”.
We use this docker for our company.
why have you chosen to use LXC and not Docker?
I found it easier to understand and get started. For example, there is nothing to “fund”. Maybe you can explain how I can use docker without having to rely on developers, since I am a user. But, like I said I can’t compare them since have never used docker. Does it require experience with development to make my own containers and images? Just sounds more complicated to me for my use cases
you treat your container just like a VM, no service separation, right?
I guess so since I don’t know what a “service separation” is
data also stored inside of the container?
Yes, everything is in the container, similar to a vm.
there is nothing to fund in docker neither. This thread talked about funding because the idea back then was to make something with separate services (and not all-in-one) which is [in the docker world] the promoted way to do stuff. And I saw clearly I couldn’t accomplish that myself, so I though maybe if more ppl where interest in such they could join to pay someone expert enough in Docker to set this up.
So funding is not required for Docker if you can do it yourself in general
you’d have a container for each service involved (i.e. Nginx, MariaDB, frappe, …). This might go as far as having a container for the right python version (2.7 here).
These separate containers talk to each other to serve an application (erpnext in our case) to your browser
This mainly seems to be of advantage when you run many instances of something or different Application which all use a database (which then can be accessed from one database Container for all different Applications)
Or you have 100 ERPNext systems … instead of running 100 Maridb Servers (as you would by just multiplying the all-in-one container/vm) they would acces their respective database all from the one Container running MariaDB
I am not expert enough to really judge what the pro’s on cons are, but in the Docker world this is very much what everybody seems to see as the way to go
Now, I have learned in this process as much as apparently ERPNext/Frrape seems not to be fit for a real service separation by design somehow.
In my opinion, the “work” needed is to document best practice to be able to launch a machine from start to finish (no interactive shell business inside the host-machine) and how to maintain security patches and a smooth way to update to latest stable erpnext .
Amazon Container Service (ECS) has this thing they call Tasks which can be used to setup isolated containers for each service (i.e. mysql, redis, frappe/erpnext, etc). Similar things could be achieved using kubernetes as well as a bunch of shell-scripts just running the docker commands one-by-one. Maybe an official repo with fine-tuned and well documented recepies for this might be the answer to something that seems to be one of the most commonly asked questions in the forums (from doing it manually to via docker or similar).
What would be of great help from the frappe-team though is documentaion for the following:
A basic system-overview of what each of our running services are doing, where we have persistant data (i.e. do we need to keep Redis AOF when doing maintenence/OS-updates), basically a suggested map of Docker volumes needed for user-uploads/attachments, relevant logs etc.
Suggested work-flow when updating erpnext / running migrations. Let’s say you’d use Amazon RDS to keep the data-store outside of the Docker instance, and maybe a S3 mount for uploaded files. Then our last challenge that needs a well thought out orchestration is when patching up the host OS or updating to a newer erpnext. We would simply spin up a new instance that would give us the latest ubuntu and frappe stuff, but for an instance used in production, we’d first have to terminate the running one so the data migrations can run safely. Here I think it would be great to split it up a bit so this could run as separate steps via the docker cmd’s… Would be great with input here.
Some good security tips on how to deal with password for the system and databases, passing those in separate from the scripts.
Bonus: but very useful. Separate docs + scripts on howto clone a database to a separate instance or locally running at an office machine where test-migration can run to avoid downtime on the production instance in case something unexpected would fail when running an update.
Thank you for the docker file. This is the only docker that is updated regularly on the docker hub. However, I’m still trying to figure out how to customize this docker file to separate the following components into different containers and connect them to each other.
hi @fblauer not sure whether you have noted that I forked this topic to an LXC/LXD topic (which I am looking at lately)
I’d be super curious to hear how you practically run your ERPNEXT on LXD. Especialy your updating/testing procedures and storage (database/attachments). If you have a minute and wouldn’t mind to share it there … that’ll be awesome
I’m trying to separate all services / parts into containers and parameterize with environment variables. If I manage to make it functional, I will publish the repository here to polish it, since I am sure something will be missing or broken. I’m not an erpnext expert but i will try do it
) POV I think the purpose of such “contained” deployment should be: