Feature: Docker image

[erikhofer]

It would be really helpful if this project was released as a Docker image.

[peter279k]

I also think the Docker image is nice to publish on the Docker hub.

And the Docker image can be used on Travis CI build.

[C-Duv]

What are the benefit of releasing a Docker image for this "agent"?

Don't get me wrong, I'm usually all in for Docker images, but for this piece of code whose sole goal is to be installed along-side a website (acting as a proxy between the HTTP client and the Matomo server) I don't see how/why run it into a Docker container could be useful.

On the other hand, with a composer package (see #48), I do see the benefit.

[erikhofer]

@C-Duv Not all websites use PHP. I wanted to use this in a containerized application and would have had to create my own Docker image and maintain it (by updating through git). It has the same benefit as a composer package but technology-agnostic.

[C-Duv]

As I said, I want to be proven I am wrong.
I don't see how running this proxy in a container is useful so if you could explain it to me.

You got a point though: no all sites uses PHP, so you don't always have a PHP interpreter available.
So you want a PHP interpreter in the container? I guess you also want a web server (to serve the files to HTTP clients), or you could use CGI.

How would you route the specific HTTP queries for http://trackedsite.com/matomo.php to this container?

Would you have one container by website you want to track or would you "share" a container with multiple websites?

[erikhofer]

I'm not exactly sure why I wanted to use this a year ago. I think I ended up making my Matomo instance available under multiple domains because there was no Docker image. But the proxy with OAuth would be more flexible. The benefit is simply that you can use this proejct outside of PHP sites.

Yes, the image has to have a webserver and PHP interpreter. This is just a matter of using the right base image.

The routing depends on the reverse proxy that is used. On my simple Docker host, I would configure Traefik to route everything under /matomo to the container. Or use a subdomain matomo.trackedsite.com as I do now. But this will of course be different on Cloud/Kubernetes/etc.

Also depends, but I think I would use one conatiner per site and make it part of the Docker Compose stack (or similar in other environments).

[PatrickHuetter]

+1 for a docker image. Same use case here. We don't use any kind of PHP applications in our stack. We also use kubernetes as main container orchestration. With a docker image we could easily provision the tracker proxy as sidecar container to the pod of the website project we want to track. It would be also possible to just start it standalone and proxy every matomo request through the ingress-controller (reverse proxy) to the tracker proxy.

The docker container should contain an integrated webserver with php support and should be configurable via environment variables.

/Update/ Kubernetes users might be able to use ExternalName Services in combination with some Ingress config to forward matomo requests from one ingress to the matomo service url. Some examples here: kubernetes/ingress-nginx#4280 (comment)

/Update2/ I created a small docker nginx php fpm image with php-8 and matomo tracker proxy. You could just use this as sidecar container or container in your stack and forward the relevant requests from your ingress to this container.
https://gitlab.com/encircle360-oss/container-images/-/tree/main/matomo/tracker-proxy

[patrick-boisen-smtdata]

+1 for a docker image. Our architecture does not include PHP at all. It runs on AWS with a bunch of different things running behind an API Gateway and the tracked site itself consists of static files served from a CDN.

If we have to build our own docker image, it gets tied into our security and compliance requirements in a different way than using an "official" container.