Updated Dockerfile

[dejan995]

Updated Dockerfile to bring it up to date with industry standards. In the process the image size was shrunk to 488mb (190mb compressed) from the original of 638mb (242mb compressed). No functional change in the Dockerfile or in the app. From the testing I did looks like everything is working.

UPDATE 5966d14: With this update the image size is shrunk to 207.6mb (79.9mb compressed i.e when downloading from DockerHub). There is some funtional change in the Dockerfile, but everything is just changes to the Debian commands to work with Alpine. From the testing I did everything looks to be working.

This fixes issue #44.

[kmille]

Hey, I'm not convinced using Alpine as base image so I will stay with Ubuntu because it's the platform most users use (and we use it for tests).

[dejan995]

Hey, First of all, I get why you want to sitck with Ubuntu, one platform for everything. It makes things a lot easier.

On the other hand, the Docker Image is idependent of the standalone version. Think of the Docker Image as a packeged version of the app, sort of like flatpacks or snaps. Everything that the app needs is packeged with it. There is no room for something to brake. In terms of Docker base images, if a base image is capable of running your software there is no reason not to use it.

I choose the python:3.8-alpine3.14 image mostly because it comes preinstalled with python 3.8. A good rule of thumb when building docker images: If there is already an image that has what you need, use that, do not build it yourself.

I chose the Alpine version of python 3.8 because of how lightweight it is. And also the package manager it uses. If you go through the logs of the current build workflow you will see that apt is pulling and downloading, in the image, a lot of unnecessery pieces of software and other stuff. (i think that it's even downloading some graphical elements, but I'm not sure) Alpine's package manager on the other hand, only downloads what you tell it to download + the dependencies that those packages need, nothing more, nothing less. Also the cache and the packages that are needed for the build process can be easally removed at the and. Where as apt might remove a package that the app actually needs and a lot of the times you need to leave the build tools in the image beacuse they can not be removed with out breaking everything.

Now on to a proposed solution: I have implemented the same test workflow you have, to run against the base image, python:3.8-alpine3.14 and the tests are passing. Just a side note, I tried also using the test-image.sh script but due to my specific development enviornment I could not get it to run. I did this on my selfhosted GitLab Server. I don't like GitHub's Actions. Because I'm using a specific python version, I don't have to run the testes for 3.6, 3.7 & 3.9. The beauty is that, the docker image will run the same regardles of the host systems OS. Also, using docker buildx, I've managed to make images for both amd64 and arm64 platforms.

Now, I think that GitHub has a way to utilize docker images in the workflow, not sure though. If we create another workflow that does the tests against the base image before building and pushing the image, we will have somewhat of a bulletproof way to build stable docker images based on Alpine. Let me know what you think.

Also, to add, Alpine was created specificly to be used inside containers that is why is so much better than Ubuntu.

Sorry for the long rant, but I had to get my point accross. 😃

Happy Holidays !!! 🥳