Official Docker container at Docker hub

[alexanderadam]

Hi folks,

thank you so much for your work. 🙏
I just thought it would be nice to have an official 🐋 Docker container for easier trying out plausible on a local machine or server.

See also nolt.io issue 56.

[ukutaht]

Thanks for opening the issue alex,

At the moment I'm working very actively on the product itself. I haven't made it easy to self-host because it's a lot of work and it would slow down development. Adding documentation for self-hosting and a Docker image is something I can see happening in the future but but I'm not going to address it immediately. Hope you understand.

[alexanderadam]

Hi Uku,

awesome, thank you for your fast response!
I wasn't expecting something immediately at all, so no pressure on that.
I just thought it would probably a good idea in general, so no need to rush. 😉

[tjomk]

@alexanderadam It is fairly easy to run the app locally if you have node and Elixir installed. It's based on my setup (I prefer to run database via docker and Elixir/Node apps locally). Here's a rough step-by-step:

1. Pull postgres docker container and run it: docker run -it --name plausible -e POSTGRES_PASSWORD=postgres -e POSTGRES_USER=postgres -e POSTGRES_DB=plausible_dev. If you have different database settings, modify config/dev.exs and look for the block that starts with config :plausible, Plausible.Repo. It defines database connection.
2. Install Elixir dependencies: mix deps.get. This should be run from the root of repository.
3. Run database migrations: mix ecto.migrate
4. Install frontend dependencies by going to the assets folder in the repo root and then running npm install.
5. Start the app: mix phx.server

If everything went well, you should be able to access the app via http://localhost:8000.

Although keep in mind that as Uku mentioned, there's more to just starting the app locally. You'll need to dig a bit into the code to configure other aspects like e.g. email, landing page, trial, etc. But that should also get you going and set up for exploration :-)

[alexanderadam]

Thank you for responding @tjomk,

I agree that this is fine for a development setup but a Docker container is obviously much easier for other environments. A properly tagged image allows easy rollbacks and updates. Also it wouldn't require to have all of the build dependencies locally available.

These are some reasons why other analytics alternatives can simply be tested/installed with a simple docker pull. They have all some official Docker containers available:

• https://hub.docker.com/r/electerious/ackee
• https://hub.docker.com/_/matomo
• https://hub.docker.com/r/usefathom/fathom/
• https://hub.docker.com/r/countly/countly-server/

[weyert]

Yeah, it's not easy to get this app running in Docker. Appears to ignore the environment variables during runtime. Only way to get it working is not to go for mix release and then run the release but get all the dependencies, build, at first start of the docker image.

[weyert]

I have made a pull request #53 which will introduce a docker-compose script which runs the development build. It's a start...

[weyert]

I am also made some changes here to make production build working: https://github.com/weyert/plausible/tree/production-release-docker

If anyone wanna try and help make it fully help that would be amazing. It's based on the Google Cloud dockerfile example

[weyert]

Any feedback @ukutaht?

[tckb]

@alexanderadam / @ukutaht / @weyert As I have mentioned in #53 (comment) I have a fork with "docker" ready configuration.

Fork: https://gitlab.com/tckb-public/plausible
Docker Registry: registry.gitlab.com/tckb-public/plausible:master-e2a7df36

It still needs a read-me description. I will add it in coming days. I plan to maintain this, ofcourse for my own personal use. @ukutaht When you have time, please do check it, I can create a PR to push in my changes.

[alexanderadam]

@tckb I like the changes you did. It looks well-thought-out! 👍
IMHO it would definitely be worth a PR.

Just one question: why did you switch away from the slim version?

[tckb]

@alexanderadam I've had https://gitlab.com/tckb-public/plausible/-/jobs/541156725#L2093 problem. Normally, this is usually due to missing packages in the base distro. This is why I avoid using the "slim" versions.

A reason why I moved away from alpine based images. This would be apparent when I add the image scanning stage (will do it in the coming days).

All in all, non-slim version is still at ~ 100Mb (the latest one is at 105.85 MiB).

[alexanderadam]

@alexanderadam I've had https://gitlab.com/tckb-public/plausible/-/jobs/541156725#L2093 problem.

Wasn't this rather solved because you added the line that installed webpack in the same commit? 🤔

[tckb]

@alexanderadam I haven't checked with just the installing ;) I did the changes together. I will check and add different images once I have all the other changes ready.

I would want to make few more changes before I officially open a PR, namely:

• Choose between Bamboo.PostmarkAdapter and Bamboo.SMTPAdapter
• Make Sentry Optional -It is good to have but, for a small personal hosting, this would require to have an account.
• Make Google client Optional - It is good to have but, for a small personal hosting, this would require to have an account.

there are more. I will add it once I have the changes in place

[ukutaht]

@tckb These changes would be awesome and welcome. I'm super happy to review stuff and merge upstream. I will make an effort to be more active in this discussion as well to help as much as I can with the time I can dedicate to this.

Here are some more things to think about when it comes to self-hosting:

• Billing/trial code locks people out after a 30-day trial if they don't have a subscription by then
• Email templates need to be reviewed.
• Some things are hardcoded, for example the script url is always https://plausible.io/js/plausible.js and the script fires to plausible.io/api/event. It's likely that there are more things that hard-coded but I can't think of any at the moment.
• I am introducing a second database for the stats engine. Account and site info will be in postgres, but the stats themselves are going to Clickhouse. There's a Docker setup for that in the .travis.yml file. This is very much WIP at the moment.
• Custom domain feature should be turned off for the self-hosted version. It will already be on a custom domain when you host it yourself. Not a big deal either, nothing bad happens if it ships with this feature but it just doesn't make sense to show it.

Some of these are not necessary for the first 'proof of concept' release but I just wrote a brain-dump of what I can think of at the moment.