Hacker News Reader

Comment by cyphar | Hacker News Reader

> So when your security team freaks out because none of your hosts/containers are showing up in their systems you'll have a lot of explaining to do =D

> "We need to scan your hosts so we can ensure that you're installing security patches."

> "We don't do that."

> "You don't install security patches?!?"

> "Yeah, well, you see..."

If you use a tool like zypper-docker, you can create a new image quickly that applies just the security patches. Currently it only works for SUSE-derived containers but we're planning on making it distribution agnostic.

There's also some work we're doing on connecting Docker containers running on SUSE enterprises to connect with SUSE Manager (aka spacewalk), so they would show up in their systems.

You can find most of this stuff in github.com/SUSE.

View on HN

zypper-docker is kinda pointless. Just re-build from your Dockerfile using the latest upstream image. It takes like 10 seconds (depending on how many external dependencies need to be fetched).

Our Docker registry pulls down the latest images (that we use with our Dockerfiles) multiple times daily. So if the author of the Dockerfile just puts "FROM whatever:latest" they are guaranteed to have all the latest/patched software whenever they "docker build".

But then you risk having untold other packages move under your feet. This is what concepts like "unattended-upgrades" address.

The risk associated with breakage from an automated upgrade is an order of magnitude less than the risk associated with being hacked because you weren't keeping up to date.

Sometimes you don't want to update all of your dependencies (isn't that the whole point of Docker), you might want to just apply security updates. Just putting "FROM whatever:latest" is a bad idea, because you don't know whether the "latest" will suddenly break your image.

The point of zypper-docker is to quickly roll out security fixes with essentially no downtime. zypper-docker also allows you to quickly check the health of all of the images and containers on your servers, so you can figure out which ones need updating. Also, zypper-docker allows you to apply RPM patches (something that's quite crucial for enterprises).

So no, it's not pointless. In fact it solves a problem that not many people have been working on solving: updating containers.

Actually, the correct and only way to find out if ":latest" breaks your image you create your image using ":latest"!

How are you going to know if the latest version of the upstream image breaks your package if you don't try it? E whole point of continuous integration is that there are no surprises when it comes time to push to production.

If ":latest" breaks your image you had better know:

A) Immediately.

B) What went wrong ASAP.

The integrated testing (that you're supposed to use with Docker best practices) should reveal if there's a problem and if it doesn't you'll still catch it during QA testing of your image.

The fact that ":latest" breaks your image should be nothing more than a few minutes to days of troubleshooting. While you're doing that your existing production images will keep on chugging away.

The only rule that you must not break is that you have the next release of your image out the door, ready for production within 30 days. Why? Because that's the maximum (hard-coded) lifetime we (and you should too) allow images to stay running.

Reply on news.ycombinator.com