My worst fears confirmed. Docker finally realized they couldn't get a piece of the orchestration pie and are resorting to making Docker a freemium product. Very sad. Wished they had gone so many different directions than this. Knew things were going to get bad then they pushed out their terrible new versioning scheme that every developer had a negative reaction to on the PR. Docker was great, but now I'm really wishing their was a fork or alternative with feature parity.
There's no need to worry. `Docker CE` is the exact same Docker as before - just renamed to clarify the relationship to Docker EE.
Docker is still open-source; it still has all the same features; it has the same maintainers and contribution roles; it has the same roadmap of features. And we still welcome pull requests.
Meanwhile we have been breaking the components of Docker into standalone upstream projects: containerd, swarmkit, libnetwork etc. So there are more and more ways to use parts of Docker without being forced to use all of it. We will continue doing that.
Is there any detailed fear that you can describe? I will do my best to reassure you.
It may be only a name change today, but relabeling the docker to 'CE' opens up a world of possibilities where 'enterprise features' get shipped in the 'EE' and the 'CE' turns into watered down freemiumware. Honestly I don't believe that this 'clarifies' an existing relationship. DDC was the product and the locked down engine was just a part of that product. This makes it excruciatingly clear that DDC failed to take off and now we're going another level down to making the engine itself a product, which comes with all sorts of questions about what will really be driving the roadmap in the future. What would have been wrong with focusing on monetizing Docker Hub and leaving the tool alone like Github and Git? Docker Hub doesn't look like it's been updated in ages... I also don't see why anyone should be thrilled that this split is being made when you can only offer a 1 year support window for 'EE'? How is anyone going to explain to their manager that what the cool tool they were sold on is now just the 'community version' and if they want support they can only get it for one year at a time? Do you know how long it takes to go through the upgrade process in a large enterprise? We'll be lucky if we get six months or less of support before we have to upgrade again. Also, I feel no urge to go and create pull requests for your community edition product. If Docker were still completely free and community driven I would feel compelled to do my part, but I'm not building software for you to sell.
I'll detail my fears. I'm afraid investment and corporate structure, specifically of infrastructure companies, directly affects the security, reliability and trust of the infrastructure on which all of this stuff runs. I am aware maintaining shareholder value for such a company may be difficult given infrastructure (or fractional infrastructure) may be asked to remain open, transparent and trustworthy for the user's benefit.
To use a bit of a biased argument, I've been told by several infrastructure VCs that the infrastructure market is currently difficult to invest in because of the uncertainty the technology behind it has brought us. I don't trust that continued traditional investments behind producing those infrastructure offerings are a rational choice for users. However, at the end of the day, only the users can speak to that claim. I can only speak my mind on the matter.
Unfortunately, it's difficult to trust a service or software built on closed technologies because seeing inside the service or software becomes difficult, expensive or impossible. The combination of desired outcomes (easy infrastructure) and risk bias (implied trust) presents itself as a dangerous one because leads to cognitive dissonance where the market must literally believe two things at once: We have to TRUST this service or software because We NEED this service or software.
I'd prefer we all work together to solve these conflicted views with "enterprise" software offerings, especially those involved in building infrastructure, but my observations say that we are more likely to not work together because of existing investment structures. Perhaps this will change over time as new models emerge. For now, I remain sceptical at best about the way we're investing and growing the infrastructure market.
Echoing @shykes below[1], Docker had premium paid products before this launch, but we're trying to make that clearer and to simplify the product lineup.
Note that Docker CE is _just_ as good as the Docker you were using yesterday. In addition, the version lifecycle improvements are designed to get new features into Docker users' hands faster (with monthly Edge releases) and to improve maintainability by overlapping the maintenance windows of free Docker CE quarterly releases.
> Docker CE is _just_ as good as the Docker you were using yesterday
The concern is that the Docker CE we'll be using in 2020 will be missing useful features that Docker EE has, and which vendors who ship containers/Dockerfiles for their products will rely on.
Docker has always been freemium. Not sure why you'd fear that even if it weren't the case. IMO freemium OSS is a good thing, this is how "free" software gets funded.
Looks like Docker is still Docker, they just tacked on CE at the end. The enterprise edition looks like a promising (and more obvious) way to monetize.
I don't think this is 100% fair. Docker (the infrastructure)is relied on by SO MANY people and projects that I don't see it going away, even if Docker (the company) shut their doors tomorrow.
Now, it's not clear to us in the public HOW MUCH of Docker (the software project)_would fall into that category. From the outside, it appears that there is a lot of community around the infrastructure, and somewhat less community around the higher layers (e.g. SwarmKit).
It's true that 1 year support is not as long as many enterprise infrastructure products. We plan to expand it over time. But we've found that it's a good fit for our current offering, and the value enterprises are getting from it.
- Keep in mind we are releasing Docker EE quarterly, and supporting every release for a year. This is attractive for enterprises who are adopting Docker in part to make their software practice more agile. They don't want to be forced to upgrade every 3 months. But they appreciate that they can. This works for Docker because it sits relatively higher on the stack. If we were providing a storage appliance, or a traditional host operating system, this wouldn't make sense
- For a company of our size and maturity (300 people, 4 year-old free product, 18 months-old paid product), earning the trust of large conservative enterprises can be hard. We do it by being honest about our abilities, conservative in what we promise, and going above and beyond to deliver on what we promised. In this case, we simply weren't confident that we could promise more than 4 simultaneous EE releases (1 year support x 4 releases per year). That might cost us sales opportunities now with more conservative buyers, but those buyers would probably have been unhappy with us anyway. We can get them later - when our product is more mature and our release and support infrastructure is more robust.
EDIT: I see other commentors confidently stating what is and isn't enterprise-ready. Remember that enterprises are, by definition, very large. There are many departments with different goals and different priorities. For some of them, Docker EE with quarterly releases and 1-year support is a good fit. For other, it's not. And that's OK.
As a relatable data point, Pivotal Cloud Foundry does not have LTS releases yet. We also release quarterly and make very frequent updates, usually from upstream CVEs, through Pivotal Network.
Enterprises want LTSes because legacy platforms are a nightmare to install, operate and upgrade. It becomes less important as the platform itself becomes less bestial.
Ultimately, enterprises want outcomes. Any given checklist item from the buying department usually represents scar tissue that may or may not still be relevant. New platforms -- Cloud Foundry, OpenShift v3, Docker EE, whichever of the thousand blooming Kubernetes offerings will succeed -- are in a position to renegotiate from first principles.
You might want to look into BOSH. It's a large part of the operability secret sauce for Cloud Foundry.
Disclosure: I work for Pivotal, we're ostensibly competitors due to the increasing overlap between Docker EE and Cloud Foundry.
That was my thought as well. Docker not supporting a version for longer than a year is a no-go. This is not enterprise ready. It's barely dev ready because my devs need a stable environment to work in, not something that's going to puke every few weeks.
Just because something isn't guaranteed not to puke every few weeks doesn't mean that it will. I've been using Docker for a while now and it has been very rare that I run into issues because of an update.
Look, CE vs EE feature gating aside I think what rubs me the wrong way the most here is the abandoning of SemVer. I was following the PR where it happened and the reasoning seemed to boil down to a bunch of hand-wavey "just because". When 1.13.1 was released I installed it being pretty confident that it was only bugfixes and that's how I perceive the rest of the world to work. When I install 17.04 CE how will I have any idea of the impact on my servers vs 17.03 CE? I mean I read CHANGELOGS and stuff when I can but there's a certain level of comfort knowing that the people who create and package the software have spent enough time to figure out it's just a bunch of non-breaking bugfixes and I'm safe to send it out pretty quickly.
EDIT: I've seen somewhere that it's supposed to mirror the Ubuntu naming scheme but that's fundamentally different. I know that the "X.04 LTS" releases are stable-ish and they only come out every 2 years (right? Going off the top of my head here), which is waaaaay different than monthly releases in terms of time spent vetting the stability IMO.
Hi, in addition to what others have said in response, note that the actual version is 17.03.0.
Patch releases will be 17.03.X, just like 1.12.0 was the initial 1.12 release has 6 patch releases after, final one being 1.12.6.
Docker has never used SemVer, so no there has been no abandoning of it. People, including you, seem to have been confused by the versioning scheme into thinking we did. Other people complained that we did not. There has always been a deprecation scheme and an API compatibility scheme that has not been SemVer, and this is not changing. Now at least the version numbering scheme makes it clear that this is not SemVer.
We take backwards compatibility seriously. If you encounter problems updating from one version of Docker to the next (whether from 1.13.1 to 17.03 or from 17.03 to the upcoming 17.04), please open an issue on docker/docker so that can fix the incompatibility and improve our change process.
Quoting from the blog post:
The Docker API version continues to be independent of the
Docker platform version and the API version does not
change from Docker 1.13.1 to Docker 17.03. Even with the
faster release pace, Docker will continue to maintain
careful API backwards compatibility and deprecate APIs and
features only slowly and conservatively. And in Docker
1.13 introduced improved interoperability between clients
and servers using different API versions, including
dynamic feature negotiation.
Docker takes backwards compatibility so seriously they wholesale block the client and server from communicating with each other if they differ by a single minor version.
Docker takes backwards compatibility so seriously they've released multiple versions of a docker registry all with completely new APIs.
The quarterly ("stable channel") CE releases (17.03, 17.06 and so on) are supported for 4 months, and will not get new features during that period. EE quarterly releases have a 1 year support period, and also won't get new features.
During the support period, bug fixes will get back ported to those versions and released as "patch" releases (e.g. 17.03.1).
When installing, you can choose to install either the "stable" (quarterly) channel, or the "edge" (monthly) channel.
This seems to carefully avoid making any promises about the future. Where SemVer _does_ make promises.
Also, picking a date for versioning is weird as it doesn't contain any information other than when the Changelog was set in stone. Too bad this decision was made, and Docker choose not to value the stability of SemVer.
What I don't understand is now there are two repositories for ubuntu for docker: apt.dockerproject.org and download.docker.com/linux/ubuntu. Will both of these continue to exist?
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!
> 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.
"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.
> 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.
> 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.
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?
Whilst Kubernetes is really cool and has a lot of nice features I think, at the moment, it's lacking in some areas that are likely to be important for Enterprise customers who are likely to be interested in this Docker EE setup.
Specifically things like best practice guides for securing Kubernetes are currently thin on the ground compared to Docker which has a fair amount of information covering that sort of thing.
Also the Kubernetes security model is still being developed with things like locking down the kubelet API still to come in 1.6. Whilst that's less likely to be important for some companies, enterprises tend towards solutions with that sort of thing sorted out.
I would never deny that there's a lot of work to do, but let's be clear: Kubernetes' security model is evolving in concert with a large number of high-profile users' demands.
Designing security in the absence of real customers would have been a mistake.
Interestingly we had many "hard" problems with Docker itself (race conditions, stuck Docker daemon) so my confidence in Docker getting the Enterprise thing right is not very high.
They also announced the Docker Certified program [1] but with no technical details about what that involves beyond hand waving that "containers are tested, built with Docker recommended best practices, are scanned for vulnerabilities, and are reviewed before posting on Docker Store."
Is there some set of automated tests my container has to pass? Can I run them today? More to the point, how much will it cost me?
Thank you. I think you buried the lede at the bottom of the page though - the certification program is free currently.
On the other hand it looks like you have to purchase an EE license to test your code for certification: "Content that runs on the Docker Community Edition may be published in the Store, but will not be supported by Docker nor is it eligible for certification".
So looks like a minimum of $750 for one node EE license to play?
Docker CE, Docker EE... was docker purchased by Oracle?
The only sad part of this annoucement is the part were they talk about "certifications" this will open the world to the next stage "docker developer certifications" and will soon start seeing HR departments asking for it.
- I'd be more comfortable using Docker if we had alternative runtimes, Docker being just one (maybe primus-inter-pares) among them; I'm aware of runC but don't know if Docker images are realistically portable (after all, Docker with its quarterly release and only 1 year enterprise support seems relative immature still)
- I'm not 100% sure on the legal situation re: distributing Linux and GNU userland binaries along with non-F/OSS commercial software; the practice of running eg `apt-get` and fetch the base OS userland on first start (and to a lesser degree, using union'd file systems, though I like that part actually), for me, has the smell of circumventing implied GPL conditions (but IANAL)
- in that light, I'd like a characterization of Docker vs. basic built-in POSIX/Linux/FreeBSD chroot jails
- the permissions story (must start as root, effective UID in container typically not resolvable with /etc/passwd) is suboptimal
> I'm aware of runC but don't know if Docker images are realistically portable
Quay, the Docker Registry competitor from CoreOS, has automatic support for converting Docker images into rkt images (as in: you push the Docker image, and pull with rkt, and it supposedly just works). I don't know how well it works in practice, though I can't imagine (from the top of my head) why it shouldn't. A Docker image is mostly a layered tarball with a few fields of metadata. Nothing particularly obscure.
> I'm aware of runC but don't know if Docker images are realistically portabl
(It wasn't clear from your comment if you were aware of this)
Since last year (docker 1.11) docker itself no longer is a runtime, and uses runC as the default runtime (https://blog.docker.com/2016/04/docker-engine-1-11-runc/)
> I'm aware of runC but don't know if Docker images are realistically portable
Until recently Cloud Foundry ran Docker images with a custom runtime backend (garden-linux). It's since switched to using runC (garden-runc). So in principle it was always possible to do this.
A major reason for the switch was to reduce duplicated effort.
Disclosure: I work for Pivotal, a major contributor to Cloud Foundry. Insofar as Docker move towards the value line, we're competitors.
Readit News
Docker is still open-source; it still has all the same features; it has the same maintainers and contribution roles; it has the same roadmap of features. And we still welcome pull requests.
Meanwhile we have been breaking the components of Docker into standalone upstream projects: containerd, swarmkit, libnetwork etc. So there are more and more ways to use parts of Docker without being forced to use all of it. We will continue doing that.
Is there any detailed fear that you can describe? I will do my best to reassure you.
To use a bit of a biased argument, I've been told by several infrastructure VCs that the infrastructure market is currently difficult to invest in because of the uncertainty the technology behind it has brought us. I don't trust that continued traditional investments behind producing those infrastructure offerings are a rational choice for users. However, at the end of the day, only the users can speak to that claim. I can only speak my mind on the matter.
Unfortunately, it's difficult to trust a service or software built on closed technologies because seeing inside the service or software becomes difficult, expensive or impossible. The combination of desired outcomes (easy infrastructure) and risk bias (implied trust) presents itself as a dangerous one because leads to cognitive dissonance where the market must literally believe two things at once: We have to TRUST this service or software because We NEED this service or software.
I'd prefer we all work together to solve these conflicted views with "enterprise" software offerings, especially those involved in building infrastructure, but my observations say that we are more likely to not work together because of existing investment structures. Perhaps this will change over time as new models emerge. For now, I remain sceptical at best about the way we're investing and growing the infrastructure market.
Echoing @shykes below[1], Docker had premium paid products before this launch, but we're trying to make that clearer and to simplify the product lineup.
Note that Docker CE is _just_ as good as the Docker you were using yesterday. In addition, the version lifecycle improvements are designed to get new features into Docker users' hands faster (with monthly Edge releases) and to improve maintainability by overlapping the maintenance windows of free Docker CE quarterly releases.
[1]: https://news.ycombinator.com/item?id=13774420
The concern is that the Docker CE we'll be using in 2020 will be missing useful features that Docker EE has, and which vendors who ship containers/Dockerfiles for their products will rely on.
I would note this is a non-apology, given it's stating you are "sorry" someone doesn't like a decision that was made.
Now, it's not clear to us in the public HOW MUCH of Docker (the software project)_would fall into that category. From the outside, it appears that there is a lot of community around the infrastructure, and somewhat less community around the higher layers (e.g. SwarmKit).
Dead Comment
I thought one of those most important enterprisy things would usually be a long support timeframe. One year isn't exactly very LTS.
- Keep in mind we are releasing Docker EE quarterly, and supporting every release for a year. This is attractive for enterprises who are adopting Docker in part to make their software practice more agile. They don't want to be forced to upgrade every 3 months. But they appreciate that they can. This works for Docker because it sits relatively higher on the stack. If we were providing a storage appliance, or a traditional host operating system, this wouldn't make sense
- For a company of our size and maturity (300 people, 4 year-old free product, 18 months-old paid product), earning the trust of large conservative enterprises can be hard. We do it by being honest about our abilities, conservative in what we promise, and going above and beyond to deliver on what we promised. In this case, we simply weren't confident that we could promise more than 4 simultaneous EE releases (1 year support x 4 releases per year). That might cost us sales opportunities now with more conservative buyers, but those buyers would probably have been unhappy with us anyway. We can get them later - when our product is more mature and our release and support infrastructure is more robust.
EDIT: I see other commentors confidently stating what is and isn't enterprise-ready. Remember that enterprises are, by definition, very large. There are many departments with different goals and different priorities. For some of them, Docker EE with quarterly releases and 1-year support is a good fit. For other, it's not. And that's OK.
Enterprises want LTSes because legacy platforms are a nightmare to install, operate and upgrade. It becomes less important as the platform itself becomes less bestial.
Ultimately, enterprises want outcomes. Any given checklist item from the buying department usually represents scar tissue that may or may not still be relevant. New platforms -- Cloud Foundry, OpenShift v3, Docker EE, whichever of the thousand blooming Kubernetes offerings will succeed -- are in a position to renegotiate from first principles.
You might want to look into BOSH. It's a large part of the operability secret sauce for Cloud Foundry.
Disclosure: I work for Pivotal, we're ostensibly competitors due to the increasing overlap between Docker EE and Cloud Foundry.
Deleted Comment
Backwards compat and LTS already comes up a lot with enterprise support, requiring an annual upgrade project will only complicate it
EDIT: I've seen somewhere that it's supposed to mirror the Ubuntu naming scheme but that's fundamentally different. I know that the "X.04 LTS" releases are stable-ish and they only come out every 2 years (right? Going off the top of my head here), which is waaaaay different than monthly releases in terms of time spent vetting the stability IMO.
Quoting from the blog post:
- https://blog.docker.com/2017/03/docker-enterprise-edition/Docker takes backwards compatibility so seriously they've released multiple versions of a docker registry all with completely new APIs.
Sorry if I don't buy it.
During the support period, bug fixes will get back ported to those versions and released as "patch" releases (e.g. 17.03.1).
When installing, you can choose to install either the "stable" (quarterly) channel, or the "edge" (monthly) channel.
Also, picking a date for versioning is weird as it doesn't contain any information other than when the Changelog was set in stone. Too bad this decision was made, and Docker choose not to value the stability of SemVer.
In the future we will phase out the apt.dockerproject.org repo.
> [...] 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!
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 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.
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 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.
Specifically things like best practice guides for securing Kubernetes are currently thin on the ground compared to Docker which has a fair amount of information covering that sort of thing.
Also the Kubernetes security model is still being developed with things like locking down the kubelet API still to come in 1.6. Whilst that's less likely to be important for some companies, enterprises tend towards solutions with that sort of thing sorted out.
Designing security in the absence of real customers would have been a mistake.
Interestingly we had many "hard" problems with Docker itself (race conditions, stuck Docker daemon) so my confidence in Docker getting the Enterprise thing right is not very high.
https://kubernetes.io/docs/getting-started-guides/rkt/
Is there some set of automated tests my container has to pass? Can I run them today? More to the point, how much will it cost me?
[1] https://blog.docker.com/2017/03/announcing-docker-certified/
On the other hand it looks like you have to purchase an EE license to test your code for certification: "Content that runs on the Docker Community Edition may be published in the Store, but will not be supported by Docker nor is it eligible for certification".
So looks like a minimum of $750 for one node EE license to play?
The only sad part of this annoucement is the part were they talk about "certifications" this will open the world to the next stage "docker developer certifications" and will soon start seeing HR departments asking for it.
[root@sandbox ~]# yum-config-manager --add-repo https://download.docker.com/linux/centos/docker.repo Loaded plugins: fastestmirror adding repo from: https://download.docker.com/linux/centos/docker.repo grabbing file https://download.docker.com/linux/centos/docker.repo to /etc/yum.repos.d/docker.repo Could not fetch/save url https://download.docker.com/linux/centos/docker.repo to file /etc/yum.repos.d/docker.repo: [Errno 14] HTTPS Error 403 - Forbidden
[1] https://store.docker.com/editions/community/docker-ce-server...
Also check out the full docs: https://docs.docker.com/engine/installation/linux/centos/
In the meantime here is the correct URL: https://download.docker.com/linux/centos/docker-ce.repo
- I'd be more comfortable using Docker if we had alternative runtimes, Docker being just one (maybe primus-inter-pares) among them; I'm aware of runC but don't know if Docker images are realistically portable (after all, Docker with its quarterly release and only 1 year enterprise support seems relative immature still)
- I'm not 100% sure on the legal situation re: distributing Linux and GNU userland binaries along with non-F/OSS commercial software; the practice of running eg `apt-get` and fetch the base OS userland on first start (and to a lesser degree, using union'd file systems, though I like that part actually), for me, has the smell of circumventing implied GPL conditions (but IANAL)
- in that light, I'd like a characterization of Docker vs. basic built-in POSIX/Linux/FreeBSD chroot jails
- the permissions story (must start as root, effective UID in container typically not resolvable with /etc/passwd) is suboptimal
Quay, the Docker Registry competitor from CoreOS, has automatic support for converting Docker images into rkt images (as in: you push the Docker image, and pull with rkt, and it supposedly just works). I don't know how well it works in practice, though I can't imagine (from the top of my head) why it shouldn't. A Docker image is mostly a layered tarball with a few fields of metadata. Nothing particularly obscure.
* https://blog.docker.com/2016/12/introducing-containerd/ * https://runc.io/
(It wasn't clear from your comment if you were aware of this) Since last year (docker 1.11) docker itself no longer is a runtime, and uses runC as the default runtime (https://blog.docker.com/2016/04/docker-engine-1-11-runc/)
Additional OCI compliant runtimes can be configured on the daemon (https://docs.docker.com/engine/reference/commandline/dockerd...), and can be selected per container, using the "--runtime" option on "docker run" (https://docs.docker.com/engine/reference/commandline/run/#op...)
Until recently Cloud Foundry ran Docker images with a custom runtime backend (garden-linux). It's since switched to using runC (garden-runc). So in principle it was always possible to do this.
A major reason for the switch was to reduce duplicated effort.
Disclosure: I work for Pivotal, a major contributor to Cloud Foundry. Insofar as Docker move towards the value line, we're competitors.