10 ms·

Docker, CoreOS, Google, Microsoft, Amazon to Develop Common Container Standard

577 points by yurisagalov 11y ago

ape4 11y ago
Lots of cooks. I hope its not a huge mess.
- Already__Taken 11y ago
  On the other hand, people need to be using this stuff to make it good. With some luck coreOS' super quick relase model can rub off on it and the nice bits can spread and bad bits can die.
- falcolas 11y ago
  You're right. Given that it's basically a tarball with some metadata, there's going to be a huge tendency to bike-shed it... and I hope we can avoid that.
- tracker1 11y ago
  This is my fear as well.. I mean look at "OpenStack" it's horrible, convoluted, excessively complicated and pretty much a pain in the ass. As it stands, docker represents a very clean level of abstraction for application/data containers... combined with any number of management layers it works... but the container layer itself is simple to use in practice. Bringing windows into the mix will only muddle things a lot. I do appreciate Joyent's work on bringing linux compatibility to SmartOS for Docker support, but my hope is that MS doesn't really screw things over here... which I really see happening given how alien the OS is compared to linux. Unless MS creates its' own common-core userspace, which combined with their efforts on opening .Net up could happen, I don't see windows applications fitting in with the rest, and it would create too divergent paths for continued success. Who knows how this will shake down, I've been a fan of lxc/docker from early on, and I use windows on my desktop, but this just scares me.
- panarky 11y ago
  What is Goldman Sachs doing in the kitchen?
  - nickstinemates 11y ago
    They're a huge user and have written a lot of code.
  - innguest 11y ago
    Any kitchen is bound to have some rats.
deathhand 11y ago
This is great news and a shift in the way business is traditionally done. If containers were a thing 20 years ago there would be fierce vendor lock-in and patent/lawsuits flying everywhere. People would chose which cloud platform to deploy based upon which tools they prefer. Docker has fundamentally changed the way they think of the way they fit in the tech eco-system. Instead of selling a set of containers that only work with their tools they've opened up the platform strengthening their position as the go-to solution for management. Prudent move on their part. It limits their potential market cap but solidifies them as an entrenched member for the foreseeable future.
- pjmlp 11y ago
  They were a thing. The company I worked for in early 2000 was using HP-UX containers.
- _hadrian 11y ago
  These are great times! Companies learnt that alone/closed/private doesn't drive innovation... You can see in the latest news many standards been made by the companies together... Working with docker for dev-environment has been fantastic (for me), really fast and easy to start/stop/modify different setups.
  - deathhand 11y ago
    Companies don't drive innovation. Innovation is just the side product of the pursuit of profit. They fill a 'need' in society and get rewarded. If this just so happens to be innovative then so be it.
- gnoway 11y ago
  You'd think that, but the closest we got was Citrix vs. Microsoft and that was over before it really ever got started: https://en.wikipedia.org/wiki/Remote_Desktop_Protocol#Version_4.0 https://en.wikipedia.org/wiki/Remote_Desktop_Protocol#Versio...
justignore 11y ago
Still true: https://xkcd.com/927/ https://xkcd.com/927/
- bhhaskin 11y ago
  I have been seeing this posted all over HN as of late. Although it is funny, it doesn't really add anything to the conversation...
  - falcolas 11y ago
    It points out, in the typical form of humor, that we're going to take a N wheels (the container spec in this case), try and shove them together, to get N+1 wheels. And this is relevant in a space with at least 4 competing standards (and one dominant one). In the short term, what Docker uses with will matter more than the output of any such committee. In the long term, well, it depends on Docker-the-company's fate.
    - jessaustin 11y ago
      Might TFA be a portent for the medium term? The big players who hope to squash Docker are embracing now, only to extend later?
    - jsmthrowaway 11y ago
      > In the short term, what Docker uses with will matter more than the output of any such committee. How is that true? I'm already excited to kill dockerd just to run containers.
      - falcolas 11y ago
        Many container services currently support starting Docker images, and with all of the money spent on marketing, Docker also owns the container ecosystem mindshare. It's their game to lose.
    - bhhaskin 11y ago
      Now that adds to the conversation. I think it is fine to use it to illustrate a point, but it doesn't stand alone by itself.
abritishguy 11y ago
I hope from this we get a really well engineered standard and not some silly mess.
deleted 11y ago
[deleted]
gtirloni 11y ago
We're not even near the peak yet. https://en.wikipedia.org/wiki/Hype_cycle#/media/File:Hype-Cycle-General.png https://en.wikipedia.org/wiki/Hype_cycle#/media/File:Hype-Cy...
- bduerst 11y ago
  Depends. Gartner doesn't put "Container Computing" on their hype curve, but I doubt it's on the level of autonomous vehicles. http://na2.www.gartner.com/imagesrv/newsroom/images/HC_ET_2014.jpg;pv4cc7877f7de80268 http://na2.www.gartner.com/imagesrv/newsroom/images/HC_ET_20...
- cdcarter 11y ago
  Or perhaps we're already at supplier consolidation...
mpdehaan2 11y ago
Hmm, interesting. I'm unclear what value this adds in the end Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference? Containers are useful if you have the build systems in source control, but if you don't, you don't know how to rebuild them or what is in them - they become dangerous in that case. They become scary "golden images". Docker files were already very easy to regenerate things -- and I think interface wise, one of the more compelling wins. If there were other systems it's still likely they would have different provisioners. It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker, and Docker becomes more or less a subcommitee of a standards body. I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me and what this means for valuation purposes.
- nailer 11y ago
  I think it means Docker the company no longer gets to define 'Docker' as 'Docker with all Docker-the-company's value-added products attached'.
  - bjt 11y ago
    I think they'll continue to define it that way, but the underlying container spec and runtime will be called something other than "Docker".
    - nickstinemates 11y ago
      This is correct.
- dragonwriter 11y ago
  > but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing From the Google/Amazon/Microsoft POV, that's part of the point. From the CoreOS/Docker POV, the fact that the container technology that the major cloud hosts support is going to define their market whether they participate or not is probably why they have an incentive to participate. > It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform. From the advantage of also being one of the players defining the standard, and one of the key implementers of the basic software, which will give them an advantage in implementing management software. > I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me Sure, they want to seek differentiation. But they probably don't want differentiate themselves as "the vendor of the container technology that isn't backed by any of the major cloud hosts", when there is a container technology that is backed by those hosts.
joslin01 11y ago
I am a big believer in containerization technology from a practical standpoint. It has allowed me to create repositories that act as services. Database, search, api, admin, etc.. they are all their own service. I do not have to configure any servers this way; instead, I declare what the system ought to be and Docker makes it happen. I don't even have to configure init scripts because a proper Dockerfile will contain a start mechanism usually in the form of any other executable: `docker run your/api --port 80 --host host.company.com`. The only thing that matters then between services is their bindings, which gives you the ability to use any programming language for any service. Deployment with ECS has been going well so far for me. My flow: 1.) Push code to GitHub 2.) GitHub tells Docker, which builds a private image 3.) Docker tells my build server 4.) Build server tells ECS to update the given service 5.) ECS pulls from DockerHub, stops service, starts service The only thing missing is that DockerHub doesn't tell my build server what tag it just built! It builds tags like dev / staging for the given branches, but doesn't relay that info over its webhook. There's a ticket open about this already and I'm sure they'll get to it soon. Nevertheless, I'm able to administer any system -- things like Elasticsearch, db, api -- from code on a branch. This is powerful to me because I have to administer environments for everything. Rather than do all this work with Puppet, Chef, or even Ansible, I can just declare what the systems ought to be and cluster them within code branches. With ECS coming into picture, you're encouraged to forget you even have physical boxes in the first place. If you think of the power at your finger tips that results from this development workflow, I believe it's a no brainer for everyone to jump on board and get this as good as it can be. It's going to be a huge boon to the software community and enable more services sharing.
- emiller829 11y ago
  I'd love to hear how you're handling the ECS part of this. From the experimentation I've done, it's not just a matter of telling ECS to update the service unless you're running 2x the number of container instances you need -- it won't pull resources out from the existing service revision in order to spin up the new ones. Certainly can be worked around, but it's a little annoying.
  - joslin01 11y ago
vezzy-fnord 11y ago
I was going to ask why IBM weren't in, but read on to see that it's a general Linux Foundation collaboration, and so naturally they're part of it. So I guess we're going to have libcontainer support for AIX Workload Partitions and OS/400 LPARs? It's gonna be interesting to see just how big the Docker libs become.
- nickstinemates 11y ago
  Stay tuned for the rest of DockerCon :)
bobsky 11y ago
The proof is in the pudding. Overall this is very positive for the ecosystem as a whole, and glad to see them all come together. But I thought a big selling point of a standard means it's written down, currently the spec returns a 404 on github [1] seems like a lot of unknowns on what's actually being proposed. It’s confusing why the App Container (appc) spec which is written down [2] and has maintainers from RedHat, Twitter, Google, Apcera, CoreOS [3] is not being promoted - what's the new OCP standard offering that isn't in the appc spec? [1] https://github.com/opencontainers/specs https://github.com/opencontainers/specs [2] https://github.com/appc/spec https://github.com/appc/spec [3] http://www.infoq.com/news/2015/05/appc-spec-gains-support http://www.infoq.com/news/2015/05/appc-spec-gains-support
- cwyers 11y ago
  I'm guessing because Docker didn't participate in App Container, so this is a compromise to bring Docker on board.
  - shykes 11y ago
    To clarify, the Open Container Project was started by Docker with the help of the Linux Foundation. Then other vendors were invited (including AppC maintainers). We did this because there was a clear demand for transforming a de-facto standard (the Docker format) into a proper standard (OCF), and for opening the governance of our runC implementation. Since AppC is a completely different format from what Docker uses, starting from that would have defeated the purpose. However it made a lot of sense to invite the people behind AppC to join, so that we could all build a better spec and implementation together, instead of arguing on technical details that don't matter.
    - deleted 11y ago
      [deleted]
    - deleted 11y ago
      [deleted]
- vidarh 11y ago
deleted 11y ago
[deleted]
olalonde 11y ago
Weird to see Microsoft in that list. On a related note, will this new container standard support non-Linux kernels? Would be nice to be able to run containers directly on OS X without having to go through the boot2docker VM.
- cbhl 11y ago
  Microsoft probably wants people running containers on HyperV/Windows Server machines, the way they currently contribute patches to Linux so people can run Linux VMs on HyperV/Windows Server.
- nickstinemates 11y ago
  Not so weird. We have been working together for a very long time, and publicly announced in October last week that Docker was coming to Windows Server.
  - contingencies 11y ago
    October last week, eh! That was about the time I deleted my last Windows VM, too.
    - nickstinemates 11y ago
      How does a demo today work? :)
- shmerl 11y ago
  I'd say it's unusual for MS to help open standards given their usual attitude and history, but if you think of it, they have no edge in containers competition. I.e. it's more likely for them to participate when they have no hope for lock-in. Good luck with expecting their participation in other situations (for instance contributing to Vulkan when their DirectX is very dominant already).
- itaysk 11y ago
  Not at all.. MS and Docker have a strong partnership, and container support is coming to Windows Server 2016 and Hyper-V http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx http://blogs.technet.com/b/server-cloud/archive/2015/04/08/m...
vacri 11y ago
If Docker's heavily screwed-up tag system becomes locked into a standard, I may as well slit my wrists now.
- colordrops 11y ago
  I agree that the tagging system needs some work. I'm curious as to what you think is wrong with it. Could you share your thoughts?
  - vacri 11y ago
    Everything gets shoehorned into the one tag. Originating repo, image name, version. So next time you pull "x/y:latest", the current holder of that tag loses everything. You see an image in the list with nothing listed - no repo and no image name, when it should just lose the 'latest' tag. If I have multiple images on a machine, I now can't tell which are the old images from a particular repo (well... I can guess by image size), and that's not great if I want to roll back. There is no reason for an image to automatically lose a tag describing where it came from. It also means you have to tag twice using the full tag if you want build numbers: this build is "x/y:latest" and "x/y:v1.2.3", when you could just do "latest" and "v1.2.3". Similarly, when you pull an image, it should pull all tags associated with that layer, so you pull 'latest' and it also brings the tag 'v1.2.3'. This seemed to be the case with the docker v1.5, but it seems inconsistent in 1.6. I haven't had time to nail down that suspicion, though. There are other bits that could do with polish (like being able to do multiple tags at once, rather than push afresh for each one), but the main problem is the single tag field. Given the amount of metadata they already store for an image, this seems a strange behaviour to suffer.
TheMagicHorsey 11y ago
What does this mean for vendors like VMWare that want VMs to be the unit of deployment that developers interface with? Seems to me that VMWare's VM management technology is still needed, but the clock is now running on how long it will be before their part of the stack is irrelevant, as all the smarts move into the container-management layer.
- joslin01 11y ago
  Well, VMs are what makes it possible for a service like AWS to spin up an instance for you. They'll be needed, but you're right, developers won't look to them as solutions for their deployment problem.
- xahrepap 11y ago
  I'm at DockerCon and VMWare has a booth. They demoed some cool stuff. Like using docker as the interface to some of their stuff. It wasn't pure containers, but they had non-linux "containers" running (DOS was their demo). Powered by VMWare but the interface was Docker. It even supported commits, pulls, and pushes. That will be a good "polyfill" for platforms that aren't supported by Docker (yet). It seems to me that VMWare is looking for ways to stay relevant long term.
  - travem 11y ago
    Here's the video of the VMware demo of running MSDOS using docker - http://youtu.be/NrsVbnn-znk http://youtu.be/NrsVbnn-znk
jakejake 11y ago
Serious question. We have a master DB and a slave, two memcache servers and 3 webservers behind a load balancer. We're not a public-facing company and so have no reason to be building for "web scale" or whatever, we're well within capacity. Deploying new code (happens weekely) is just as simple as clicking one deploy button in our version control system (which does a "git pull" on the web servers). DB changes (which are very rare, once or twice a year) we run manually. The cache servers never change. All of the server run automated security updates on the OS. Otherwise we upgrade non-essential packages every few months. Is there a way that using Docker could make things better for us? I feeling the "you should be using Docker" coming at me from every angle. Our deployment is certainly not very sexy but it is simple and doesn't take a major amount of effort. Is there a use case for a company like mine?
- contingencies 11y ago
  Not really. If your master burns and dies, your recovery or promotion process on the slave is probably manual. That's OK, but you could make it automated. Docker wouldn't actually solve the hard bits, but would possibly make the automation easier.
- rattray 11y ago
  My guess is probably not, you're doing just fine. If your server configurations change for some reason in the future (sounds unlikely) it might be easier to start from scratch with Docker than manually adjust the servers; but that all depends on your situation.
- i_have_to_speak 11y ago
  You're doing an excellent job. Don't let all the marketing money fool you.
castell 11y ago
What's next? Develop a common executable standard? Develop a common UI standard?
rbanffy 11y ago
Would anyone care to explain how Microsoft fits on this picture?
- hornetblack 11y ago
  Microsoft is going have containers for Windows Server. It looks like it would would with Docker's client as well. "Last October, Microsoft and Docker, Inc. jointly announced plans to bring containers to developers across the Docker and Windows ecosystems via Windows Server Containers, available in the next version of Windows Server." http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils-new-container-technologies-for-the-next-generation-cloud/ http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils...
- aduric 11y ago
  There are a large number of web applications running in IIS under the .NET platform: http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html http://news.netcraft.com/archives/2014/04/02/april-2014-web-... Also, Microsoft has made some announcements recently to get on the containerization bandwagon: http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils-new-container-technologies-for-the-next-generation-cloud/ http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils...
  - rbanffy 11y ago
    Yes, but Docker is an application distribution format that essentially bundles parts of the server the app needs to run on with it so they can run within a container on the host machine. Didn't Microsoft solve this application bundling with .NET before?
erikpukinskis 11y ago
If I was the NSA I would be drooling at this opportunity.
nlake44 11y ago
Containers in themselves offer little additional value to virtual machines. Don't switch over just because of the hype. Evaluate it yourself! (I personally LOVE vagrant!)

577 points by yurisagalov 11y ago

ape4 11y ago

Lots of cooks. I hope its not a huge mess.

Already__Taken 11y ago
On the other hand, people need to be using this stuff to make it good. With some luck coreOS' super quick relase model can rub off on it and the nice bits can spread and bad bits can die.
falcolas 11y ago
You're right. Given that it's basically a tarball with some metadata, there's going to be a huge tendency to bike-shed it... and I hope we can avoid that.
tracker1 11y ago
This is my fear as well.. I mean look at "OpenStack" it's horrible, convoluted, excessively complicated and pretty much a pain in the ass. As it stands, docker represents a very clean level of abstraction for application/data containers... combined with any number of management layers it works... but the container layer itself is simple to use in practice. Bringing windows into the mix will only muddle things a lot. I do appreciate Joyent's work on bringing linux compatibility to SmartOS for Docker support, but my hope is that MS doesn't really screw things over here... which I really see happening given how alien the OS is compared to linux. Unless MS creates its' own common-core userspace, which combined with their efforts on opening .Net up could happen, I don't see windows applications fitting in with the rest, and it would create too divergent paths for continued success. Who knows how this will shake down, I've been a fan of lxc/docker from early on, and I use windows on my desktop, but this just scares me.
panarky 11y ago
What is Goldman Sachs doing in the kitchen?
- nickstinemates 11y ago
  They're a huge user and have written a lot of code.
- innguest 11y ago
  Any kitchen is bound to have some rats.

deathhand 11y ago

This is great news and a shift in the way business is traditionally done. If containers were a thing 20 years ago there would be fierce vendor lock-in and patent/lawsuits flying everywhere. People would chose which cloud platform to deploy based upon which tools they prefer. Docker has fundamentally changed the way they think of the way they fit in the tech eco-system. Instead of selling a set of containers that only work with their tools they've opened up the platform strengthening their position as the go-to solution for management. Prudent move on their part. It limits their potential market cap but solidifies them as an entrenched member for the foreseeable future.

pjmlp 11y ago
They were a thing. The company I worked for in early 2000 was using HP-UX containers.
_hadrian 11y ago
These are great times! Companies learnt that alone/closed/private doesn't drive innovation... You can see in the latest news many standards been made by the companies together... Working with docker for dev-environment has been fantastic (for me), really fast and easy to start/stop/modify different setups.
- deathhand 11y ago
  Companies don't drive innovation. Innovation is just the side product of the pursuit of profit. They fill a 'need' in society and get rewarded. If this just so happens to be innovative then so be it.
gnoway 11y ago
You'd think that, but the closest we got was Citrix vs. Microsoft and that was over before it really ever got started: https://en.wikipedia.org/wiki/Remote_Desktop_Protocol#Version_4.0 https://en.wikipedia.org/wiki/Remote_Desktop_Protocol#Versio...

justignore 11y ago

Still true: https://xkcd.com/927/ https://xkcd.com/927/

bhhaskin 11y ago
I have been seeing this posted all over HN as of late. Although it is funny, it doesn't really add anything to the conversation...
- falcolas 11y ago
  It points out, in the typical form of humor, that we're going to take a N wheels (the container spec in this case), try and shove them together, to get N+1 wheels. And this is relevant in a space with at least 4 competing standards (and one dominant one). In the short term, what Docker uses with will matter more than the output of any such committee. In the long term, well, it depends on Docker-the-company's fate.
  - jessaustin 11y ago
    Might TFA be a portent for the medium term? The big players who hope to squash Docker are embracing now, only to extend later?
  - jsmthrowaway 11y ago
    > In the short term, what Docker uses with will matter more than the output of any such committee. How is that true? I'm already excited to kill dockerd just to run containers.
    - falcolas 11y ago
      Many container services currently support starting Docker images, and with all of the money spent on marketing, Docker also owns the container ecosystem mindshare. It's their game to lose.
  - bhhaskin 11y ago
    Now that adds to the conversation. I think it is fine to use it to illustrate a point, but it doesn't stand alone by itself.

abritishguy 11y ago

I hope from this we get a really well engineered standard and not some silly mess.

deleted 11y ago

[deleted]

gtirloni 11y ago

We're not even near the peak yet. https://en.wikipedia.org/wiki/Hype_cycle#/media/File:Hype-Cycle-General.png https://en.wikipedia.org/wiki/Hype_cycle#/media/File:Hype-Cy...

bduerst 11y ago
Depends. Gartner doesn't put "Container Computing" on their hype curve, but I doubt it's on the level of autonomous vehicles. http://na2.www.gartner.com/imagesrv/newsroom/images/HC_ET_2014.jpg;pv4cc7877f7de80268 http://na2.www.gartner.com/imagesrv/newsroom/images/HC_ET_20...
cdcarter 11y ago
Or perhaps we're already at supplier consolidation...

mpdehaan2 11y ago

Hmm, interesting. I'm unclear what value this adds in the end Yes container images would become portable between systems, but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing? What's the value difference? Containers are useful if you have the build systems in source control, but if you don't, you don't know how to rebuild them or what is in them - they become dangerous in that case. They become scary "golden images". Docker files were already very easy to regenerate things -- and I think interface wise, one of the more compelling wins. If there were other systems it's still likely they would have different provisioners. It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker, and Docker becomes more or less a subcommitee of a standards body. I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me and what this means for valuation purposes.

nailer 11y ago
I think it means Docker the company no longer gets to define 'Docker' as 'Docker with all Docker-the-company's value-added products attached'.
- bjt 11y ago
  I think they'll continue to define it that way, but the underlying container spec and runtime will be called something other than "Docker".
  - nickstinemates 11y ago
    This is correct.
dragonwriter 11y ago
> but if you hide the underlying system enough under abstraction layers what makes me choose between CoreOS or Docker or the future thing From the Google/Amazon/Microsoft POV, that's part of the point. From the CoreOS/Docker POV, the fact that the container technology that the major cloud hosts support is going to define their market whether they participate or not is probably why they have an incentive to participate. > It seems the (excuse me for the buzzword) value add then quickly becomes in the people providing management software for Docker, rather than in Docker Docker-the-company is probably going to be one of the "people" providing management support for the new standard container platform. From the advantage of also being one of the players defining the standard, and one of the key implementers of the basic software, which will give them an advantage in implementing management software. > I'm sure that's NOT true, but it's confusing why they wouldn't want to seek differentiation to me Sure, they want to seek differentiation. But they probably don't want differentiate themselves as "the vendor of the container technology that isn't backed by any of the major cloud hosts", when there is a container technology that is backed by those hosts.

joslin01 11y ago

I am a big believer in containerization technology from a practical standpoint. It has allowed me to create repositories that act as services. Database, search, api, admin, etc.. they are all their own service. I do not have to configure any servers this way; instead, I declare what the system ought to be and Docker makes it happen. I don't even have to configure init scripts because a proper Dockerfile will contain a start mechanism usually in the form of any other executable: `docker run your/api --port 80 --host host.company.com`. The only thing that matters then between services is their bindings, which gives you the ability to use any programming language for any service. Deployment with ECS has been going well so far for me. My flow: 1.) Push code to GitHub 2.) GitHub tells Docker, which builds a private image 3.) Docker tells my build server 4.) Build server tells ECS to update the given service 5.) ECS pulls from DockerHub, stops service, starts service The only thing missing is that DockerHub doesn't tell my build server what tag it just built! It builds tags like dev / staging for the given branches, but doesn't relay that info over its webhook. There's a ticket open about this already and I'm sure they'll get to it soon. Nevertheless, I'm able to administer any system -- things like Elasticsearch, db, api -- from code on a branch. This is powerful to me because I have to administer environments for everything. Rather than do all this work with Puppet, Chef, or even Ansible, I can just declare what the systems ought to be and cluster them within code branches. With ECS coming into picture, you're encouraged to forget you even have physical boxes in the first place. If you think of the power at your finger tips that results from this development workflow, I believe it's a no brainer for everyone to jump on board and get this as good as it can be. It's going to be a huge boon to the software community and enable more services sharing.

emiller829 11y ago
I'd love to hear how you're handling the ECS part of this. From the experimentation I've done, it's not just a matter of telling ECS to update the service unless you're running 2x the number of container instances you need -- it won't pull resources out from the existing service revision in order to spin up the new ones. Certainly can be worked around, but it's a little annoying.
- joslin01 11y ago

vezzy-fnord 11y ago

I was going to ask why IBM weren't in, but read on to see that it's a general Linux Foundation collaboration, and so naturally they're part of it. So I guess we're going to have libcontainer support for AIX Workload Partitions and OS/400 LPARs? It's gonna be interesting to see just how big the Docker libs become.

nickstinemates 11y ago
Stay tuned for the rest of DockerCon :)

bobsky 11y ago

The proof is in the pudding. Overall this is very positive for the ecosystem as a whole, and glad to see them all come together. But I thought a big selling point of a standard means it's written down, currently the spec returns a 404 on github [1] seems like a lot of unknowns on what's actually being proposed. It’s confusing why the App Container (appc) spec which is written down [2] and has maintainers from RedHat, Twitter, Google, Apcera, CoreOS [3] is not being promoted - what's the new OCP standard offering that isn't in the appc spec? [1] https://github.com/opencontainers/specs https://github.com/opencontainers/specs [2] https://github.com/appc/spec https://github.com/appc/spec [3] http://www.infoq.com/news/2015/05/appc-spec-gains-support http://www.infoq.com/news/2015/05/appc-spec-gains-support

cwyers 11y ago
I'm guessing because Docker didn't participate in App Container, so this is a compromise to bring Docker on board.
- shykes 11y ago
  To clarify, the Open Container Project was started by Docker with the help of the Linux Foundation. Then other vendors were invited (including AppC maintainers). We did this because there was a clear demand for transforming a de-facto standard (the Docker format) into a proper standard (OCF), and for opening the governance of our runC implementation. Since AppC is a completely different format from what Docker uses, starting from that would have defeated the purpose. However it made a lot of sense to invite the people behind AppC to join, so that we could all build a better spec and implementation together, instead of arguing on technical details that don't matter.
  - deleted 11y ago
    [deleted]
  - deleted 11y ago
    [deleted]
vidarh 11y ago

deleted 11y ago

[deleted]

olalonde 11y ago

Weird to see Microsoft in that list. On a related note, will this new container standard support non-Linux kernels? Would be nice to be able to run containers directly on OS X without having to go through the boot2docker VM.

cbhl 11y ago
Microsoft probably wants people running containers on HyperV/Windows Server machines, the way they currently contribute patches to Linux so people can run Linux VMs on HyperV/Windows Server.
nickstinemates 11y ago
Not so weird. We have been working together for a very long time, and publicly announced in October last week that Docker was coming to Windows Server.
- contingencies 11y ago
  October last week, eh! That was about the time I deleted my last Windows VM, too.
  - nickstinemates 11y ago
    How does a demo today work? :)
shmerl 11y ago
I'd say it's unusual for MS to help open standards given their usual attitude and history, but if you think of it, they have no edge in containers competition. I.e. it's more likely for them to participate when they have no hope for lock-in. Good luck with expecting their participation in other situations (for instance contributing to Vulkan when their DirectX is very dominant already).
itaysk 11y ago
Not at all.. MS and Docker have a strong partnership, and container support is coming to Windows Server 2016 and Hyper-V http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx http://blogs.technet.com/b/server-cloud/archive/2015/04/08/m...

vacri 11y ago

If Docker's heavily screwed-up tag system becomes locked into a standard, I may as well slit my wrists now.

colordrops 11y ago
I agree that the tagging system needs some work. I'm curious as to what you think is wrong with it. Could you share your thoughts?
- vacri 11y ago
  Everything gets shoehorned into the one tag. Originating repo, image name, version. So next time you pull "x/y:latest", the current holder of that tag loses everything. You see an image in the list with nothing listed - no repo and no image name, when it should just lose the 'latest' tag. If I have multiple images on a machine, I now can't tell which are the old images from a particular repo (well... I can guess by image size), and that's not great if I want to roll back. There is no reason for an image to automatically lose a tag describing where it came from. It also means you have to tag twice using the full tag if you want build numbers: this build is "x/y:latest" and "x/y:v1.2.3", when you could just do "latest" and "v1.2.3". Similarly, when you pull an image, it should pull all tags associated with that layer, so you pull 'latest' and it also brings the tag 'v1.2.3'. This seemed to be the case with the docker v1.5, but it seems inconsistent in 1.6. I haven't had time to nail down that suspicion, though. There are other bits that could do with polish (like being able to do multiple tags at once, rather than push afresh for each one), but the main problem is the single tag field. Given the amount of metadata they already store for an image, this seems a strange behaviour to suffer.

TheMagicHorsey 11y ago

What does this mean for vendors like VMWare that want VMs to be the unit of deployment that developers interface with? Seems to me that VMWare's VM management technology is still needed, but the clock is now running on how long it will be before their part of the stack is irrelevant, as all the smarts move into the container-management layer.

joslin01 11y ago
Well, VMs are what makes it possible for a service like AWS to spin up an instance for you. They'll be needed, but you're right, developers won't look to them as solutions for their deployment problem.
xahrepap 11y ago
I'm at DockerCon and VMWare has a booth. They demoed some cool stuff. Like using docker as the interface to some of their stuff. It wasn't pure containers, but they had non-linux "containers" running (DOS was their demo). Powered by VMWare but the interface was Docker. It even supported commits, pulls, and pushes. That will be a good "polyfill" for platforms that aren't supported by Docker (yet). It seems to me that VMWare is looking for ways to stay relevant long term.
- travem 11y ago
  Here's the video of the VMware demo of running MSDOS using docker - http://youtu.be/NrsVbnn-znk http://youtu.be/NrsVbnn-znk

jakejake 11y ago

Serious question. We have a master DB and a slave, two memcache servers and 3 webservers behind a load balancer. We're not a public-facing company and so have no reason to be building for "web scale" or whatever, we're well within capacity. Deploying new code (happens weekely) is just as simple as clicking one deploy button in our version control system (which does a "git pull" on the web servers). DB changes (which are very rare, once or twice a year) we run manually. The cache servers never change. All of the server run automated security updates on the OS. Otherwise we upgrade non-essential packages every few months. Is there a way that using Docker could make things better for us? I feeling the "you should be using Docker" coming at me from every angle. Our deployment is certainly not very sexy but it is simple and doesn't take a major amount of effort. Is there a use case for a company like mine?

contingencies 11y ago
Not really. If your master burns and dies, your recovery or promotion process on the slave is probably manual. That's OK, but you could make it automated. Docker wouldn't actually solve the hard bits, but would possibly make the automation easier.
rattray 11y ago
My guess is probably not, you're doing just fine. If your server configurations change for some reason in the future (sounds unlikely) it might be easier to start from scratch with Docker than manually adjust the servers; but that all depends on your situation.
i_have_to_speak 11y ago
You're doing an excellent job. Don't let all the marketing money fool you.

castell 11y ago

What's next? Develop a common executable standard? Develop a common UI standard?

rbanffy 11y ago

Would anyone care to explain how Microsoft fits on this picture?

hornetblack 11y ago
Microsoft is going have containers for Windows Server. It looks like it would would with Docker's client as well. "Last October, Microsoft and Docker, Inc. jointly announced plans to bring containers to developers across the Docker and Windows ecosystems via Windows Server Containers, available in the next version of Windows Server." http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils-new-container-technologies-for-the-next-generation-cloud/ http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils...
aduric 11y ago
There are a large number of web applications running in IIS under the .NET platform: http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html http://news.netcraft.com/archives/2014/04/02/april-2014-web-... Also, Microsoft has made some announcements recently to get on the containerization bandwagon: http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils-new-container-technologies-for-the-next-generation-cloud/ http://azure.microsoft.com/blog/2015/04/08/microsoft-unveils...
- rbanffy 11y ago
  Yes, but Docker is an application distribution format that essentially bundles parts of the server the app needs to run on with it so they can run within a container on the host machine. Didn't Microsoft solve this application bundling with .NET before?

erikpukinskis 11y ago

If I was the NSA I would be drooling at this opportunity.

nlake44 11y ago

Containers in themselves offer little additional value to virtual machines. Don't switch over just because of the hype. Evaluate it yourself! (I personally LOVE vagrant!)