Throughout this book, we worked with Docker Swarm on a set of different underlying technologies without, so far, diving too deep into this implication: We ran Swarm on the top of AWS, DigitalOcean, and on our local workstations. For test and staging purposes, the platform onto which we run Swarm might be of secondary importance (let's fire up some AWS instances with Docker Machine and work that way), but for production it's mandatory to understand the pros and cons, reason, evaluate, and follow the trend.
In this chapter, we're going to review several public and private cloud options and technologies and their possible intersections. We'll finally treat the brand new buzzwords of CaaS (Container as a Service) and IaaC (Infrastructure as a Code) in Chapter 11, What it Next?
Mainly, we will be looking at:
As long as with Docker For Mac and Windows, the Docker team started working on the new generation toolsets for operators: Docker for AWS and Docker for Windows. These are intended to provide a taste of automatic for deploying Docker infrastructures, especially Swarm-ready ones.
The goals are to provide with a standard way of doing things, integrating the underlying infrastructure with the Docker tools and let people to run, with no effort, the latest software versions on the platform they love. The ultimate goal is really to let developers to move things from their laptops with Docker for Mac/Windows to the cloud, with Docker for AWS/Azure.
The user experience is, as always in the Docker ecosystem, great. The requirements are:
Basically, Docker for AWS is a clickable template for CloudForms. CloudForms is the orchestration system for AWS, which allows to create templates of complex systems, for example, you can specify a web infrastructure made of three web servers, one database, and one load balancer.
Instead of a web or other generic infrastructure, Docker for AWS of course comes with the capability of creating Docker Swarm (mode) infrastructures: it creates as many masters and workers as you specify, puts a load balancer in front, and configures all networking accordingly.
This is the welcome screen:
Then, you can specify some basic and advanced options:
As you can see, you can select the number of managers and workers, as well as the flavor of the instances to be launched. So far, up to 1,000 workers are supported. After that, you just have to click on Create Stack in the next step, and wait for a few minutes for CloudForms to bring the infrastructure up.
What the template does is to:
Once CloudFormation has finished, it will prompt with a green confirmation.
Now, we're ready to jump into our new Docker Swarm infrastructure. Just pick up one of the manager's public IPs and connect to it using the SSH key specified in the first step:
ssh [email protected]
Thanks to an agreement with Microsoft, also automatic Swarm deployment for Azure is available as a one-click experience (or almost).
The prerequisites for deploying Swarm on Azure are:
To generate the last, you can conveniently use a docker image, and launch it with:
docker run -it docker4x/create-sp-azure docker-swarm
During the process, at some point, you will be required to login through a browser to the specified URL. At the end, a pair ID/secret will be available for you to input in the Azure wizard form.
Once everything is fine, you can just click on OK and Create.
A set of classical virtual machines will be created to run the specified number of managers (here 1) and workers (here 4), as long as with the proper internal networks, load balancers, and routers. Just as in Docker for AWS, you can start using your deployed Swarm by SSHing to the public IP of one manager:
ssh [email protected]
There is one limitation in the Azure template now, it only supports one manager. The possibility to add new managers should, however, come very soon.