Just build your own. It's not that hard.

Before containers we would script the install process using Ansible. With containers we script the install process using a Dockerfile. If you know how to do one, you know how to do the other. Just don't be lazy and use unofficial images created by people you don't know or trust. Just like you wouldn't pull any random role from ansible-galaxy. Or pull a random guy off the street and ask them to provision your infrastructure for you.

Then all you have to do is just rebuild your images every week and you're set. All we had to do for this was have our Jenkins build pipeline run weekly & have it pass `--pull --no-cache` to `docker build`.

You can even avoid dockerfiles by using Ansible: https://docs.ansible.com/ansible/latest/scenario_guides/guid...

We tried that about a year or two ago with `ansible-docker`. At the time it didn't leverage the docker cache so it was quite slow. Looks like that got replaced with `ansible-bender` which according to the readme does use the docker cache!

Thanks for mentioning this, will definitely have to give this another go.

"But we need to figure out the tooling and ecosystem story to build, verify and update container deployments securely."

Already done: Solaris zones. Available in the SmartOS distribution near you. Combine with OS packaging, imgadm and vmadm commands for maximum impact.

I've spend 1 minute skimming some of the docs, but it's unclear whether these tools can do a better job than the docker-like tooling. The vmadm "build an image from scratch with a json file" doesn't help in building Hadoop any more than the oldest versions of docker did using a minimal image and a Dockerfile.

How does provide visibility into every dependency inside an image? Especially when using 3rd-party-maintained images that consist of significant hours of work per image to get the image to work.

(BTW., I built "live CD images" for use in physical and virtual machines since ~2001, using tools such as mklivecd, livecd-tools etc.).

It doesn't. He's a troll that claims solaris is the solution to every problem that he doesn't understand.

I suspect there's a similar story around LXC available.

> A lot of them involve messy build steps, including downloading binaries or source tarballs without verification

Do they though?

Whenever I write Dockerfiles that depend on external downloads, I always check the hash matches one baked into the Dockerfile itself, and I've always seen others doing the same.

I have seen this many times, generally the high profile containers do that, and these issues are more common among my peers. This requires self discipline and containers were pushed as a panacea for environments where the discipline is lacking.

What is the point of storing the hash of an external file instead of checking the file into local version control? You're making it a part of your sources either way.

People who want to run docker don't want to run artifactory.

I'm not saying it's a good thing, but that's what I observed.

Do you have any examples of high-profile images that do this?

I really just haven't seen this with the ones I use.

Sorry, I see that my response looks ambiguous.

I meant the opposite. The high profile containers generally do the right thing, but containers created by peers rarely do it.

There's no mechanism to make things reproducible you need to implement it yourself, and from my experience most people (not the ones that release something publicly, but ones that work for a companies that use it) don't do it.