RAraimille1·Dec 2, 2015
In Docker Swarm down? docker run swarm create: connection timed outdocker-archive
classicswarm
Go2014–2026
docker-archive / classicswarm · Archived
classicswarm
Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit
28Distinct people
30Mentions
1Explicit recommenders
5.7KGitHub stars
What to know before exploring
What it is
Swarm Classic: a container clustering system. Not to be confused with Docker Swarm which is at https://github.com/docker/swarmkit
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I would definitely check out a number of docker related technologies. To answer your question, we don't have our software out in Docker yet, but it's coming, and it will make a…
InTheArena used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- moby/swarmkit · linked in 6 of the same discussions
- docker-archive-public/docker.machine · linked in 4 of the same discussions
- moby/moby · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:01:02 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year30 dated mentions
Observed mentions: 2014-12-04 16:09:08 UTC to 2026-01-24 19:38:42 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
6 sources> Kubernetes requires you to learn its CLI and configurations. You cannot use docker-compose.yml definitions you created earlier. You’ll have to create Kubernetes equivalents. You cannot use Docker CLI commands you learned before. You’ll have to learn Kubernetes CLI and, likely, make sure that the whole organization learns it as well.
That seems unfair, as as far as I can tell there are not "swarm equivalents" for most of kubernetes features.
Does swarm have any of the features that kubernetes does for scaling different containers or doing rolling upgrades?
It looks like [1] the swarm scheduler does not yet restart containers if a host goes down.
[1] https://github.com/docker/swarm/issues/599
In Docker Clustering Tools Compared: Kubernetes vs. Docker SwarmFWIW, it's possible to specify Swarm filters using Compose which Swarm can use to know it should colocate containers on the same node ("affinity"): https://github.com/docker/swarm/tree/master/scheduler/filter...
In Announcing Docker 1.9: Production-Ready Swarm and Multi-Host NetworkingA couple things I've found when evaluating these:
Docker Swarm seems to be the only one that supports one-off interactive containers that bind a TTY, like a Rails console (i.e. does the cluster support `docker run -it --rm busybox sh`). But its scheduling strategies[1] aren't as sophisticated as the others.
Marathon doesn't support linked containers[2], so if you're using Mesos and need linked containers, you probably will want to run Kubernetes on it and use pods.
[1]: https://github.com/docker/swarm/tree/b2182d080956040730cc76c...
[2]: https://support.mesosphere.com/hc/en-us/articles/205006415-H...
In Kubernetes V1 ReleasedI would definitely check out a number of docker related technologies. To answer your question, we don't have our software out in Docker yet, but it's coming, and it will make a splash when it lands.
Vagrant is a great technology, but I recommend taking a look at Docker compose (https://docs.docker.com/compose/) previously known as FIG. One of the great advantages of compose is that combine it with Swarm (https://github.com/docker/swarm) and you have a very robust distributed deployment system. Docker-machine is the direct competitor to vagrant, but to be honest, I don't use it. I spin up my docker containers via some build in service API's we already built for proprietary reasons.
If you want to get really robust, you can also look at Kubernetes (and their zero-downtime deployment) and Mesos. These both add a huge amount of complexity t t
Read the rest
he deployment, but also grant a robust distributed system for managing downtime and deployment. Redhat also has Openshift.
> My ideal setup would be a hypervisor infrastructure with a bunch of VM's running only Docker applications.
You should take a look at https://github.com/docker/machine and https://github.com/docker/swarm , they were designed with exactly that goal in mind!
In Docker and the PID 1 zombie reaping problem