Docker Enterprise Edition

https://blog.docker.com/2017/03/docker-enterprise-edition/

by frostmatthew • 9 years ago

231 201 9 years ago

blog.docker.com

grabcocque• 9 years ago

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

shykes39• 9 years ago

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!

saycheese• 9 years ago

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?

tyingq3• 9 years ago

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

013a• 9 years ago

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.

curun1r4• 9 years ago

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.

thockingoog12• 9 years ago

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.

nul_byte3• 9 years ago

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

raesene64• 9 years ago

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.

thockingoog12• 9 years ago

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.

hjacobs3• 9 years ago

Kubernetes is definitely lacking some best practice guides. We are trying to share our learnings here: https://kubernetes-on-aws.readthedocs.io/en/latest/admin-gui...

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.

esseti2• 9 years ago

But isn't kubernetes managing docker containers? or does it support anything else?

bdcravens• 9 years ago

It supports rkt:

https://kubernetes.io/docs/getting-started-guides/rkt/

Crsvoboda• 9 years ago

Check out CRI-O. Goal is to make anything OCI compliant a first class citizen in Kubernetes. https://github.com/kubernetes-incubator/cri-o/blob/master/RE...

gfunk911• 9 years ago

Hoping this is mostly support

doubleorseven• 9 years ago

it's all in here : https://www.docker.com/pricing

kenperkins• 9 years ago

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

tobltobs• 9 years ago

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.

AckSyn2• 9 years ago

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.

todd3834• 9 years ago

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.

shykes39• 9 years ago

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.

kupiakos• 9 years ago

At some point it might make sense to do something like Ubuntu: LTS releases (5 year support) every two years, and short term support often.

jacques_chester7• 9 years ago

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.

nikcub• 9 years ago

I'd like to +1 this - one year is a tough sell in a world where a 5-10 years is norm

Backwards compat and LTS already comes up a lot with enterprise support, requiring an annual upgrade project will only complicate it

shykes39• 9 years ago

Sorry about that. We will expand the support window over time.

evilduck• 9 years ago

On the other hand, expecting a company to promise a 5 year support window when they're less than 5 years old seems unrealistic.

lenovouser2• 9 years ago

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.

shykes39• 9 years ago

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.

nilved• 9 years ago

We'll see about that

lenovouser2• 9 years ago

Not sure about this, generally I have the feeling that Docker doesn't really care anymore about making a great open source container engine. They've never listened to the people who pointed out flaws in Docker which then made these guys start working on rkt. I've had a ton of issues with Docker and IPTables, Multi Host Networking, IPv6 etc. - there were solutions available most of the time but it always takes ages for them to merge it in (5+ months in some cases) or even care about basic issues such as not being able to run IPTables with docker because it bypasses IPTables en total. Adding a EE will definitely not make things better, in my opinion even worse. I think most "new" features will be put into EE so that they can bait enterprises into buying it. But maybe I am mistaken, we'll see. Like I said, not sure about it.

human_error• 9 years ago

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.

twelvenmonkeys2• 9 years ago

IMO, rkt is great since it's simple. Although I do agree in regards in how to build multi-container applications.

jzelinskie• 9 years ago

rkt's unit of execution is pods; most users are simply running pods with only one container, though.

rktnetes leverages the fact that rkt can natively execute a whole pod to avoid a lot of the extra code integrating with Kubernetes that docker requires.

amouat3• 9 years ago

I don't think this is the intention. Personally, I think the name "CE" is a bit unfortunate, as it implies what you said. However, for the time-being at least, I would expect the core Docker engine to remain the same between CE and EE.

shykes39• 9 years ago

One reason for the name change is to clarify that Docker is a product. If you're looking to use Docker as a low-level component to run containers as part of another product, then you should not use Docker: instead you should use containerd, which we have spun out of Docker for exactly that reason.

A few resources about containerd:

https://containerd.tools

https://blog.docker.com/2017/02/containerd-summit-recap-slid...

willemmali• 9 years ago

Does anyone here have a good guide for moving from Docker and docker-compose to rkt and related tooling?

I like what I'm hearing about rkt but I'm having a lot of trouble even getting a single simple container image together, let alone run it...

crb• 9 years ago

http://kompose.io/ is part of the Kubernetes project (in incubation) — https://github.com/kubernetes-incubator/kompose

koolba• 9 years ago

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

majewsky9• 9 years ago

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

twelvenmonkeys2• 9 years ago

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

shykes39• 9 years ago

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

https://docs.docker.com/engine/reference/commandline/stack/

programd2• 9 years ago

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/

friism8• 9 years ago

Here's a link to resources on how to start publishing content: https://success.docker.com/store

programd2• 9 years ago

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?

ilovecaching2• 9 years ago

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.

friism8• 9 years ago

I'm sorry you don't like the new versioning.

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

kordless3• 9 years ago

I'm sorry you don't like the new versioning.

I would note this is a non-apology, given it's stating you are "sorry" someone doesn't like a decision that was made.

danudey2• 9 years ago

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.

shykes39• 9 years ago

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.

ilovecaching2• 9 years ago

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.

kordless3• 9 years ago

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.

Tassels• 9 years ago

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.

djb_hackernews2• 9 years ago

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.

thockingoog12• 9 years ago

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

falsedan• 9 years ago

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?

coolowencool2• 9 years ago

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

cpuguy833• 9 years ago

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

coolowencool2• 9 years ago

That resolved it. Thanks!

friism8• 9 years ago

Fixed now, thanks for reporting: https://store.docker.com/editions/community/docker-ce-server...

Also check out the full docs: https://docs.docker.com/engine/installation/linux/centos/

JustinAiken3• 9 years ago

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

JustinAiken3• 9 years ago

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

shykes39• 9 years ago

You can uncheck it in stable releases, but not in beta releases. This is so we can track error rates, crashes etc to make sure the stable releases are actually stable :)

JustinAiken3• 9 years ago

Ah, that's okay then!

forgotpwtomain• 9 years ago

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

cpuguy833• 9 years ago

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

ecnahc515• 9 years ago

Yes, it has packet filter (pf).

SadWebDeveloper• 9 years ago

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.

kordless3• 9 years ago

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

ascendantlogic2• 9 years ago

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.

friism8• 9 years ago

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/

thaJeztah2• 9 years ago

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.

zegerjan2• 9 years ago

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.

pdeuchler2• 9 years ago

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.

cpuguy833• 9 years ago

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.

compuguy• 9 years ago

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?

andrewhsu• 9 years ago

Yes, for now both will continue to exist. The download.docker.com/linux/ubuntu repo is the preferred method of installing docker-ce on ubuntu. Instructions here: https://docs.docker.com/engine/installation/linux/ubuntu/#in...

In the future we will phase out the apt.dockerproject.org repo.

justincormack• 9 years ago

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.

ascendantlogic2• 9 years ago

Yes, using `major.minor.patch` versioning does give a strong impression of SemVer usage.

elcapitan• 9 years ago

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

shykes39• 9 years ago

Here you go: https://www.docker.com/get-docker#/edition

tomjen3• 9 years ago

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

drdaeman2• 9 years ago

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.

shykes39• 9 years ago

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.

drdaeman2• 9 years ago

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

friism8• 9 years ago

Docker CE and EE are based on the Docker open source project and work the same way. You can also use a Docker CE client to talk to Docker EE host or swarm, and vice-versa.

The Docker Cloud team is working on improvements to reduce segmentation too - stay tuned.

je42• 9 years ago

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

smugcloud• 9 years ago

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.

huksley• 9 years ago

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_byte3• 9 years ago

Also EE support for RHEL: https://store.docker.com/editions/enterprise/docker-ee-serve...

tannhaeuser• 9 years ago

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

majewsky9• 9 years ago

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.

jacques_chester7• 9 years ago

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.

friism8• 9 years ago

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://runc.io/

thaJeztah2• 9 years ago

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/)

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

sandGorgon• 9 years ago

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

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

friism8• 9 years ago

Thanks, this is excellent feedback.

friism8• 9 years ago

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

asher_• 9 years ago

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.

Docker Enterprise Edition

Related Stories