Alternatives to Docker Swarm logo

Alternatives to Docker Swarm

Docker Compose, Rancher, Ansible, Apache Mesos, and Kubernetes are the most popular alternatives and competitors to Docker Swarm.
428
413
+ 1
207

What is Docker Swarm and what are its top alternatives?

Swarm serves the standard Docker API, so any tool which already communicates with a Docker daemon can use Swarm to transparently scale to multiple hosts: Dokku, Compose, Krane, Deis, DockerUI, Shipyard, Drone, Jenkins... and, of course, the Docker client itself.
Docker Swarm is a tool in the Container Tools category of a tech stack.
Docker Swarm is an open source tool with 5.7K GitHub stars and 1.1K GitHub forks. Here’s a link to Docker Swarm's open source repository on GitHub

Docker Swarm alternatives & related posts

related Docker Compose posts

GitHub
GitHub
nginx
nginx
ESLint
ESLint
AVA
AVA
Semantic UI React
Semantic UI React
Redux
Redux
React
React
PostgreSQL
PostgreSQL
ExpressJS
ExpressJS
Node.js
Node.js
FeathersJS
FeathersJS
Heroku
Heroku
Amazon EC2
Amazon EC2
Kubernetes
Kubernetes
Jenkins
Jenkins
Docker Compose
Docker Compose
Docker
Docker
#Containerized
#Containers
#Backend
#Stack
#Frontend

Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.

We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.

See more
Zach Holman
Zach Holman
at Zach Holman · | 14 upvotes · 45.4K views
Docker Compose
Docker Compose
Docker
Docker
Home Assistant
Home Assistant

I've been recently getting really into home automation- you know, making my house Smart™, which basically means half the time my lights don't turn on and the other half of the time apparently my kitchen faucet needs a static IP address.

But it's been a blast! It's a fun way to write code for yourself, outside of work, to have an impact in the real world. It's a nice way of falling in love with a different side of programming again.

I've used Apple's HomeKit for awhile, since we're pretty all-in in Apple devices at home, but the rough edges have been grating at me more and more. HomeKit is so opaque- you can't see what's wrong, why a device is unresponsive, and most importantly: the compatibility isn't there. HomeKit has a limited selection of — more expensive — accessories, and as you go beyond just simple LED lights, you want a bit more power. Also, we're programmers, dammit, gimme all the things.

Anyway, I've switched to Home Assistant the last few months, and I'm kicking myself I didn't make the switch earlier. As a programmer, it's great: you get the most capability than pretty much any other smart home platform (integrations have been written for most devices and technologies out there today), it's easier to debug, and when you want to go bigger than just simple lights on/off, HA has some really powerful stuff behind it.

I use Home Assistant in conjunction with Docker and Docker Compose; since the config is extracted out, upgrades are usually as easy as a pull of the latest version. I've just started digging into writing integrations for a lesser-used device that I have at home, and HA makes it pretty straightforward to just magically add it to the home network.

It plays well with others, too- we require a VPN connection in to the home network to access our Home Assistant install, and HA has a few tricks to help with that (ignoring the VPN route if you're on a local network, etc). Nice client support for iOS and Android, too.

Anyway, big fan of Home Assistant if you want to go beyond simple home automations and setup. Wish I would have done it a lot earlier. Also, big fan of jumping into all this if you have the time and interest to do so- it's been tickling a different part of my code brain than I've had access to in awhile, and that's been fun in and of itself.

See more
Ansible logo

Ansible

5.1K
3.7K
1.2K
5.1K
3.7K
+ 1
1.2K
Radically simple configuration-management, application deployment, task-execution, and multi-node orchestration engine
Ansible logo
Ansible
VS
Docker Swarm logo
Docker Swarm

related Ansible posts

Tymoteusz Paul
Tymoteusz Paul
Devops guy at X20X Development LTD · | 13 upvotes · 291K views
Amazon EC2
Amazon EC2
LXC
LXC
CircleCI
CircleCI
Docker
Docker
Git
Git
Vault
Vault
Apache Maven
Apache Maven
Slack
Slack
Jenkins
Jenkins
TeamCity
TeamCity
Logstash
Logstash
Kibana
Kibana
Elasticsearch
Elasticsearch
Ansible
Ansible
VirtualBox
VirtualBox
Vagrant
Vagrant

Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

See more
Pedro Arnal Puente
Pedro Arnal Puente
CTO at La Cupula Music SL · | 7 upvotes · 53.4K views
atLa Cupula Music SLLa Cupula Music SL
Ansible
Ansible
Packer
Packer
Terraform
Terraform
Amazon ElastiCache
Amazon ElastiCache
Redis
Redis
Amazon RDS for Aurora
Amazon RDS for Aurora
Amazon S3
Amazon S3
Amazon EC2
Amazon EC2
Debian
Debian

Our base infrastructure is composed of Debian based servers running in Amazon EC2 , asset storage with Amazon S3 , and Amazon RDS for Aurora and Redis under Amazon ElastiCache for data storage.

We are starting to work in automated provisioning and management with Terraform , Packer , and Ansible .

See more
Apache Mesos logo

Apache Mesos

219
241
30
219
241
+ 1
30
Develop and run resource-efficient distributed systems
Apache Mesos logo
Apache Mesos
VS
Docker Swarm logo
Docker Swarm

related Apache Mesos posts

StackShare Editors
StackShare Editors
| 1 upvotes · 12K views
atUber TechnologiesUber Technologies
Apache Aurora
Apache Aurora
Docker
Docker
Apache Mesos
Apache Mesos

Docker containers on Mesos run their microservices with consistent configurations at scale, along with Aurora for long-running services and cron jobs.

See more

related Kubernetes posts

Yshay Yaacobi
Yshay Yaacobi
Software Engineer · | 27 upvotes · 289.6K views
atSolutoSoluto
Docker Swarm
Docker Swarm
Kubernetes
Kubernetes
Visual Studio Code
Visual Studio Code
Go
Go
TypeScript
TypeScript
JavaScript
JavaScript
C#
C#
F#
F#
.NET
.NET

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

See more
Conor Myhrvold
Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 16 upvotes · 731.5K views
atUber TechnologiesUber Technologies
Apache Spark
Apache Spark
C#
C#
OpenShift
OpenShift
JavaScript
JavaScript
Kubernetes
Kubernetes
C++
C++
Go
Go
Node.js
Node.js
Java
Java
Python
Python
Jaeger
Jaeger

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

See more
CoreOS logo

CoreOS

190
143
45
190
143
+ 1
45
Linux for Massive Server Deployments
CoreOS logo
CoreOS
VS
Docker Swarm logo
Docker Swarm

related Compose posts

Gregory Koberger
Gregory Koberger
Founder · | 13 upvotes · 56.8K views
atReadMe.ioReadMe.io
Compose
Compose
MongoLab
MongoLab
MongoDB Atlas
MongoDB Atlas
PostgreSQL
PostgreSQL
MySQL
MySQL
MongoDB
MongoDB

We went with MongoDB , almost by mistake. I had never used it before, but I knew I wanted the *EAN part of the MEAN stack, so why not go all in. I come from a background of SQL (first MySQL , then PostgreSQL ), so I definitely abused Mongo at first... by trying to turn it into something more relational than it should be. But hey, data is supposed to be relational, so there wasn't really any way to get around that.

There's a lot I love about MongoDB, and a lot I hate. I still don't know if we made the right decision. We've been able to build much quicker, but we also have had some growing pains. We host our databases on MongoDB Atlas , and I can't say enough good things about it. We had tried MongoLab and Compose before it, and with MongoDB Atlas I finally feel like things are in a good place. I don't know if I'd use it for a one-off small project, but for a large product Atlas has given us a ton more control, stability and trust.

See more
Docker Cloud logo

Docker Cloud

64
64
9
64
64
+ 1
9
A hosted service for Docker container management and deployment
Docker Cloud logo
Docker Cloud
VS
Docker Swarm logo
Docker Swarm
OpenStack logo

OpenStack

369
332
88
369
332
+ 1
88
Open source software for building private and public clouds
OpenStack logo
OpenStack
VS
Docker Swarm logo
Docker Swarm
Docker Machine logo

Docker Machine

341
347
13
341
347
+ 1
13
Machine management for a container-centric world
Docker Machine logo
Docker Machine
VS
Docker Swarm logo
Docker Swarm
Helm logo

Helm

313
154
4
313
154
+ 1
4
The Kubernetes Package Manager
Helm logo
Helm
VS
Docker Swarm logo
Docker Swarm

related Helm posts

Emanuel Evans
Emanuel Evans
Senior Architect at Rainforest QA · | 12 upvotes · 130.1K views
atRainforest QARainforest QA
Terraform
Terraform
Helm
Helm
Google Cloud Build
Google Cloud Build
CircleCI
CircleCI
Redis
Redis
Google Cloud Memorystore
Google Cloud Memorystore
PostgreSQL
PostgreSQL
Google Cloud SQL for PostgreSQL
Google Cloud SQL for PostgreSQL
Google Kubernetes Engine
Google Kubernetes Engine
Kubernetes
Kubernetes
Heroku
Heroku

We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).

We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .

Read the blog post to go more in depth.

See more
Ido Shamun
Ido Shamun
at The Elegant Monkeys · | 6 upvotes · 48K views
atDailyDaily
Helm
Helm
Docker
Docker
CircleCI
CircleCI
GitHub
GitHub
Kubernetes
Kubernetes

Kubernetes powers our #backend services as it is very easy in terms of #devops (the managed version). We deploy everything using @helm charts as it provides us to manage deployments the same way we manage our code on GitHub . On every commit a CircleCI job is triggered to run the tests, build Docker images and deploy them to the registry. Finally on every master commit CircleCI also deploys the relevant service using Helm chart to our Kubernetes cluster

See more
Spring Cloud logo

Spring Cloud

246
211
0
246
211
+ 1
0
Spring helps development teams everywhere build simple, portable,fast and flexible JVM-based systems and applications.
    Be the first to leave a pro
    Spring Cloud logo
    Spring Cloud
    VS
    Docker Swarm logo
    Docker Swarm

    related Spring Cloud posts

    IntelliJ IDEA
    IntelliJ IDEA
    Linux
    Linux
    GitHub
    GitHub
    MongoDB
    MongoDB
    Kafka
    Kafka
    RabbitMQ
    RabbitMQ
    Redis
    Redis
    MySQL
    MySQL
    Elasticsearch
    Elasticsearch
    Spring Cloud
    Spring Cloud
    Spring Boot
    Spring Boot

    Spring-Boot Spring Cloud Elasticsearch MySQL Redis RabbitMQ Kafka MongoDB GitHub Linux IntelliJ IDEA

    See more

    related Portainer posts

    Wallace Alves
    Wallace Alves
    Cyber Security Analyst · | 1 upvotes · 28.8K views
    nginx
    nginx
    Logstash
    Logstash
    Kibana
    Kibana
    Elasticsearch
    Elasticsearch
    ELK
    ELK
    Portainer
    Portainer
    Docker Compose
    Docker Compose
    Docker
    Docker

    Docker Docker Compose Portainer ELK Elasticsearch Kibana Logstash nginx

    See more
    Google Cloud Container Builder logo

    Google Cloud Container Builder

    140
    150
    0
    140
    150
    + 1
    0
    Stand-alone tool for building container images regardless of deployment environment
      Be the first to leave a pro
      Google Cloud Container Builder logo
      Google Cloud Container Builder
      VS
      Docker Swarm logo
      Docker Swarm
      Marathon logo

      Marathon

      72
      50
      5
      72
      50
      + 1
      5
      Deploy and manage containers (including Docker) on top of Apache Mesos at scale
      Marathon logo
      Marathon
      VS
      Docker Swarm logo
      Docker Swarm
      Docker Hub logo

      Docker Hub

      70
      36
      0
      70
      36
      + 1
      0
      Build and Ship any Application Anywhere
        Be the first to leave a pro
        Docker Hub logo
        Docker Hub
        VS
        Docker Swarm logo
        Docker Swarm
        Weave logo

        Weave

        36
        31
        7
        36
        31
        + 1
        7
        Weave creates a virtual network that connects Docker containers deployed across multiple hosts.
        Weave logo
        Weave
        VS
        Docker Swarm logo
        Docker Swarm
        Compose on Kubernetes logo

        Compose on Kubernetes

        31
        48
        0
        31
        48
        + 1
        0
        Deploy applications described in Compose onto Kubernetes clusters (by Docker)
          Be the first to leave a pro
          Compose on Kubernetes logo
          Compose on Kubernetes
          VS
          Docker Swarm logo
          Docker Swarm