
Cluster and app management services in Docker Cloud are shutting down on May 21 - zebra9978
https://docs.docker.com/docker-cloud/migration/
======
zebra9978
We are extremely worried about the future of Docker Swarm as well. We love
Swarm - but we are seeing most work out of the Docker team is to give a
migration path to kubernetes. A huge number of docker swarm networking bugs
are not being worked on.

We will be happy if Docker talks about Swarm becoming a management UX for K8s
- but we need visibility. These are production orchestration systems. The
migration path is not easy.

And seeing what Docker Co is doing with Cloud, it is not very comforting to
trust that they will do the right thing with Swarm.

~~~
adamtulinius
Why did you pick Swarm for production?

We followed Swarm from the beginning, but after a few releases at v0.4 it was
clear not to ever use Swarm, and that it mostly was the Docker PR machine that
made it sound nice, and not the actual features.

Maybe it got better later on, but the first several Swarm announcements seemed
really off-putting to me.

We ended up on Mesos/Marathon, not that that has a bright future either, but
it was at least capable of restarting containers from the beginning..

Just migrate to Kubernetes. It has won.

~~~
jrs95
Is HashiCorp’s Nomad in a similar position at this point? I really enjoy it’s
(relative) simplicity.

~~~
wmf
I get the impression that Nomad was never particularly alive to begin with,
which is a shame since it seems better designed. But it doesn't have that
"ZOMG Google has blessed us with the secrets of the borg" that DevOps crave.

~~~
rmetzler
Nomad was my choice for queue centric workloads, but it doesn't seem to fit
the webserver / long living services as good as Kubernetes. I'm not sure, but
I would think you could run Nomad and Kubernetes on the same servers, sharing
the Docker runtime.

~~~
wmf
If you run two schedulers they don't have a correct view of available
capacity. You can use Mesos as a meta-scheduler but that introduces more
complexity.

------
jopsen
People, yours truly included, seem a bit concerned with the 2 months notice.

To be fair docker cloud was never great and hopefully it doesn't have many big
customers...

But the precedence of shutting down a paid service with 2 months notice is not
nice. What would happen if this was docker hub? Panic!

~~~
gingerlime
> What would happen if this was docker hub? Panic!

Isn't docker hub relatively easy to replace, in comparison?

Otherwise, is this a wakeup call perhaps?

~~~
TheDong
docker hub is surprisingly difficult to replace because of how docker
registries work.

Traditional package managers have two distinct concepts: a repository and
packages within those repositories.

For example, if ubuntu took down their apt repo server, I could run my own
with all the same packages and change a single sources.list entry and all my
servers, ansible roles installing packages, etc, would operate the same.

This is possible because the package name+version is an identifier everything
else uses and the only thing that cares about the repository is apt itself;
all other tooling doesn't need to know about the repository the package is
sourced from.

Docker conflates those two things. Each client doesn't just send a package
name, it sends a url + package name + version (e.g.
foo.registryurl.com/image:version). Because every single client has the detail
of "foo.registryurl.com" baked in, it's difficult to change that. I can't
change a single "repository-mapping" file that the docker daemon reads to
quickly update it.

Instead, I have to update every single client.

The idea of decoupling those is not new. In 2014 it was proposed [1], and
various implementations that would help make it easier to migrate off the
default registry have been proposed and rejected [2]

This doesn't even get into the lack of tooling for chasing down the transitive
dependencies building my images has on various registries with each FROM.

[1]:
[https://github.com/moby/moby/issues/8329](https://github.com/moby/moby/issues/8329)

[2]:
[https://github.com/moby/moby/pull/5821#issuecomment-49492924](https://github.com/moby/moby/pull/5821#issuecomment-49492924)

~~~
lloeki
> Instead, I have to update every single client.

To combat this, every single image we use from hub.docker.com is "proxied"
into our registry with a one-line Dockerfile:

    
    
       FROM image:version
    

Building the "proxy" image and publishing it in our registry is entirely
automated (using CI+Registry of a self-hosted Gitlab). Then we make everything
point to our version in our registry. Should hub.docker.com go belly-up, then
we have 1. a cache of versions in use (current and past), and 2. full control
of the images (possibly making our own FROM scratch) without having to change
a single line in downstream consumers. Initially we did this to be safe from
hub.docker.com possibly intermittent availability that would delay image pulls
on deployments.

~~~
donmcronald
Do you do it per project or as a separate project that houses all the proxy
images? How do you version the proxy images? What namespace do you push them
into? Is it easy enough to deal with that it doesn’t waste a lot of time?

I’ve been trying to insulate myself from docker too and the FROM proxy
strategy seems to break the least stuff. Have you hit any pain points?

~~~
lloeki
This is a single 'gitlab.example.com/docker/library' project.

We use orphan branches, one per image, although other strategies are possible
(like using the commit diff and directory name).

Proxy images are versioned using branch names (e.g postgres vs postgres-9.6),
images are pushed to gitlab.example.com/docker/library/postgres, and using
version detection we generate docker image tags (e.g a 'postgres' branch will
create postgres:latest, plus extracting version from postgres --version also
pushes postgres:10 and postgres:10.1 images.

See this .gitlab-ci.yml[0]. Yes, there is one per branch. This can be
generalised further (especially with Gitlab's new import system for .gitlab-
ci.yml) but works well enough in practice, it's very low maintenance, and
updates are a mere commit+push away.

In fact we use this not just for proxying images but for all "generalised",
"utility", or "dependency" images that are not the result of a given full-
blown app project in its own repo (those have their own CI/CD process in their
respective repo)

[0]:
[https://gitlab.com/snippets/1705998](https://gitlab.com/snippets/1705998)

------
zebra9978
Twitter users are up in arms because of the decision to retire production
systems with a 2 months notice -
[https://twitter.com/thomashermine/status/976398123215065088](https://twitter.com/thomashermine/status/976398123215065088)

[https://twitter.com/garethdiz/status/976188140670017536](https://twitter.com/garethdiz/status/976188140670017536)

[https://twitter.com/LenioLabsLLC/status/976201790482915328](https://twitter.com/LenioLabsLLC/status/976201790482915328)

~~~
scrollaway
> Twitter users

 _People_. People are up in arms.

Anyway, yeah, that's insane. Even Google, who constantly shuts stuff down,
usually does so with way more heads up. For comparison, Google Reader, a
completely free service, shut down with 3.5 months advance notice. Google Wave
got almost 6 months notice.

~~~
cygned
> Google Reader

It still hurts.

~~~
Hallucinaut
It was the day RSS died for me

~~~
detaro
I really don't get why this statement is so common. More or less every other
hosted reader immediately offered a migration path, so getting out of Reader
and up and running somewhere else was really easy.

------
showkhill
Please keep docker swarm going guys, it's a great product.

Docker cloud is no loss (with apologies to those who are using it in
production) and will hopefully free up your people to work on other important
stuff.

Otherwise if we can continue to use the compose configuration api and the
docker deploy/service api with k8s under the hood then I guess that's a
reasonable compromise.

------
andrei821
Had a startup in this area, with swarm under the hood, and realised last year
(when RackSpace closed Carina) that 1. swarm is loosing momentum due to the
ammount of new features, stability and native cloud integration that k8s
brought; 2. containers are beeig adopted at a huge speed, and big cloud
providers like aws and gce have lots of users and trust, so the effort of
offer CaaS is not that big, with great chances of success; 3. The hosting
market is tough due to comprtition. DigitalOcean was in this market way before
they were caled DO.; 4. When you want to make money from OSS like Docker does,
companies like RedHat and IBM allready have years ahead of competition due to
their established sales channels (in 1-2y from now we will see tectonic in all
rhel powered companies, and docker announcing that it’s not supporting UCP any
more)

------
the_imp
The timing of this (shutdown on 21 May) made me wonder if it's related to the
GDPR coming into effect starting on 25 May.

~~~
perlgeek
It may well but, but everybody knew that GDPR was coming. If this was the
reason, why not announce it (much) earlier?

------
sidi
Given the time it takes to migrate the production stack to another system (one
or more months), this won't be enough time for many users to migrate. There is
no drop-in replacement. It is pretty abrupt of them to give a 60 day notice.

On a meta thought, I wonder what potentially caused this move. It is/was a
pretty decent service.

------
devmunchies
I was logged into docker the other day and saw this notification but I
didn’t—and still don’t—know exactly what services they’re referring to. Do
they mean everything under cloud.docker.com, the swarms beta, or something
else?

------
adityapatadia
It was long known since they did not ship any new update since August 2016. We
at Turing Analytics migrated to Rancher labs about 6 months ago.

They should have announced it earlier and should have given more time to
paying customers. I am glad I migrated very early.

~~~
gingerlime
Is there a hosted rancher service?

I played around with it a long while ago and really liked it, but felt like
more moving parts (and particularly on MySQL, which wasn't in our stack)
wasn't something I was too keen on. Having someone manage this for us could be
worth paying for though.

~~~
pronik
Rancher, the container orchestration, is pretty much dead too, since it's
K8s-based from (upcoming) 2.0 on, i.e. it's becoming a K8s distribution and
has to compete with K8s itself, OpenShift and probably upcoming open-sourced
edition of Tectonic. RancherOS might live on, even though there is a lot of
doubt on why it should do so.

~~~
gtirloni
I think you mean "cattle", the container orchestration system in Rancher 1.x

Rancher (and Rancher OS) seem to be doing fine and getting updates constantly.

We're eyeing Rancher 2.x and the Kubernetes integration but it gives me
confidence seeing Rancher 1.x getting updated while they are so focused in 2.x
and K8s.

------
krispbyte
Wasn't the whole point of docker containers that deploys and migrations are a
breeze?

~~~
sidi
Docker cloud offered CI/CD integrations and management features similar to K8S
that were proprietary to them. While Docker images themselves are portable,
this is a whole different beast.

~~~
est
in other words, for the micro-service world, you don't have the monolith, the
whole stack is the monolith?

------
zbruhnke
As I read through this all it feels sort of weird even typing it but I kind of
hope Amazon or Microsoft buys Docker rather than Oracle, Google or IBM.

I think Microsoft still employs thousands of great engineers and have been
early embracers of containerization among the large companies out there and
because Satya was a large part of growing Azure into what it is (IMHO a pretty
solid set of services) it could make a lot of sense

~~~
rmetzler
I was wondering if you think the whole Docker inc is closing or something like
that. Docker is only shutting down their cloud offering for Docker Swarm and I
think it is to bundle their resources and focus on integrating Kubernetes.

~~~
QuinnyPig
I’m trying and failing to imagine a future where Docker achieves business
success as a stand-alone entity.

------
jcoffland
This is why your company or product should not depend on that new cool
SaaS/PaaS.

~~~
yannski
This is why you should write your app code to be independant from your current
provider, Always thinking that you may have to change (maybe urgently) in the
future

------
tnolet
Damn. My last company ran a bunch of production things in Docker Cloud.
Contrary to many opinions, I kinda liked it. It was cheap and fairly simple to
use. The API was straightforward and way less expansive and cumbersome than
something like AWS ECS.

------
jimaek
What was the point of acquiring Tutum killing it, rebranding to Docker Cloud
and killing it as well.

Tutum actually worked and I really liked it. Now I plan to use Rancher on top
of kubernetes for my docker hosting

------
molszanski
Long time docker user here.

Docker Cloud was getting worse and worse. Tutum (they acquired, rebranded and
killed it) was great. But docker team just destroyed it.

That is a shame. Tutum was great since it scaled up and __down __very well.
Nobody thinks about scaling down, but this is important in many ways.

Right now IMO: \- Docker swarm - scales up and down ok. Had too many bugs with
even on stable. \- Rancher - fine, very good for medium deployments. \- k8 -
winner for larger scale but scales down badly.

This is really sad.

------
crehn
Please keep swarm mode going. It’s a pleasure to use, easy to set up, works
well with Compose and overall satisfies a lot use cases. Thanks for your work!

------
is0tope
I've been meaning to learn kubernetes for a while now having been a docker
compose user for a few years. Swarm seemed super appealing due to easy
migration and simplicity. Having gone through a few tutorials for Kube I still
feel a little overwhelmed with the volume of configuration, and also how local
development is meant to be done. This was always a very cool part of compose.

~~~
jwhitlark
I found kubernetes up and running really helpful. Kubernetes the hard way was
really useful, but a painful weekend.

------
agotterer
Docker really needs to provide some transparency around these decisions.
People are concerned about the future of the ecosystem. They have every right
to shutdown aspects of their offering. But the community deserves an
explainstion. This notice didn’t even attempt to explain the decision. Is
Docker stopping development on swarm? Getting out of the PaaS business?
Downsizing?

~~~
dahidahi1
How is the community affected in any way by this decision? Docker cloud is a
management product and only open to paying customers.

------
BenfromOz
Wow this is very surprising.

I've been working on a Docker Cloud alternative for awhile now. I'm aiming for
something that kind of balances the convenience of Heroku with the Docker
experience.

It's still in beta but if anyone wants to check it out it's at:
[https://codemason.io/](https://codemason.io/)

------
jakob223
What exactly is docker cloud and how does it fit in the docker workflow?

~~~
a012
I don't have experience with Docker Cloud, but it's Docker company's SaaS.

[https://blog.docker.com/2015/10/docker-acquires-
tutum/](https://blog.docker.com/2015/10/docker-acquires-tutum/)

------
paride5745
How long until redhat buys docker?

~~~
coredog64
My nightmare is that Oracle outbids Redhat for Docker.

~~~
dahidahi1
The.Worst.Nightmare!

We saw that happen with Sun, BEA, Peoplesoft etc. Sad days.

------
Kiro
GDPR killed Docker Cloud. It's not the last victim we will see.

~~~
StreamBright
What? How on earth could have this been the case?

------
gaius
Docker the file format/command line syntax/etc will long outlive Docker the
company

Kubernetes “won” so now the competition has shifted from who can innovate to
who can execute and operate.

~~~
joefarish
Genuine question - what makes you think that Kubernetes has won?

~~~
gaius
_Genuine question - what makes you think that Kubernetes has won?_

Well, "won" in quotes. I am not a k8s fanboy or anything, I simply observe
that all the major cloud providers are offering managed k8s services that have
superseded their own proprietary container-type offerings. For better or worse
that's where the momentum is. If you wanted to containerize your stack right
now, k8s then pick one of the big 3, seems like a safe bet.

~~~
imiric
I've noticed the same trend, and as a fan of Docker Swarm, along with this
news, I'm not happy about it.

Compared to Kubernetes, Swarm is a breeze to setup, deploy and manage. The
manifest files are the same Docker Compose files we're used to, just expanded
to cover the new stack concepts. It has support for remote storage mounting,
advanced networking configuration, various interesting volume and network
plugins[0], and is generally a pain-free experience to use (from my admittedly
short time with both).

Kubernetes is a fine product. It's just a shame Swarm doesn't seem to have the
same traction.

Can someone share their Swarm experience in production, possibly compared to
k8s?

[0]:
[https://docs.docker.com/engine/extend/legacy_plugins/](https://docs.docker.com/engine/extend/legacy_plugins/)

~~~
sz4kerto
We're going with Swarm exactly because of the reasons you've listed. The EE
part is a bit flaky sometimes (I'm looking at you, UCP), but Swarm is
brilliant.

~~~
sandGorgon
I agree - but I'm now very afraid. I'm beginning to wonder if its not better
to just swallow the pain and just go k8s.

I would love it (and pay for it) if Swarm says that it is a opinionated distro
(ingress/overlay) + management layer on top of k8s.

The silence is deafening and not nice.

~~~
sz4kerto
I don't think that you need to be afraid and migrate just because of that.
Swarm is not a service, so if they stopped developing it then you'd have
plenty of time figuring out how to move away because your Swarm clusters would
not stop working.

Also, there are very large Swarm installations in production at large
companies, so I'd be surprised if Docker cancelled the product (which is their
flagship).

------
holydude
I always chuckle when people put so much trust in "startup" companies. It's
the same like believing in IBM not trying to screw you over.

There's a reason why people and businesses hate vendor lock ins. There's a
reason why we do not want AWS to reign supreme for long.

~~~
WillPostForFood
At least you know isn’t going to be shutting down their cloud services anytime
soon.

