You’ve probably read our recent blog on monitoring Amazon Elastic Container Service for Kubernetes (EKS) with AppDynamics, which integrates seamlessly into EKS environments.
There are multiple approaches to running Docker containers in AWS, and we support them. The two main flavors are Amazon Elastic Container Service (ECS) and EKS. Here’s how they differ, and why you may choose one over the other.
ECS vs. EKS
Amazon ECS is the Docker-compatible container orchestration solution from Amazon Web Services. It allows you to run and scale containerized applications on EC2 instances. Provided by Amazon as a service, ECS consists of multiple built-in components that enable administrators to create clusters, tasks and services.
EKS makes it easy to deploy, manage, and scale containerized applications using Kubernetes on AWS. It manages the complexities of installing and operating Kubernetes clusters, and brings additional value to enterprises, including choice and portability, high availability, and network isolation and performance. For more details on the power of EKS, see our blog on monitoring EKS with AppDynamics.
Which is best for you, ECS or EKS? For many enterprises that containerize their applications and want a simple way to deploy them in AWS, ECS may be the way to go. Perhaps they don’t need all the features that Kubernetes provides, or simply don’t want the additional complexity. They do, however, want to run Docker with support for AWS native services, such as Elastic Load Balancers, CloudTrail, CloudWatch, and so on.
EC2 vs. Fargate
Once you’ve decided that ECS is the way to go, there’s one more decision to make: whether to use the EC2 launch type and have more granular control over instance types, server images and clusters, or have AWS Fargate manage all the placement and availability of your containers. In the examples below, we’ll use the EC2 launch type, as this will allow us to look at the underlying concepts of ECS. But it’s definitely worth checking out Fargate, which has the potential to greatly simplify administration of your container infrastructure. As I write this, Fargate support is only available for ECS, but Amazon has announced that Fargate will also support EKS before the end of the year.
Source: Amazon
Key Concepts in ECS
An ECS Container Instance is simply an EC2 instance running the ECS Container Agent and registered with an ECS cluster. To get started, use Amazon’s ECS-optimized AMI and the default cluster that’s created for you when you first use the ECS service. In practice, you would use ECS clusters to separate your workloads into different environments (for example, dev, staging and production) and also to distribute them across Availability Zones. As the name implies, ECS Container Instances provide the services needed to run your containers, and can be configured with the correct access permissions, connectivity and resources.
ECS Task Definitions are used to specify the container(s) where you wish to deploy to the Container Instances, and how the ECS Container Agent should run them. In addition to setting the location of the container images, which typically are pulled from the Elastic Container Registry (ECR) service or the Docker Hub/Store, the task definition also controls resource limits, environment variables, networking mode, data volumes—in fact, all the things you specify when you launch a container from the command line. So, no surprises there.
Finally, ECS provides a service scheduler for long-running services or applications, with an ability to run one-off jobs. The scheduler supports two strategies: Replica, which places and maintains tasks across the cluster, as specified by the Task Definition; and Daemon, which can be used to place exactly one task on each container instance. You would typically use the Replica strategy to scale out application components, while the Daemon strategy is ideal for running the AppDynamics Server Agent to support container visibility. (More on Daemon in a minute.)
AppDynamics in ECS
To understand how AppDynamics integrates with ECS environments, let’s quickly compare the concept of a container and task in ECS with a node and tier in AppDynamics. Here’s a quick recap of Apps, Tiers and Nodes in AppD:
-
App: a business service or application that contains a set of related services and business transactions, typically something that people or systems interact with. An app could be a mobile banking application with its associated backend, an airline booking application, and so on. In general, multiple pieces of functionality are tied together to provide business value.
-
Tier: a particular service that’s a part of an application. For example, an identification service or an order service. An application generally has multiple tiers.
-
Node: a member of a tier. All nodes essentially run the same code, usually with a load balancer (tier) in front of them.
So how does this related to ECS containers and tasks? In AppDynamics, it’s natural to group similar containers deployed as a service at the tier level; it’s exactly the same as Kubernetes, where a tier maps naturally to a service deployment, and the nodes are instances of that service. In this model, we normally configure node reuse with a suitable prefix to handle the dynamic nature of typical services, which scale up and down naturally. For APM purposes, we are usually interested in the aggregate behavior and availability of the service as a whole, rather than that of individual (and often short-lived) containers.
Monitoring in ECS with AppDynamics
Using AppDynamics to monitor applications deployed with ECS is straightforward. Simply follow these main steps:
-
Include the appropriate APM agent in each container you want to monitor. We’ll show a simple example that you can try, one using a pre-built image freely available from the AppDynamics Docker Store with the Java Agent already installed and configured.
-
Create a task that acts as a recipe for the deployment of your containers. Define all the info for each container, including environment variables, in the task. Note: one unfortunate feature of ECS is that you can’t pass environment variables across all containers, as you would with a environment file. Rather, you must name the environment variables for the agents in each container, if you aren’t naming them another way. Fortunately, you can do all this using the JSON task definition, so this is easily scriptable.
-
Deploy the AppDynamics Server Agent with Docker Visibility enabled on each ECS container instance to provide fully container visibility for your APM monitoring. If you’re using ECS with the EC2 launch type, you’ll usually want to take advantage of the Daemon scheduling strategy to ensure that the Server Agent is deployed once on each Container Instance, just like a Kubernetes daemonset or server daemon service. If you’re using ECS with Fargate, this option isn’t available, so you would include the Server Agent as part of your task definition.
A Simple Example
Here’s a simple example that shows how to deploy a Docker container with the AppDynamics Java APM Agent pre-installed. You can find examples on the Docker Store, and the source code is available on GitHub, if you want to build your own. To keep things simple, you may prefer to copy your images to Amazon’s Elastic Container Registry (ECR) and load them from there.
Here you can see the task and container definitions used to deploy the base image, which contains the Java APM Agent using the standard environment variables for configuring the agent. The standard base container from the AppDynamics Docker Store has Tomcat pre-installed with our Java agent. On startup, you will see output from the agent indicating that it is initialized and ready to begin instrumenting your application.
Step 1. Task Definition
Step 2. Container Definition
Step 3. Runtime Output from the Container
Now here’s how to deploy the AppDynamics Server Agent, again using a base image from the AppDynamics Docker Store, to provide integrated container visibility:
Step 1. Task Definition
Step 2. Container Definition
Step 3. Runtime Output from the Server Agent Container
Amazon ECS includes a command line interface compatible with Docker Compose but, if you wish, you can also use the AWS Management Console.
Try this for yourself with your AppDynamics account (sign up for a free trial using our SaaS service). If you follow these steps and then view the logs for the Tomcat container, you’ll see the AppDynamics Agent start up and connect to the Controller, ready to report business transactions and application metrics. Drop an application war file into the Tomcat working directory, and you’re up and running!
