Create an easy-install Docker image

atjn commented 1 year ago

I would like to create a Docker image for OwnTracks where everything is pre-installed and setup. We talked about this in https://github.com/owntracks/talk/issues/127#issuecomment-1096792270 as a way to make the barrier of entry much lower for new OwnTracks users. I am personally interested in it because I want to use a setup that I know has no security vulnerabilities (see https://github.com/owntracks/talk/issues/146#issuecomment-1205272152), and making an official implementation allows everyone take a look and see if they can find any vulnerabilities that we need to fix.

For this package to be useful for less technical people, it needs to be easy to find and use, it needs to be well supported now and in the future, and it needs to look "official" and safe to use. To satisfy those requirements, I think we need to:

Mention the package in the booklet and in other OwnTracks documentation, to make sure people are aware that it exists and understands that it is the recommended solution for less technical people.
Create a thorough guide in the booklet (or modify the existing) which covers basics for how to set it up.
Add its GitHub repository to this organization, and publish the package under the official OwntTracks profile. (this requires allowing me to publish updates to the Docker profile)

I am willing to do most of the work to make this happen, but you obviously have to permit that I make those changes, and give me access to the org/repo and Docker profile. I am also curious to hear if you have any other thoughts or ideas for this concept.

As a last note, I expect to update the Docker image for many years to come, but I cannot make any hard commitments, which is another reason that I want it to be published officially by OwnTracks - so that other people can take over and maintain the support if I stop doing it.

atjn commented 1 year ago

I have started prototyping it in https://github.com/atjn/easy-owntracks

jpmens commented 1 year ago

Thank you for the suggestion which will be discussing (hopefully) towards the end of the week.

compuguy commented 1 year ago

I took a quick look at that repo @atjn. Out of curiosity, is there a reason that everything is running in one docker container versus just using the existing containers that Owntracks puts out + build/deploy the authelia container?

atjn commented 1 year ago

@compuguy thanks for taking a look! The goal is to make the package as simple to install as possible. Asking people to install and configure three separate Docker images is a lot of installation, and will put it out of reach for a large percentage of users. It also makes it harder for me to make the software run the way I want it to, so I see it as a win-win to consolidate them into a single solution.

compuguy commented 1 year ago

Based on my experience with docker compose, one can define multiple services/images in a docker-compose.yml file. All you have to do is define where the image comes from or how it's built + run 'docker compose pull'. If one isn't taking advantage of the modularity and containerization of Docker...there's really no need to use it then. Instead I would just deploy it directly on the instance. That's just my $0.02 as a Integrator & DevOps engineer who does this for a day job...

Edit: typos (curse you phone autocorrect!)

kfdm commented 1 year ago

I'm also coming at this as an outsider, but often putting multiple services in a single docker file is not recommended so something like a docker-compose file would likely follow the recommendations better, and still mostly be a single command from the end user's perspective.

atjn commented 1 year ago

I am happy to discuss this to make sure we do the right thing from the start. I am not a Docker expert, so maybe you have some counterarguments to the following:

Support

We can all agree that docker-compose is great, but for many user-friendly services, it is not supported. Say for example you want to run it on a Synology NAS, you need to follow this wild guide, which basically tells you to do all the things that the NAS doesn't support. The same can be said for the common frontends that are available for Docker and Podman. None of them support docker-compose.

Therefore we are back to the argument that a single container is much easier to set up than three.

Updates

I want to nudge people to update their installs, and this is not an easy task for the average people in Docker. How do we make sure that the different containers are using versions that are compatible with each other? What if authelia updates to a new major version, and we have to change the way we communicate with it, but we either haven't released a version that supports it yet, or we can't because we need to also keep backwards compatibility? What if we change to a different service?

This is all solved by having a single container that is only updatable as a whole. It could also be solved by docker-compose, but I can guarantee you there will be hundreds of people asking why their update failed, because they used a different update mechanism.

Non-Docker solutions

I have looked into publishing it on 1-click solutions like droplets. These generally require a single ISO to run, so it would be much more streamlined to have a single container for that purpose.

Other stuff

@kfdm

putting multiple services in a single docker file is not recommended

I would argue that owntracks is a single service for the end-user. If you want to set up your own custom system, then it becomes a set of different services, but the point of this easy-install solution is to cater to people that just want it to work, regardless of what runs in the container. You could also say that the recorder container is a set of different services (frontend, API, ocat, database), and that those themselves are build up of different packages and services.

@compuguy

If one isn't taking advantage of the modularity and containerization of Docker...there's really no need to use it then.

We want to allow people to use this on any machine with any OS/distro/package-manager/whatever. If we don't package it as a Docker container, we will have to support different versions of jq, curl, caddy, authelia to name a few, and we will need some sort of monster installation helper that can detect missing/unsupported dependencies and guide the user on how to install it. This would need to have custom guides for Windows install, Mac install, apt, pkg, rpm, packman, so forth. We would also need to publish packages for all those package managers. I would rather publish a single container and let Docker deal with the rest.

growse commented 1 year ago

@atjn I think this is a great idea. Anything that makes life easier for people to get started is much appreciated. When you get to the point of being ready to accept issues / comments on https://github.com/atjn/easy-owntracks, let us know and we'll start poking around with it.

Based on my experience with docker compose, one can define multiple services/images in a docker-compose.yml file. All you have to do is define where the image comes from or how it's built + run 'docker compose pull'. If one isn't taking advantage of the modularity and containerization of Docker...there's really no need to use it then. Instead I would just deploy it directly on the instance. That's just my $0.02 as a Integrator & DevOps engineer who does this for a day job...

As someone who also does this for my day job, I know life is never as simple or clear-cut as that. :)

Don't get me wrong, docker-compose has enormous value, and the principle of "one container should do one thing" is great if you're planning on operating each component separately (with its own lifecycle etc.). However, not everyone is. Personally, when I go to a new project for the first time, I'll take "Run this docker container" over "Run this docker-compose script which will startup an unknown number of containers" every day of the week.

I'm also coming at this as an outsider, but often putting multiple services in a single docker file is not recommended so something like a docker-compose file would likely follow the recommendations better, and still mostly be a single command from the end user's perspective.

Who's making these recommendations? The S6 folk hard disagree (https://github.com/just-containers/s6-overlay#the-docker-way), so I think the only statement we can apply with certainty across all user scenarios is "It depends". As @atjn has already noted, docker-compose is hard/impossible for some deployment scenarios.

There's definitely value to having both, because different people have different needs and trade-offs. If someone wants to put a docker-compose manifest together, I'm all for it.

jpmens commented 5 months ago

We've created a Quicksetup which configures an MQTT server, our Recorder and Frontend with all bells and whistles as well as a configurable list of friends. Not docker as some of us think this has a lower entry barrier.

atjn commented 5 months ago

Thank you, that looks very cool! I still plan to continue work on the docker image, as I think I can add more functionality and improve the barrier to entry even further. I have not worked on it for a while because I have been busy with other projects, but I still plan to finish it :)

owntracks / talk