5 ms·

An honest question, I am just beginning to understand containers so it might be naive. Containers share kernel from the base operating system so when kernel up

An honest question, I am just beginning to understand containers so it might be naive. Containers share kernel from the base operating system so when kernel updates to new incompatible version with breaking changes, how containerize application will continue to work.

pgeorgi 10y ago
The kernel interface tends to be super stable (eg on Linux, kernel interface ABI breakage is a blocker bug, and Linus rants about that every now and then when people ignore this). So it shouldn't be too painful to run RedHat 4.1 (from 1997) in a container on top of current Linux 4.8 and use that to run software linked against that ancient set of libraries. Probably easier than getting all those libraries to run in a current era userland.
- drieddust 10y ago
  Thanks understood, that means forward compatibility is guaranteed mostly.
- user5994461 10y ago
  Did you try that? I am experiencing so many issues with Docker and current kernels. I can only envision an attempt to run RedHat 4.1 over a modern system as a recipe for disaster.
  - drieddust 10y ago
    What kind of issues you have got into? I would like to hear from you. Though I don't have any experience of managing containers, argument does not make a lot of sense to me. They are pitched as holy grail which will get rid of entire IT team managing the operating system i.e. upgrades, patching, and configuration management. It just looks counter-intuitive to me as any new upgrade, bug fix , or security patch still needs to be applied to base OS. Containerized application can move freely from one host OS to another host OS but they will still depend on same underlying environment.
    - jacques_chester 10y ago
      > They are pitched as holy grail which will get rid of entire IT team managing the operating system i.e. upgrades, patching, and configuration management. They don't. Containers push a lot of that responsibility out to the developers. You still need operators if you're running your own IaaS substrate. Disclosure: I work for Pivotal, we do some stuff with containers.
      - deleted 10y ago
        [deleted]
    - user5994461 10y ago
      > What kind of issues you have got into? I would like to hear from you. See my blog post here. https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.wordpress.com/2016/11/01/docker-in-product...
      - jacques_chester 10y ago
        With respect to your "Future Roadmap", I'm obliged to encourage you to look at Cloud Foundry. It has some code in common with Docker at the lowest level, but the bulk of it is written from the ground up, fully TDD, fully pair-programmed, proved in production for several years running. I'm also obliged to disclose that I work for Pivotal, the majority donor of engineering to Cloud Foundry.
    - deleted 10y ago
      [deleted]
  - cpitman 10y ago
    I actually did this a while ago. I wanted to try out creating a docker base image from scratch so created one for RHEL 4 and then launched it as a container on RHEL 7. I didn't do too much with it other then prove out that I could run processes in it, but as far as I could tell it was functional. And the weird looks I got from people when I told them about it were great! Disclaimer: I work for Red Hat.
    - vidarh 10y ago
      RHEL 4 is about 7 years newer than Redhat 4.1... It may very well be possible to get Redhat 4.1 running too, but RHEL 4 is not quite in the same league.

pgeorgi 10y ago

The kernel interface tends to be super stable (eg on Linux, kernel interface ABI breakage is a blocker bug, and Linus rants about that every now and then when people ignore this). So it shouldn't be too painful to run RedHat 4.1 (from 1997) in a container on top of current Linux 4.8 and use that to run software linked against that ancient set of libraries. Probably easier than getting all those libraries to run in a current era userland.

drieddust 10y ago
Thanks understood, that means forward compatibility is guaranteed mostly.
user5994461 10y ago
Did you try that? I am experiencing so many issues with Docker and current kernels. I can only envision an attempt to run RedHat 4.1 over a modern system as a recipe for disaster.
- drieddust 10y ago
  What kind of issues you have got into? I would like to hear from you. Though I don't have any experience of managing containers, argument does not make a lot of sense to me. They are pitched as holy grail which will get rid of entire IT team managing the operating system i.e. upgrades, patching, and configuration management. It just looks counter-intuitive to me as any new upgrade, bug fix , or security patch still needs to be applied to base OS. Containerized application can move freely from one host OS to another host OS but they will still depend on same underlying environment.
  - jacques_chester 10y ago
    > They are pitched as holy grail which will get rid of entire IT team managing the operating system i.e. upgrades, patching, and configuration management. They don't. Containers push a lot of that responsibility out to the developers. You still need operators if you're running your own IaaS substrate. Disclosure: I work for Pivotal, we do some stuff with containers.
    - deleted 10y ago
      [deleted]
  - user5994461 10y ago
    > What kind of issues you have got into? I would like to hear from you. See my blog post here. https://thehftguy.wordpress.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.wordpress.com/2016/11/01/docker-in-product...
    - jacques_chester 10y ago
      With respect to your "Future Roadmap", I'm obliged to encourage you to look at Cloud Foundry. It has some code in common with Docker at the lowest level, but the bulk of it is written from the ground up, fully TDD, fully pair-programmed, proved in production for several years running. I'm also obliged to disclose that I work for Pivotal, the majority donor of engineering to Cloud Foundry.
  - deleted 10y ago
    [deleted]
- cpitman 10y ago
  I actually did this a while ago. I wanted to try out creating a docker base image from scratch so created one for RHEL 4 and then launched it as a container on RHEL 7. I didn't do too much with it other then prove out that I could run processes in it, but as far as I could tell it was functional. And the weird looks I got from people when I told them about it were great! Disclaimer: I work for Red Hat.
  - vidarh 10y ago
    RHEL 4 is about 7 years newer than Redhat 4.1... It may very well be possible to get Redhat 4.1 running too, but RHEL 4 is not quite in the same league.