Hacker News Reader

Comment by stackskipton | Hacker News Reader

You still have to rebuild each Application Container with new CACert and deploy them. Depending on teams are working, that can be disruptive.

View on HN

I would say that if rebuilding your docker containers is a disruptive process, that is a process issue.

I would agree but it doesn't change the fact that many companies do not have CD and have processes that must be followed for rollouts.

It's same problem we have when libraries get massive security vulnerabilities. Updating them is not always as easy as many would like.

I think the number one thing that bites a lot of container workflows is when you have a separate "base image" build that depends on external, mutable package sources using tools that don't support locking, such as apt.

This gets worse for each additional such layer, for example if you start from ubuntu:whatever and have a system deps layer, then an application deps layer, then static assets, then your app's code. Unless you think about it upfront when designing the pipeline, it can be challenging to trace all that state backwards and figure out how to safely re-build thing-from-x-weeks ago but with a single unsafe package bumped forward.

Every shop with competent devops people present should be set up for this, but it usually doesn't come for free.

AFAIK a container build just puts files into a base image, this creates a sort of a commit chained to the base image commit. This means to update the base image you only need to rebase that commit on top of the new base image branch automatically.

I haven’t seen tooling for rebasing OCI images yet. Considering you’d still have to do this and roll it out to the server, you can just re-run the CI, which would build the image again, but also test that it works with the new base image.

You actually can sort of do this just inside a modern docker file, with COPY --link

That version of copy overlays the copied content without any knowledge of its underlay, so if the underlay changes, the hash of the layer created by COPY remains identical.

Obviously there are lots of situations this doesn't work for, but say you have a pool of Ubuntu packages (the system layer) and then you separately copy a CMake installspace or built uv project from a build stage, that project layer can be identical in hash if it's copied onto an updated system layer.

In practice, it's hard to get this to work because it's very easy in docker to accidentally trigger a rebuild for some random reason, but all the pieces are there.

Reply on news.ycombinator.com