4 ms·

In a situation where there are many running containers a security patch could be applied across the board and still have confidence that running apps are not af

In a situation where there are many running containers a security patch could be applied across the board and still have confidence that running apps are not affected. This would be a case by case situation if they were all Dockerfiles.

jacques_chester 8y ago
I agree with this bit. The cool part is that when the patch arrives, devs don't have to do anything to be patched. Cloud Foundry already does this with buildpacks and so does Heroku. A big part of what's new is that layer rebasing could make this really really fast.
- pm90 8y ago
  Personally, I don't think this kind of magic is a good thing. But to each their own.
  - jacques_chester 8y ago
    Could you elaborate, though? It helps us to understand what seems magical so that we can either explain it better or make the process more transparent.
    - pm90 8y ago
      For companies with compliance requirements, you're required to change the systems explicitly; this is one of the reason why Docker images work so well; you can target specific tags for deployment and nothing changes with the same tag. Aside from that; I think its a bad idea to have things update automatically. What if the upstream fix breaks things? It reduces trust in the build system.
      - jacques_chester 8y ago
        Thankyou, I appreciate the answer. > For companies with compliance requirements, you're required to change the systems explicitly; this is one of the reason why Docker images work so well; you can target specific tags for deployment and nothing changes with the same tag. This isn't really true, though. Tags are floating targets, only the digest is stable. Taking Kubernetes as an example, suppose I push an updated Pod definition where I've changed an image tag from v1 to v2. If the tag is not properly locked, then I can be running multiple versions of the software without even realising it. Speaking of regulation, we find a lot of people like buildpacks for that exact reason. Operators know exactly what OS is running in every container, exactly what JDK is running in every container, everything up to the runtime (and as FTL matures, up to the package dependencies as well). The platform doesn't have to accept any old container, they can all enter through a trusted pathway. You can do this with docker builds, of course. You build CI/CD, you have centrally-controlled images, prevent non-conforming images from reaching production and so forth. But then you've pretty much recreated all the stuff buildpacks gave you, except you're the one having to maintain it. > Aside from that; I think its a bad idea to have things update automatically. What if the upstream fix breaks things? It reduces trust in the build system. Rebasing layers is close to instant. You can rollback the change as soon as it looks bad. More to the point, if the OS vendor or runtime have broken ABI compatibility, rebuilding a docker image won't necessarily help you to notice that before runtime.
        pm90 8y ago
        I think I may have been unclear with my terminology; I said tag but I meant the sha checksum of the built docker image, which is unique.
        jacques_chester 8y ago
        Gotcha. Not my intention to jump down your throat with hiking boots, but the tag-vs-digest thing has been a big part of what I've worked on over the past few months. I agree heartily that keeping the books using digests is the only sane option and buildpacks retain that property. They're just producing and updating OCI images, at the end of the day.

jacques_chester 8y ago

I agree with this bit. The cool part is that when the patch arrives, devs don't have to do anything to be patched. Cloud Foundry already does this with buildpacks and so does Heroku. A big part of what's new is that layer rebasing could make this really really fast.

pm90 8y ago
Personally, I don't think this kind of magic is a good thing. But to each their own.
- jacques_chester 8y ago
  Could you elaborate, though? It helps us to understand what seems magical so that we can either explain it better or make the process more transparent.
  - pm90 8y ago
    For companies with compliance requirements, you're required to change the systems explicitly; this is one of the reason why Docker images work so well; you can target specific tags for deployment and nothing changes with the same tag. Aside from that; I think its a bad idea to have things update automatically. What if the upstream fix breaks things? It reduces trust in the build system.
    - jacques_chester 8y ago
      Thankyou, I appreciate the answer. > For companies with compliance requirements, you're required to change the systems explicitly; this is one of the reason why Docker images work so well; you can target specific tags for deployment and nothing changes with the same tag. This isn't really true, though. Tags are floating targets, only the digest is stable. Taking Kubernetes as an example, suppose I push an updated Pod definition where I've changed an image tag from v1 to v2. If the tag is not properly locked, then I can be running multiple versions of the software without even realising it. Speaking of regulation, we find a lot of people like buildpacks for that exact reason. Operators know exactly what OS is running in every container, exactly what JDK is running in every container, everything up to the runtime (and as FTL matures, up to the package dependencies as well). The platform doesn't have to accept any old container, they can all enter through a trusted pathway. You can do this with docker builds, of course. You build CI/CD, you have centrally-controlled images, prevent non-conforming images from reaching production and so forth. But then you've pretty much recreated all the stuff buildpacks gave you, except you're the one having to maintain it. > Aside from that; I think its a bad idea to have things update automatically. What if the upstream fix breaks things? It reduces trust in the build system. Rebasing layers is close to instant. You can rollback the change as soon as it looks bad. More to the point, if the OS vendor or runtime have broken ABI compatibility, rebuilding a docker image won't necessarily help you to notice that before runtime.
      - pm90 8y ago
        I think I may have been unclear with my terminology; I said tag but I meant the sha checksum of the built docker image, which is unique.
        jacques_chester 8y ago
        Gotcha. Not my intention to jump down your throat with hiking boots, but the tag-vs-digest thing has been a big part of what I've worked on over the past few months. I agree heartily that keeping the books using digests is the only sane option and buildpacks retain that property. They're just producing and updating OCI images, at the end of the day.