
What I found wrong in Docker 1.12 - rusher81572
http://www.linux-toys.com/?p=684
======
andrewguenther
Disclaimer: I work at AWS, but on a product which does not compete with Docker
or its orchestration tools in any way shape or form. My opinions are my own.

I wouldn't even limit this to just the swarm feature. We've been running
Docker in production for a year, using it in dev environments a year before
that, and we've had major problems nearly every release. We had to upgrade
directly from Docker 1.7 to 1.11 because every release in between was too
unstable or had glaring performance regressions. We ended up running a custom
build and backporting features which were worth the risk.

Speaking of 1.12, my heart sank when I saw the announcement. Native swarm adds
a huge level of complexity to an already unstable piece of software. Dockercon
this year was just a spectacle to shove these new tools down everyone's
throats and really made it feel like they saw the container parts of Docker as
"complete." One of the keynote slides literally read "No one cares about
containers." I get the feeling we'll be running 1.11 for quite some time...

~~~
StreamBright
Would rkt be a worth to try alternative?

~~~
fuzzy2
Hm, I don’t think so. It just doesn’t have enough momentum and as such there
aren’t many containers available. Of course, if you want to roll your own,
that may not be relevant.

I tried it with the nginx and php-fpm Docker containers, but it wouldn’t work
– because those containers assume specific process hierarchies (to log to the
console where you issued `docker run`) that just aren’t present when using
rkt. The advertised Docker compatibility only goes so far.

I still think rkt is a great idea, but I’m too lazy to develop my own
containers. The documentation isn’t that good either.

~~~
cookiecaper
They need to implement support for the Dockerfile format if they want to win.
People value inertia. The switching costs have to be low if you expect anyone
to switch; this only become non-true when the incumbent becomes intolerably
useless to the general userbase.

~~~
philips
rkt can run any docker image built by a Dockerfile:
[https://coreos.com/rkt/docs/latest/running-docker-
images.htm...](https://coreos.com/rkt/docs/latest/running-docker-images.html)

I agree that we need a better ecosystem of build tools and that is something
we are looking to help build out. But, with rkt what we are trying to do is
build an excellent runtime; and think the build side is an important and
orthogonal problem.

------
InTheArena
There are a couple of things here. 1) Right now everyone is afraid that Docker
will emulate VMware, and crowd them out of the container space, much like
VMware killed most of their competitors. 2) To this end, I have heard that
Google and Redhat have massive marketing budgets, and that the marching orders
have been over and over - don't say docker, say k8s. 3) The real battle is
where the money is - large scale distributed systems. Companies want to freeze
docker out, because Docker controls the lowest point of access - the container
runtime itself. 4) hence google is trying to push "docker compatible" ideas
that are just the OCI standard - nothing to do with Docker itself.

AWS doesn't want to support Swarm, because it gives people portability off of
their cloud. Google doesn't want to support swarm, because K8s is a trojan for
Google Cloud. No one else wants to support swarm because it competes with
their products.

That said, what's happening right now, if we are not careful, will fragment
the container ecosystem, and it make it impossible for single containers to
target multiple runtimes.

Docker is the only one who can deliver a universal set of functionality that
is leveraged by all. From a technology point of view, Docker is going in the
right direction. We got burned with Redhat in Openshift 1 & 2 land, and that's
left us with a point of view that the only thing we can depend on is a
container runtime itself, and 12fa applications.

K8s does not really work that way. It's huge and it's heavy, and it expects
every app to be written it's way.

The technical direction here for Docker is good. But the implementation and
early release is ridiculous. I was impressed by the first RC release, and then
terrified that they released a RC as production.

~~~
wstrange
> Docker is the only one who can deliver a universal set of functionality that
> is leveraged by all.

Why do you say that? I have quite a bit more faith in the design chops of the
folks behind Kubernetes (Google, Redhat, CoreOS, and many others) than Docker
Inc.

Swarm really only touches the surface of the requirements for large scale
distributed container orchestration.

Kubernetes is complex because the problem it attempts to solve is complex.

I'd also add that Kubernetes is dead simple to _use_. The difficulty is in
setting it up - but even that is getting much better.

~~~
InTheArena
Good question. K8s has a network mode that is incompatible with swarm, mesos
and nomad. Swarm only touches the very top of requirements for complex
deployments, but going into K8s, the way they do thing pretty much prevents
separate container orchestration systems from working in parallel.

For it to be universal, it has to live in the container runtime.

------
kozikow
I wish that docker would adapt more of a Unix philosophy and focus on doing
one thing well. Why does everyone have to compete with everyone rather than
create set of tools that work well together?

I see docker-machine and docker-swarm as distractions. Reasons why doing all
those other things, instead of focusing on containerisation and packaging may
be harm-full for docker itself:

\- Bundling-in the orchestration with docker make k8s or Mesos more inclined
to fork docker and pull out unnecessary cruft.

\- Churning out half-ready features causes Docker to be known as unreliable
and leads to posts with titles like this. Such reputation tends to stay long
after bugs are fixed. SV-esque launch and iterate works for web apps, but IMO
not for back-end software.

~~~
rglullis
"In infantry battles, he told us, there is only one strategy: Fire and Motion.
You move towards the enemy while firing your weapon. The firing forces him to
keep his head down so he can't fire at you. (That's what the soldiers mean
when they shout "cover me." It means, "fire at our enemy so he has to duck and
can't fire at me while I run across this street, here." It works.) The motion
allows you to conquer territory and get closer to your enemy, where your shots
are much more likely to hit their target. If you're not moving, the enemy gets
to decide what happens, which is not a good thing. If you're not firing, the
enemy will fire at you, pinning you down."

From one of Spolky's finest, _Fire and Motion_ :
[http://www.joelonsoftware.com/articles/fog0000000339.html](http://www.joelonsoftware.com/articles/fog0000000339.html)

~~~
JonnieCache
"If only the Generals had not been content to fight machine-gun bullets with
the breasts of gallant young men, and think that that was waging war."

\- Churchill 1931

~~~
SixSigma
I want you to think very seriously over this question of poison gas. I would
not use it unless it could be shown either that (a) it was life or death for
us, or (b) that it would shorten the war by a year.

It is absurd to consider morality on this topic when everybody used it in the
last war without a word of complaint from the moralists or the Church. On the
other hand, in the last war bombing of open cities was regarded as forbidden.
Now everybody does it as a matter of course. It is simply a question of
fashion changing as she does between long and short skirts for women.

\- Churchill 1944

~~~
randylahey
"War,” writes von Clausewitz, “is an act of violence intended to compel our
opponent to fulfil our will…This is the way in which the matter must be
viewed, and it is to no purpose, it is even against one’s own interest, to
turn away from the consideration of the real nature of the affair because the
horror of its elements excites repugnance.”

~~~
gaius
Supreme excellence consists of breaking the enemy's will, without fighting --
Sun Tzu

------
jondubois
Yes maybe the Docker team should just have joined forces with Kubernetes (K8s)
instead of going out on their own and building Swarm from scratch.

K8s is far ahead of Swarm - K8s has practically built its own language using
YAML files - Swarm is still at a stage that all the configs for a service have
to fit into a single command (and the options are much more restrictive than
K8s).

To be fair, I do like some things about Swarm better than K8s (based on the
docs), but in practice, Swarm is behind and they should tell you that up
front. When I was just starting out, I literally had to install all of them;
Swarm, Mesos and K8s to be able to make an informed decision because, in the
case of Docker, the docs are like 6 months ahead of reality. I didn't realize
that the Docker 'service' command didn't even exist until v1.12 and I couldn't
install v1.12 on my machine (last time I tried, installation was failing -
Obviously not yet stable).

I think Swarm has potential but they need to accept that they're just not
going to be the first to market.

~~~
siegecraft
To be fair, I don't think they built Swarm from scratch, I think it is/was a
rebranding of an acquired product. That being said, Docker and swarm in
particular move too fast for their docs to keep up (let's change the syntax
for some important commands between the final RC and the release?) and it
feels like the only way to be well informed is to scour the github issues,
which seems wrong for something that's touted as a stable, commercially-
supported product.

~~~
justincormack
Swarmkit was built from scratch, based on lessons learned in the previous non
integrated Swarm.

~~~
lcalcote
This is true. The team packed a lot into this new codebase. Many miles to go,
however.

------
gnur
The new swarm mode is great when it works, but it is monster to debug. It
takes care of so many things that it is nearly impossible to pin point what
component isn't working.

The issues I have encountered with swarm mode:

* Some containers could not use hostnames to connect to other containers.

* Sometimes, in a 3 node swarm, containers on A could be reached from B, but not from C.

* After every reboot these issues could be fixed or start occurring.

* It automatically adds firewall rules for every service you port map to be exposed to the internet, without warning

In the end I switched to nomad, it isn't perfect either but at least it is
consistent.

~~~
dexterbt1
Do you have the links to the issue tracker for each of these issues? For me/us
to subscribe/follow.

------
nickbauman
If you look at the design of Kubernetes you'll find a very strong opinion on
how networking is done. Kubernetes does not allow the use of Network Address
Translation (NAT) for container-to-container or for container-to-node traffic.
The internal container IP address must match the IP address that is used to
communicate with it. Swarm plays faster and looser than this. I think Google's
age and experience shows that Docker went the wrong way.

~~~
InTheArena
If by google's age and experience, you mean the requirements of the Google
Cloud, then i agree.

Docker is doing exactly what they should be, but in a manner that is
destructive. Getting a built in consistent p2p routing mesh under every
container is brilliant, and fixes one of the biggest problems with k8s and
swarm (it's not really possible for these technologies to interoperate because
of incompatibilities with the network model).

The big problem is the stability hit. 1.12 had no business loosing the rc
label.

~~~
dward
> If by google's age and experience, you mean the requirements of the Google
> Cloud, then i agree.

Why do you think this is a requirement of Google Cloud?

~~~
InTheArena
Kubernetes and Google Cloud were both informed by the design and implemention
of Borg. Kubernetes is basically for all intents and purposes Google Container
Engine. That's fine, but it;s highly tuned for how google sees the world.

~~~
nickbauman
Huh? Kubernetes can run just fine outside of Google's Cloud. It'll work on any
TCP/IP IaaS offering out there. If you mean it demands a clear end-to-end
connection model for the important moving parts, then, yeah; because of hard-
won experience of what works. They found out that you want to spend your time
on bugs in your app, not bugs in your networking infra.

------
colemickens
Swarm Mode is "great". Assuming you've never heard of or used Kubernetes. In
which case, Docker Swarm is too little, and a year+ too late.

As for marketing, it does seem a bit funny that a product would announce "deep
integration with underlying infrastructure" for a cloud provider when they
haven't written a single line of (public) code to actually support that cloud
provider.

The fun thing is this arguably critical blog post praises features in "swarm
mode" that have long been present in Kubernetes/Mesos/Nomad:
[labels/constraints].

There could be a lot written about the fact that Docker ships "Swarm Mode" as
stable in 1.12 despite virtually everyone's actual first-hand experiences. I
would argue that if "Swarm Mode" were not shipped inside of Docker 1.12 and
didn't benefit from riding along with the normal `docker` package, few would
be talking about it.

~~~
rusher81572
Yeah, Docker has a lot of catching up to do. They bragged a lot lately about
how Swarm is faster than K8s but you really can not compare the two when you
look at features and stability of k8s.

~~~
sjellis
It's amazing (and not in a good way) that this stuff is being shipped in a
point release.

------
CSDude
I also assumed the new easy swarm would be easier, but the Multi-host network
only works with the newly introduced service command only, it does not work
with regular docker run command, which is disappointing because you still
neeed a third party key-value store for it, but not for docker service. It
literally took me hours to realize that was missing. I think 1.12 was just
rushed to show it in DockerCon, normally major releases were mostly bug-free
and worked as intended.

~~~
rusher81572
I feel the pain for I was in the same boat.

------
systemz
Docker team, please focus on one thing - packing apps to containers. Leave
everything else to other projects, don't try to do everything wrong, just do
one thing good. Thank you.

~~~
sjellis
The problem is that they literally can't do that - Docker Inc. took a huge
pile of VC money, and containerization is a commodity feature. To succeed they
have to build higher-level products and services, which put them in direct
competition with the other vendors in the ecosystem.

~~~
dominotw
>To succeed they have to build higher-level products and services

I wish they didn't have to cram it all into single product docker though.

~~~
illumin8
Great point - it would be nice if they separated out their monetization
products (Swarm, Docker Datacenter, etc) from the core Docker engine. There is
plenty of money to be made from enterprise customers who will want the
security features of Docker Datacenter, or support for Swarm, without bundling
your orchestration layer with the container runtime engine.

This type of bundling reminds me of Microsoft bundling IE with Windows.
Initially, IE was much worse than Netscape, and this seems like roughly the
same thing - monopoly in one market bundling an inferior product to try and
achieve a monopoly in another somewhat related market.

------
boomstik
I haven't played enough with Docker Swarm to run into any of these issues, but
Rancher (www.rancher.com) does all of this, and more, very well. I am not
affiliated with them - just a happy user and contributor of github issues.

~~~
drdaeman
Went with them last week, as it seemed to be one of the most sane options out
there (I've tried a lot). Still, has its share of issues. Few ones I've
encountered so far:

\- Their built-in load balancing (HAProxy-based) is nearly impossible to
debug. Literally no logging there.

\- No locality awareness. DNS queries always return all addresses they know
about (including those that don't even work -
[https://github.com/rancher/rancher/issues/5792](https://github.com/rancher/rancher/issues/5792))
and I haven't yet found any good way to prioritize containers co-running on
the local host to the more distant ones
([https://github.com/rancher/rancher/issues/5798](https://github.com/rancher/rancher/issues/5798)
\- if someone been to this situation and has some ideas, would appreciate any
suggestions!).

\- Storage management was advertised, but can't find anything besides NFS
(which is SPOF) and Amazon EFS (which I don't use). There was GlusterFS
support, but it seems it was too broken so they had removed it or something
like that. If one wants persistent storage, they'd better pin containers to
hosts.

~~~
bboreham
> I haven't yet found any good way to prioritize containers co-running on the
> local host

You may find that RFC3484 helps; it prefers the address with the longest
prefix in common with your own address so will tend to pick your own address.
And you are probably getting this behaviour already.

~~~
drdaeman
Thanks for the pointers! Unfortunately, I don't think this applies. I'm
certainly not getting this behavior - I wouldn't have even thought of it if I
haven't observed higher latencies resulting from (sub)requests chain jumping
from node to node back-and-forth, instead of staying within the node's
boundaries.

The problem is, the network space there is flat, not hierarchical - while I
haven't looked at the actual implementation code, I believe container
addresses are just randomly chosen from a single big 10.42/16 subnet and I'm
unaware if there's a way that I can assign hosts, say, a /20 out of that space
(yes, this would've solved things nicely).

~~~
bboreham
Oh. Right. I happen to work on a different Docker network, which 'chunks' the
address space so containers on the same machine are very likely to have
contiguous addresses. Hadn't occurred to me theirs doesn't do that.

~~~
drdaeman
Just curious - what networking/clustering solution you're using?

(I'm asking, so the next time I'll have to make a choice between stacks I
would be more aware about the finer details.)

Thanks!

~~~
bboreham
I work on Weave Net
[http://github.com/weaveworks/weave](http://github.com/weaveworks/weave).

------
erikb
Quality is something long term, but because the world becomes faster and
faster people care less about it. Hype can generate a lot of money in the
short term. And that is what is valued the most in the current economy. Being
a quality guy myself I also feel that this is painful, but I think it's hard
to blame anybody for that. I don't know anybody who goes for the short term
success because they want to live in that kind of world. It's just about the
only thing that gets rewarded.

------
wrong_variable
# Market-Driven-Development

Docker promises too much and delivers too little. Story of every software
project in the last 50 years.

------
agentgt
I wish Docker had some more open source competitors particularly some non-
profit competitors. Yes I know Docker is open source but I have this terribly
gut feeling about becoming too reliant on their technology. I feel like I'm
going to screwed some day.

I guess I just know some day Docker's investors are going to want their money
back.

Yes sure there are other quasi opensource products that are super critical
that I use but they all have alternatives (for example Java has plenty of
alternatives).

Hopefully I don't get downvoted to oblivion for this comment. I am sure my
trust issues are illogical and I would really like to remove the inhibition to
use docker but articles like this do not help.

~~~
sjellis
I don't think that you are being completely illogical. One thing about the
Docker stack, though, is that it is supported by every major vendor, and you
may well be getting your server installations through a vendor (Red Hat, AWS
etc.), so in that case you are insulated from problems. As other commenters
have discussed, the vendors test and patch their Docker distributions
themselves already, as well as contributing to development.

We also already have a functional replacement with rkt. It can use Docker
images, and Kubernetes can use rkt as a run-time in place of Docker, so Docker
is not irreplaceable.

I think that the most valuable bits of Docker today are the developer tooling
- easy Windows and Mac installers, Docker Compose, the online documentation,
and the Hub for grabbing ready-made images. None of which, AFAIK, makes much
money for Docker Inc.

------
graffitici
It seems that using Kubernetes is definitely more mature and usable than
Swarm. But how would you rate the other Docker projects, like docker-machine
and docker-compose. Does Kubernetes also subsume those projects?

These seem to be way more mature than Swarm.

~~~
fideloper
I don't know if Kubernetes is more usable - it's a MONSTER to host yourself.

Other docker projects suffer from various levels of similar issues. Docker-
machine is nice, but has a ton of rough edges, especially when spinning up
host on AWS. It feels like the programmer(s) of machine never used AWS beyond
the simplest use case.

~~~
iso-8859-1
Did you see
[https://github.com/kubernetes/minikube](https://github.com/kubernetes/minikube)
?

------
daxorid
We've experimented with docker in a few places, and the deployment workflow is
just painful:

    
    
      1. sudo docker build -t quay.io/foo/bar
      2. sudo docker push quay.io/foo/bar
      3. <login to production>
      4. sudo docker pull quay.io/foo/bar
      5. sudo docker kill foobar
      6. sudo docker rm foobar
      7. sudo docker run -p 80:80 -p 443:443 -e FOO=bar --name foobar --net=host -d quay.io/foo/bar
    

I can never understand how people talk about docker making deployments somehow
easier.

~~~
justinsaccount
How is that painful?

I run a service using docker and have your steps 4 through 7 as part of a
systemd unit file. Updating the application requires a single systemd restart
command.

~~~
sandGorgon
could you talk about your deployment scripts ? i am trying to deploy a single
flask app which uses redis. I'm not sure how to set up logging, etc. and
whether redis and flask will go in the same VM.

~~~
justinsaccount
Not much in the way of scripts, but the systemd file I use is something like
this:

    
    
      [Unit]
      Description=App
      After=docker.service
      Requires=docker.service
    
      [Service]
      TimeoutStartSec=0
      ExecStartPre=/usr/bin/docker pull app
      ExecStartPre=-/usr/bin/docker kill app
      ExecStartPre=-/usr/bin/docker rm app
      ExecStart=/usr/bin/docker run --name app --rm=true -p 80:80 app
    
      [Install]
      WantedBy=multi-user.target
    

With something like dokku I could just push the git repo containing the
Dockerfile and it would accomplish the same thing

~~~
detiber
You probably also want to add: PartOf=Docker.service

This will ensure that a restart of the docker service will trigger this
service to be restarted.

------
epberry
I share the pain of this post - except my run-in with 1.12 occurred with
Docker for Windows. The shared volumes and host networking were totally
nondeterministic. I don't think I had really ever experienced software which
seemed to fail so randomly.

On the other hand I think Docker can probably be forgiven for my particular
frustration. For one, the software was in beta. And two, working with Windows
and all the different flavors must be a nightmare.

~~~
djs55
(I work at Docker)

If you haven't already and can spare the time, could you file a pair of
issues: perhaps one for the shared volume problem and another for the
networking on [https://github.com/docker/for-
win](https://github.com/docker/for-win) ?

We've been fixing bugs in both areas and the fixes should arrive in the beta
channel over the next few updates. Thanks for your patience!

------
api
Am I the only person around here who is skeptical of _all_ this added
complexity?

Some of it is clearly very useful, but some of it strikes me as a tower of
babel built upon workarounds to problems that have simpler solutions.

What I see here are several different vendors vying to make sure they remain
relevant. While I understand this and even the need for it, I also understand
that it can drive poor engineering decisions in the long run.

------
kennysipe
Disclaimer: I work for Mesosphere

This is the reason the latest Mesos and DCOS has the universal containerizer.
Docker is great for development but currently doesn't make sense for
production. The latest DCOS uses the docker images without the docker process
and provides the high scale production quality needed for a large datacenter.

------
vacri
> _please take it slow and make Docker great again!_

Perhaps they should create some sort of firewall? I mean, the network packets
coming through... they bring malware... they're spam... and some, I assume,
are good traffic.

~~~
m_mueller
I agree very much. Trying to figure out how Docker hacks your host's iptables
and how to deal with it in a production network is a pain.

~~~
andrewguenther
We never let Docker set its own iptables rules. It is a pain at first, but it
forces you to understand how the rules work, what is going on, and has the
added bonus of keeping those rules consistent across Docker releases and in
your own version control.

~~~
m_mueller
so as I understand you add and remove the port mapping and other FW entries
with your own scripts whenever you spin up / stop a container?

~~~
andrewguenther
Port mapping isn't handled by iptables, only the wiring of the docker virtual
interface. We take care of that piece, but let docker do whatever it wants
within that interface.

------
moondev
This should be renamed to "the sad state of swarm mode"

------
rusher81572
I am looking more and more about using the Apcera Platform. They have
everything I need in a container management platform for free:
[https://www.apcera.com/community-edition](https://www.apcera.com/community-
edition)

~~~
jacques_chester
Do you work for Apcera?

Your submission page is heavy on the linux-toys.com domain, implying that it's
yours. That same site identifies the author as working at Apcera.

There is also a submission in your account that points directly to an Apcera
blogpost, with the same author name.

Disclosure: I work for Pivotal, we donate the majority of engineering to Cloud
Foundry. Apcera has beef with us.

~~~
rusher81572
Yes, I work for Apcera and linux-toys.com is my personal blog where I talk
about open source technologies (mainly Docker lately) and software that I
develop. Like the article states, I am a Docker fanboy and want them to be
great again. The blog website is actually running on a four node Raspberry pi
cluster that I referenced in the blog as a link. The reason I joined Apcera is
because they are also developing cool container technology. Until recently,
Apcera was only available to enterprises and didn’t have a solution for
“homeduction” users like me to host and run applications like my blog and a
few other services. With the community edition of the software, I can gather a
few spare x86 boxes and make the switch. I will still be running the same
Docker images but using Apcera’s orchestration software instead of swarm.

~~~
jacques_chester
Thanks. I'm glad to hear Apcera is branching out and that you're excited to
work there.

------
finid
Trying to run Docker on your own to do anything meaningful can be a very
painful exercise.

I gave up after trying to spin up a cluster on DigitalOcean using v1.12. Like
the author, I couldn't get my containers to see each other, something that
worked before v1.12.

------
radarsat1
I personally just getting into Docker and am looking at the swarm feature for
deploying containerized compute nodes to our cluster. People here seem to be
complaining specifically about Swarm mode, is there anything I should watch
out for? What does Kubernetes provide that Docker swarm doesn't?

I've tested Docker Swarm a bit and it seems to work as advertised.

Is it just about node selection not being sophisticated enough? In that case I
don't need to worry since all my nodes are the same, but if there's any words
of warning I'm all ears. Thanks.

------
maxamillion
I've been using docker since version 0.6 and followed almost every version
upgrade since and it's an absolute mess. This blog post is spot on.

My old team had a production environment running in docker containers for
about a year (this was pre-swarm, pre-kubernetes) and then transitioned to
just using ansible for application deployment in a more "traditional" manner
because we spent more time trying to fix broken things with docker than it was
worth.

------
sandGorgon
Question: we are looking to deploy a flask + redis based application to a
single server on AWS using docker. No load balancing, no multiple server

what is the current best practice to do this (with logging, etc.) ? should I
even be considering something like marathon/k8s, etc ?

currently I have a fat docker VM with supervisord and all services running in
a single VM with highly fragile logging. I dont think this can last.

getting started seems very intimidating in the Docker world.

~~~
josegonzalez
Dokku should be able to handle all of your concerns. We do load-balancing on
the server via nginx, use Docker's plumbing (the docker command/api) to build
nice porcelain (our own cli tool) for stuff like restart policies etc. It's
targeted specifically at single-server solutions, and migrating once you are
large enough to another platform is easy as we tend to not build in platform
lock-in.

Feel free to jump on our slack or irc:
[http://dokku.viewdocs.io/dokku/getting-started/where-to-
get-...](http://dokku.viewdocs.io/dokku/getting-started/where-to-get-help/)

Disclaimer: I am a maintainer of Dokku

------
dang
I changed the baity, over-general title "The Sad State of Docker" to what the
first paragraph of the article says it's actually about.

Generally we moderate HN stories/threads less when a YC startup or YC itself
is at issue. But we do still moderate them some, because the standards of the
site still apply.

(We haven't done anything here besides this title edit, though, in case
anybody is wondering.)

------
nullcipher
Negative comments here seem to be a gross overreaction. This is primarily a
code release. Code is always going to keep moving. I have used swarm and it's
nowhere close to unstable as people say it is. Is it production ready?
Probably not. But which software is production ready in every big release?

Unnecessary fear mongering by people who have an outside agenda.

~~~
cpitman
Which release is going to be production ready, and which features are
production ready in each release? If Docker Inc documented which features are
production ready, I'd have more sympathy for that point of view.

What we've had to do at Red Hat is always stay a couple releases behind (we're
shipping 1.10+patches right now) and backport all the fixes from upstream
releases to make it stable (ie production ready). Docker keeps shipping new
versions, with fixes for old issues but then a whole new set of issues added
in.

------
dominotw
is swarm mode same as docker swarm [1]? Curious, Why they choose the same name
if that's not the case.

Why would one use docker swarm[1] vs just docker swarm mode.

1.[https://github.com/docker/swarm](https://github.com/docker/swarm)

~~~
eppsilon
It's not the same. Strangely the docker-swarm tutorial doesn't mention swarm
mode. I wasn't able to follow it successfully with Docker 1.12. That was when
I realized docker-swarm != swarm mode, so I tried the swarm mode tutorial
instead, and it worked as expected.

Maybe docker-swarm is not supported anymore with 1.12? It was all pretty
confusing.

~~~
dominotw
>Maybe docker-swarm is not supported anymore with 1.12?

I am using docker-swarm with 1.12 so it's definitely supported. Yea I am
really confused too :D.

------
bullen
If you need a distributed PaaS alternative for RPi and others, you can look at
[https://github.com/tinspin/rupy](https://github.com/tinspin/rupy).

It's simple and stable!

------
Nano2rad
One reason for release of Open source software is testing.

~~~
majewsky
Yes, but that's why "alpha", "beta" and "RC" labels exist.

------
SparkyMcUnicorn
rekt.. I mean, rkt

------
initdaemon
IMHO, nobody should care / worry about the underlying orchestration. The
industry is moving toward the public service model, and all these management
problem is solved by the cloud platform, not app developers. Check out
hyper.sh, that's what container service would be.

~~~
mixedCase
Or I could manage my own network, which isn't that hard and for a lot of (if
not most) cases, less expensive.

------
gbrayut
So you are saying that a new major software release that is less than a month
old still has some bugs? I am shocked. Shocked! Well, not that shocked.

If you can't take the bleeding part of bleeding edge, wait for things to
mature before using them. Bitching and whining that they didn't create a
perfect product out the gate only belittles the hard work it took to get a new
product out the door.

This is how software releases work in the real world!

~~~
colemickens
It's one thing to knowingly release beta software as "beta".

It's another thing to bundle beta software into an existing package and label
it as stable in order to stay relevant in the orchestration game.

------
hackits
Don't know what all the fuss is about when essentially you're getting Docker
for free?

~~~
abrookewood
That's terrible logic. Imagine if Google just decided to delete people's email
randomly in Gmail ... because free.

~~~
hackits
Are you paying for the service?

~~~
Noseshine
Actually we _do_ pay for "free".

Why do you think "free" is used as a marketing strategy? Obviously there _is_
a monetary benefit somewhere - or anyone attempting a "free" or even just a
"low(er) price" strategy must be doing wrong. An example is Uber, which has
just generated yet another billion dollar loss headline.

Apart from the data collection model, what it does is it removes the incentive
of others to enter that market and possibly create something better.

And on an individual level, something can have a cost merely by existing -
because I have top _choose_. And if I choose wrong I end up worse than where I
could be.

Imagine I was an evil guy from a Disney movie. My next project to annoy people
might be to create an app that _seems_ to work - but has a lot of very
annoying flaws. However, I never mention the flaws (of course not), instead I
go all out on my marketing and make a lot of claims to get people to use my
evil software. I then sit back and with an evil laugh enjoy the frustration
that I created a million times - the (Disney-level) evil scheme succeeded. I
wasted lots of people's time; I may also have sabotaged other (non-evil)
projects by taking users away from them, and I managed to raise the world-wide
frustration level.

~~~
hackits
Unless you write a check out to them, then I classify that as being free.
You're feeling that you're entitled to a service that you don't pay anything
for.

~~~
Noseshine
That is so random - what does your reply have to do with what I wrote?

