
Docker Enterprise Edition - frostmatthew
https://blog.docker.com/2017/03/docker-enterprise-edition/
======
ilovecaching
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.

~~~
shykes
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.

~~~
ilovecaching
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.

~~~
benmusch
Seems unlikely that there would be 'enterprise features'... the value of
Docker is that you can send a Dockerfile somewhere and it will work
identically on each system. If they changed the feature-set of Docker EE it'd
undermine the reason people use their product

~~~
majewsky
I'd guess that if enterprise features were to appear, it would be higher up in
the stack then "sending a Dockerfile somewhere". Container runtimes are
becoming (or have already become) a commodity, so people are now chasing to
get a slice of the orchestration pie before everyone standardizes on
Kubernetes.

------
tobltobs
> Each Docker EE release is supported and maintained for one year and receives
> security and critical bugfixes during that period.

I thought one of those most important enterprisy things would usually be a
long support timeframe. One year isn't exactly very LTS.

~~~
shykes
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.

~~~
jacques_chester
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.

------
ascendantlogic
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.

~~~
friism
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.
    

\- [https://blog.docker.com/2017/03/docker-enterprise-
edition/](https://blog.docker.com/2017/03/docker-enterprise-edition/)

~~~
pdeuchler
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.

Sorry if I don't buy it.

~~~
shykes
> _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._

That has been fixed. Note that this limitation (although it turned out to be
annoying, which is why we removed it), did _not_ actually break reverse
compatibility in the API. It just made the client excessively paranoid about
reverse compatibility. In other words the client didn't trust the stability of
the daemon enough, even though the daemon in pratice almost never broke
compat.

> _Docker takes backwards compatibility so seriously they 've released
> multiple versions of a docker registry all with completely new APIs._

I'm not sure what you're referring to, but I will look into it. Is this still
affecting you? Or is it a past problem you are still pissed off about?

~~~
pdeuchler
With all due respect, this is exactly the attitude that will prevent
enterprises from ever taking Docker seriously.

Why should enterprises trust you on backwards compatibility when longstanding
issues with backwards compatibility were just fixed and then glossed over like
this ("it never broke in practice because we forcibly made you update")?
Docker has repeatedly made poor decisions with really poor optics both in the
open source community and with their product, this is just one example, and
asking enterprises to just trust you now while not even providing the support
terms most of the enterprise world demands is doing the exact opposite of
inspiring trust.

Do you honestly not remember sunsetting the python docker registry _just a
year and a half ago_ and then introducing a brand new golang registry product
with an entirely different API? Because that's precisely what enterprises pay
to avoid, they don't shell out absurd money for LTS versions to hit a
constantly moving target. And please don't patronize me with "past problem",
some of us lowly end users of your product had to clean up that mess just to
get day to day operations working again. Forgive me if I'm gunshy.

~~~
shykes
My intention is not dismiss your complaint, but to gather more details so I
can help.

Here is a list of known past breaking changes in the Docker API.
[https://docs.docker.com/engine/breaking_changes/](https://docs.docker.com/engine/breaking_changes/)

If you have encountered a breaking change that is not on the list, could you
mention it either here or on
[https://github.com/docker/docker.github.io](https://github.com/docker/docker.github.io)
?

Some of your claims about breaking backwards compatibility above are
incorrect. I am trying my best to point that out without seeming dismissive of
your overall point - which I think is that Docker can do more to improve
stability and backwards-compat. I agree with that point.

------
grabcocque
I don't see how a freemium model solves the fundamental problem of Kubernetes
eating their lunch. If anything surely this exacerbates it?

~~~
shykes
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](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!

~~~
tyingq
_" 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.

~~~
shykes
> _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.

~~~
majewsky
> 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.

~~~
jacques_chester
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.

~~~
majewsky
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. :)

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

~~~
majewsky
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](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).

~~~
jacques_chester
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.

------
programd
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?

[1] [https://blog.docker.com/2017/03/announcing-docker-
certified/](https://blog.docker.com/2017/03/announcing-docker-certified/)

~~~
friism
Here's a link to resources on how to start publishing content:
[https://success.docker.com/store](https://success.docker.com/store)

~~~
programd
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?

------
SadWebDeveloper
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.

~~~
kordless
Providing certification is typically a means of establishing trust in the
marketplace and opens up new revenue. We saw this with OpenStack.

------
coolowencool
Following the directions here[1] - adding Docker CE to CentOS 7.3 is broken
right now:

[root@sandbox ~]# yum-config-manager --add-repo
[https://download.docker.com/linux/centos/docker.repo](https://download.docker.com/linux/centos/docker.repo)
Loaded plugins: fastestmirror adding repo from:
[https://download.docker.com/linux/centos/docker.repo](https://download.docker.com/linux/centos/docker.repo)
grabbing file
[https://download.docker.com/linux/centos/docker.repo](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](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...](https://store.docker.com/editions/community/docker-ce-server-
centos?tab=description)

~~~
cpuguy83
Thanks for reporting! Looks like a typo on the store page install
instructions, having this updated.

In the meantime here is the correct URL:
[https://download.docker.com/linux/centos/docker-
ce.repo](https://download.docker.com/linux/centos/docker-ce.repo)

~~~
coolowencool
That resolved it. Thanks!

------
tannhaeuser
To the Docker guys/gals around here

\- 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

~~~
friism
Docker is trying to alleviate this concern by spinning out and trying to
foster alternative runtimes, check out containerd and runc:

* [https://blog.docker.com/2016/12/introducing-containerd/](https://blog.docker.com/2016/12/introducing-containerd/) * [https://runc.io/](https://runc.io/)

~~~
thaJeztah
> 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/](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...](https://docs.docker.com/engine/reference/commandline/dockerd/#docker-
runtime-execution-options)), and can be selected per container, using the
"\--runtime" option on "docker run"
([https://docs.docker.com/engine/reference/commandline/run/#op...](https://docs.docker.com/engine/reference/commandline/run/#options))

------
huksley
As I understand one of the target audiences of Docker EE is RHEL/Docker users.
New version of documentation now says:

\- Docker Community Edition (Docker CE) is not supported on Red Hat Enterprise
Linux.

Previous version of documentation have had no such sentence.

~~~
nul_byte
Also EE support for RHEL:
[https://store.docker.com/editions/enterprise/docker-ee-
serve...](https://store.docker.com/editions/enterprise/docker-ee-server-rhel)

------
lenovouser
Nice, no features anymore for CE. I really love the path Docker has taken in
the past months...

I wish I could switch to rkt, but there are so many things such as docker-
compose which don't exist as equivalent for rkt yet.

~~~
shykes
> _Nice, no features anymore for CE_

What do you mean by that? Docker CE will continue to ship features in exactly
the same way as before. If anything the new monthly edge releases will allow
us to ship features faster. A common complaint from enterprise customers was
that they were tied to the same release trains as the community version. Now
that the CE and EE releases are clearly distinct, CE has more flexibility to
move fast.

~~~
human_error
That's how it always starts. EE gets introduced, Company assures everyone they
will have the same features then CE goes down the hill in time. I want to
believe you though.

~~~
shykes
What's hilarious is that Docker is frequently criticized for "moving too fast"
and "adding too many features". Now it seems we're going to be suspected of
not adding enough features... Which is it?

------
JustinAiken
Ugh, Docker for Mac now has two separate ads in it's 9 options in the menubar
:/

------
drdaeman
A possibly bad thing I see about this, there seems to be a segmentation of
sorts. I've noticed there are now a few conflicting editions of Docker Engine.
There's CE and EE now, then there's some version that Docker Cloud Agent
bundles, and probably more. (Maybe I'm wrong, though)

Maybe that's just me, but it would be better if there'd be one core to rule
them all, and extras would be managed by plugins/wrappers/companion daemons.
So if you have Docker Engine installed you're good to go.

~~~
shykes
One of the goals of this release is to remove this fragmentation. For example
Docker Cloud will use CE, and soon will allow you to easily upgrade to EE.

In the free / open-source side, Docker CE is the "one core to rule them all"
that you describe.

~~~
drdaeman
Oh, then it's great!

I just didn't wanted to have different daemons (server, not client), and
having to replace them if I'll want to use Cloud, EE or whatever (or stop
using that or replace them with something else, etc).

------
twelvenmonkeys
Off-ish topic. But will the last piece of the puzzle (compose) be integrated
into the Docker Go binary?

~~~
shykes
Yes. We have already started in 1.13. Check out the "docker stack" subcommand.

[https://docs.docker.com/engine/reference/commandline/stack/](https://docs.docker.com/engine/reference/commandline/stack/)

------
sandGorgon
What about swarm? you have not mentioned it in your blog post - will it
continue to be part of CE?

You guys have a big PR problem when it comes to swarm. I believe that Swarm is
a nicer, simpler alternative to those trying out kubernetes and its well worth
running in production.

But there are absolutely no case studies, success stories, etc around Swarm.
Possibly that's happening as a consequence of your Datacenter product. For
example, this entire page has zero mentions of Swarm -
[https://www.docker.com/enterprise-edition](https://www.docker.com/enterprise-
edition)

On Azure, it took me quite a while to figure out (after going through support)
that their cluster management is the pre-1.12 cluster product... not the Swarm
mode.

Then someone pointed Docker-for-Azure which is way down google search results
when you search for "azure docker swarm".

So what's the future of swarm? will you go back from being integrated to a
separate product like Datacenter? why is it conspicuous by its absence in
every post and press release? Including a path to your enterprise product.

The consequence of that is the comments on this very thread on HN : "Docker
does not implement service discovery like kubernetes".

~~~
friism
Oh, and to answer your question: Yes, Swarm is core part of Docker and is in
Docker Community Edition too!

------
JustinAiken
Uuuuuugggh. Docker for Mac now won't let you uncheck "Send usage statistics"

~~~
forgotpwtomain
Does OS X have an iptables equivalent? Does seem rather unfriendly though..

~~~
cpuguy83
Not sure how configurable it is under the hood, but it's in the "Security &
Privacy" preferences pane.

------
koolba
I don't understand what anybody would be paying for here.

If I'm already paying $OS_VENDOR to support my OS, wouldn't whatever packages
I'm running be covered as well? If not, why am I paying them?!

~~~
majewsky
$OS_VENDOR most likely only ships Docker the container runtime, not Docker all
the other shebang.

------
smugcloud
These comments are crazy. @shykes and team have done a wonderful job of making
Linux containers easier to use. They have every right to make money from that
work, and nothing Docker has done to date has concerned me with it's future.
We also run Kubernetes in Production, from source, using a custom provisioner.

------
gfunk911
Hoping this is mostly support

~~~
doubleorseven
it's all in here :
[https://www.docker.com/pricing](https://www.docker.com/pricing)

~~~
kenperkins
If you link deeper to the offerings for specific providers you get a bit more
clarity. For example, Docker EE for AWS is $0.119 per node hour, or roughly
$80/month per node.

[https://store.docker.com/editions/enterprise/docker-ee-
aws?t...](https://store.docker.com/editions/enterprise/docker-ee-
aws?tab=description)

~~~
technofiend
I have to assume some really deep discounts must be available, because
although I can see paying $80 per "node" in a small shop, when you start to
scale this doesn't make any sense. If I had a shop with 50,000 servers in it
that would be $48 million a year in docker fees. Sorry, no.

~~~
shykes
That is very typical of enterprise products. Large deployments always get
discounts. Extremely large deployments will often request "all-you-can-eat"
unlimited deployment for a flat fee.

------
falsedan
Can I license a single node & then rephrase all my support requests so they
occur on that host? Even better, can I do it with the AWS option so I only
need to pay when I find a critical bug?

------
asher_
Does anyone know why GCP isn't one of the supported cloud providers for EE?
This is surprising to me since they had docker-related offerings a long time
before AWS and Azure.

------
je42
1 year of support is better than 0 years of support.

------
elcapitan
Is there a tl;dr on the differences between enterprise and community edition?

~~~
shykes
Here you go: [https://www.docker.com/get-
docker#/edition](https://www.docker.com/get-docker#/edition)

~~~
tomjen3
Ford's this mean that we can no longer have more than one private image
server?

