Greg Werner

Docker Cloud to the Rescue

Greg Werner

3Blades offers data science collaboration services. In addition to offering task based project management features, 3Blades also allows users to spawn custom workspace, model and data source instances within the context of their projects. A variety of resource configurations are available for different instance types. For example, a user can launch an RStudio IDE workspace with a 1 vCPU and 2 GB of memory and another Hadoop datasource instance with 2vCPU and 4 GB of memory. Docker is a natural fit to enable this type of flexibility.

It didn’t take very long for our team to go ‘all in’ with Docker. We were thrilled when we saw the added benefit of being able to quickly deploy our application stack after green builds with Continuous Integration tools. However, we struggled with a few issues when running multiple instances of our services, particularly service discovery.


The need for service discovery

Our application stack has the following general layout:

As an AWS customer, we wished to maintain EC2 instance type flexibility. For example, in our staging environment we may use one large instance for all application stack elements, whereas in production we have the option of separating stack elements across multiple VPC segments and availability zones. Instances may also scale up or down depending on resource usage.

Combined with Continuous Delivery workflows, this presents a challenge when having to dynamically route traffic to the correct stack element. For example, if multiple instances of a stack element are running on one EC2 instance then ephemeral ports must be used to avoid service conflicts, thus SRV records need dynamic updates. If the stack element is redeployed to another EC2 instance, then both the IP address and port must be updated.

Our first attempts with service discovery centered on setting up a service registration cluster. We prototyped several solutions, including etcd, Zookeeper and Consul. Although all these solutions have proven themselves in production environments, we found that a lot of our time was being spent on DevOps issues instead of improving our application. Consul in particular is a great K/V solution and takes much of the guesswork out of getting set up with service discovery. However soon we found ourselves dealing with the additional expense of having to deal with multiple Consul servers across multiple AWS AZ’s to enable high availability.


Enter Docker Clouddockercloud-cloud-sticker-final

We started testing with Docker Cloud to solve our deployment and service discovery needs. Docker Cloud has several features that made our lives much easier. For us, the best feature was to install one Docker Cloud ‘bundle agent’ on our EC2 instance which included everything needed for instance (node) management, container management and service discovery. We also liked having service triggers available to use as webhooks with external services to automate our workflows, such as redeploying a service when a new image is pushed to Docker Hub.

To enable this workflow in Docker Cloud, you just need to follow these general steps:

  • Set up an account with a cloud service provider.
  • Register for a new Docker Cloud account.
  • Set up nodes by either launching nodes directly from Docker Cloud or by importing your own node.
  • Tag nodes as needed, for example ‘staging’ and ‘proxy’. These tags will help target your deployments.
  • Define and tag each service in your stack. This will ensure your services end up on the proper nodes.
  • (Optional) Define new service trigger: Triggers allow you to set up webhooks from third party services for enable end-to-end CI/CD workflows.
  • Deploy service.

Our reverse proxy configuration file has one value for the upstream server directive, either app-staging or app-production, depending on whether the deployment is for staging or production. As long as the service name is consistent the reverse proxy will route traffic to the correct container, regardless of when and where the service is deployed. Also, the Docker Cloud service itself will load balance traffic to it’s individual containers residing on your node instances. Adopting Docker Cloud has allowed us to not only reduce cost, but achieve an automated CI/CD pipeline with minimal set-up – saving us time spent on DevOps to let us focus on improving our application for our customers.


Want to learn more about Docker Cloud?

Watch this overview webinar



Learn More about Docker

Continue reading...

Be the first to write a comment.

Leave a Reply