Docker

[Th3Whit3Wolf]

I would love to make a pull request but I'm really not quiet strong with the Dockerness. I think having a Dockerfile, docker-compose.yml, and an official docker image might make it easier for certain people to use and work on goatcounter.

[arp242]

I'm not a huge fan of Docker, and to be honest don't feel like installing it, maintaining a Dockerfile, dealing with support requests, etc. There are only so many hours in a day, and I don't see how this improves the quality of the product. I also feel it's rather superfluous for a project like this, as it's not a Rails project with loads of dependencies or some such

For local dev, just using go build seems much easier to me, and if you want to use Docker for your production, then it's really easy to set up a basic Dockerfile.

If someone else wants to maintain all of this, then I'll happily link it though.

[sent-hil]

I was able to get it working in docker, pushed the Dockerfile here: https://github.com/sent-hil/dokku-gocounter. It assumes you are using dokku and postgres.

Also found https://github.com/baethon/docker-goatcounter.

[anarcat]

the problem with not publishing a Docker container yourself is exactly what seems to be happening now: a bunch of people will roll their own and your users will not know which container is to be trusted...

Would you be open to accepting a PR that would add a Dockerfile to this repository, possibly bridging it with Docker hub?

The advantage of Docker in my case is that Golang packages do have tons of dependencies. They're hidden by that convenient static binary, but I kind of prefer to run those in a sandbox (e.g. Docker) than directly as my regular user. And therefore it's nice to actually build from source while I'm there. ;)

here's my own take on it:

https://github.com/anarcat/goatcounter/blob/Dockerfile/Dockerfile

[arp242]

the problem with not publishing a Docker container yourself is exactly what seems to be happening now: a bunch of people will roll their own and your users will not know which container is to be trusted...

I don't think that's a bad thing; people can just write their own Dockerfiles and be responsible for their own environment. You don't really need to trust some stranger's setup.

Would you be open to accepting a PR that would add a Dockerfile to this repository, possibly bridging it with Docker hub?

For context, I've written a bit more about this over here: #130 (comment)

[anarcat]

I don't think that's a bad thing; people can just write their own Dockerfiles and be responsible for their own environment. You don't really need to trust some stranger's setup.

I guess that's true, and that's often how I use Docker, but in my experience people just blindly trust whatever hub.docker.com gives them... ;)

So you'll effectively end up with support requests from deployments you have no control over... but I guess that's on par for the course with free software anyways. :)

For context, I've written a bit more about this over here: #130 (comment)

... and in there:

So what I'm afraid of is that someone will add it, and then disappear after a few months (which is perfectly fair), and then I'm "stuck" with this Dockerfile and people asking me "I get this vague Docker error, please help!" or "How do I do X in with Docker?"

Sounds like pretty much exactly what I'm proposing here. :P That said, I'm working with the Dockerfile I wrote there and it works pretty awesomely well, I have to say... ;)

Thanks for the context...

[ItalyPaleAle]

I don't think that's a bad thing; people can just write their own Dockerfiles and be responsible for their own environment. You don't really need to trust some stranger's setup.

Well, this is the issue in my opinion... There are 2 reasons why I use Docker (and I'm hopeful I'm not the only one):

1. To simplify the deployment of applications. I know Goatcounter is a single binary, but it's still much simpler to pull a Docker image that is known to be working and ready to roll. It's also easier to properly segment your apps (so Goatcounter can't communicate with another application on the host directly), secure the access to the database, and even configure the proxy (with Traefik running, exposing a new app is as simple as adding a label to your running container).
2. To simplify management of the application. For example, I could tell pin to Goatcounter version 1.x and just run a "docker pull" to automatically get the latest version of the application, if any, and as long as the app follows semver and contains the required upgrading scripts and runs them, it just works.

Having a container (published by anyone) helps with point 1, although you need to trust whatever container you're running. Having an official container is usually the only way to ensure point 2, meaning ensuring that as soon as a new version of Goatcounter comes out, the container is updated.

It doesn't necessarily need to be a lot extra work... If you could set up continuous integration, the container would be built automatically!

[anarcat]

Having a container (published by anyone) helps with point 1, although you need to trust whatever container you're running. Having an official container is usually the only way to ensure point 2, meaning ensuring that as soon as a new version of Goatcounter comes out, the container is updated.

I guess that's my situation as well. I use Docker as an alternative packaging solution when no Debian package is available...

For the record, I have filed a Request For Package for it, but the large number of dependencies will make packaging it a little harder than others...

[arp242]

Well, this is the issue in my opinion... There are 2 reasons why I use Docker

Sure, and that's all perfectly fine; but there's a difference between people choosing to use Docker vs. spending quite a bit of time in explicitly advertising it as supported. I'm fairly sure that GoatCounter will work on NetBSD, but if someone comes at me with a weird NetBSD error then it'll be a "yeah nah, not sure". I'll gladly fix stuff for NetBSD if need be, but I also don't have the resources at this point to spend a lot of time figuring out NetBSD errors.

In my experience setting up a CI (and fixing it when it will inevitably breaks) can be quite a time-sink.
I really try to prioritize quite aggressively on things at the moment just because there's only so many hours in a day 😅

As I mentioned a few months ago: if people want to make and maintain a Docker repo then I don't mind adding it. But the key part is in the "and maintain" part (and even then it'll be extra work for me, I spent some time this week debugging the Gatsby integration someone else wrote; it wasn't really clear the problem was there from the outset).

---

Re: Debian issues:

You can try dh-make-golang estimate zgo.at/goatcounter @anarcat; you should always use that path and never the GitHub one.

It looks like that dh-make-golang program builds stuff in GOPATH mode by the way, rather than Go module mode. You need to be careful with this, as just go get will ignore the versions in go.mod, potentially leading to breakage (has happened with go-sqlite). The dh-make-golang program doesn't seem to reference "modules" or "go.mod" at all 🤔

Also, what's Debian's support policy these days for packages? As I understood it back in the day (as a friend explained it to me back then) once you get "version X" in a Debian release it was pinned to that version (except bugfixes) for 5 years. Not sure if that kind of policy is a good fit for GoatCounter at this point.

[anarcat]

re zgo.at: ack.

Also, what's Debian's support policy these days for packages? As I understood it back in the day (as a friend explained it to me back then) once you get "version X" in a Debian release it was pinned to that version (except bugfixes) for 5 years. Not sure if that kind of policy is a good fit for GoatCounter at this point.

As for that, the release schedule is a bit faster, but it's similar: no fixes but critical or security fixes in stable releases for their lifetime, which are around 3 years these days. That said, that's only for stable releases: "unstable" and "testing" are "rolling releases" (so to speak) that are updated as needed. It's trivial to keep a package to enter "stable" (file a critical bug to block it from entering) and is frequently done to keep cutting-edge packages from being shipped in stable releases, while still allowing "unstable" users to enjoy the marvels of new stuff. :)

So yeah, don't worry about Debian, we've seen it all, but it's good to voice your opinion about stability garantees as Debian is kind of a good test for that... ;)

[arp242]

It's trivial to keep a package to enter "stable" (file a critical bug to block it from entering) and is frequently done to keep cutting-edge packages from being shipped in stable releases, while still allowing "unstable" users to enjoy the marvels of new stuff.

Alright, coolio 👍 GoatCounter is still in fairly early days and while it's "stable" in the sense of "reasonably bug-free", it's not really stable in the sense of "gets a lot of large changes". At this point, shipping it in Debian stable would probably more of an inconvenience to users than anything else. I do plan to do "LTS" releases or some such at some point, but I do have a "minimal feature" checklist in my head I want to do first.

[anarcat]

At this point, shipping it in Debian stable would probably more of an inconvenience to users than anything else. I do plan to do "LTS" releases or some such at some point, but I do have a "minimal feature" checklist in my head I want to do first.

Understood, I'll make that more obvious in the Debian side of things. In the meantime, I do recommend you state that more obviously in the README or in the program's documentation, because I was under the impression that goatcounter was LTS ready because of the apparent use of semantic versionning. :) In other words, because it's not 0.x, I thought it was ready. ;)

[anarcat]

You can try dh-make-golang estimate zgo.at/goatcounter @anarcat; you should always use that path and never the GitHub one.

I have tried that and it works slightly better. There are 6 dependencies (outside of zgo.at) missing from Debian, unless we count geoip2-golang which is a fork from upstream (and can hopefully be resolved). We should probably vendor the remaining 16 dependencies in the zgo.at namespace, unless those are known to be actually be in use outside of goatcounter...

Thanks!

[arp242]

I was under the impression that goatcounter was LTS ready because of the apparent use of semantic versionning. :) In other words, because it's not 0.x, I thought it was ready. ;)

Most programs (1.0 or otherwise) aren't usually supported for 5 years. That's probably quite rare and only done for comparatively large projects? I don't think it's especially common for projects with just one main author and a few patches from contributors 😅

As for the dependencies: I'd just build it from the go.mod?

[anarcat]

Most programs (1.0 or otherwise) aren't usually supported for 5 years. That's probably quite rare and only done for comparatively large projects? I don't think it's especially common for projects with just one main author and a few patches from contributors sweat_smile

The point is not necessarily that the upstream author has to do the maintenance, but that there is a way for downstream distributions to contribute to that in a meaningful way. If upstreams follows semver, then downstream can (say) fork off 1.3.1 and build their own 1.3.2 and even contribute it back upstream for everyone to enjoy.

Of course, in practice, that rarely happens, as collaboration between upstreams and downstreams is never that good, and upstreams are rarely interested in maintaining their project that long, as you correctly point out. :) But it's the theory at least...

Also, it's not 5 years. :) It's more like 3:

https://wiki.debian.org/DebianReleases

I find it kind of funny that Debian has this reputation of maintaining stuff forever, when the longest supported release (excluding LTS, which is unofficial) was four years, which was released in... 2002! Since then, every release has been supported for at most 3 years, at first by accident, and then by policy of the release team.

Compare this with Ubuntu, often thought of as a "fast paced" distribution:

https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions

They push out a new release every six month, that is supported until the next, but they also have LTS releases which are officially supported... for 5 years! (And extended support for 8 or even 10 years sometimes!) Also keep in mind that most packages in Ubuntu come from Debian, with a delay, so you have an even worse problem to manage there, if you worry about things like that...

Anyways... maybe that's where the confusion comes from? ;)

[ForestJohnson]

fwiw this is my basic docker file, I did not bother with setting up users inside the container because I'm using the docker userns-remap feature. I referred to https://www.arp242.net/static-go.html for the build flags. IDK what im doing i just want it to run on ODROID XU4.

FROM golang:1.16-buster as build
ARG GOARCH=
ENV CGO_ENABLED 1
ENV CC "$CC"

RUN mkdir /build
WORKDIR /build
RUN apt update && apt install -y git build-essential
RUN git clone -v https://github.com/zgoat/goatcounter
RUN cd goatcounter && git checkout v1.4.2
RUN cd goatcounter && echo "CC=$CC" && go get 
RUN cd goatcounter/cmd/goatcounter && go build -tags 'sqlite_omit_load_extension osusergo netgo'  -ldflags='-extldflags=-static'  -o ../../../goatcounter_binary -v .

FROM alpine
WORKDIR /app

RUN apk add --update --no-cache tzdata alpine-conf  && setup-timezone -z UTC
COPY --from=build /build/goatcounter_binary /app/goatcounter
RUN chmod +x /app/goatcounter 
ENTRYPOINT ["/app/goatcounter"]
CMD ["help"]

This is how I build a multi-architecture image for it: https://paste.cyberia.club/~forest/0c8c7a7ddbb58d6da779ccd858dec43af3eeeae1

Note that my build script modifies the docker file a bit per GOARCH setting:

...blahblah...
sed -E 's/GOARCH=/GOARCH=arm/'   -i dockerbuild/Dockerfile-arm
sed -E 's/build-essential/gcc-arm* build-essential/'  -i dockerbuild/Dockerfile-arm
sed -E 's/CC "\$CC"/CC "arm-linux-gnueabi-gcc"/'  -i dockerbuild/Dockerfile-arm
sed -E 's|FROM alpine|FROM arm32v7/alpine|'   -i dockerbuild/Dockerfile-arm
....

Not perfect but seems to get the job done...?