-
-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Docker Build #189
base: master
Are you sure you want to change the base?
Add Docker Build #189
Conversation
Here's a link to my test dockerhub page, though ideally, it would be hoped to be migrated to the official etesync dockerhub account. |
I don't think it's the same thing. The server is actually complex, comes with deps, configurations and etc. The DAV bridge stores some data internally and comes with deps too. To be honest, the docker image was created before we had pre-built binaries. Not sure if we would have done it if we already had binaries. Web, on the other hand, is really just a bunch of files that we already package and sign pre-built, as well as offer the option to build yourself.
This is a very good point, because even though I don't agree with the need, you are not the only one that wants a docker container and having an official one will therefore be better. The question is then: what about etesync-notes? That should probably also be in the same docker container, no? How should it work? Different ports? I'd rather not have different paths because I don't want to commit to supporting that in the images. Could you remind me on Wednesday if I don't comment here until then? Will have a think... Thanks! |
Well we could do like etesync dav and store the dockerfile for each application in the source code repo itself. And each dockerfile would build each specific app rather than bundling the different applications together in a single dockerfile. That way we follow the docker philosopy of one service, one container. |
Yeah, but this is not really a service, it's just files. :P It would just be a pity if people would need to run two containers, and two local nginx instances just to serve a few static files. |
Well the alternative would be to build an omnibus package containing both the server and the web client and rolling everything into one |
Which is what I was asking for in the first place hahahahaha 😂 |
Hi there! Just wanted to mention that I was indeed surprised to not find any official Docker image for etesync-web, and that imho it would be great if there was one. I personally user docker for 100% of the services I host, so that would make things really easier in my case :).
It's true that with docker we tend to spawn lots of nginxes in different containers for various web services − even static ones such as this one − which can be perceived as a waste. But nowadays this is rather well accepted since nginx only has a tiny footprint, and since it makes managing web services easier, when each lives its own process, each with its own nginx or apache version, each with its own configuration. |
OK, I'm convinced. Just a few comments about the PR then:
Thanks! |
Hello. Does that mean there is no way to host etesync-web with docker ? |
@tiritibambix, it's just a static website, you can just build it and host it. You don't really need docker for this (though you can). |
Unfortunately, I'm not currently using Etesync right now |
I agree, I would like to just insert the docker compose file into deploy and work with the program |
This should reopen the pull request to add the docker build.
I understand that you are reluctant to take on the packaging for docker as the web client is nothing more than a bundle of static files. But this docker is very simple, All it does is pull the latest version of the web client from git and build it in a node docker container, then copies the built files from that build container into an official nginx container. It will require little to no maintenace.
In addition, seeing as there are docker images for both the server and the dav bridge, it would make logical sense to have one as well for the web client. This would fulfill that role.
I am willing to take on maintenance for any bug reports or feature requests for the docker package. All you have to do is assign the relevant issues to me.
I just really wish to see an official web client image that users can use and trust. The dockerfile would be in the codebase for all to see and verify for themselves and it would simplify installation and self hosting.