16 ms·

Docker 1.12: Now with Built-In Orchestration

275 points by sashk 10y ago

d33 10y ago
I chose Docker for my project with hope that it would help me create an easily reproducible development environment... And I'm not really sure if it was a good idea. There's so many moving parts and I can't name one that actually works well. Configuring storage is a hell (running out of disk space can lead to errors that are really difficult to debug), the dance with bridges makes configuring firewall a terrible experience. I definitely wouldn't recommend it as a stable container solution.
- gizmodo59 10y ago
  Can you briefly describe your environment?
- deleted 10y ago
  [deleted]
- redrummr 10y ago
  Why is storage an issue? With databases, for example, you store data upstream (on the host) and keep the dockerised app/thing mostly stateless, or at least capped with regards to storage. More details about your environment would be appreciated.
  - jdoliner 10y ago
    Keeping data on the host is exactly the reason that it's an issue. Swarm offers not guarantees that containers will be rescheduled on the same host that it was initially scheduled on and assumes that it can reschedule containers as failures arise... this doesn't work when your database gets rescheduled and emptied along the way.
    - zamalek 10y ago
      > your database gets rescheduled and emptied along the way That's bundling an CP application into seemingly AP infrastructure (from what I gleaned from their docs). Completely the wrong tool for the job. If the application was designed for that it would have recovered. In your defense, they have nothing to warn about that in their documentation.
      - jdoliner 10y ago
        This isn't really a CAP theorem problem and it's certainly not right to describe Docker as "AP infrastructure." What would that mean exactly? Would you expect this problem to go away if I used a database that sacrificed consistency for availability such as Riak?
        zamalek 10y ago
        Swarm (not the whole of Docker) seems like something designed for databases like Riak, yes. A SQL failover cluster might work, but certainly not a single database container on infrastructure designed for highly available apps.
    - kerr23 10y ago
      In docker 1.12 you can 'tag' a node and tell a 'service' to only run on the tagged nodes. Not saying that's a good idea, but it is getting closer. You could, for example, have a node that's only for DBs that has volumes on it. You could then use DRBD on the host to clone that data to a secondary node. then in the event that node 1 dies swarm would bring the DB up on node2. With the mesh network stuff they've added the endpoint would remain the same, so all your apps would need to do would be re-connect.
      - jdoliner 10y ago
        > Not saying that's a good idea, but it is getting closer. No, that isn't getting closer it's getting farther away. The whole point of containers is that they make the host machine completely fungible. If I can only schedule my DB containers on a specific machine then I might as well just run my DB on that machine and be done with it.
        kerr23 10y ago
        hmm, your first complaint was that "Swarm offers no guarantees that containers will be rescheduled on the same host". I'm saying that, if you want, you CAN make it guarantee that a container will be rescheduled to the same host. (or a controlled level of hosts). I don't think it's docker's responsibility to solve database clustering. And, as I said, I'm not advocating running a production DB in docker. But I can see a way that you may be able to.
        jdoliner 10y ago
        I see how that was confusing. I meant that the fact that Swarm doesn't offer such a guarantee is the reason that storing the data on the host isn't a solution. My real complaint is that none of these give you a way to do persistence that doesn't destroy some other really nice properties of containers. There's lots of people trying to fix this problem the right way, Kubernetes has made a lot of progress on having volumes follow the containers around from host to host. Torus is a slightly different approach, Flocker is another one. > I don't think it's docker's responsibility to solve database clustering. I don't know if I'd call it a responsibility. But Docker is obviously trying to expand their platform into more and more aspects of containerization. If they figured out persistence that would really set them apart, something that this product doesn't really do. It mostly just keeps them even with Kubernetes at best. And an imitation of it at worst.
  - jodok 10y ago
    why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest
  - jodok 10y ago
    why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest
- jjtheblunt 10y ago
  Did you try rkt or find something else which you liked?
- lewisl9029 10y ago
  I've been experimenting with Docker for reproducible dev environments as well for a while now, and my biggest issue has been with the app build step, which often requires a specific non-Linux platform (OS X for iOS and Windows for UWP). Back in my previous project using Cordova, I made the Docker workflow work adequately by offloading builds to web-based build services like PhoneGap Build and Ionic Package (building only a thin live-reloading wrapper app that points to a configurable IP:port for development). But my new project uses React Native, and I haven't found any similar build services for React Native apps (or even just regular native apps) yet. Anyone have any suggestions?
  - theodorton 10y ago
    Bitrise and Circle CI both support OS X environments for building projects. Combined with fastlane, you'd probably have a good setup for continuous delivery. I've only got experience with running fastlane locally though.
    - nomel 10y ago
      I'm not a web guy, so this question is genuine. How in the world do you keep up/discover all of the different frameworks that seem to pop up daily?
      - skewart 10y ago
        By spending unreasonable amounts of time on HN - at least that's how I rationalize things to myself.
- lopatin 10y ago
  I totally agree. Docker feels really tidy conceptually. I ended up somehow convincing myself that adding this extra layer of technology into my (relatively tiny) infrastructure will decrease it's complexity. Unsurprisingly, the effect was the exact opposite.
  - knz 10y ago
    I feel the exact opposite! The Dockerfile is a simple way to define my environment and it's trivial to run the app in either development, QA, or production. Throw in some of the other functionality such as being able to deploy from an image rather than having to rebuild each time, and it's been a productive addition to my toolset. I'm guessing it depends on how complex your application is, but I've found it fantastic for running Python (Flask), PostgreSQL/PostGIS, MapServer, and some other smaller applications.
    - Annatar 10y ago
      And did you produce OS packages for any of that configuration work, or did you just end up dumping a bunch of files into the "image"?
      - knz 10y ago
        It's not an image in the sense that you can run updates/installs and strip out the crap associated with that but it's so trivial to run "images" that the benefits far outweigh the additional disk space for our use cases.
  - codygman 10y ago
    I've been enjoying Nixos[0] and hope to try Nixops[1] soon. The difference between Nixos and docker is that nixos makes it possible to have a truly reproducible environment. See the surprisingly readable paper[2] for more details. 0: http://nixos.org/ http://nixos.org/ 1: http://nixos.org/nixops/ http://nixos.org/nixops/ 2: https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf
- ldehaan 10y ago
  just a quick tip: check out weave for managing networking, IMO it's much easier and I'm not even talking about the docker plugin. just use weave without the plugin and it works amazingly well. for the configuration aspect, just use dockerfiles and a system like mesos and marathon for deploying production. you can then write simple restful API commands to launch different environments with marathon. build all your docker containers to act as single server instances, i.e., spark on one container, SQL on another. tie in a default install of cadvisor on all mesos clients and you can have easy monitoring as well.
- rdtsc 10y ago
  You probably want something like NixOS or Guix if you really want to go down that way. Yeah I see where you are coming from. First time I heard about Docker, I thought it did what NixOS does, but it doesn't really.
- catmanjan 10y ago
  I think Vagrant would be a good replacement for you, it's basically docker but built exactly for reproducible dev environments
- Annatar 10y ago
  You might want to try out SmartOS: one .json file, vmadm(1M) and imgadm(1M) commands later, you'll have a fully isolated UNIX server, running at the speed of bare metal and residing on ZFS, protecting your data. If you need a more complex network setup, dladm(1M) will enable you to configure virtual switches and routers. The manual pages are really good, too. And there is nothing to install, as SmartOS runs from memory, so that all storage in the system can be used for virtual servers. Upgrades are a breeze by just booting into a new image, either from USB or PXE booting from the network.
- fpoling 10y ago
  From my experience with Docker one should just avoid docker-supplied volumes and manage the storage oneself using host bind mounts for containers and consistently using --read-only for containers themselves. With that it is really weired to read all complains and issues about volumes management. It seems Docker just picked up wrong model for their storage. Then they try forever to fix impedance mismatch between that model and how people want to use Docker.
  - cpuguy83 10y ago
    Care to clarify issues you have with volume management? I think the biggest issue is around the `-v` syntax (and the corrosponding API). In the UX we call things a volume which are actually a mount (which happen to use a volume). I like the way we have implemented this in the new services API.... `docker run --mount type=volume,source=important_data,volume-driver=foo,volume-options=...`
    - fpoling 10y ago
      For me the biggest issue with docker volumes is lack of any notion of subvolumes or volume grouping. Consider an application consisting of few containers communicating over unix sockets each with its own state. Surely I can create a bunch of volumes for the containers, but those would not have any notion of grouping. That complicates administration and development. For example, it is very useful to have a shell view of all volumes for the application to poke inside or debug issues. Surely I can do docker run ubuntu and mount all relevant volumes under /mnt there, but that is not user friendly. Or consider that during development or debugging I want to transfer the state to another machine. Why it is not possible to tar all application volumes with single command and restore them in a new place again with single command? I.e, something similar for docker save/load, but for volumes? All those issues are trivially solvable if I use some directory on a file system for the whole application state and use subdirectories there for individual volumes for the containers and then pass those with -v to relevant containers.
- flavioaiello 10y ago
  My experience with Docker is kind of ambivalent. We are using docker with docker compose on a legacy vmware stack in a corporate environment. No swarm and no docker overlay network as it does undermine firewalls. It is perfect to apply gitlow and semver to each build of each docker image, so each outcoming application stack is fully determenistic and auditable. Docker storage and network are really simple and docker is the perfect fit. On the other side devs were asking for jenkins for that process. We run also Jenkins on Docker but it's cumbersome as it doesn't allow declarative configuration. There are dozen of plugins out there but it doesn't change the fact that the outcome is ressource hungry and slow. For now we are actually optimizing using Job-DSL plugin. We reached our target, but it was extremly time consuming and pain. For a new project I'm in, maybe we go to replace jenkins with concourseci or drone. Imho a PaaS doesn't solve processual versioning and testing requirements. For that you still need further tools - with or without docker.
  - pas 10y ago
    Try Drone CI. It's _very_ Docker friendly.
  - jacques_chester 10y ago
    > For a new project I'm in, maybe we go to replace jenkins with concourseci or drone. I love Concourse. Look me up if you have questions.
- jondubois 10y ago
  I also didn't get the point of Docker until a few months ago when I got acquainted with Kubernetes (K8s) and Rancher. It doesn't really make sense to use Docker without some sort of distributed scheduling/orchestration system like Kubernetes, Docker Swarm or Mesos. I think the first few years of Docker were just pointless but I genuinely feel that it is all starting to come together now. Docker 1.12 looks promising on the orchestration front - Hopefully they will back all these new features with thorough documentation (which I found lacking in Swarm when compared to K8s). It looks like Swarm is just following in K8s' footsteps and maybe even improving things along the way. Based on what I just read, it looks like Docker Swarm might finally be a serious contender to K8s.
deleted 10y ago
[deleted]
geodel 10y ago
I also noticed that now 'Docker for mac' is available without beta invite. I just downloaded and installed though its version is 1.12.0-rc2. Maybe they will make formal announcement when 1.12 for mac is released.
- ingve 10y ago
  They have announced a Public Beta: https://blog.docker.com/2016/06/docker-mac-windows-public-beta/ https://blog.docker.com/2016/06/docker-mac-windows-public-be...
  - geodel 10y ago
    Ohk, great. I did not notice that blog post.
- T-A 10y ago
  Also https://docs.docker.com/docker-for-windows/ https://docs.docker.com/docker-for-windows/ !
hosh 10y ago
I'm not surprised the Kubernetes primitives got copied into this. I had stated before that Kubernetes was what Docker wants to be when it grows up -- and maybe that time is here. Having used Kubernetes in production, I don't know robust the Docker orchestration primitives are in comparison. But I'll probably find out soon. The big advantage having a built-in Docker orchestration is that Kubernetes is painful to install from scratch. (Yes, there are scripts to help mitigate this; yes, GKE is effectively hosted Kubernetes). I'm involved in another Dockerization projection, but we don't know if we want to invest the time into setting up Kubernetes (though GKE is an option). This would be a good time to check things out. Just to show how quickly things change. In 2015, I tried the docker compose, AWS ECS, and Kubernetes for production deployment, and of all of them, Kubernetes addressed the pain points in a practical way. The Kubernetes project ended in late 2015, and now six months later, things changed again ...
- jacques_chester 10y ago
  I'll seed what will quickly be an enthusiastic crowd of spruikers for various platforms: have you looked at Cloud Foundry? It's mature, has been scaled to 10,000 real app containers in a single install with a 250,000-container milestone coming soon, belongs to an independent foundation instead of a single company, runs on AWS, Azure, GCP, OpenStack, vSphere with more coming. It handles routing, service injection, logging, container orchestration and a whole bunch of other bits and bobs. You can get started by just pushing your sourcecode, or you can provide container images, whichever works better for you. We even made a version you can test drive on your laptop[0] and we've been working on a "bootloader" for spinning up a full AWS version quickly[1]. Disclaimer: by "we" I mean Pivotal, my employer, which donates the majority of engineering effort to Cloud Foundry. [0] http://pivotal.io/pcf-dev http://pivotal.io/pcf-dev [1] https://github.com/pivotal-cf-experimental/bosh-bootloader https://github.com/pivotal-cf-experimental/bosh-bootloader
  - Veratyr 10y ago
    Back when I looked at CloudFoundry (years ago now), it didn't work out because there was no middle ground deployment between a single PC and a full blown production deployment. You either ran it on one machine or you spun up what would have costed ~$1200 in servers at the time. It doesn't appear this has changed: http://docs.pivotal.io/pivotalcf/1-7/customizing/openstack.html http://docs.pivotal.io/pivotalcf/1-7/customizing/openstack.h... Even at a cheap provider like DigitalOcean, this is 16x10 + 6x160 = $1120/month in __overhead__, without even running any useful applications.
csears 10y ago
Just based on the details mentioned in the keynote, the services API and swarm features look very similar to what's offered by Kubernetes... service discovery, rolling updates, load balancing, health checks, auto-healing, advanced scheduling. I guess this was to be expected, but it's also kind of sad. I think it would have been a more strategic move to embrace Kubernetes instead of trying to compete with it.
- atonse 10y ago
  The problem for docker is that just by building docker engine, they don't really have a way to make money – so stuff like this is probably all an attempt to actually have differentiating products that can generate revenue.
  - hosh 10y ago
    Yep, and CoreOS and Kubernetes are already moving towards Rocket as the default, underlying engine.
    - zwischenzug 10y ago
      Kubernetes? Really? Any evidence?
      - hosh 10y ago
        https://github.com/kubernetes/kubernetes/issues/2725 https://github.com/kubernetes/kubernetes/issues/2725 https://docs.google.com/document/d/1dYxInIUDTm4HEArQ9Hom_1NhYw22WrXWdglnaLjtQsI/edit#heading=h.2mzw2mutm6lx https://docs.google.com/document/d/1dYxInIUDTm4HEArQ9Hom_1Nh... I should clarify: CoreOS + Kubernetes using rocket by default. From what I understand, CoreOS is driving the effort to get rocket supported by Kubernetes. K8S looks like it is going for agnostic implementation.
        sbt 10y ago
        Yes. Also note that CoreOS is basically a shell corporation for Google.
deleted 10y ago
[deleted]
waitwhatwhoa 10y ago
At first I was worried that this is yet another Raft implementation, but it seems they're building on etcd's version [1] which should be a win for everyone trying to prove correctness for the various implementations. 1. https://github.com/docker/swarmkit/blob/a78a157ef66adf0978f031e7bbc9bff2c16df9a0/manager/state/raft/raft.go#L19 https://github.com/docker/swarmkit/blob/a78a157ef66adf0978f0...
- gtirloni 10y ago
  I like it that etcd is self-contained and easy to troubleshoot, as opposed to a blackbox with tons of magic. The demo for `docker swarm` was great but as an infrastructure engineer, it worries me. First because of the blackbox effect I mentioned above and secondly because I'm not sure how much flexibility is compromised to achiveve that. Sure, it's awesome to quickly have a cluster up for your app and the user experience is phenomenal... but what about storage, network, firewalls, integrating with my linux distro, etc. Things are never this simple when they reach a certain scale and/or number of requirements deviate from those of a simple app. From a quick look at the docs and watching the demo, Kubernetes still feels like a safer option, today. That being said, it's nice to see competition in this space. I guess this will put pressure on Kubernetes and others to improve the user experience further.
kstenerud 10y ago
Omg their navigation bar covers half my screen! Seriously, why do companies inside upon reducing my screen real estate for stupid shit?
- rcarmo 10y ago
  I actually think this is a valid point, even if somewhat colloquially expressed. I had a lot of trouble getting past that menu bar on Opera Mini and even on an iPad, it's entirely too much.
  - wallace_f 10y ago
    Agreed. To be honest, I think the colloquial nature of the post is fine in this case.
- KenCochrane 10y ago
  Sorry for the issue, we are looking at fixing it.
namidark 10y ago
I wish they would address stability issues first, like this bug[1] that has been around 2 years and is still happening on the latest versions. https://github.com/docker/docker/issues/5618 https://github.com/docker/docker/issues/5618
- SEJeff 10y ago
  Or this nasty one[1] that has been around just over a year now. It didn't take me more work than using docker as a build server to run into this. There are some udev hacks that make it better, but the underlying issue is ultimately docker here. Doesn't seem that docker inc upstream takes stability seriously from my standpoint. [1] https://github.com/docker/docker/issues/13885 https://github.com/docker/docker/issues/13885
  - cpuguy83 10y ago
    Hard problems are hard. We are looking at all kinds of issues related to this, and in reality reports from that issue are likely caused by different things (some things are fixed, others obviously not). There are several people looking how we can resolve issues like this.
- cpuguy83 10y ago
  This is a caused by a race condition in the kernel that is not particularly easy to solve. The way to solve this is not use the `--userland-proxy=false` function.
  - EDevil 10y ago
    Is this acknowledged by the Kernel team? Is there a ticket on the Kernel side where we can keep track of progress?
ShakataGaNai 10y ago
This seems like a really exciting, albeit natural, evolution of the Docker "platform". It's really true that no one cares about containers, everyone just wants their apps to work. That being said the one giant omission from Docker is still seems to be management of volumes/data. Great, we can run 100 nodes on AWS in a matter of minutes, but if your system has data storage requirements (ex: Almost every database ever) ... You're kinda left up to your own still. How does Docker Orchestration migrate the data volumes? They really tried to sell this as "You don't need to do anything but the AWS beta, the DAB and a few commands" which would be wonderful. However with the need for reliable data storage... you're still stuck doing everything "the old fashion way". (Edit: No, I don't mean store data IN the container, I presume no one is that silly. I meant the attached volumes. No volume mgmt = less greatly less helpful).
- gongfupotass 10y ago
  It seems to me they are more focused on NOsql databases with multiple nodes and shared data like cassandra. So that you don't have to worry too much about volume/data mgmt because you will have multiple copies of the data on other containers when you lose a docker host or a container. You also should conside that docker might not be the best option as opposed to just some vms on openstack for your much needed databases. I'm stuck trying convince my co-workers that docker is not the answer to everything.
  - ShakataGaNai 10y ago
    In no way did I mean to convey "store data IN the container" as I had simply assumed no one was that silly. What I actually meant was as "there is no way to deal with volumes". So spinning up 100 instances and hot failover doesn't help if it doesn't deal with the attached volumes. Without that functionality, the orchestration is less magic and more "eh".
  - djsumdog 10y ago
    Don't use OpenStack. It's an appropriate solution never. I've been at too many shops where OpenStack is just a bottomless cesspool of the company hemorrhaging money to keep a shitty broken platform barely stable.
lvh 10y ago
The new orchestration looks based on Swarm and possibly Compose; have they resolved the issue where the lack of lifecycle semantics means that your services don't work if they have any sort of cluster semantics, like Riak, Cassandra or Zookeeper? These previously always required outside hacks to work, and work flawlessly with Kubernetes. It looks like there's some service discovery support; which may or may not fit the bill.
- shykes 10y ago
  Yes, all of that works seamlessly now. Each container gets an IP and is discoverable via DNS.
  - falcolas 10y ago
    Due to caching implementations which change between OSes, programming languages, and routers, DNS is actually a really terrible discovery mechanism at scale. For example, I'd never want to implement service discovery via DNS in Java, which ignores expiration times and caches queries according to its own settings. I've also seen some server configurations which result in every gethostbyname call to a fully recursive query against DNS.
    - XorNot 10y ago
      The thing is you always need DNS, to the point that I'd rather fix broken logic where I find it rather then try and use something else. Because I'll still end up supporting DNS if I try to run something else.
      - falcolas 10y ago
        Not all use of DNS is the same. If you're attempting service discovery over DNS and need a timely response on changes, any form of caching behavior that does not conform to the specs is going to cause you a headaches when you need it to work most in production.
    - shykes 10y ago
curiousDog 10y ago
Maybe i'm not uptodate or misunderstanding, but doesn't Mesos/Mesosphere do something similar?
- wmf 10y ago
  There are a dozen tools that do something similar.
rcarmo 10y ago
This is great. I can't wait for an ARM build, though.
- PanosJee 10y ago
  Try resin.io!
  - rcarmo 10y ago
    I did. I want the mainstream stuff.
eddd 10y ago
I wish docker released lite version of docker. Only containerisation, no networking configurations, weird cache mechanisms - just something small and easy to use locally. No one sane will run docker on prod anyway.
- atonse 10y ago
  Since it's just one binary, what difference would this make in day-to-day operations?
- Siilwyn 10y ago
  Take a look at rkt in that case: https://github.com/coreos/rkt https://github.com/coreos/rkt
  - orthecreedence 10y ago
    Yes, if you don't look at rkt's for its minimal approach, then at least look at it for its ability to run containers without requiring a root service that runs all your containers under one process.
- friism 10y ago
  Take a look at containerd: https://github.com/docker/containerd https://github.com/docker/containerd
- boucher 10y ago
  They have. It's called runc. (Or, if you want a slightly higher level wrapper API to manage your containers, containerd)
- ams6110 10y ago
  Just use libvirt (virsh utility command) if that's all you want.
  - sciurus 10y ago
    Oh gosh, no. Whatever faults Docker may have, they're outweighed by its very approachable UI compared to the discombobulation that is libvirt's interface. https://libvirt.org/drvlxc.html https://libvirt.org/drvlxc.html
heurist 10y ago
Great, now make it a first class citizen in compose and mix in docker-machine's provisioning capabilities!
foxylion 10y ago
If someone else also want to see the keynote, they have a recording: http://www.ustream.tv/recorded/88610090 http://www.ustream.tv/recorded/88610090
- jjn2009 10y ago
  Thanks, I was looking all over for this! Much appreciated.
ssijak 10y ago
I was using osx beta but uninstalled it for now because docker was eating all my space without recovering it after deleting containers. Anybody using rkt for dev wants to share their experiences, I am thinking about trying it but would not invest time if it is not ready yet.
- foxylion 10y ago
  There may be images or volumes you should remove when no longer required.
  - ssijak 10y ago
    Nope, it was known bug and still not fixed by the time I removed it.
    - avsm 10y ago
      Sorry about that -- this was a bug in one of the betas where log rotation was broken. It's been fixed about 3 or 4 betas ago via a mid-week hotfix, so the latest open beta should be just fine. Hope you get a chance to try the latest series again soon!
cdnsteve 10y ago
I have two code bases that are microservices. I thought using Docker would be easy to setup and share a redis instance between these services. After spending a day trying various thing I just gave up and did 'brew install redis' and got back to real app dev. Docker isn't streamlined enough, does have great examples and is still changing lots. Sometimes doing it the old fashioned way is what lets you ship features faster.
webaholic 10y ago
is docker as good as rkt nowadays?
Annatar 10y ago
The article is lots of blah blah plus "lock-in" for good measure, with exactly zero code or configuration examples, and it reads like a snake oil salesman brochure. I'm still skeptical about the purported advantage of Docker / Linux over zones / SmartOS.
boulos 10y ago
I find it super amusing that GCE isn't mentioned, that ostensibly Kubernetes is the source of lock-in (despite being open-source and likely having more cycles on EC2 than on GCE/GKE), and that this proudly uses gRPC for http/2 and protobuf goodness. So which is it, is Google an evil vendor trying to lock you in, or are we actually doing work in the open and just hoping you'll choose us when you want infrastructure? Disclaimer: I work on Compute Engine, and think of the Kubernetes folks as friends.
- shykes 10y ago
  Disclaimer: I work at Docker. You are reading way too much into this. We're introducing orchestration in Docker because it solves a problem for our users. We haven't called your employer or anyone else "evil", and frankly this announcement is not about Google or any other company. It's about improving Docker for its users. Speaking personally, I think GCE is a great product, Docker wouldn't exist without Go, and although grpc is not my personal favorite, it gets the job done and it's quite popular with Docker engineers. The libcontainer project (now runc/containerd) started with a very fruitful collaboration between Docker and Google engineers. The current Docker networking model is also heavily based on early feedback from the Kubernetes team (one IP per container, remove nat between containers, etc.) Yes, some features of Docker overlap with other products. One of those products is Kubernetes but there are dozens of others. That kind of healthy competition is normal and good for users!
estefan 10y ago
Have they sorted out storing secrets yet? That's one thing I noticed that Kubernetes manages that docker is still scratching it's head over. But this looks like it could be great progress. Orchestration was always the main pain that stopped me from using docker.
tapirl 10y ago
Docker is great (wonderful in fact) for building development/CI environment. I never use docker for production.

275 points by sashk 10y ago

d33 10y ago

I chose Docker for my project with hope that it would help me create an easily reproducible development environment... And I'm not really sure if it was a good idea. There's so many moving parts and I can't name one that actually works well. Configuring storage is a hell (running out of disk space can lead to errors that are really difficult to debug), the dance with bridges makes configuring firewall a terrible experience. I definitely wouldn't recommend it as a stable container solution.

gizmodo59 10y ago
Can you briefly describe your environment?
deleted 10y ago
[deleted]
redrummr 10y ago
Why is storage an issue? With databases, for example, you store data upstream (on the host) and keep the dockerised app/thing mostly stateless, or at least capped with regards to storage. More details about your environment would be appreciated.
- jdoliner 10y ago
  Keeping data on the host is exactly the reason that it's an issue. Swarm offers not guarantees that containers will be rescheduled on the same host that it was initially scheduled on and assumes that it can reschedule containers as failures arise... this doesn't work when your database gets rescheduled and emptied along the way.
  - zamalek 10y ago
    > your database gets rescheduled and emptied along the way That's bundling an CP application into seemingly AP infrastructure (from what I gleaned from their docs). Completely the wrong tool for the job. If the application was designed for that it would have recovered. In your defense, they have nothing to warn about that in their documentation.
    - jdoliner 10y ago
      This isn't really a CAP theorem problem and it's certainly not right to describe Docker as "AP infrastructure." What would that mean exactly? Would you expect this problem to go away if I used a database that sacrificed consistency for availability such as Riak?
      - zamalek 10y ago
        Swarm (not the whole of Docker) seems like something designed for databases like Riak, yes. A SQL failover cluster might work, but certainly not a single database container on infrastructure designed for highly available apps.
  - kerr23 10y ago
    In docker 1.12 you can 'tag' a node and tell a 'service' to only run on the tagged nodes. Not saying that's a good idea, but it is getting closer. You could, for example, have a node that's only for DBs that has volumes on it. You could then use DRBD on the host to clone that data to a secondary node. then in the event that node 1 dies swarm would bring the DB up on node2. With the mesh network stuff they've added the endpoint would remain the same, so all your apps would need to do would be re-connect.
    - jdoliner 10y ago
      > Not saying that's a good idea, but it is getting closer. No, that isn't getting closer it's getting farther away. The whole point of containers is that they make the host machine completely fungible. If I can only schedule my DB containers on a specific machine then I might as well just run my DB on that machine and be done with it.
      - kerr23 10y ago
        hmm, your first complaint was that "Swarm offers no guarantees that containers will be rescheduled on the same host". I'm saying that, if you want, you CAN make it guarantee that a container will be rescheduled to the same host. (or a controlled level of hosts). I don't think it's docker's responsibility to solve database clustering. And, as I said, I'm not advocating running a production DB in docker. But I can see a way that you may be able to.
        jdoliner 10y ago
        I see how that was confusing. I meant that the fact that Swarm doesn't offer such a guarantee is the reason that storing the data on the host isn't a solution. My real complaint is that none of these give you a way to do persistence that doesn't destroy some other really nice properties of containers. There's lots of people trying to fix this problem the right way, Kubernetes has made a lot of progress on having volumes follow the containers around from host to host. Torus is a slightly different approach, Flocker is another one. > I don't think it's docker's responsibility to solve database clustering. I don't know if I'd call it a responsibility. But Docker is obviously trying to expand their platform into more and more aspects of containerization. If they figured out persistence that would really set them apart, something that this product doesn't really do. It mostly just keeps them even with Kubernetes at best. And an imitation of it at worst.
- jodok 10y ago
  why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest
- jodok 10y ago
  why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest
jjtheblunt 10y ago
Did you try rkt or find something else which you liked?
lewisl9029 10y ago
I've been experimenting with Docker for reproducible dev environments as well for a while now, and my biggest issue has been with the app build step, which often requires a specific non-Linux platform (OS X for iOS and Windows for UWP). Back in my previous project using Cordova, I made the Docker workflow work adequately by offloading builds to web-based build services like PhoneGap Build and Ionic Package (building only a thin live-reloading wrapper app that points to a configurable IP:port for development). But my new project uses React Native, and I haven't found any similar build services for React Native apps (or even just regular native apps) yet. Anyone have any suggestions?
- theodorton 10y ago
  Bitrise and Circle CI both support OS X environments for building projects. Combined with fastlane, you'd probably have a good setup for continuous delivery. I've only got experience with running fastlane locally though.
  - nomel 10y ago
    I'm not a web guy, so this question is genuine. How in the world do you keep up/discover all of the different frameworks that seem to pop up daily?
    - skewart 10y ago
      By spending unreasonable amounts of time on HN - at least that's how I rationalize things to myself.
lopatin 10y ago
I totally agree. Docker feels really tidy conceptually. I ended up somehow convincing myself that adding this extra layer of technology into my (relatively tiny) infrastructure will decrease it's complexity. Unsurprisingly, the effect was the exact opposite.
- knz 10y ago
  I feel the exact opposite! The Dockerfile is a simple way to define my environment and it's trivial to run the app in either development, QA, or production. Throw in some of the other functionality such as being able to deploy from an image rather than having to rebuild each time, and it's been a productive addition to my toolset. I'm guessing it depends on how complex your application is, but I've found it fantastic for running Python (Flask), PostgreSQL/PostGIS, MapServer, and some other smaller applications.
  - Annatar 10y ago
    And did you produce OS packages for any of that configuration work, or did you just end up dumping a bunch of files into the "image"?
    - knz 10y ago
      It's not an image in the sense that you can run updates/installs and strip out the crap associated with that but it's so trivial to run "images" that the benefits far outweigh the additional disk space for our use cases.
- codygman 10y ago
  I've been enjoying Nixos[0] and hope to try Nixops[1] soon. The difference between Nixos and docker is that nixos makes it possible to have a truly reproducible environment. See the surprisingly readable paper[2] for more details. 0: http://nixos.org/ http://nixos.org/ 1: http://nixos.org/nixops/ http://nixos.org/nixops/ 2: https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf
ldehaan 10y ago
just a quick tip: check out weave for managing networking, IMO it's much easier and I'm not even talking about the docker plugin. just use weave without the plugin and it works amazingly well. for the configuration aspect, just use dockerfiles and a system like mesos and marathon for deploying production. you can then write simple restful API commands to launch different environments with marathon. build all your docker containers to act as single server instances, i.e., spark on one container, SQL on another. tie in a default install of cadvisor on all mesos clients and you can have easy monitoring as well.
rdtsc 10y ago
You probably want something like NixOS or Guix if you really want to go down that way. Yeah I see where you are coming from. First time I heard about Docker, I thought it did what NixOS does, but it doesn't really.
catmanjan 10y ago
I think Vagrant would be a good replacement for you, it's basically docker but built exactly for reproducible dev environments
Annatar 10y ago
You might want to try out SmartOS: one .json file, vmadm(1M) and imgadm(1M) commands later, you'll have a fully isolated UNIX server, running at the speed of bare metal and residing on ZFS, protecting your data. If you need a more complex network setup, dladm(1M) will enable you to configure virtual switches and routers. The manual pages are really good, too. And there is nothing to install, as SmartOS runs from memory, so that all storage in the system can be used for virtual servers. Upgrades are a breeze by just booting into a new image, either from USB or PXE booting from the network.
fpoling 10y ago
From my experience with Docker one should just avoid docker-supplied volumes and manage the storage oneself using host bind mounts for containers and consistently using --read-only for containers themselves. With that it is really weired to read all complains and issues about volumes management. It seems Docker just picked up wrong model for their storage. Then they try forever to fix impedance mismatch between that model and how people want to use Docker.
- cpuguy83 10y ago
  Care to clarify issues you have with volume management? I think the biggest issue is around the `-v` syntax (and the corrosponding API). In the UX we call things a volume which are actually a mount (which happen to use a volume). I like the way we have implemented this in the new services API.... `docker run --mount type=volume,source=important_data,volume-driver=foo,volume-options=...`
  - fpoling 10y ago
    For me the biggest issue with docker volumes is lack of any notion of subvolumes or volume grouping. Consider an application consisting of few containers communicating over unix sockets each with its own state. Surely I can create a bunch of volumes for the containers, but those would not have any notion of grouping. That complicates administration and development. For example, it is very useful to have a shell view of all volumes for the application to poke inside or debug issues. Surely I can do docker run ubuntu and mount all relevant volumes under /mnt there, but that is not user friendly. Or consider that during development or debugging I want to transfer the state to another machine. Why it is not possible to tar all application volumes with single command and restore them in a new place again with single command? I.e, something similar for docker save/load, but for volumes? All those issues are trivially solvable if I use some directory on a file system for the whole application state and use subdirectories there for individual volumes for the containers and then pass those with -v to relevant containers.
flavioaiello 10y ago
My experience with Docker is kind of ambivalent. We are using docker with docker compose on a legacy vmware stack in a corporate environment. No swarm and no docker overlay network as it does undermine firewalls. It is perfect to apply gitlow and semver to each build of each docker image, so each outcoming application stack is fully determenistic and auditable. Docker storage and network are really simple and docker is the perfect fit. On the other side devs were asking for jenkins for that process. We run also Jenkins on Docker but it's cumbersome as it doesn't allow declarative configuration. There are dozen of plugins out there but it doesn't change the fact that the outcome is ressource hungry and slow. For now we are actually optimizing using Job-DSL plugin. We reached our target, but it was extremly time consuming and pain. For a new project I'm in, maybe we go to replace jenkins with concourseci or drone. Imho a PaaS doesn't solve processual versioning and testing requirements. For that you still need further tools - with or without docker.
- pas 10y ago
  Try Drone CI. It's _very_ Docker friendly.
- jacques_chester 10y ago
  > For a new project I'm in, maybe we go to replace jenkins with concourseci or drone. I love Concourse. Look me up if you have questions.
jondubois 10y ago
I also didn't get the point of Docker until a few months ago when I got acquainted with Kubernetes (K8s) and Rancher. It doesn't really make sense to use Docker without some sort of distributed scheduling/orchestration system like Kubernetes, Docker Swarm or Mesos. I think the first few years of Docker were just pointless but I genuinely feel that it is all starting to come together now. Docker 1.12 looks promising on the orchestration front - Hopefully they will back all these new features with thorough documentation (which I found lacking in Swarm when compared to K8s). It looks like Swarm is just following in K8s' footsteps and maybe even improving things along the way. Based on what I just read, it looks like Docker Swarm might finally be a serious contender to K8s.

deleted 10y ago

[deleted]

geodel 10y ago

I also noticed that now 'Docker for mac' is available without beta invite. I just downloaded and installed though its version is 1.12.0-rc2. Maybe they will make formal announcement when 1.12 for mac is released.

ingve 10y ago
They have announced a Public Beta: https://blog.docker.com/2016/06/docker-mac-windows-public-beta/ https://blog.docker.com/2016/06/docker-mac-windows-public-be...
- geodel 10y ago
  Ohk, great. I did not notice that blog post.
T-A 10y ago
Also https://docs.docker.com/docker-for-windows/ https://docs.docker.com/docker-for-windows/ !

hosh 10y ago

I'm not surprised the Kubernetes primitives got copied into this. I had stated before that Kubernetes was what Docker wants to be when it grows up -- and maybe that time is here. Having used Kubernetes in production, I don't know robust the Docker orchestration primitives are in comparison. But I'll probably find out soon. The big advantage having a built-in Docker orchestration is that Kubernetes is painful to install from scratch. (Yes, there are scripts to help mitigate this; yes, GKE is effectively hosted Kubernetes). I'm involved in another Dockerization projection, but we don't know if we want to invest the time into setting up Kubernetes (though GKE is an option). This would be a good time to check things out. Just to show how quickly things change. In 2015, I tried the docker compose, AWS ECS, and Kubernetes for production deployment, and of all of them, Kubernetes addressed the pain points in a practical way. The Kubernetes project ended in late 2015, and now six months later, things changed again ...

jacques_chester 10y ago
I'll seed what will quickly be an enthusiastic crowd of spruikers for various platforms: have you looked at Cloud Foundry? It's mature, has been scaled to 10,000 real app containers in a single install with a 250,000-container milestone coming soon, belongs to an independent foundation instead of a single company, runs on AWS, Azure, GCP, OpenStack, vSphere with more coming. It handles routing, service injection, logging, container orchestration and a whole bunch of other bits and bobs. You can get started by just pushing your sourcecode, or you can provide container images, whichever works better for you. We even made a version you can test drive on your laptop[0] and we've been working on a "bootloader" for spinning up a full AWS version quickly[1]. Disclaimer: by "we" I mean Pivotal, my employer, which donates the majority of engineering effort to Cloud Foundry. [0] http://pivotal.io/pcf-dev http://pivotal.io/pcf-dev [1] https://github.com/pivotal-cf-experimental/bosh-bootloader https://github.com/pivotal-cf-experimental/bosh-bootloader
- Veratyr 10y ago
  Back when I looked at CloudFoundry (years ago now), it didn't work out because there was no middle ground deployment between a single PC and a full blown production deployment. You either ran it on one machine or you spun up what would have costed ~$1200 in servers at the time. It doesn't appear this has changed: http://docs.pivotal.io/pivotalcf/1-7/customizing/openstack.html http://docs.pivotal.io/pivotalcf/1-7/customizing/openstack.h... Even at a cheap provider like DigitalOcean, this is 16x10 + 6x160 = $1120/month in __overhead__, without even running any useful applications.

csears 10y ago

Just based on the details mentioned in the keynote, the services API and swarm features look very similar to what's offered by Kubernetes... service discovery, rolling updates, load balancing, health checks, auto-healing, advanced scheduling. I guess this was to be expected, but it's also kind of sad. I think it would have been a more strategic move to embrace Kubernetes instead of trying to compete with it.

atonse 10y ago
The problem for docker is that just by building docker engine, they don't really have a way to make money – so stuff like this is probably all an attempt to actually have differentiating products that can generate revenue.
- hosh 10y ago
  Yep, and CoreOS and Kubernetes are already moving towards Rocket as the default, underlying engine.
  - zwischenzug 10y ago
    Kubernetes? Really? Any evidence?
    - hosh 10y ago
      https://github.com/kubernetes/kubernetes/issues/2725 https://github.com/kubernetes/kubernetes/issues/2725 https://docs.google.com/document/d/1dYxInIUDTm4HEArQ9Hom_1NhYw22WrXWdglnaLjtQsI/edit#heading=h.2mzw2mutm6lx https://docs.google.com/document/d/1dYxInIUDTm4HEArQ9Hom_1Nh... I should clarify: CoreOS + Kubernetes using rocket by default. From what I understand, CoreOS is driving the effort to get rocket supported by Kubernetes. K8S looks like it is going for agnostic implementation.
      - sbt 10y ago
        Yes. Also note that CoreOS is basically a shell corporation for Google.

deleted 10y ago

[deleted]

waitwhatwhoa 10y ago

At first I was worried that this is yet another Raft implementation, but it seems they're building on etcd's version [1] which should be a win for everyone trying to prove correctness for the various implementations. 1. https://github.com/docker/swarmkit/blob/a78a157ef66adf0978f031e7bbc9bff2c16df9a0/manager/state/raft/raft.go#L19 https://github.com/docker/swarmkit/blob/a78a157ef66adf0978f0...

gtirloni 10y ago
I like it that etcd is self-contained and easy to troubleshoot, as opposed to a blackbox with tons of magic. The demo for `docker swarm` was great but as an infrastructure engineer, it worries me. First because of the blackbox effect I mentioned above and secondly because I'm not sure how much flexibility is compromised to achiveve that. Sure, it's awesome to quickly have a cluster up for your app and the user experience is phenomenal... but what about storage, network, firewalls, integrating with my linux distro, etc. Things are never this simple when they reach a certain scale and/or number of requirements deviate from those of a simple app. From a quick look at the docs and watching the demo, Kubernetes still feels like a safer option, today. That being said, it's nice to see competition in this space. I guess this will put pressure on Kubernetes and others to improve the user experience further.

kstenerud 10y ago

Omg their navigation bar covers half my screen! Seriously, why do companies inside upon reducing my screen real estate for stupid shit?

rcarmo 10y ago
I actually think this is a valid point, even if somewhat colloquially expressed. I had a lot of trouble getting past that menu bar on Opera Mini and even on an iPad, it's entirely too much.
- wallace_f 10y ago
  Agreed. To be honest, I think the colloquial nature of the post is fine in this case.
KenCochrane 10y ago
Sorry for the issue, we are looking at fixing it.

namidark 10y ago

I wish they would address stability issues first, like this bug[1] that has been around 2 years and is still happening on the latest versions. https://github.com/docker/docker/issues/5618 https://github.com/docker/docker/issues/5618

SEJeff 10y ago
Or this nasty one[1] that has been around just over a year now. It didn't take me more work than using docker as a build server to run into this. There are some udev hacks that make it better, but the underlying issue is ultimately docker here. Doesn't seem that docker inc upstream takes stability seriously from my standpoint. [1] https://github.com/docker/docker/issues/13885 https://github.com/docker/docker/issues/13885
- cpuguy83 10y ago
  Hard problems are hard. We are looking at all kinds of issues related to this, and in reality reports from that issue are likely caused by different things (some things are fixed, others obviously not). There are several people looking how we can resolve issues like this.
cpuguy83 10y ago
This is a caused by a race condition in the kernel that is not particularly easy to solve. The way to solve this is not use the `--userland-proxy=false` function.
- EDevil 10y ago
  Is this acknowledged by the Kernel team? Is there a ticket on the Kernel side where we can keep track of progress?

ShakataGaNai 10y ago

This seems like a really exciting, albeit natural, evolution of the Docker "platform". It's really true that no one cares about containers, everyone just wants their apps to work. That being said the one giant omission from Docker is still seems to be management of volumes/data. Great, we can run 100 nodes on AWS in a matter of minutes, but if your system has data storage requirements (ex: Almost every database ever) ... You're kinda left up to your own still. How does Docker Orchestration migrate the data volumes? They really tried to sell this as "You don't need to do anything but the AWS beta, the DAB and a few commands" which would be wonderful. However with the need for reliable data storage... you're still stuck doing everything "the old fashion way". (Edit: No, I don't mean store data IN the container, I presume no one is that silly. I meant the attached volumes. No volume mgmt = less greatly less helpful).

gongfupotass 10y ago
It seems to me they are more focused on NOsql databases with multiple nodes and shared data like cassandra. So that you don't have to worry too much about volume/data mgmt because you will have multiple copies of the data on other containers when you lose a docker host or a container. You also should conside that docker might not be the best option as opposed to just some vms on openstack for your much needed databases. I'm stuck trying convince my co-workers that docker is not the answer to everything.
- ShakataGaNai 10y ago
  In no way did I mean to convey "store data IN the container" as I had simply assumed no one was that silly. What I actually meant was as "there is no way to deal with volumes". So spinning up 100 instances and hot failover doesn't help if it doesn't deal with the attached volumes. Without that functionality, the orchestration is less magic and more "eh".
- djsumdog 10y ago
  Don't use OpenStack. It's an appropriate solution never. I've been at too many shops where OpenStack is just a bottomless cesspool of the company hemorrhaging money to keep a shitty broken platform barely stable.

lvh 10y ago

The new orchestration looks based on Swarm and possibly Compose; have they resolved the issue where the lack of lifecycle semantics means that your services don't work if they have any sort of cluster semantics, like Riak, Cassandra or Zookeeper? These previously always required outside hacks to work, and work flawlessly with Kubernetes. It looks like there's some service discovery support; which may or may not fit the bill.

shykes 10y ago
Yes, all of that works seamlessly now. Each container gets an IP and is discoverable via DNS.
- falcolas 10y ago
  Due to caching implementations which change between OSes, programming languages, and routers, DNS is actually a really terrible discovery mechanism at scale. For example, I'd never want to implement service discovery via DNS in Java, which ignores expiration times and caches queries according to its own settings. I've also seen some server configurations which result in every gethostbyname call to a fully recursive query against DNS.
  - XorNot 10y ago
    The thing is you always need DNS, to the point that I'd rather fix broken logic where I find it rather then try and use something else. Because I'll still end up supporting DNS if I try to run something else.
    - falcolas 10y ago
      Not all use of DNS is the same. If you're attempting service discovery over DNS and need a timely response on changes, any form of caching behavior that does not conform to the specs is going to cause you a headaches when you need it to work most in production.
  - shykes 10y ago

curiousDog 10y ago

Maybe i'm not uptodate or misunderstanding, but doesn't Mesos/Mesosphere do something similar?

wmf 10y ago
There are a dozen tools that do something similar.

rcarmo 10y ago

This is great. I can't wait for an ARM build, though.

PanosJee 10y ago
Try resin.io!
- rcarmo 10y ago
  I did. I want the mainstream stuff.

eddd 10y ago

I wish docker released lite version of docker. Only containerisation, no networking configurations, weird cache mechanisms - just something small and easy to use locally. No one sane will run docker on prod anyway.

atonse 10y ago
Since it's just one binary, what difference would this make in day-to-day operations?
Siilwyn 10y ago
Take a look at rkt in that case: https://github.com/coreos/rkt https://github.com/coreos/rkt
- orthecreedence 10y ago
  Yes, if you don't look at rkt's for its minimal approach, then at least look at it for its ability to run containers without requiring a root service that runs all your containers under one process.
friism 10y ago
Take a look at containerd: https://github.com/docker/containerd https://github.com/docker/containerd
boucher 10y ago
They have. It's called runc. (Or, if you want a slightly higher level wrapper API to manage your containers, containerd)
ams6110 10y ago
Just use libvirt (virsh utility command) if that's all you want.
- sciurus 10y ago
  Oh gosh, no. Whatever faults Docker may have, they're outweighed by its very approachable UI compared to the discombobulation that is libvirt's interface. https://libvirt.org/drvlxc.html https://libvirt.org/drvlxc.html

heurist 10y ago

Great, now make it a first class citizen in compose and mix in docker-machine's provisioning capabilities!

foxylion 10y ago

If someone else also want to see the keynote, they have a recording: http://www.ustream.tv/recorded/88610090 http://www.ustream.tv/recorded/88610090

jjn2009 10y ago
Thanks, I was looking all over for this! Much appreciated.

ssijak 10y ago

I was using osx beta but uninstalled it for now because docker was eating all my space without recovering it after deleting containers. Anybody using rkt for dev wants to share their experiences, I am thinking about trying it but would not invest time if it is not ready yet.

foxylion 10y ago
There may be images or volumes you should remove when no longer required.
- ssijak 10y ago
  Nope, it was known bug and still not fixed by the time I removed it.
  - avsm 10y ago
    Sorry about that -- this was a bug in one of the betas where log rotation was broken. It's been fixed about 3 or 4 betas ago via a mid-week hotfix, so the latest open beta should be just fine. Hope you get a chance to try the latest series again soon!

cdnsteve 10y ago

I have two code bases that are microservices. I thought using Docker would be easy to setup and share a redis instance between these services. After spending a day trying various thing I just gave up and did 'brew install redis' and got back to real app dev. Docker isn't streamlined enough, does have great examples and is still changing lots. Sometimes doing it the old fashioned way is what lets you ship features faster.

webaholic 10y ago

is docker as good as rkt nowadays?

Annatar 10y ago

The article is lots of blah blah plus "lock-in" for good measure, with exactly zero code or configuration examples, and it reads like a snake oil salesman brochure. I'm still skeptical about the purported advantage of Docker / Linux over zones / SmartOS.

boulos 10y ago

I find it super amusing that GCE isn't mentioned, that ostensibly Kubernetes is the source of lock-in (despite being open-source and likely having more cycles on EC2 than on GCE/GKE), and that this proudly uses gRPC for http/2 and protobuf goodness. So which is it, is Google an evil vendor trying to lock you in, or are we actually doing work in the open and just hoping you'll choose us when you want infrastructure? Disclaimer: I work on Compute Engine, and think of the Kubernetes folks as friends.

shykes 10y ago
Disclaimer: I work at Docker. You are reading way too much into this. We're introducing orchestration in Docker because it solves a problem for our users. We haven't called your employer or anyone else "evil", and frankly this announcement is not about Google or any other company. It's about improving Docker for its users. Speaking personally, I think GCE is a great product, Docker wouldn't exist without Go, and although grpc is not my personal favorite, it gets the job done and it's quite popular with Docker engineers. The libcontainer project (now runc/containerd) started with a very fruitful collaboration between Docker and Google engineers. The current Docker networking model is also heavily based on early feedback from the Kubernetes team (one IP per container, remove nat between containers, etc.) Yes, some features of Docker overlap with other products. One of those products is Kubernetes but there are dozens of others. That kind of healthy competition is normal and good for users!

estefan 10y ago

Have they sorted out storing secrets yet? That's one thing I noticed that Kubernetes manages that docker is still scratching it's head over. But this looks like it could be great progress. Orchestration was always the main pain that stopped me from using docker.

tapirl 10y ago

Docker is great (wonderful in fact) for building development/CI environment. I never use docker for production.