Hacker News Reader

Comment by shykes | Hacker News Reader

Hi, I'm the founder of Docker.

> [...] a freemium model

Docker had already adopted an enterprise subscription + freemium model, but the offering was less clear (case in point: you weren't aware of it). This clarifies and simplifies our offering, and upgrades the enterprise offering along the way.

> [...] solves the fundamental problem of Kubernetes eating their lunch

Kubernetes is a component (like containerd or swarmkit), while Docker is a platform which integrates many components (like Cloud Foundry or Openshift).

So Docker and Kubernetes are not directly competitive - Docker just happens not use Kubernetes as an orchestration component. It uses SwarmKit, an open-source component developed in-house (https://github.com/docker/swarmkit)

A better comparison would be Docker and Openshift (which is Kubernetes-based). Is Openshift eating Docker's lunch? It certainly doesn't feel that way to me, but of course I am biased. Docker has three major advantages over Openshift: it's modular, it has better security, and it's not locked to RHEL. The main advantage of Openshift of course is that it is highly integrated into the Red Hat platform, which is appealing if you are already heavily invested in it. Openshift also benefits from the demand for a commercially supported product based on kubernetes.

But either way the market is so early, and the demand so strong, I believe there is room for more than one major container platform. In a few years when the market starts maturing, we'll see!

View on HN

> Kubernetes is a component...while Docker is a platform which integrates many components...So Docker and Kubernetes are not directly competitive

I wonder whether this is a distinction that exists in your mind, as someone intimately involved in the development of the docker tool and the Docker, Inc business model more so than in the minds of Docker users. You have a vested interest in making Docker encompass all that Docker, Inc produces. For many of us, this is actually against our interests. A lot of us want Docker to just be the base containerization layer with other offerings (like k8s, swarm, etc) built on top of it and branded separately. Continually adding more to the docker base layer adds confusion in the minds of people who don't follow Docker closely, makes it harder to get it approved for use in our organizations and increases the security footprint that needs to be audited.

I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else rather than trying to stuff everything into one tool with one name. You have no idea how hard some of us have had to fight inside our organizations to simply deploy builds inside containers. Increasing the scope of what Docker means is just giving ammunition to our internal opponents.

I understand why you're doing what you're doing...there's no money in developing that base layer unless you can parlay it into selling the other parts of your platform, but just understand that what you're doing isn't really user-friendly and many users won't pliantly go along with whatever marketing decisions you make. Like it or not, Docker is an ecosystem, not a platform. It has a life of its own that you're only partially able to shape. You have the advantage of being able to shape the roadmap for the underlying containerization layer and the goodwill that comes from putting in the work to have created initially and maintain that layer on an ongoing basis. That should be enough without leveraging it further.

> I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else

We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker.

I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677

I hope this helps.

Again, that's a relatively-recent branding decision on your part. It's pretty meaningless to people that have spent more than a year trying to explain to people what Docker is and why we should use it. Trying to go back to those people now to switch terminology is, at best a massive headache and, at worst, going to get containerization efforts canceled.

I'm not sure I understand the problem. Whatever containerization project you were building on top of Docker, it is just as viable today as yesterday. No option has been removed - if anything there are now more options available to you. All new versions of Docker remain backwards-compatible with previous versions. And components of Docker which were previously not available standalone, now are.

What exactly would you like Docker to do, that we're not currently doing?

What you're missing is the ecosystem vs platform distinction. A platform is yours to control and an ecosystem has a life of its own. You're right that everything that was possible still is. But docker, as a term, developed in ways not controlled by you. It took on a meaning that's probably more limited than you'd like. And it developed momentum that can't be stopped or diverted by a marketing strategy and a press release from Docker, Inc.

You're not the first company that's had to deal with this. To me, it's similar to Google's failed attempts to keep people from using their name as a verb. You're both companies that has a wildly successful initial product that got associated with your company's name and that hindered attempts to branch out from that initial offering. But the more you try to repurpose the term to refer to your broader offering rather than the narrower base layer that it started out as, the more you create problems for those of us that have spent a lot of time and effort selling your approach within our organizations. Not everyone is sold on containerization and we (your advocates) have people that will pounce on any confusion as a way to push back.

Decision-makers in organizations are often surprisingly non-technical. Imagine if there were a company behind email. And that company wanted to make money selling add-on services like encryption and mailing list management. So it decided to call the base email layer libsmtpd and repurpose the term email to mean the broader platform offering. Now imagine you've got to explain this change to your elderly mother who's just gotten over the hump and gotten comfortable with sending email and referring to email correctly.

That's kinda the position you're putting us in.

Very well said!

I understand what you're saying. And you would be 100% correct if everyone shared your definition of Docker as a tiny container runtime and nothing else. But that is not at all the case. There are conflicting narratives of what Docker is and isn't. And where you see the mystical forces of brand destiny deciding which narrative will win - I have seen the kitchen where the branding sausage is made. And believe me there is nothing magical about it. Some vendors want you to believe Docker is a component, so they spend money in marketing programs and suddenly you're hearing through various channels that Docker is a component. We in turn want you to know that Docker is a product, we invest in telling you that story, and here we are.

The difference is that we invented Docker. We understand its future potential and control its design and trademark. Our competitors don't.

So I'm sorry that you have a different definition of Docker than the people who invented Docker. But just like Google decides what Google is - Docker decides what Docker is.

If Google decided to pivot to a lunch delivery service and shut their search offerings, people would still 'google' things.

I'm sorry you feel that way.

For what it's worth, my notion of what Docker is comes from having run it in production since before the transition away from LXC. I ran a small team inside a relatively large company (8000 employees, $25B mkt cap) and we largely had control over our own ops. We ran into a lot of early adopter pains, but the benefits definitely outweighed the pain.

I was also in various architecture groups that made decisions for the larger products at the company. I was always honest about the drawbacks, but I pushed for limited exploratory projects using Docker to try to slowly move ops in that direction. I had a lot of opposition from ops folks that never felt the pain of the developer experience and worried that Docker was an encroachment on their fiefdom (GoT had nothing on our internal politics :-)

Slowly, we (I wasn't the only Docker supporter at the company) made progress. We set up a Quay private registry server so that, at least, teams could begin to experiment. And when I met your team at re:invent and heard that you were developing your own offering for private registry, I convinced them to switch. The first-party argument was easy to make and the company didn't really quibble about sub-7-figure software purchases.

I ended up leaving that company last year, so your current direction isn't really making my life harder, but had I stayed,it would be. If you want to be explicit in your targeting of a different market segment from the kind of early adopter that I am/was, that's fine. But don't accuse me of having my view shaped by competitors' marketing. That's a highly revisionist view of your own history. Because when I got on the Docker bandwagon, the reality absolutely matched what I'm describing. Docker was the base layer and a prefix added to related product offerings. But it wasn't a platform like you're describing. That seems like it's changed now, which would've really screwed me in trying to push Docker at my previous employer.

None of that has changed. Docker is still targeted explicitly at your use case. I believe your project would have been just fine. Docker EE was shaped by requirements very similar to your own. But I can't seem to convince you of that... Sorry if I'm not being clear. Maybe we can discuss in person one of these days :)

@curun1r

Maybe you should face and accept the fact that Docker is not going in the direction you need it to, and its future plans are not aligned with your interest.

These are perfectly reasonable reasons for a company to cancel the efforts and avoid the headache.

A comment on a news will not put it back on the "right" track. Don't invest in risky and uncertain products.

We are going in the direction he wants us to. We're just doing it under the name "containerd" and he's unhappy that we're not calling it "Docker". If he were to simply accept our choice of naming, 100% of his issues would go away.

>> accept our choice of naming,

Therefore you are not going in the direction he wants you to.

The name for that is "Docker" and it has been for many years already. You can't just rename things to fit your new marketing strategy and pretend that your users won't get hurt.

If you could simply erase the memory of all inhabitants of Earth and rename all books and articles even written, then yes, there would be no issues in renaming.

I don't understand this level of outrage. In any case being outraged doesn't make you right, and it doesn't authorize you to twist the facts. So let's compare your claim that Docker was "just a container runtime" for years, and we are suddenly changing that to "fit our marketing strategy", whatever that means. For reference here is the changelog of Docker: https://github.com/docker/docker/blob/master/CHANGELOG.md

- Docker has included a container build system since version 0.3 in May 2013. https://github.com/docker/docker/blob/master/CHANGELOG.md#03...

- Docker has included image storage and distribution since the version 0.1 in March 2013. https://github.com/docker/docker/blob/master/CHANGELOG.md#01...

- The official website has said "Docker is a platform to build, ship and run distributed applications" since 2014, and clearly featuring the collection of multiple tools forming that platform. https://web.archive.org/web/20141216011043/https://www.docke...

- Docker has included a distributed key-value store and optional multi-host networking since version 1.7 in June 2015. https://github.com/docker/docker/blob/master/CHANGELOG.md#17...

- Docker has included orchestration since 1.12 in June 2016.

- Docker has included cryptographic content trust since version 1.8 in August 2015. https://blog.docker.com/2015/08/content-trust-docker-1-8/

- Docker has included secrets management since 1.13 in February 2017. https://blog.docker.com/2017/02/docker-secrets-management/

- Docker for Mac and Windows have included a built-in hypervisor and OS since March 2016. https://blog.docker.com/2016/03/docker-for-mac-windows-beta/

- Docker for AWS and Azure have also included a built-in OS since June 2016. https://blog.docker.com/2016/06/azure-aws-beta/

- Docker started gradually factoring out its container runtime in 2013. First with libcontainer; then with runc/OCI; and most recently with containerd. https://containerd.tools

- containerd in particular exists since 2015; and it's been over a year since Docker doesn't perform any container runtime task itself - it's all handed off to containerd.

I could go on. Docker has said clearly and consistently, for several years now, that it is building a platform made of a collection of tools, including but not limited to a core container runtime. You just didn't want to hear that explanation, either because you didn't like it, or because someone other than Docker (perhaps a competitor) gave you an incorrect explanation of what Docker is.

And now that the dissonance is becoming hard to ignore, you're forced to reconcile your incorrect definition of Docker with the real definition, and it makes you angry. But, like I said, being angry doesn't make you right. And it doesn't put you above having to provide evidence of your claims. So, can you provide concrete evidence that we are "hurting our users"?

I think Solomon has hit the nail on the head here, but I'll call it out even more starkly.

Assuming containerd is successful, and that higher-order systems like Kubernetes and Mesos use containerd directly, we will see one of two things in 12-18 months time: 1) There are hundreds of thousands of DOCKER users 2) There are hundreds of thousands of CONTAINERD users

The split is forcing stratification (in a good way) where there previously was none. Users have to identify whether they think "docker" means "a container runtime" or "a full stack".

Of course, the pie is growing, so maybe we get both results. The real problems over the next 12-18 months are MESSAGING and DISENTANGLING. How do you get this message across to people, and can you actually change the words in the common vernacular?

As owners of the word "Docker" Solomon can define it how he likes, but that doesn't mean he can actually stop people from using it to mean something else. That's going to be a process.

c.f. "literally". Even Webster's Dictionary has given up the fight on that.

I think this distinction is important for people to internalize. Docker heard the userbase that there needed to be a distinction between the "bottom half" and the "top half" of the Docker stack.

Giving away the Docker name to the bottom half would have been dumb (IMO), so extracting it as containerd makes sense.

Will that confound some people? Sure, but they will get over it. I think it was the right thing to do, but then I am known to be a big fan of layered systems. :)

"docker" has too much brand recognition to let it go even though this whole 'rename' (that's what this is) makes things much more confusing than before.

"Kubernetes is a component (like containerd or swarmkit)...Docker is a platform...(like Cloud Foundry or Openshift)"

I think that's pushing k8s farther to the left of what it really is, and pushing Docker farther to the right of what it really is.

k8s, for example, incorporates service discovery. As far as I can tell, swarmkit does not. k8s incorporates networking, containerd does not. Similar for things like ingress load balancing.

There are certainly potential customers debating, directly, k8s vs your full Docker platform, even if there are some gaps they have to fill with other software.

> k8s, for example, incorporates service discovery. As far as I can tell, swarmkit does not. k8s incorporates networking, containerd does not. Similar for things like ingress load balancing.

Swarmkit does in fact implement service discovery, networking, and ingress load-balancing. It also implements out-of-the-box node security and mutual TLS, secure secrets management, a built-in raft store, infrastructure-agnostic overlay networking, and various goodies which we needed to make Docker work great out of the box.

containerd is a different type of component entirely - in fact it is very complementary to kubernetes.

> There are certainly potential customers debating, directly, k8s vs your full Docker platform

They typically debate Docker vs kubernetes-based platforms (among other possible alternatives). If they're a Red Hat shop, they typically evaluate Openshift. Sometimes there's a team building an in-house platform. Nobody ever deploys kub alone in production. There is always some form of platform on top.

>containerd is a different type of component entirely - in fact it is very complementary to kubernetes

You made the initial comparison.

> Nobody ever deploys kub alone in production. There is always some form of platform on top.

Which is another way of saying "even if there are some gaps they have to fill with other software". Sure, some customers pick a platform where the gaps are prefilled. Not terribly different from some of your customers that pair docker pieces with pieces from other vendors.

>> containerd is a different type of component entirely - in fact it is very complementary to kubernetes

> You made the initial comparison.

Yes, sorry I wasn't clear. I meant that they were both components, as opposed to complete products.

On the other hand, SwarmKit and Kubernetes are comparable in functionality.

> Which is another way of saying "even if there are some gaps they have to fill with other software".

I agree.

> Sure, some customers pick a platform where the gaps are prefilled. Not terribly different from some of your customers that pair docker pieces with pieces from other vendors.

I also agree.

It seems that there is nothing left to disagree on :)

Sure. Said more concisely, my beef was that you compared k8s to things narrower in purpose, then compared Docker to things broader in purpose. It made the gap between the two seem larger than what it is. I agree there's a gap.

Edit:

Re: "Try developing on Docker for Mac/Windows and deploying to production with Docker for AWS/Azure"

Developing on a platform that isn't the same as your production platform is an avoidable situation. I could develop on .Net and deploy on mono as well, but...

The gap is in fact huge. Try developing on Docker for Mac/Windows and deploying to production with Docker for AWS/Azure. Then try to build the same level of functionality yourself from naked kubernetes and only open-source tools. Let me know when you're done :)

The difference is that I can put together components of Kubernetes that actually work. Sorry to be inflammatory, but I've been working on the bleeding edge of Swarm and it simply doesn't deliver what's promised (ex: flaky management of iptables, missing idioms/abstractions, etc.).

Single-host Docker in production, yeah that's not terribly complex, but the new price of admission for production is a complete orchestration layer, and there is 0% chance I consider taking a Swarm cluster to production any time soon. And that's to say nothing of the DDC disaster...

MiniKube as a local env is getting great feedback filling this niche.

It's absolutely awesome in this role.

I don't know if a few hundred lines of shell scripting and Helm charts are considered building around it though, but that's enough for a Git hosting service (Gogs) and a CI (Drone 0.5) with persistent storage with vboxsf.

I deploy on minikube (Mac Desktop) and GKE.

There are 4 lines of configuration that differ between those two environments.

> Nobody ever deploys kub alone in production

That doesn't gel with any reality I know of, sorry. Lots of people use higher level platforms, or develop bespoke tooling, to be sure, but that's going to be true forever, for every platform.

(disclosure for others: I'm a Kubernetes founder)

Replying to myself: The fact that someone builds tooling on top of your offering is not an indictment of your product. It simply means people are using it.

Be worried when people STOP trying to wrap your stuff with their own opinions.

> Nobody ever deploys kub alone in production.

Uhh, we do. And we're not alone as we work with several other companies that do. That's quite a big nobody tent.

What do you use for provisioning and upgrading Kub? For monitoring it? For CICD? For access control? Image registry? Image build? The collection of these things, and everything else required for deploying and managing containers in production, is what I call a container platform.

Is kub core not working on spinning out built-in volume plugins out of the core to keep it smaller? Are the maintainers not recommending using third-party tools + 3PR for all major new features going forward?

It seems like my comment was misinterpreted as a criticism of kub, or a sign of ignorance. It was neither. I stand by my comment that nobody runs naked kub in production. That doesn't make it any less good, stable or useful. It just means it's not meant to be a complete product.

I beg to differ, having done Kubernetes training for nearly a year now. None of the shops I've trained at had any platforms on "top" of Kubernetes. They all ran Kubernetes directly from the source. And we're talking about some big enterprises here, not mom and pop shops.

When an enterprise runs Kubernetes directly from the source how do they deal with bugs and support ? Doesn't that need some vendor backing with tight SLAs ?

> Nobody ever deploys kub alone in production.

We do: https://kubernetes-on-aws.readthedocs.io/en/latest/admin-gui...

There are only a few AWS integration components we added, e.g. to use the "new" AWS ALB (see the linked text for details).

> Nobody ever deploys kub alone in production.

We do. I work at SAP, and we run our company-wide OpenStack on pure Kubernetes on CoreOS's Container Linux. [1] We do use Docker (the container runtime) because it comes with CoreOS, but no other Docker product as far as I'm aware. I've been working with Kubernetes for quite some time now, and honestly don't know what else you would need on top of it (except for some Continuous Integration tool, of course, but that's already a staple of any well-organized agile team, no matter the platform).

[1] I mean the API and orchestrator parts, not the customer VMs themselves. These sit on traditional hypervisors.

Of interest, SAP is a Platinum member of the Cloud Foundry Foundation and has a certified CF distribution, SAP Cloud Platform.

Disclosure: I work for Pivotal, another Foundation member, which also sells a commercial CF distribution.

Ah, yeah, the CF guys are from another team. They deploy their stuff on (among other things) the VMs created by the OpenStacks running within our Kuberneteses, though. It's turtles all the way down. :)

That's more turtles than I've typically seen. How're you deploying k8s?

Bare-metal with homebrew automation. We install CoreOS via PXE boot, and during the installation it also sets up a Kubelet as an rkt container. The Kubelet then spins up the other k8s components via manifests. The pod and service networks are routed via BGP using our own https://github.com/sapcc/parrot

Later this year, we will go back and evaluate the maturing k8s administration landscape. Our current approach has a few drawbacks, e.g. it requires a CoreOS reinstall to upgrade k8s cleanly (since all the magic happens in cloud-init and Ignition).

Could you email me on my work address? I may have something of interest to share. I'm just not sure if we've made it public yet.

See my clarifying comment: https://news.ycombinator.com/item?id=13788426

Especially since OpenShift uses both Docker and Kubernetes...

So Docker is like Openshift, except openshift uses docker as a component? Very confusing..

Openshift uses a very small subset of Docker. That subset is now available standalone as containerd, in part to allow Openshift to no longer depend on what is essentially a competing platform. I expect lits of constructive open-source collaboration with Red Hat on containerd.

This is why it's important to clarify what "Docker" means in context. Kube and OpenShift DO use Docker (the lower-level infrastructure parts of it, but not the higher-level platformy parts of it).

That represents the evolution of the containerd-vs-docker split, and (to me) seems totally rational.

> Kubernetes is a component (like containerd or swarmkit)

That's a bit of stretch. Everything that people use to build something bigger is a "component", but that doesn't make it not a platform.

Kubernetes is absolutely a platform, in that it is the base layer on which higher-level systems are built. It's somewhat less opinionated than OpenShift (which is literally Kubernetes++) or Docker (the full stack), but that is by design. Opinions are too fickle - Kubernetes is here to service the evolving fashion of opinions, while providing durable base abstractions.

That's totally fair. Maybe I should have used to word "product" instead of "platform".

THAT is true. Kubernetes on its own is not a product, per se. There is no one company behind it. No legally binding support contract. etc.

It is the basis for many products (plural) and an ecosystem, which is really what we wanted to achieve.

> Kubernetes is a component (like containerd or swarmkit), while Docker is a platform

That's a really interesting angle to take on it. I think most users of Kubernetes would view it as the opposite; that K8s is the platform and Docker is just one component of that platform. It probably depends on which camp you've really bought into.

Yes, that is a common misunderstanding with the kubernetes community. We are correcting that misunderstanding with a few simple steps:

- What kubernetes needs from Docker is a simple and robust container runtime. We are spinning out containerd (the core container runtime that powers the Docker platform) to provide exactly that. We are actively working with the Kubernetes community to make sure containerd is a perfect fit for kubernetes to integrate - a better fit than Docker itself, in fact, since it will be much smaller and change only very slowly. See https://containerd.tools and https://blog.docker.com/2017/02/containerd-summit-recap-slid...

- This in turn will free Docker to focus on serving its userbase of developers and enterprises, which do want an integrated platform. Take a look at Docker for Mac/Windows or Docker for AWS/Azure for a sense of where we are taking the platform.

- If you ask the core kubernetes maintainers, they will tell you that kube is intended to be the "kernel" of your distributed system, and it's up to you to build a platform on top. So in that way, I think we agree that kubernetes is ultimately a component - nothing derogatory about that!

- You mention "camps". I think this evolution is very exciting because it allows us to move beyond the concept of camps. With containerd, a lot of bridges are already being built - engineers are collaborating peacefully and focusing on solving technical problems, which is a huge relief to everyone. Nobody likes drama.

- Lastly, we are making sure Docker is a very modular and loosely coupled platform. So, who knows? If enough of our customers ask us, maybe we'll eventually integrate kubernetes as an optional component ;) The point is, we have an opportunity to refocus the conversation on technical tradeoffs rather than silly pissing contests.

For all these reasons I think 2017 will be a good year for the entire container community.

> If enough of our customers ask us, maybe we'll eventually integrate kubernetes as an optional component

I have agitated for a long time that it's silly to be competing at the layer of orchestration - it's not a revenue-producing product on its own. I'd love to see more alignment here. At this point, the systems are very similar in a number of facets.

We're wasting a lot of time copying features and ideas back-and-forth, when we could be pushing the state of the art forward faster.

My understanding is Red Hat is generating more revenue than Docker selling to the enterprise market. Is this true, and if so, how does Docker plan to beat them?

Why does Docker Inc have to beat Red Hat? It's a big, growing market, enough cake for everyone?

Aren't unicorn valuations based on the likelihood of winning a winner-take-all race?

No, they're based on the likelihood of achieving massive growth in revenue. In consumer markets that often requires a winner-takes-all race. In the enterprise market, which is Docker's market, winner-take-all is not as central because enterprise buyers care more about interoperability and integrations of many products made by many vendors.

This is why, for example, Microsoft is seeing much more success with less tight coupling of Windows, Azure and Office.

Yet Docker is embracing "tight coupling" if not in the architecture ('batteries not included') then certainly in the marketing of their platform.

If you use Docker it's expected (by Docker) that you will use Swarm. And now it's expected that your organization will use EE (is that Java EE? no it's Docker EE.)

Docker followed the Apple II model into the enterprise, it was a fancy typewriter.

Our motto is "batteries included but removable". We make sure the platform works great out of the box, and offers a smooth integrated experience. That is a big differentiator for Docker.

At the same time, we also make sure you can pop the hood, mess with the components directly, and swap them out in various ways. You can do this within the Docker ecosyste with Docker plugins (for things like networking, storage, logging, authorization); or you can do it outside the ecosystem by hitting the low-level open-source components directly: containerd/runc, swarmkit, notary, libnetwork, infrakit.. All these components are usable standalone, and Docker preserves the loose coupling.

You're right that currently Docker does not offer swappable orchestration - not because we don't want to, but because it's hard to do that without affecting the quality of the platform. Sometimes excessive abstraction leads to bad engineering.

In early versions of Docker Swarm we experimented with pluggable support for Mesos, Kubernetes etc. It worked in demos but we didn't find it fit for production.

I hope this helps understand our approach better.

In a growth market you don't have to beat anyone. You just have to deliver enough value to enough customers to capture part of that growth in the form of revenue. Which is the purpose of Docker EE :)

More importantly than any of that, to capture any revenue you need to have a business model where you actually bill something!

RedHat has OpenShift and support contracts.

Google/AWS bill the usage directly, and get returns on other products you use.

Docker didn't have much to sell.

Can you explain how Docker has better security then OpenShift? (asking to learn, not a challenge).

Off the top of my head:

- End-to-end content trust with crypto signatures and verifications using Notary/TUF https://docs.docker.com/engine/security/trust/content_trust/

- Secrets management with encrypted storage and transport (https://blog.docker.com/2017/02/docker-secrets-management/)

- A vulnerability scanner that can detect vulnerabilities in arbitrary binaries without distro lock-in (ie. even if your developer built from source on a non-Red Hat distro, it will still catch vulnerabilities) https://docs.docker.com/datacenter/dtr/2.2/guides/admin/conf...

- Secure orchestration out-of-the-box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk...

- Somewhat counter-intuitively, the default security profile is more secure in Docker than in Openshift, because the focus on "systemd everywhere" requires loosening the sandbox to allow systemd's tentacles to get through. In the past Red Hat has actually introduced CVEs in their forked version of Docker that didn't exist in the official Docker.

- In Docker for AWS, Docker for Azure, Docker for Mac, Docker for Windows, we embed a specialized Linux distro that is trimmed down and locked down to the extreme, making OS surface area much much smaller than a traditional OS like Red Hat.

Reply on news.ycombinator.com