Debian based Docker Image

[Fixmetal]

Linting Dockerfile with Hadolint warns about package pinning:

$ hadolint-Linux-x86_64 Dockerfile
Dockerfile:3 DL3018 Pin versions in apk add. Instead of apk add <package> use apk add <package>=<version>
Dockerfile:16 DL3018 Pin versions in apk add. Instead of apk add <package> use apk add <package>=<version>

This is important for a stable release, but Alpine lacks the prerequisites to achieve this. Packages are not archived in repos but to the latest release. Plus build of Ofelia fetches from alpine-community repository which has a 6 months out of support policy:

Step 9/12 : RUN apk --no-cache add ca-certificates tzdata
 ---> Running in 9f67a987896e
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz

The same Alpine Community Repository page links to a Stack Overflow page which states:

Pinning a package to an exact version carries the risk that the package will be dropped from the repo, and your Dockerfile will fail to build in the future. The official recommendation can be read here, citation below.

Alternately, you could simply set a minimum package version instead of an exact version.

We don't at the moment have resources to store all built packages indefinitely in our infra. Thus we currently keep only the latest for each stable branch and has always been like that.

There has been a discussion of keeping all packages tagged as Alpine in the future. However, this is still "in-progress". The official recommendation is to keep your own mirror/repository with all the specific package and their versions that you may want to use.

— Timo Teräs, @fabled (Alpine)

Plus pinning to a major.minor.* fashion doesn't either in APK. It would be pointless anyway since the only the latest package is archived in repos. It would only be achieved by enabling older repos (we are at 3.12 atm, think about enabling 3.11 repo to install older stuff on 3.12 - bad practice).

In my working experience, a much more preferable way is to adopt a Debian based image. Advantages are:

1. Able to pin major.minor (and eventually forget about it)
2. No need to install build dependencies for Go (golang:buster image includes gcc + make)
3. tzdata package already installed:

Reading state information...
tzdata is already the newest version (2020a-0+deb10u1).

4. Similar build times:

Successfully built 6567bdaaa439
Successfully tagged ofelia:debian

real 0m23,759s
user 0m0,099s
sys 0m0,077s

Successfully built 21348a0fa533
Successfully tagged ofelia:alpine

real 0m18,067s
user 0m0,081s
sys 0m0,081s

This is a PR to achieve having a Debian based Ofelia image with the followings:

1. Hadolint linting pass
2. Non-privileged image
   3. Proper .dockerignore file to avoid big contexts sent over Docker Daemon see commit ed46a0b
3. Basing the build on 1.13-buster image

The only drawback is a somewhat bigger image:

$ docker images|grep ofelia
ofelia alpine 16db9fb0f410 51 seconds ago 22.6MB
ofelia debian 6567bdaaa439 10 minutes ago 91.7MB

I hope this PR is welcomed. Please review it - especially the NON ROOT user part. Maybe some more efforts should be done here to guarantee /var/run/docker.sock handling.

Best regards,

Simone

[taraspos]

Hey.
Thanks for the PR. I would totally agree about absolute need pinning packages version for python, etc based images.
However, not that sure about golang, since binary is mostly self-sufficient.

Also, I'm not that sure how safe it is to pin the ca-certificates version since they can expire as well.

Using Alpine is common practice for golang tools because it is a tiny Linux environment to run go binary which [almost] doesn't require installation of additional packages, so there is no real need to pin them.

And actually, I never seen many golang Docker images for opensource tools with pinned packages version.
I even had trouble finding an example of Debian based images for golang tools, because all of them in Alpine.

So here is the official debian-based docker image for the go itself, and ca-certificates are not being pinned there:
https://github.com/golang/build/blob/master/env/linux-x86-stretch/Dockerfile#L26

Or here is Dockerfile in the official repository for the example app:
https://github.com/golang/build/blob/master/devapp/Dockerfile#L42