During the DockerCon a couple of weeks ago <https://2017.dockercon.com/> the new native swarm functionality was one of the highlighted themes.
A swarm is a cluster of Docker engines, or nodes, which acts as an orchestrator, monitor and ingress load balancer for all the services deployed on swarm. The Docker Engine set of commands provide for a way to create, manage and deploy nodes.
Features that were previously only available as a part of external packages such as Kubernetes are now available natively within Dockers packages. Docker engines participating in a cluster are running in swarm mode and can either join an existing swarm or create a new one.
Swarm also adds an extra level of security to container management. With Swarm, the Docker Engine designates itself as a manager node and a new root Certificate Authority (CA). From there a secure keys are generated for the management plane communications between Docker Engines and containers.
Important to microservices, Swarm supports interesting networking capabilities. To expose services to external components, such as cloud load balancers, access is published on the PublishedPort of any node in the cluster whether or not the node is currently running the task for the service. All nodes in the swarm route ingress connections to a running task instance. Further for inter-container communications, swarm mode natively supports overlay networks, which works similarly to virtual networks in virtual machine infrastructure.
As is the case with any infrastructure and orchestration tool, the security of the platform itself is always an issue, which needs attention.
In the case of Swarm, it appears that Dockers has paid a lot of attention to implementing both access and encryption controls within this infrastructure.
More to the point, Swarm is also available within the Docker Enterprise Edition. Enterprise Edition has a host of new security features, that enterprises will find very useful.
Among these are:
With the built in load balancer, this new generation of Docker provides new options for DevOps manager when it comes to orchestrating their microservices environments.
With Docker first-gen architecture and engine running individual containers / services, East — West APIs had to be managed either by dedicated API managers or via load-balancer with built-in service discovery. While these dedicated tools may still provide the fastest time to deployment, the new option is to rely on built-in networking and load balancing to publish only selected APIs.
With most environments using containers developed by 3rd parties (including open source) along with containers developed internally, API security in micro-service environment is one of the most critical issues in micro-service applications. Any one of the 3rd party containers can hide a big scary wolf in sheep’s clothing right inside the corporate perimeter.
Dockers early adopters care and so should we.
At the conference we have seen presentations from early production Dockers deployments by Intuit and Visa.
Intuit engineer has given a great presentations about lessons learned using the latest set of Docker software, including Swarm. It is amazing to see how tight the collaboration is between Dockers and it’s early customers. That said, it is apparent that the maturity of the Swarm load balancer is not quite up to the robustness of some other API management tools, such as Mashape Kong, for example.
Check out parts of Intuit’s talk — it’s very educational
While running a much smaller project, Visa has also started looking at Swarm for container orchestration, although this is not yet in production.
Interestingly, Visa named Security Landscape and integration into SDLC processes as two of the four most critical steps of deploying Dockers-based infrastructure.
Whichever way one decides to manage microservices API — making sure APIs are secure is key.
Is Docker Swarm going to change how we do microservices APIs? was originally published in Wallarm on Medium, where people are continuing the conversation by highlighting and responding to this story.