Docker Container Immutability

[simoncaron]

Hey @1activegeek , great work on making a simple way to run airconnect in a container. (I use it every day :))

I just noticed that the binaries are not baked in the docker image but rather downloaded by a script on first init. (from what I understand, it pulls the latest release from the git repo). This is kind of breaking the immutability of the image. The binaries can change while the image remains the same (this could cause some troubles when breaking changes are made, or when broken binaries get pushed by mistake).

Have you ever considered adding the binaries when the image is built and tag it latest + a specific tag corresponding to the aiconnect version (currently 0.2.51.1)? That would ensure that we get proper traceability and immutability for each image.

Let me know if I can be of any help in implementing this if you're interested!

[1activegeek]

Thanks for the kudos. It's been awhile since I've stopped and analyzed the way I worked out running this initially. I do know it uses the init script to pull the binaries on startup. If I recall correctly though, that actually only happens when the image is built. If you were to startup a fresh container, it would simply have the binaries already active and ready to go. No scripting would happen to pull this down. So while the older versions of the image may have the same code, it will have the version of code at that point in time when the weekly job runs in GH Actions.

If you'd like to suggest making changes, please feel free to submit PR and I can take a peak when I have a chance. I have it in my plans to maybe later this year or early next year sit down with some learning again on Docker to re-understand how to build solid images as I have some other projects I want to work on.

[1activegeek]

@simoncaron take a look at the latest version of my changes. I had to dig in for a different issue and realize what you were highlighting here. Essentially since my build was running a script on boot that grabs the binary, it was always grabbing the latest binary which could be broken etc. I've moved the binary retrieval into the dockerfile, so now the container will start and run scripts that maneuver the binary, but it will already be downloaded WHEN the build was run. This should provide what you were speaking of. I'm not quite skilled enough yet to know how to tie it to the build versions from the repo where the binaries live. If you have ideas or would like to add a pull request, please feel free.

[1activegeek]

Haven't heard back here, so I'm going to assume this meets the basic need and close this out. The only thing I'm not doing here is scraping the download to identify the current version at time and use that label on my container. Please feel free to re-open and/or make a PR if you would like to alter it's current behavior.

[1activegeek]

@simoncaron just dropping here to let you know, I finally got around to it! 😄 I was able to work out the builds still being triggered weekly to keep the image fresh, but have now keyed it on release versions from the developer, with tags to match, allowing for the ability to select/choose a version. Hopefully this is what you had in mind?