21 ms·

Docker Enterprise Edition

231 points by frostmatthew 10y ago

grabcocque 10y ago
I don't see how a freemium model solves the fundamental problem of Kubernetes eating their lunch. If anything surely this exacerbates it?
- shykes 10y 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 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 10y 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?
    - seeekr 10y ago
      Why does Docker Inc have to beat Red Hat? It's a big, growing market, enough cake for everyone?
      - bradmwalker 10y ago
        Aren't unicorn valuations based on the likelihood of winning a winner-take-all race?
        shykes 10y ago
        No, they're based on the likelihood of achieving massive growth in revenue. In consumer markets that often requires a winner-takes-all race. In the enterprise market, which is Docker's market, winner-take-all is not as central because enterprise buyers care more about interoperability and integrations of many products made by many vendors. This is why, for example, Microsoft is seeing much more success with less tight coupling of Windows, Azure and Office.
        tmzt 10y ago
        Yet Docker is embracing "tight coupling" if not in the architecture ('batteries not included') then certainly in the marketing of their platform. If you use Docker it's expected (by Docker) that you will use Swarm. And now it's expected that your organization will use EE (is that Java EE? no it's Docker EE.) Docker followed the Apple II model into the enterprise, it was a fancy typewriter.
        shykes 10y ago
        Our motto is "batteries included but removable". We make sure the platform works great out of the box, and offers a smooth integrated experience. That is a big differentiator for Docker. At the same time, we also make sure you can pop the hood, mess with the components directly, and swap them out in various ways. You can do this within the Docker ecosyste with Docker plugins (for things like networking, storage, logging, authorization); or you can do it outside the ecosystem by hitting the low-level open-source components directly: containerd/runc, swarmkit, notary, libnetwork, infrakit.. All these components are usable standalone, and Docker preserves the loose coupling. You're right that currently Docker does not offer swappable orchestration - not because we don't want to, but because it's hard to do that without affecting the quality of the platform. Sometimes excessive abstraction leads to bad engineering. In early versions of Docker Swarm we experimented with pluggable support for Mesos, Kubernetes etc. It worked in demos but we didn't find it fit for production. I hope this helps understand our approach better.
  - tyingq 10y 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.
    - shykes 10y ago
      > 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.
      - tyingq 10y ago
        >containerd is a different type of component entirely - in fact it is very complementary to kubernetes You made the initial comparison. > Nobody ever deploys kub alone in production. There is always some form of platform on top. Which is another way of saying "even if there are some gaps they have to fill with other software". Sure, some customers pick a platform where the gaps are prefilled. Not terribly different from some of your customers that pair docker pieces with pieces from other vendors.
  - 013a 10y 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.
    - shykes 10y ago
      Yes, that is a common misunderstanding with the kubernetes community. We are correcting that misunderstanding with a few simple steps: - What kubernetes needs from Docker is a simple and robust container runtime. We are spinning out containerd (the core container runtime that powers the Docker platform) to provide exactly that. We are actively working with the Kubernetes community to make sure containerd is a perfect fit for kubernetes to integrate - a better fit than Docker itself, in fact, since it will be much smaller and change only very slowly. See https://containerd.tools https://containerd.tools and https://blog.docker.com/2017/02/containerd-summit-recap-slides-videos-meeting-notes/ https://blog.docker.com/2017/02/containerd-summit-recap-slid... - This in turn will free Docker to focus on serving its userbase of developers and enterprises, which do want an integrated platform. Take a look at Docker for Mac/Windows or Docker for AWS/Azure for a sense of where we are taking the platform. - If you ask the core kubernetes maintainers, they will tell you that kube is intended to be the "kernel" of your distributed system, and it's up to you to build a platform on top. So in that way, I think we agree that kubernetes is ultimately a component - nothing derogatory about that! - You mention "camps". I think this evolution is very exciting because it allows us to move beyond the concept of camps. With containerd, a lot of bridges are already being built - engineers are collaborating peacefully and focusing on solving technical problems, which is a huge relief to everyone. Nobody likes drama. - Lastly, we are making sure Docker is a very modular and loosely coupled platform. So, who knows? If enough of our customers ask us, maybe we'll eventually integrate kubernetes as an optional component ;) The point is, we have an opportunity to refocus the conversation on technical tradeoffs rather than silly pissing contests. For all these reasons I think 2017 will be a good year for the entire container community.
      - thockingoog 10y ago
  - curun1r 10y 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.
    - shykes 10y ago
      > I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker. I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677 https://news.ycombinator.com/item?id=13775677 I hope this helps.
  - thockingoog 10y 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.
    - shykes 10y ago
      That's totally fair. Maybe I should have used to word "product" instead of "platform".
      - thockingoog 10y ago
        THAT is true. Kubernetes on its own is not a product, per se. There is no one company behind it. No legally binding support contract. etc. It is the basis for many products (plural) and an ecosystem, which is really what we wanted to achieve.
  - nul_byte 10y ago
    Can you explain how Docker has better security then OpenShift? (asking to learn, not a challenge).
    - shykes 10y ago
      Off the top of my head: - End-to-end content trust with crypto signatures and verifications using Notary/TUF https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/ - Secrets management with encrypted storage and transport (https://blog.docker.com/2017/02/docker-secrets-management/ https://blog.docker.com/2017/02/docker-secrets-management/) - A vulnerability scanner that can detect vulnerabilities in arbitrary binaries without distro lock-in (ie. even if your developer built from source on a non-Red Hat distro, it will still catch vulnerabilities) https://docs.docker.com/datacenter/dtr/2.2/guides/admin/configure/set-up-vulnerability-scans/ https://docs.docker.com/datacenter/dtr/2.2/guides/admin/conf... - Secure orchestration out-of-the-box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk... - Somewhat counter-intuitively, the default security profile is more secure in Docker than in Openshift, because the focus on "systemd everywhere" requires loosening the sandbox to allow systemd's tentacles to get through. In the past Red Hat has actually introduced CVEs in their forked version of Docker that didn't exist in the official Docker. - In Docker for AWS, Docker for Azure, Docker for Mac, Docker for Windows, we embed a specialized Linux distro that is trimmed down and locked down to the extreme, making OS surface area much much smaller than a traditional OS like Red Hat.
- raesene6 10y 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.
  - thockingoog 10y 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.
    - raesene6 10y ago
      Of course, I don't think my comment implied anything else... do you? My point was around maturity of things that enterprises tend to focus on like hardening/security best practice guides. The kubelet API bit was just an example, although I do think the Kubernetes docs could be a bit clearer that this is a critical change to make after install to secure the cluster, given that all the install methods I've tried so far (kube-up, kubeadm etc) leave the kubelet API available unauthenticated by default.
      - thockingoog 10y ago
        My point was that we have enterprises who are using it and helping to shape it. There are parts that are simply under-developed and there are parts that are downright embarrassing, no denial. I do expect that many of the docs/articles/blogs written about 1.6, 1.7, 1.8 are going to focus on hardening, security, etc. I just hope it isn't selinux style: "how do I turn it off" :)
- esseti 10y ago
  But isn't kubernetes managing docker containers? or does it support anything else?
  - bdcravens 10y ago
    It supports rkt: https://kubernetes.io/docs/getting-started-guides/rkt/ https://kubernetes.io/docs/getting-started-guides/rkt/
    - ex3ndr 10y ago
      When i last checked out features of rkt on k8s it lacks of many fundamental things like log streaming and persisting data for a while after pod deletion.
    - esseti 10y ago
      i'll, thanks. just one question: how stable/good is rkt for production?
  - Crsvoboda 10y 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/README.md https://github.com/kubernetes-incubator/cri-o/blob/master/RE...
gfunk911 10y ago
Hoping this is mostly support
- doubleorseven 10y ago
  it's all in here : https://www.docker.com/pricing https://www.docker.com/pricing
  - kenperkins 10y 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?tab=description https://store.docker.com/editions/enterprise/docker-ee-aws?t...
    - technofiend 10y ago
      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 10y ago
        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.
lenovouser 10y 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.
- shykes 10y 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 10y ago
    We'll see about that
  - lenovouser 10y 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 10y 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.
tobltobs 10y 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.
- AckSyn 10y 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 10y 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.
    - jsudhams 10y ago
      In large enterprise it will take 6 months to get a version certified to work with tooling so need 3 year at the minimum to put any effort on it.
      - IMTDb 10y ago
        Docker initial release was just 4 years ago, your asking for a support timeframe that's around the same length as the age of the project itself. Docker still is a new product, evolving very fast (this announcement is just one more proof of that). Is it production ready ? Yes If you want to move fast and benefit from new tech and are ready to upgrade regularly. No if you are not able to perform those upgrades and need insurance that the project will contribute significant ressources to fixing issues on 3 years old versions. And currently I totally understand that the Docker team sets slider more towards "new dev" than towards "support". That will probably change in the future.
koolba 10y 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?!
- majewsky 10y ago
  $OS_VENDOR most likely only ships Docker the container runtime, not Docker all the other shebang.
twelvenmonkeys 10y ago
Off-ish topic. But will the last piece of the puzzle (compose) be integrated into the Docker Go binary?
- shykes 10y ago
  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/
programd 10y 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/ https://blog.docker.com/2017/03/announcing-docker-certified/
- friism 10y ago
  Here's a link to resources on how to start publishing content: https://success.docker.com/store https://success.docker.com/store
  - programd 10y 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?
merb 10y ago
lol
ilovecaching 10y 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.
- friism 10y 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 https://news.ycombinator.com/item?id=13774420
  - kordless 10y 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.
  - danudey 10y 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.
- shykes 10y 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.
falsedan 10y 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?
coolowencool 10y 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 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-centos?tab=description https://store.docker.com/editions/community/docker-ce-server...
- cpuguy83 10y 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 https://download.docker.com/linux/centos/docker-ce.repo
  - coolowencool 10y ago
    That resolved it. Thanks!
- friism 10y ago
  Fixed now, thanks for reporting: https://store.docker.com/editions/community/docker-ce-server-centos?tab=description https://store.docker.com/editions/community/docker-ce-server... Also check out the full docs: https://docs.docker.com/engine/installation/linux/centos/ https://docs.docker.com/engine/installation/linux/centos/
JustinAiken 10y ago
Ugh, Docker for Mac now has two separate ads in it's 9 options in the menubar :/
JustinAiken 10y ago
Uuuuuugggh. Docker for Mac now won't let you uncheck "Send usage statistics"
- shykes 10y 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 :)
  - JustinAiken 10y ago
    Ah, that's okay then!
- forgotpwtomain 10y ago
  Does OS X have an iptables equivalent? Does seem rather unfriendly though..
  - cpuguy83 10y ago
    Not sure how configurable it is under the hood, but it's in the "Security & Privacy" preferences pane.
  - ecnahc515 10y ago
    Yes, it has packet filter (pf).
SadWebDeveloper 10y 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.
- kordless 10y ago
  Providing certification is typically a means of establishing trust in the marketplace and opens up new revenue. We saw this with OpenStack.
ascendantlogic 10y 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.
- friism 10y 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/ https://blog.docker.com/2017/03/docker-enterprise-edition/
  - thaJeztah 10y 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.
elcapitan 10y ago
Is there a tl;dr on the differences between enterprise and community edition?
- shykes 10y ago
  Here you go: https://www.docker.com/get-docker#/edition https://www.docker.com/get-docker#/edition
  - tomjen3 10y ago
    Ford's this mean that we can no longer have more than one private image server?
drdaeman 10y 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.
- shykes 10y 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.
  - drdaeman 10y 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).
- friism 10y 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 10y ago
1 year of support is better than 0 years of support.
smugcloud 10y 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 10y 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_byte 10y ago
  Also EE support for RHEL: https://store.docker.com/editions/enterprise/docker-ee-server-rhel https://store.docker.com/editions/enterprise/docker-ee-serve...
tannhaeuser 10y 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
- majewsky 10y 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_chester 10y 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.
- friism 10y 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://blog.docker.com/2016/12/introducing-containerd/ * https://runc.io/ https://runc.io/
shiftoutbox 10y ago
Hahahahahhhahaha
sandGorgon 10y 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 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 10y ago
  Thanks, this is excellent feedback.
- friism 10y ago
  Oh, and to answer your question: Yes, Swarm is core part of Docker and is in Docker Community Edition too!
asher_ 10y 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.

231 points by frostmatthew 10y ago

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

shykes 10y 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 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 10y 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?
  - seeekr 10y ago
    Why does Docker Inc have to beat Red Hat? It's a big, growing market, enough cake for everyone?
    - bradmwalker 10y ago
      Aren't unicorn valuations based on the likelihood of winning a winner-take-all race?
      - shykes 10y ago
        No, they're based on the likelihood of achieving massive growth in revenue. In consumer markets that often requires a winner-takes-all race. In the enterprise market, which is Docker's market, winner-take-all is not as central because enterprise buyers care more about interoperability and integrations of many products made by many vendors. This is why, for example, Microsoft is seeing much more success with less tight coupling of Windows, Azure and Office.
        tmzt 10y ago
        Yet Docker is embracing "tight coupling" if not in the architecture ('batteries not included') then certainly in the marketing of their platform. If you use Docker it's expected (by Docker) that you will use Swarm. And now it's expected that your organization will use EE (is that Java EE? no it's Docker EE.) Docker followed the Apple II model into the enterprise, it was a fancy typewriter.
        shykes 10y ago
        Our motto is "batteries included but removable". We make sure the platform works great out of the box, and offers a smooth integrated experience. That is a big differentiator for Docker. At the same time, we also make sure you can pop the hood, mess with the components directly, and swap them out in various ways. You can do this within the Docker ecosyste with Docker plugins (for things like networking, storage, logging, authorization); or you can do it outside the ecosystem by hitting the low-level open-source components directly: containerd/runc, swarmkit, notary, libnetwork, infrakit.. All these components are usable standalone, and Docker preserves the loose coupling. You're right that currently Docker does not offer swappable orchestration - not because we don't want to, but because it's hard to do that without affecting the quality of the platform. Sometimes excessive abstraction leads to bad engineering. In early versions of Docker Swarm we experimented with pluggable support for Mesos, Kubernetes etc. It worked in demos but we didn't find it fit for production. I hope this helps understand our approach better.
- tyingq 10y 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.
  - shykes 10y ago
    > 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.
    - tyingq 10y ago
      >containerd is a different type of component entirely - in fact it is very complementary to kubernetes You made the initial comparison. > Nobody ever deploys kub alone in production. There is always some form of platform on top. Which is another way of saying "even if there are some gaps they have to fill with other software". Sure, some customers pick a platform where the gaps are prefilled. Not terribly different from some of your customers that pair docker pieces with pieces from other vendors.
- 013a 10y 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.
  - shykes 10y ago
    Yes, that is a common misunderstanding with the kubernetes community. We are correcting that misunderstanding with a few simple steps: - What kubernetes needs from Docker is a simple and robust container runtime. We are spinning out containerd (the core container runtime that powers the Docker platform) to provide exactly that. We are actively working with the Kubernetes community to make sure containerd is a perfect fit for kubernetes to integrate - a better fit than Docker itself, in fact, since it will be much smaller and change only very slowly. See https://containerd.tools https://containerd.tools and https://blog.docker.com/2017/02/containerd-summit-recap-slides-videos-meeting-notes/ https://blog.docker.com/2017/02/containerd-summit-recap-slid... - This in turn will free Docker to focus on serving its userbase of developers and enterprises, which do want an integrated platform. Take a look at Docker for Mac/Windows or Docker for AWS/Azure for a sense of where we are taking the platform. - If you ask the core kubernetes maintainers, they will tell you that kube is intended to be the "kernel" of your distributed system, and it's up to you to build a platform on top. So in that way, I think we agree that kubernetes is ultimately a component - nothing derogatory about that! - You mention "camps". I think this evolution is very exciting because it allows us to move beyond the concept of camps. With containerd, a lot of bridges are already being built - engineers are collaborating peacefully and focusing on solving technical problems, which is a huge relief to everyone. Nobody likes drama. - Lastly, we are making sure Docker is a very modular and loosely coupled platform. So, who knows? If enough of our customers ask us, maybe we'll eventually integrate kubernetes as an optional component ;) The point is, we have an opportunity to refocus the conversation on technical tradeoffs rather than silly pissing contests. For all these reasons I think 2017 will be a good year for the entire container community.
    - thockingoog 10y ago
- curun1r 10y 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.
  - shykes 10y ago
    > I won't speak for others, but it would make my life much easier if you'd build (and name) your offerings on top of the base containerization tool like everyone else We are doing exactly that. The base containerization layer is containerd, and it is now available standalone separate from Docker. I covered this topic in more detail in another comment: https://news.ycombinator.com/item?id=13775677 https://news.ycombinator.com/item?id=13775677 I hope this helps.
- thockingoog 10y 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.
  - shykes 10y ago
    That's totally fair. Maybe I should have used to word "product" instead of "platform".
    - thockingoog 10y ago
      THAT is true. Kubernetes on its own is not a product, per se. There is no one company behind it. No legally binding support contract. etc. It is the basis for many products (plural) and an ecosystem, which is really what we wanted to achieve.
- nul_byte 10y ago
  Can you explain how Docker has better security then OpenShift? (asking to learn, not a challenge).
  - shykes 10y ago
    Off the top of my head: - End-to-end content trust with crypto signatures and verifications using Notary/TUF https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/ - Secrets management with encrypted storage and transport (https://blog.docker.com/2017/02/docker-secrets-management/ https://blog.docker.com/2017/02/docker-secrets-management/) - A vulnerability scanner that can detect vulnerabilities in arbitrary binaries without distro lock-in (ie. even if your developer built from source on a non-Red Hat distro, it will still catch vulnerabilities) https://docs.docker.com/datacenter/dtr/2.2/guides/admin/configure/set-up-vulnerability-scans/ https://docs.docker.com/datacenter/dtr/2.2/guides/admin/conf... - Secure orchestration out-of-the-box: https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ https://docs.docker.com/engine/swarm/how-swarm-mode-works/pk... - Somewhat counter-intuitively, the default security profile is more secure in Docker than in Openshift, because the focus on "systemd everywhere" requires loosening the sandbox to allow systemd's tentacles to get through. In the past Red Hat has actually introduced CVEs in their forked version of Docker that didn't exist in the official Docker. - In Docker for AWS, Docker for Azure, Docker for Mac, Docker for Windows, we embed a specialized Linux distro that is trimmed down and locked down to the extreme, making OS surface area much much smaller than a traditional OS like Red Hat.
raesene6 10y 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.
- thockingoog 10y 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.
  - raesene6 10y ago
    Of course, I don't think my comment implied anything else... do you? My point was around maturity of things that enterprises tend to focus on like hardening/security best practice guides. The kubelet API bit was just an example, although I do think the Kubernetes docs could be a bit clearer that this is a critical change to make after install to secure the cluster, given that all the install methods I've tried so far (kube-up, kubeadm etc) leave the kubelet API available unauthenticated by default.
    - thockingoog 10y ago
      My point was that we have enterprises who are using it and helping to shape it. There are parts that are simply under-developed and there are parts that are downright embarrassing, no denial. I do expect that many of the docs/articles/blogs written about 1.6, 1.7, 1.8 are going to focus on hardening, security, etc. I just hope it isn't selinux style: "how do I turn it off" :)
esseti 10y ago
But isn't kubernetes managing docker containers? or does it support anything else?
- bdcravens 10y ago
  It supports rkt: https://kubernetes.io/docs/getting-started-guides/rkt/ https://kubernetes.io/docs/getting-started-guides/rkt/
  - ex3ndr 10y ago
    When i last checked out features of rkt on k8s it lacks of many fundamental things like log streaming and persisting data for a while after pod deletion.
  - esseti 10y ago
    i'll, thanks. just one question: how stable/good is rkt for production?
- Crsvoboda 10y 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/README.md https://github.com/kubernetes-incubator/cri-o/blob/master/RE...

gfunk911 10y ago

Hoping this is mostly support

doubleorseven 10y ago
it's all in here : https://www.docker.com/pricing https://www.docker.com/pricing
- kenperkins 10y 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?tab=description https://store.docker.com/editions/enterprise/docker-ee-aws?t...
  - technofiend 10y ago
    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 10y ago
      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.

lenovouser 10y 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.

shykes 10y 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 10y ago
  We'll see about that
- lenovouser 10y 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 10y 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.

tobltobs 10y 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.

AckSyn 10y 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 10y 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.
  - jsudhams 10y ago
    In large enterprise it will take 6 months to get a version certified to work with tooling so need 3 year at the minimum to put any effort on it.
    - IMTDb 10y ago
      Docker initial release was just 4 years ago, your asking for a support timeframe that's around the same length as the age of the project itself. Docker still is a new product, evolving very fast (this announcement is just one more proof of that). Is it production ready ? Yes If you want to move fast and benefit from new tech and are ready to upgrade regularly. No if you are not able to perform those upgrades and need insurance that the project will contribute significant ressources to fixing issues on 3 years old versions. And currently I totally understand that the Docker team sets slider more towards "new dev" than towards "support". That will probably change in the future.

koolba 10y 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?!

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

twelvenmonkeys 10y ago

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

shykes 10y ago
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/

programd 10y 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/ https://blog.docker.com/2017/03/announcing-docker-certified/

friism 10y ago
Here's a link to resources on how to start publishing content: https://success.docker.com/store https://success.docker.com/store
- programd 10y 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?

merb 10y ago

lol

ilovecaching 10y 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.

friism 10y 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 https://news.ycombinator.com/item?id=13774420
- kordless 10y 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.
- danudey 10y 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.
shykes 10y 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.

falsedan 10y 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?

coolowencool 10y 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 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-centos?tab=description https://store.docker.com/editions/community/docker-ce-server...

cpuguy83 10y 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 https://download.docker.com/linux/centos/docker-ce.repo
- coolowencool 10y ago
  That resolved it. Thanks!
friism 10y ago
Fixed now, thanks for reporting: https://store.docker.com/editions/community/docker-ce-server-centos?tab=description https://store.docker.com/editions/community/docker-ce-server... Also check out the full docs: https://docs.docker.com/engine/installation/linux/centos/ https://docs.docker.com/engine/installation/linux/centos/

JustinAiken 10y ago

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

JustinAiken 10y ago

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

shykes 10y 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 :)
- JustinAiken 10y ago
  Ah, that's okay then!
forgotpwtomain 10y ago
Does OS X have an iptables equivalent? Does seem rather unfriendly though..
- cpuguy83 10y ago
  Not sure how configurable it is under the hood, but it's in the "Security & Privacy" preferences pane.
- ecnahc515 10y ago
  Yes, it has packet filter (pf).

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

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

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

friism 10y 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/ https://blog.docker.com/2017/03/docker-enterprise-edition/
- thaJeztah 10y 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.

elcapitan 10y ago

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

shykes 10y ago
Here you go: https://www.docker.com/get-docker#/edition https://www.docker.com/get-docker#/edition
- tomjen3 10y ago
  Ford's this mean that we can no longer have more than one private image server?

drdaeman 10y 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.

shykes 10y 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.
- drdaeman 10y 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).
friism 10y 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 10y ago

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

smugcloud 10y 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 10y 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_byte 10y ago
Also EE support for RHEL: https://store.docker.com/editions/enterprise/docker-ee-server-rhel https://store.docker.com/editions/enterprise/docker-ee-serve...

tannhaeuser 10y 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

majewsky 10y 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_chester 10y 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.
friism 10y 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://blog.docker.com/2016/12/introducing-containerd/ * https://runc.io/ https://runc.io/

shiftoutbox 10y ago

Hahahahahhhahaha

sandGorgon 10y 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 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 10y ago
Thanks, this is excellent feedback.
friism 10y ago
Oh, and to answer your question: Yes, Swarm is core part of Docker and is in Docker Community Edition too!

asher_ 10y 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.