Added Dockerfile suitable for DockerHub Auto-Builds

[dcwangmit01]

Hi @fstab,

This PR adds a Dockerfile for grok_exporter which builds an alpine linux docker image which contains a statically compiled grok_exporter binary. This should be suitable for DockerHub Auto-builds. If you wanted, you could go to dockerhub and create a connected public repository with the following build settings which will auto-build a "latest" docker image upon master branch changes, and auto-build a "vX.Y.Z" docker image upon repo tagging.

Thanks!
-dave

[coveralls]

Coverage remained the same at 70.047% when pulling 1f0ddb1 on dcwangmit01:dockerfile into 7ae298d on fstab:master.

[fstab]

The release.sh script uses fstab/grok_exporter-compiler-amd64 for building Linux amd64 binaries, which is maintained on github.com/fstab/docker-grok_exporter-compiler. Could you use fstab/grok_exporter-compiler-amd64 as the builder? Then I need to maintain only the existing Dockerfile for Linux builds.

[dcwangmit01]

@fstab Are you essentially asking me to replace lines 4-18 in this PR's Dockerfile with?

FROM fstab/grok_exporter-compiler-amd64 as builder

I just wanted to clarify.

Thanks!

[fstab]

Yes, that's what I mean.

[rustycl0ck]

Any update on this?
Docker image would be useful if built from here.

[dcwangmit01]

@rustycl0ck I took a look a few months ago. It's not as easy as swapping the FROM image, since the image being requested is redhat-based as well as quite old (Centos 6). Centos 6 is so old... that I think that backporting would not be worth it, since the docker build with the Dockerfile in this PR already works with the latest Debian LTS.

It's definitely doable. Just need to find the time to fix this as the maintainer expects. Still on my TODO eventually list.

In the meantime, I'm using the 0.1.0-webhook image here

[fstab]

The reason why the Linux build is using the old CentOS 6 image is that if you build it on newer Linux versions, grok_exporter will be linked to GLIBC_2.14 or newer. There was at least one user who was stuck on an old RHEL system that didn't have GLIBC_2.14, so I switched to the old CentOS to be compatible with older GLIBCs. See comment in https://github.com/fstab/docker-grok_exporter-compiler/blob/master/Dockerfile.amd64

If there are any issues with the old CentOS image we can consider updating. However, I don't see why the old image would cause problems. Is there anything specific that speaks against keeping the old image? As long as there are no problems with CentOS 6 I think we should keep it for compatibility.

[dcwangmit01]

@fstab That's interesting. That user must not be using the docker image, which would have those library dependencies.

FYI, the docker image that's built in this PR creates a statically-linked grok_exporter binary. It doesn't rely on any system shared libraries. I don't know if this fact would make a difference for that specific user.

$ docker run --rm  -i -t --entrypoint "/bin/sh" dcwangmit01/grok_exporter:0.1.0-webhook
/app # apk add file
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.9/community/x86_64/APKINDEX.tar.gz
(1/2) Installing libmagic (5.36-r0)
(2/2) Installing file (5.36-r0)
Executing busybox-1.29.3-r10.trigger
OK: 11 MiB in 16 packages
/app # file /app/grok_exporter
/app/grok_exporter: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, Go BuildID=Yu5K3I48JksO5ydxUaB5/pmdp9jlxvCePWJKhup1K/HUW3zCiA3LOFD9icjE1x/zTvm826-IKoMmaEWFkxa, BuildID[sha1]=316f2fe472816148c830d96e337b4befcbf213e0, not stripped

There's no need to merge this PR. Feel free to close it.

Thanks for the awesome work on this cool component.

[Skeen]

Any updates on this? - Running fstab/grok_exporter-compiler-amd64 gives me SIGSEGV on Debian bullseye (amd64), whereas if I build an image using the provided Dockerfile I get a fully functional image.

[edobry]

Would be great to have this Dockerized, much simpler adoption. Super useful tool in theory!

[Skeen]

Hi @fstab

I'm seeing the following:

skeen@ibuprofen ~> docker run -it centos:8 /bin/bash -c 'hostname'
cacce553aa4a
skeen@ibuprofen ~> docker run -it centos:7 /bin/bash -c 'hostname'
d91eb444d709
skeen@ibuprofen ~> docker run -it centos:6 /bin/bash -c 'hostname'
SIGSEGV
skeen@ibuprofen ~> docker run -it centos:5 /bin/bash -c 'hostname'
SIGSEGV

On Debian testing.

The cause seems to be Spectre V1 mitigation introduced in newer kernels.
See CentOS/sig-cloud-instance-images#62 / CentOS/sig-cloud-instance-images#103 and microsoft/WSL#1462 / microsoft/WSL#4694 for references.

Thus the solution here is to either use a newer centos version (centos 6 was released ~9 years ago, and lost support ~3 years ago, with full deprecation this year.), or have users modify their kernel boot arguments, by adding vsyscall=emulate.