Docker image

[dmaciel]

Hi

I have been testing creating a docker image, It is currently working and I believe it will make it easier to start using Standard File. The paths are currently pointing to my docker hub account, feel free to change the paths before merging.

I did a couple of changes in the src code, let me know what you think

[tectiv3]

Hey, thank you for your PR. I've decided to do it somewhat differently, check out my commit. I will test it a bit and then merge into master with a v0.5.0 tag.

[JokerQyou]

Good to know Docker support is going official. If standardfile could be statically compiled, I wonder why is alpine being used as base image of the final stage? Why not use scratch which is an empty image? (like this) That would result in a smaller image size.

[tectiv3]

@JokerQyou well, true. What is the resulting size of your image? Mine is 8Mb as Docker Hub reported and 17.5Mb installed.

[JokerQyou]

I took some time to compare them an hour ago, and in this case the benefit is very limited. My image is 14.7 MB installed. Guess I've underestimated the size increment of static linking. I was building with glibc from Debian, don't know if that's related.

[tectiv3]

I wander how did you manage to build without cgo? sqlite requires it

[JokerQyou]

I'm not familiar with compilers so I cannot really tell... It's just some old build config copied from my other golang project. And so far my server seems to be running well, no error or data loss.

[tectiv3]

Yeah, I think compiler just ignored CGO_ENABLED=0 flag because it could not be built without it. And golang:stretch has gcc in it.

[dmaciel]

Didn't pick Scratch because I was having issues loading the configuration and didn't know that sqlite can be installed inside Scratch. When I finished debugging forgot to try it again

@tectiv3 regarding your changes:

• The golang flags was something that I was expecting as recommendation. wasn't sure what tool were you using for the golang builds
• The tags in the dockerfile were there on purpose, using latest is discourage and can only bring issues down the road. I just notice that some merge in my branch removed the tags from the final stage, but in my plans where that everything was tied to a version
• The ugly change that I did in the way the config was loaded was more a limitation from the library used (confita), the less changes in code the better. If confita already managed prefixes in ENV config vars I would only create SF_ and let the app handle it without any additional change

Were you working on the docker container before I made the PR? I had a hard time (mostly by not knowing about the CGO_ENABLED=1 flag) and I looked into your repo for a container build before making the PR, did I miss something?

[tectiv3]

No no, I went the whole way only after I got your PR. Regarding using latest, I am planing on testing any major Go release and keeping this implementation updated. I also included sample docker-compose file as it is easier to configure your instance from it than to bake config values into the image. P.S. You don't need to install sqlite in the image as its support being compiled into binary. And it turned out you don't even need to specify CGO_ENABLED=1 because you can't compile sqlite without it. Check out the resulting Dockerfile.

[dmaciel]

My plans where to create the docker-compose (and a Helm chart) after the PR was accepted. I didn't make any sense to continue working when I wasn't sure if my PR was going to be rejected (as it finally was)

I put the config values into the image to make it clear the values being used by default, I prefer to be explicit to avoid bugs.

[tectiv3]

I would gladly accept PR with a switch away from confita btw.