Clojurians Log v2

I can't figure out anything from the https://doi-janky.infosiftr.net/ thats linked

I don't, but I will say that sticking to the official clojure images is a good way to ensure you are dealing with known quantities. our code, pipelines, etc. are open and auditable and docker hub does a lot of vetting on our images. if there's anything you need that you're finding cumbersome to do with them, feel free to open an issue here: https://github.com/Quantisan/docker-clojure

(I'm one of the maintainers of these images)

what makes something "official" though?

https://docs.docker.com/docker-hub/official_images/

I search the "offical" docker images by "tag" they seem to all be by that user. I'm not saying thats an issue...

weird the tag search might be a wider search then the context of the "docker official image" ?

These images are the official ones: https://hub.docker.com/_/clojure

Oh you know what, that might be the Jenkins user that pushes from the official Docker CI pipeline

I can confirm in a bit. Need to take my kid home from the oral surgeon first.

thanks 🙂 yea, thats what i'm guessing. It's just hard to figure out whats going on there and it's nice to have at least a thin blanket of understanding.

For sure. I have remarked to myself in the past they push with an account name that doesn't scream “official Docker business” but don't recall off the top of my head if that's the one or not.

TY for your effort here on these images, i have no idea what i would be doing without them!

Sure thing! I rely on them heavily too. :)

Yeah that's them. The “doi“ at the beginning stands for Docker Official Images I believe. Not the most transparent choice haha…

Yes, create your own image and push to your own repo, tag appropriately and don't touch it

Thanks!

you probably don't really want that. instead, use as specific a tag as you depend on (e.g. build tool version) and then o/w update from upstream regularly. o/w you're just sitting on security vulns we've pushed fixes for.

in FROM clojure:tools-deps-alpine the tag is tools-deps-alpine? The image is what is built from the dockerfile that uses that FROM function, and that's what is tagged and we can rely on to be the same. If we rebuild and re-tag would we expect things in tool-deps-alpine to have changed? If so, how much? i would assume it would always have tools-deps and alpine but for everything else to be udpated, is that right?

yes, the tag comes after the colon (except for when docker refers to the whole thing as a tag just to be confusing)

the upstream images won't change on your machines until / unless you do another explicit docker pull

but you should do those regularly

for anything that you want to manually update (b/c e.g. it might break your app in prod if a node silently pulls a newer images), you can specify any or all of the the temurin (jdk) version, the ubuntu version, the build tool and version, and whether or not it's using the alpine variant.

that makes sense. Somewhat unrelated question, which jdk (open, orcal, temurin) do you prefer? I get the impression it doesn't matter very much for most use cases.

so for example, if you just have FROM clojure:tools-deps and you build that today w/o an existing clojure:tools-deps image on your machine, it will pull down an image equivalent to clojure:temurin-17-tools-deps-1.11.1.1149-jammy

so you can specify that full tag if you want to be in charge of when any of those values change. o/w they will change from pull to pull.

but even fully-specified tags will get security patches and what not (assuming they're still supported like temurin but not openjdk )

temurin is currently the one and only supported jdk in these images

the older openjdk variants are EOL'd and for supporting existing installations only

and so, consequently, if you don't specify a jdk, you'll temurin-17 (17 b/c that's the current Java LTS release)

Yeah, I didn't clarify that - what you push to your own repo should remain frozen, and it will be based on whatever original tag you based your image on

that's exactly how we locked our base image with specific JDK, baked-in support libraries etc etc