Microservices deployment on Amazon EC2 Container Service with Weave Net

Amazon EC2 container service is a scalable container management service that allows you to manage Docker containers on a cluster of Amazon EC2 instances. Weave Net provides a simple and robust software-defined network for apps running as Docker containers that does not require a external database (cluster store). Weave simplifies setting up a container network within the Amazon EC2 Container Service. Because Weave allows each container to use standard port numbers – for example you can expose MySQL on port 3306 – managing services is straightforward. Every container can find the IP of any other container using a simple DNS query on the container’s name, and communicate directly without NAT or complicated port mapping.

An advantage to using DNS is that when you use a container name within (say) a config file, you are not required to have a script in place to generate the name based on run-time variables. You can also optionally burn the config file with the hostname right into the container image.

There is no need to deploy extra services to achieve DNS lookup and load balancing. Weave Net takes care of both automatic service discovery and load balancing, reducing overhead and complexity. Weave saves you time and money, and lets you focus on app development rather than your infrastructure design.

This guide also introduces Weave Scope, and Weave Cloud which enables you to visualize and understand your container-based microservices.

Two types of containerized microservices are demonstrated in this guide: HTTP Servers and “Data Producers”.

Data producers generically model containers that produce a data feed of some kind. The HTTP Servers present a web interface to the data from the Data Producers. This is a very common pattern in distributed systems, but its implementation requires answers to the following questions:

Service discovery: How does an HTTP Server find a Data Producer to connect to?

Load balancing/fault tolerance: How can the HTTP Servers make uniform and efficient use of all the Data Producers available to them?

Weave solves these issues using its built-in DNS server, where it securely and transparently:

Implements service discovery by adding DNS A-records for your containers based on
their names.

What You Will Use

Before You Begin

We will make use of the Amazon Web Services (AWS) CLI tool to manage and access AWS. You need a valid Amazon Web Services account, and also have the AWS CLI set up and configured before working through this guide. Please ensure your AWS account has the appropriate administrative privileges. Amazon provides extensive documentation on how to set up the AWS CLI.

Note: the source code shown above has been simplified and reformatted for clarity.

When ECS launches a container, the call to Docker is intercepted by Weave’s Docker API proxy,
and an address is assigned using Weave’s automatic IP allocator. The container is then registered with the Weave DNS service and attached to the Weave network. Weave Net’s DNS registers A-records based on the container’s name:

A dataproducer A-record for all the Data Producer containers.

A httpserver A-record for all the HTTP Server container.

The Data Producer waits for requests on TCP port 4540 and responds with a string containing its IP address.

The HTTP Server works as follows:

Contacts a Data Producer and obtains its message (nc dataproducer 4540). This
implicitly does the load balancing due to weavedns’ response randomization
(more about this in the next section).

Composes HTML with the information obtained in (1) and (2).

Waits for a browser to connect.

What’s Happening in the Hosts?

Weave Scope provides a real-time visualization of the containers running on the Weave network and also an overview of how they communicate with each other.

As an alternative, if you did not provide a token, all of your ECS instances will still be running equipped with a Weave Scope
web application listening on port 4040 (this solution does have some
performance and administration issues compared to using the Weave Cloud service, but it
is more than sufficient for demonstration purposes).

To access it, open your browser and paste the Weave Scope application URL from any of your instances:

This is what you should see with Weave Scope when accessing one of the HTTP Servers multiple
times (i.e. reloading http://foo.region.compute.amazonaws.com in your browser
multiple times).

Click the httpserver container to display its details.

Note that the edges between one of the httpserver containers (the one
accessed from your browser) and the three dataproducer containers, reflect
the load balancing scheme that we built using the weavedns service.

More insights into the Weave network can be gleaned by selecting different views: Applications (by
name), Containers by image and Hosts.

To dig even deeper on what’s happening in the ECS instances, access
them through ssh:

ssh -i weave-ecs-demo-key.pem ec2-user@${INSTANCE}

where ${INSTANCE} can be any of your 3 instance hostnames
(foo.region.compute.amazonaws.com, bar.region.compute.amazonaws.com or
baz.region.compute.amazonaws.com in the setup.sh example listing above).

Container ecs-weave-ecs-demo-task-1-httpserver-a2bad7f8f792f185f901 is the
HTTP Server of this host, producing the output you saw in your browser. Note
how container names are mangled by ECS:
ecs-${TASK_FAMILY_NAME}-${TASK_FAMILY_VERSION}-${STRIPPED_CONTAINER_NAME}-${UUID}.

Container ecs-weave-ecs-demo-task-1-dataproducer-dec2b39a92e0edb1aa01 is the
Data Producer of this host.

Containers weaveproxy and weave are responsible for running
Weave within each ECS instance. For illustration purposes, the proxy was shown out
of Docker in the previous section’s diagram, but in actual fact weaveproxy runs
inside of Docker.

Container weavescope is responsible for running Weave Scope and for monitoring each instance.

Container ecs-agent corresponds to
Amazon’s ECS Agent, which runs on
all of the EC2 instances and is responsible for starting containers on behalf of Amazon ECS. For simplification, the ECS Agent was represented out of Docker in the previous
section’s diagram.

View the IP addresses of the HTTP Servers and the Data Producers by running:

Re-running these commands vary the IP addresses. This is the weavedns service transparently balancing the load by randomizing the IP addresses, as the HTTP servers are connecting to Data Producers.

Cleanup

To clean up this demonstration run:

./cleanup.sh

This script will work even if something has gone wrong while configuring the
demonstration (for example, if setup.sh didn’t finish due to missing AWS
permissions). If this was the case, cleanup.sh may output errors while it is
trying to destroy resources, which weren’t created. Simply disregard them.

Optionally (if you would like to use Scope ‘Cloud’ and you are participating in the Early
Access program), add your Scope ‘Cloud’ service token to the User Data. Run the following
command, replacing XXXX with your Scope ‘Cloud’ service token.

Known Issues and Limitations

Auto Scaling Groups are required for ECS to work with Weave. If you create individual
instances, they will not work and won’t be able to see each other due to how Weave finds peers in ECS.

For the Advanced User: Build Your Own Weave ECS AMI

If you need to incorporate changes to the Weave AMI, you can do so by following these steps.

Conclusions

You have used Weave out-of-the-box within the Amazon Container Management service or ECS and used Weave for both service discovery and load balancing between containers running in Amazon EC2 instances. In addition to this, you were introduced to Weave Cloud for visualizing and monitoring a Weave container network.

Weave runs regardless of whether it was executed on the same or on different hosts, and can even run across completely different cloud providers if necessary.

You can easily adapt these examples and use them as a templates in your own implementation. We would be very happy to hear any of your thoughts or issues via Help and Support.