4 ms·

What does prod have to do with stale Docker images? The problem is not updating your images. Running old libs on bare metal has exactly the same problem.

syshum 6y ago
Exactly, I know a few places that have years old installs of linux that never get updates... same thing. nothing in docker prevents updates, just people in general are poor about doing maintenance, this is a story that is old as computers, and why MS forced updates on everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things
- Wowfunhappy 6y ago
  > everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things It sure would be helpful if the updates didn't actually break things. It's usually not the security fixes that do that—stuff rarely breaks on LTSC, or in Debian point releases—it's all the other changes that get rolled in. There's just too much churn across the industry. Even if the changes are good, too little thought is given to the cost of change itself.
tannhaeuser 6y ago
> The problem is not updating your images. Running old libs on bare metal has exactly the same problem. Updating libs on bare metal has maintainers and distributions, though. And doesn't force you to roll your own security infra within containers.
- acdha 6y ago
  You have all of that inside the container, too: apt-get upgrade doesn’t magically stop working because it’s in a Dockerfile. The difference is that you have a trivial way to confirm deployments and be confident that there isn’t other mutable state preventing an upgrade.
  - tannhaeuser 6y ago
    If you base your container on Debian/Ubuntu, that is. And is at odds with the principle of only packing what's actually needed. If you base all your images on Debian/Ubuntu anyway, then what's the point of containers? If there's a vulnerability, you'd have to upgrade all of them anyway and they're living now as binary images on your build host instead of a versioned O/S.
    - Jonnax 6y ago
      A container starts instantly and uses far fewer resources than a VM. Even if you do a FROM Ubuntu or FROM Debian that's still a huge advantage.
    - seniorThrowaway 6y ago
      A lot of this discussion seems to revolve around running java inside containers without explicitly saying so. Running the JVM brings along a whole host of dependencies which is typically resolved by running a full blown base OS image. It is still desirable by many teams due to past issues with maintaining the JVM on VM or metal hosts.
    - acdha 6y ago
      All containers give you a guaranteed build process and proof that mutable state is only stored in well-known locations. That’s a huge advantage over full servers right there as any experienced Unix admin will tell you. If you’re using a container based on an OS, you are installing far, far less and having only one process running. That again is a huge savings: no time securing postfix and cron, etc. Another big advantage is that you’re shifting this work from the deployment time to build time. You do it once and can test it as long as you want before deploying it to production - no more failures because Red Hat’s mirror is unavailable or malfunctioning during your prod update window.

syshum 6y ago

Exactly, I know a few places that have years old installs of linux that never get updates... same thing. nothing in docker prevents updates, just people in general are poor about doing maintenance, this is a story that is old as computers, and why MS forced updates on everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things

Wowfunhappy 6y ago
> everyone because left to their own most people choose to "postpone" them indefinitely for fear of breaking things It sure would be helpful if the updates didn't actually break things. It's usually not the security fixes that do that—stuff rarely breaks on LTSC, or in Debian point releases—it's all the other changes that get rolled in. There's just too much churn across the industry. Even if the changes are good, too little thought is given to the cost of change itself.

tannhaeuser 6y ago

> The problem is not updating your images. Running old libs on bare metal has exactly the same problem. Updating libs on bare metal has maintainers and distributions, though. And doesn't force you to roll your own security infra within containers.

acdha 6y ago
You have all of that inside the container, too: apt-get upgrade doesn’t magically stop working because it’s in a Dockerfile. The difference is that you have a trivial way to confirm deployments and be confident that there isn’t other mutable state preventing an upgrade.
- tannhaeuser 6y ago
  If you base your container on Debian/Ubuntu, that is. And is at odds with the principle of only packing what's actually needed. If you base all your images on Debian/Ubuntu anyway, then what's the point of containers? If there's a vulnerability, you'd have to upgrade all of them anyway and they're living now as binary images on your build host instead of a versioned O/S.
  - Jonnax 6y ago
    A container starts instantly and uses far fewer resources than a VM. Even if you do a FROM Ubuntu or FROM Debian that's still a huge advantage.
  - seniorThrowaway 6y ago
    A lot of this discussion seems to revolve around running java inside containers without explicitly saying so. Running the JVM brings along a whole host of dependencies which is typically resolved by running a full blown base OS image. It is still desirable by many teams due to past issues with maintaining the JVM on VM or metal hosts.
  - acdha 6y ago
    All containers give you a guaranteed build process and proof that mutable state is only stored in well-known locations. That’s a huge advantage over full servers right there as any experienced Unix admin will tell you. If you’re using a container based on an OS, you are installing far, far less and having only one process running. That again is a huge savings: no time securing postfix and cron, etc. Another big advantage is that you’re shifting this work from the deployment time to build time. You do it once and can test it as long as you want before deploying it to production - no more failures because Red Hat’s mirror is unavailable or malfunctioning during your prod update window.