6 ms·

I really haven't looked at rkt as much as I should, but we're more likely to invest in looking at lower level tools like runC moving forward.

StreamBright 10y ago
Amazing thank you! I need to chose a containerization tech in the next month and I am pretty worried to go with Docker because I hear many stories about how it is not really production ready. Thanks for mentioning runC I will check it out.
- colemickens 10y ago
  runC isn't an orchestration solution. It's a low-level component that can be (or is already) used by higher-level orchestration technologies.
  - StreamBright 10y ago
    Great, I do not need any orchestration solution at all. I need a container running thing that can encapsulate any software that we are developing (Java, C#, Node.JS, etc.). And now we are approaching the question what is my problem with Docker. I believe it is a misconception to compete with already existing tools like systemd. I especially do not want any mediocre orchestration solutions in my infrastructure that introduce big overhead and complexity that I do not need at all. One thing I learned along the way of managing large clusters (5K+ nodes) that Swarm like frameworks are extremely error prone. If you flip the problem and build a startup script the pulls down the container configuration from S3 for example and the container itself has code that attaches the instance to the right service (EKB, Haproxy, etc.) you can achieve the same without introducing services that sole purpose is to maintain a state that you do not need.
    - sjellis 10y ago
      I really do wonder what it would take to get the ecosystem to get behind rkt or something else. The present situation feels to me like it's held together by a shared desire to keep the Docker brand going, and that conflicts between Docker Inc. and basically everybody else just won't stop, because there is a lot of money involved for all sides.
      - StreamBright 10y ago
        For me the question is more like: why should we bundle together containerization with anything else? Why couldn't we follow the unix philosophy and have the containers work together with the orchestration softwares and not tied together. CoreOS seems to have it kind of independent. Our biggest blocker is the lack of RPMs for CentOS/RedHat for rkt.
    - galdosdi 10y ago
      If you want a container-like technology that already has the large cluster management, scaling built in and is ideal for software whose source code you control think about trying kubernetes (and/or any similar competitors).
    - jacques_chester 10y ago
      Sounds like you want a PaaS. Cloud Foundry is currently running real applications with 10k+ containers per installation. We are on track to test it with 250k app instances. Plus it's been around for, in internet terms, eternity. Garden predates Docker, Diego predates Kubernetes, BOSH predates Terraform or CloudFormation and so on. Used by boring F1000 companies, which is why it's not talked about much on HN. Disclosure: I work for Pivotal, we are the majority donors of engineering to Cloud Foundry.
  - cyphar 10y ago
    We're actually working on getting OCI support into Kubernetes. It's a long way away, but we're very determined to get large orchestration engines to provide support for OCI runtimes (runC being the canonical example of such a runtime).
- andrewguenther 10y ago
  All depends on your use case. RunC could be way too low level for what you need and Docker may be production ready for your specific use case.
  - StreamBright 10y ago
    No, it is perfectly covering my use case. I need a _reliable_ containerization app that does not run any additional service on my boxes. I am working on an extremely low overhead orchestration for our cluster so we can avoid Swarm entirely.
- dominotw 10y ago
  > I need to chose a containerization tech You are more likely to run into issues with containerization itself ( cgroup, namespaces ect) than abstractions on top of it. Unless you are doing some sort of orchestration on top of containers, you can't go wrong with any of the container abstractions.
- hartem_ 10y ago
  Disclaimer: I work at Mesosphere. There are alternative runtime implementations (such as Mesos/Mesosphere DC/OS) that let you have best of both worlds: developers can still use Docker and produce Docker images but you use production-grade container orchestration (and that same Docker images) without using Docker daemon for your actual service deployment.

StreamBright 10y ago

Amazing thank you! I need to chose a containerization tech in the next month and I am pretty worried to go with Docker because I hear many stories about how it is not really production ready. Thanks for mentioning runC I will check it out.

colemickens 10y ago
runC isn't an orchestration solution. It's a low-level component that can be (or is already) used by higher-level orchestration technologies.
- StreamBright 10y ago
  Great, I do not need any orchestration solution at all. I need a container running thing that can encapsulate any software that we are developing (Java, C#, Node.JS, etc.). And now we are approaching the question what is my problem with Docker. I believe it is a misconception to compete with already existing tools like systemd. I especially do not want any mediocre orchestration solutions in my infrastructure that introduce big overhead and complexity that I do not need at all. One thing I learned along the way of managing large clusters (5K+ nodes) that Swarm like frameworks are extremely error prone. If you flip the problem and build a startup script the pulls down the container configuration from S3 for example and the container itself has code that attaches the instance to the right service (EKB, Haproxy, etc.) you can achieve the same without introducing services that sole purpose is to maintain a state that you do not need.
  - sjellis 10y ago
    I really do wonder what it would take to get the ecosystem to get behind rkt or something else. The present situation feels to me like it's held together by a shared desire to keep the Docker brand going, and that conflicts between Docker Inc. and basically everybody else just won't stop, because there is a lot of money involved for all sides.
    - StreamBright 10y ago
      For me the question is more like: why should we bundle together containerization with anything else? Why couldn't we follow the unix philosophy and have the containers work together with the orchestration softwares and not tied together. CoreOS seems to have it kind of independent. Our biggest blocker is the lack of RPMs for CentOS/RedHat for rkt.
  - galdosdi 10y ago
    If you want a container-like technology that already has the large cluster management, scaling built in and is ideal for software whose source code you control think about trying kubernetes (and/or any similar competitors).
  - jacques_chester 10y ago
    Sounds like you want a PaaS. Cloud Foundry is currently running real applications with 10k+ containers per installation. We are on track to test it with 250k app instances. Plus it's been around for, in internet terms, eternity. Garden predates Docker, Diego predates Kubernetes, BOSH predates Terraform or CloudFormation and so on. Used by boring F1000 companies, which is why it's not talked about much on HN. Disclosure: I work for Pivotal, we are the majority donors of engineering to Cloud Foundry.
- cyphar 10y ago
  We're actually working on getting OCI support into Kubernetes. It's a long way away, but we're very determined to get large orchestration engines to provide support for OCI runtimes (runC being the canonical example of such a runtime).
andrewguenther 10y ago
All depends on your use case. RunC could be way too low level for what you need and Docker may be production ready for your specific use case.
- StreamBright 10y ago
  No, it is perfectly covering my use case. I need a _reliable_ containerization app that does not run any additional service on my boxes. I am working on an extremely low overhead orchestration for our cluster so we can avoid Swarm entirely.
dominotw 10y ago
> I need to chose a containerization tech You are more likely to run into issues with containerization itself ( cgroup, namespaces ect) than abstractions on top of it. Unless you are doing some sort of orchestration on top of containers, you can't go wrong with any of the container abstractions.
hartem_ 10y ago
Disclaimer: I work at Mesosphere. There are alternative runtime implementations (such as Mesos/Mesosphere DC/OS) that let you have best of both worlds: developers can still use Docker and produce Docker images but you use production-grade container orchestration (and that same Docker images) without using Docker daemon for your actual service deployment.