4 ms·

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

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".

goldbrick 11y ago
But then you risk having untold other packages move under your feet. This is what concepts like "unattended-upgrades" address.
- riskable 11y ago
  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.
cyphar 11y ago
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.
- riskable 11y ago
  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.
- deleted 11y ago
  [deleted]

goldbrick 11y ago

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

riskable 11y ago
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.

cyphar 11y ago

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.

riskable 11y ago
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.
deleted 11y ago
[deleted]