etesync / etesync-web

An EteSync web client
https://www.etesync.com
GNU Affero General Public License v3.0
245 stars 29 forks source link

Add Docker Build #189

Open BeatLink opened 3 years ago

BeatLink commented 3 years ago

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.

BeatLink commented 3 years ago

Here's a link to my test dockerhub page, though ideally, it would be hoped to be migrated to the official etesync dockerhub account.

https://hub.docker.com/r/beatlink/etesync-web-docker

tasn commented 3 years ago

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 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.

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.

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. Additionally, does this mean this docker image sits here or elsewhere?

Could you remind me on Wednesday if I don't comment here until then? Will have a think... Thanks!

BeatLink commented 3 years ago

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.

tasn commented 3 years ago

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.

BeatLink commented 3 years ago

Well the alternative would be to build an omnibus package containing both the server and the web client and rolling everything into one

BeatLink commented 3 years ago

Which is what I was asking for in the first place hahahahaha :joy:

Ezwen commented 3 years ago

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 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.

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.

tasn commented 3 years ago

OK, I'm convinced. Just a few comments about the PR then:

  1. Can we make it copy the current directory and build it from that instead of from git?
  2. Can we make it copy package.json and yarn.lock before the rest and then run yarn install so that this part is cached?

Thanks!

tiritibambix commented 2 years ago

Hello. Does that mean there is no way to host etesync-web with docker ?

tasn commented 2 years ago

@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).

BadCo-NZ commented 1 year ago

@BeatLink any update on your progress or response to @tasn comments above?

I came here looking for a docker image of the web app after replacing nextcloud with etesync, looking forward to the containerisation! šŸ˜

BeatLink commented 1 year ago

Unfortunately, I'm not currently using Etesync right now

michael2to3 commented 1 year ago

I agree, I would like to just insert the docker compose file into deploy and work with the program