Cookbooks and Recipes

Chef is a Ruby-based configuration management language that AWS OpsWorks Stacks uses to enforce configuration on Amazon EC2 on-premises instance nodes. Chef uses a declarative syntax to describe how to configure a node without detailing the actual steps to achieve the desired configuration. Chef organizes these declarative statements into recipes, which act as a collection of resources to configure on nodes.

template '/tmp/somefile' do
  mode '0755'
  source 'somefile.erb'
  not_if { File.exist?('/etc/passwd') }
end

In the previous example, the file /tmp/somefile is created from the somefile.erb template. This template file is in a cookbook, which acts as a container for recipes and any files, templates, attributes, or other components to enforce configuration on a node. Attribute files provide data to recipes, and AWS OpsWorks Stacks can modify them with custom JSON at the stack, layer, and deployment levels. You can copy files from cookbooks to nodes to create static files and use templates to provide dynamic data to files before you create them on the node.

Cookbooks normally belong to a cookbook repository, or chef-repo, which is a versioned directory that contains cookbooks and their recipes. A single cookbook repository can contain one or more cookbooks. When you set the cookbook repository for a stack, all cookbooks in the repository copy to each instance in the stack. The directory structure of a chef-repo must match Figure 9.1.

Recipes use nodes to execute in their “run list.” Recipes that you assign to a node’s run list execute in the order in which they appear. You can assign recipes to roles, which you assign to a node’s run list.

RUN_LIST="recipe['postgresql::default'],recipe['monitoring::default']"
RUN_LIST="role['database-server']"

In a typical Chef installation, one or more Chef Servers manage multiple nodes across an enterprise. The Chef Server is responsible for distributing cookbooks, managing node information, and providing data to nodes as the Chef runs (an execution of chef-client on a node that enforces any assigned recipes).

Managing Cookbooks

To install custom cookbooks in your stack, you first have to enable the Use Custom Chef Cookbooks field in the stack properties. Once you enable this field, you can then provide the details of the cookbook repository, such as the Git Repository URL, as shown in Figure 9.2.

When instances first create and start in a stack, they will download custom cookbooks from the repository you select. However, running instances will not download new cookbooks automatically. You must manually set the Run Command’s Command option to Update Custom Cookbooks, as shown in Figure 9.3.

 You cannot manually start stopped Amazon EBS backed load-based and time-based instances, and thus you must replace the instance to update custom cookbooks.

berks package cookbooks.tar.gz
Cookbook(s) packaged to /Users/username/tmp/berks/cookbooks.tar.gz

source "https://supermarket.chef.io"
cookbook "server-app", path: "./server-app"
cookbook "server-utils", path: "./server-utils"

berks package cookbooks.tar.gz

Stack

A typical workload in AWS will include systems for various purposes, such as load balancers, application servers, proxy servers, databases, and more. The set of Amazon EC2 on-premises instances, Amazon RDS, Elastic Load Balancing, and other systems make up a stack. You can organize stacks across an enterprise.

Suppose you have a single application with dev, test, and production environments. Each of these environments has a stack that enables you to separate resources to ensure stability of changes. You group resources into stacks by logical or functional purposes. The example stack in Figure 9.4 includes three layers, a cookbook repository, an application repository, and one app to deploy to the application server instances. This stack manages a full application available to users over the Internet.

When you create a new stack, you will have the option to set the stack’s properties.

Layer

A layer acts as a subset of instances or resources in a stack. Layers act as groups of instances or resources based on a common function. This is especially important, as the Chef recipe code applies to a layer and all instances in a layer. A layer is the point where any configuration of nodes will be set, such as what Chef recipes to execute at each lifecycle hook. A layer can contain any one or more nodes, and a node must be a member of one or more layers. When a node is a member of multiple layers, it will run any recipes you configure for each lifecycle event for both layers in the layer and recipe order you specify.

From the point of view of a Chef Server installation, a layer is synonymous with a Chef Role. In the node object, the layer and role data are equivalent. This is primarily to ensure compatibility with open-source cookbooks that are not written specifically for AWS OpsWorks Stacks.

Amazon ECS Cluster Layer

Amazon ECS cluster layers provide configuration management capabilities to Linux instances in your Amazon ECS cluster. You can associate a single cluster with a single stack at a time. To create this layer, you must register the cluster with the stack. After this, it will appear in the Layer type drop-down list of available clusters from which to create a layer, as shown in Figure 9.5.

 Use the console or AWS CLI/SDK commands to create the cluster.

After the layer is created, any existing cluster instances will not import into the stack. Instead, the instances need to register with the stack as on-premises instances, or you need to create a new instance in the layer with the AWS OpsWorks Stacks console or CLI and replace them with new instances. When you create new instances, AWS OpsWorks Stacks will automatically install Docker and the Amazon ECS agent before it registers the instance with the cluster.

 An instance cannot belong to both an Amazon ECS cluster layer and a Chef 11.10 built-in layer. However, the instance can belong to an Amazon ECS cluster layer and other custom layer(s).

apache2
|- templates
|-- default
|--- apache2.conf.erb

Instances

An instance represents either an Amazon EC2 or on-premises instance, and the configuration AWS OpsWorks Stacks enforces upon it. You can associate instances with one or more layers, which will define the configuration to apply to the instance. AWS OpsWorks Stacks can create instances. For existing instances or on-premises servers, they can register with a stack, and you can manage them in the same manner as if you created them as AWS OpsWorks Stacks.

Instance Type

AWS OpsWorks Stacks supports three instance types.

24/7 instances This instance type runs until you manually stop it.

Time-based instances Instances of this type run on a daily and weekly schedule that you configure and are useful for handling predictable changes in a load on your stack.

Load-based instances Load-based instances start and stop automatically based on metrics such as NetworkOut or CPUUtilization.

You can use time-based and load-based instances to implement automatic scaling in response to predictable or sudden changes in demand. However, unlike Amazon EC2 Auto Scaling groups, you must create time-based and load-based instances ahead of time with the AWS OpsWorks console or AWS CLI. The underlying Amazon EC2 instance will not be created until the time you specify, or the load threshold occurs, but the AWS OpsWorks instance object must exist ahead of time.

If your stack contains more than several instances, a mix of the previous instance types will provide adequate scalability in response to predictable and sudden changes in demand.

For example, if the lowest demand throughout the day in your environment requires three running instances, then it would make sense to include at least three 24/7 instances in the stack. If demand has a predictable pattern throughout the rest of the day, you can use a number of time-based instances to scale out to meet known increases in demand. To accommodate any potential changes outside the norm, you can configure additional load-based instances as well. Figure 9.6 demonstrates the use of each instance type to react dynamically to changes in request volume.

Apps

An app refers to the location where you store application code and other files. This can be an Amazon S3 bucket, a Git repository, or an HTTP bundle. If you require credentials to connect to the repository, the app configuration provides them as well. The Deploy lifecycle event includes any apps that you configure for an instance at the layer or layers to which it corresponds.

After you configure one or more apps for a layer, running a deployment on instances in that layer will copy the application code from the configured repository and perform any needed deployment steps. In Chef 11.10 built-in layers, this occurs automatically. For custom layers in any Chef version, the deployment process is not automatic, and you must use custom cookbooks.

To perform app updates, you first modify the app itself to point to a new version. Either the current location (Amazon S3 file, Git branch, or HTTP archive) must have the update of the new application code or the app must point to a new revision. Currently running instances will not automatically update. Instances that create after the app updates will deploy the latest version. Any instances that stop at the time of the update will update when the instance starts again.

Users and Permissions Management

AWS OpsWorks Stacks provides the ability to manage users at the stack level, independent of IAM permissions. This is incredibly useful to provide access to instances in a stack without giving a user actual permission to your account. Since most large organizations have strict access policies for third-party contractors, AWS OpsWorks Stacks allows you to give access to perform some stack management tasks, as well as Secure Socket Shell (SSH) or Remote Desktop Protocol (RDP) access to stack instances, and not allow nonemployees access to perform tasks within your account.

Managing Permissions

There are four permission types you can apply to a user to provide stack-level permission.

Deny No action is allowed on the stack.

Show The user can view stack configuration but cannot interact with it in any way.

Deploy The user can view stack configuration and deploy apps.

Manage The user can view stack configuration, deploy apps, and manage stack configuration.

AWS OpsWorks Stacks permissions do not allow certain actions, such as to create or clone stacks. IAM permissions restrict these actions, and you must assign them to an IAM user or IAM role. If the user in question is also an IAM user, you can fine-tune the permissions levels.

Along with stack-level permissions, you can give AWS OpsWorks users SSH or RDP access into instances with or without administrative access. You can also configure users to manage their own SSH keys so that they can set their key once they provide access and do not require shared key files through other means. This is also more secure than Amazon EC2 key pairs, as the keys are unique to individual users.

User permissions are set at the stack level in the AWS OpsWorks console, as shown in Figure 9.7. Here you can assign stack and instance permissions to individual user accounts.

Lifecycle Events

At each layer of a stack, you will set which Chef recipes you would like to execute at each stage of a node’s lifecycle, such as when it comes online or goes offline. These stages are lifecycle events. The recipes at each lifecycle event execute in the order you specify in the AWS OpsWorks Agent.

Outside of the lifecycle events, you can execute recipes manually with the Execute Recipes command in the AWS OpsWorks console (see Figure 9.8) or AWS CLI. When invoking the command, you can provide a list of recipes to execute in order.

You can add more custom recipes to each lifecycle event in the layer’s configuration. Recipes execute in the order they appear in the Custom Chef recipes lifecycle event, as shown in Figure 9.9.

Resource Management

AWS OpsWorks Stacks allows for management of other resources in your account as part of your stack, and it includes elastic IP addresses, Amazon EBS volumes, and Amazon RDS instances. You register the resources with the stack to make them available to assign them to instances or layers. If you attach resources to instances in the stack and you delete the instance, the resource remains registered with the stack until it is manually deregistered. Deregistering resources does not automatically delete them. You must delete the resource itself with the respective service console or AWS CLI command.

Amazon RDS Instances

You can register Amazon EBS instances to only one stack at a time. However, you can register a single Amazon RDS instance with multiple apps in the same stack.

Chef 11 and Chef 12

Both Chef 11 and Chef 12 provide unique functionality differences that are important to note before you use AWS OpsWorks Stacks. Each of the major differences is outlined in this section.

The differences in this section are with respect to AWS OpsWorks Stacks as a service, and they do not include differences between Chef versions 11.10 and 12.0. Since version 11.10 has been deprecated by Chef, community support will not be as strong as for later versions.

app = search("aws_opsworks_app").first
Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********")
Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********")

Data Bags and Custom JSON

In Chef 11.10 stacks, you provide data to instances with custom JSON, which populates in the node object when Chef runs. You can access this information in your recipe code to specify configuration based on the value of custom JSON. You can specify custom JSON at the stack, layer, and deployment levels. Any data that you define at the deployment level overrides the data set at the layer or stack levels. Any data set at the layer level overrides the data set at the stack level.

{
  "state": "visible",
  "colors": {
    "foreground": "light-blue",
    "background": "dark-gray"
  }
}

{
  "state": "hidden",
  "colors": {
    "foreground": "light-blue",
    "background": "dark-gray"
  }
}

Chef::Log.info("********** The app's initial state is '#{node['state']}' **********")
Chef::Log.info("********** The app's initial foreground color is '#{node['colors']['foreground']}' **********")
Chef::Log.info("********** The app's initial background color is '#{node['colors']['background']}' **********")

Custom JSON is limited to 80 KB in size. If you need to provide larger data, consider the use of Amazon S3 and retrieve files with a custom cookbook.

Chef::Log.info ("********** The app's short name is '#{node['opsworks']['applications'].first['slug_name']}' **********")
Chef::Log.info("********** The app's URL is '#{node['deploy']['simplephpapp']['scm']['repository']}' **********")
Moving to data bags in Chef 12.0 and 12.2 stacks, Chef search is used to query data bag contents. The above example would instead look like:
app = search("aws_opsworks_app").first
 
Chef::Log.info("********** The app's short name is '#{app['shortname']}' **********")
Chef::Log.info("********** The app's URL is '#{app['app_source']['url']}' **********")

{
  "opsworks": {
    "data_bags": {
      "users": {
        {
          "id": "nick",
          "comment": "Nick Alteen",
          "home": "/opt/alteen",
          "ssh_keys": ["123…", "456…"]
        }
      }
    }
  }
}

Monitor Instance Metrics

AWS OpsWorks Stacks provides a custom dashboard to monitor up to 13 custom metrics for each instance in the stack. The agent that runs on each instance will publish the information to the AWS OpsWorks Stacks service. If you enable the layer, system, application, and custom logs, they automatically publish to Amazon CloudWatch Logs for review without access the instance itself. You can monitor details at the stack, layer, and instance levels. The metrics that the AWS OpsWorks Agent publishes include cpu_idle, memory_free, procs, and others. Since these metrics are provided by the AWS OpsWorks Agent running on the instance itself, information not available to the underlying host of the instance is provided.

For each stack in your account, a dashboard displays these metrics over time. The metrics divide by layer and display over time periods that vary, as shown in Figure 9.10.

If you select a layer name in the monitoring dashboard, you can review each individual layer. In the layer’s dashboard, metrics divide by individual instances. For example, if you select PHP App Server, as shown in Figure 9.10, the screen in Figure 9.11 displays.

From the layer dashboard, you can review individual instance metrics if you select the instance name. For example, if you select php-app1, as shown in Figure 9.11, the screen in Figure 9.12 displays.

If you enable Amazon CloudWatch Logs on Linux stacks, you can configure the AWS OpsWorks Agent to send system, application, and custom logs to Amazon CloudWatch Logs. With this, alerts can be set when the logs detect specific string patterns, such as HTTP 500 responses in web servers. To publish logs, the instance profile for any instances in the layer must contain permission to push logs. To do this, you assign the AWSOpsWorksCloudWatchLogs managed policy to the corresponding role. Since this integration requires a later agent version, enabling it for your layer will result in all instances being upgraded to a compatible agent version (if they do not already have one).

When you stream logs to Amazon CloudWatch Logs, the log groups use the following naming convention:

stack_namelayer_namechef_log_name

Custom logs, which you define by the file path in the layer settings, add to log groups with the naming convention.

/stack_name/layer_short_name/file_path_name

Along with CloudWatch Logs, CloudWatch Events support stacks. Any time the following types of events occur, you can invoke custom actions in response.

• Instance state change
• Command state change
• Deployment state change
• Alerts

Using AWS OpsWorks Stacks with AWS CodePipeline

Inside a stack, you specify a value for App to refer to a repository or archive that contains application code to deploy to one or more layers. You can use AWS CodePipeline to update an AWS OpsWorks app, which then deploys to any instances in layers you associate with this app.

To configure AWS CodePipeline to deploy to a stack, select the appropriate stack, layer, and app to update with the input artifact, as shown in Figure 9.13.

Deployment Best Practices

Since app or cookbook updates do not deploy automatically to running instances, you need a robust deployment strategy to ensure that changes complete successfully (or do not cause outages if they fail). This section details the deployment best practices recommended by AWS.

Amazon ECS Cluster

Amazon ECS clusters are the foundational infrastructure components on which containers run. Clusters consist of one or more Amazon EC2 instances in your Amazon VPC. Each instance in a cluster (cluster instance) has an agent installed. The agent is responsible for receiving container scheduling/shutdown commands from the Amazon ECS service and to report the current health status of containers (restart or replace). Figure 9.14 demonstrates an Amazon EC2 launch type, where instances make up the Amazon ECS cluster.

In an AWS Fargate launch type, Amazon ECS clusters are no longer made up of Amazon EC2 instances. Since the tasks themselves launch on the AWS infrastructure, AWS assigns each one an elastic network interface with an Amazon VPC. This provides network connectivity for the container without the need to manage the infrastructure on which it runs. Figure 9.15 demonstrates an AWS Fargate cluster that runs in multiple availability zones (AZs).

An individual cluster can support both Amazon EC2 and AWS Fargate launch types. However, a single cluster instance can belong to only one cluster at a time. Amazon EC2 launch types support both on-demand and spot instances, and they allow you to reduce cost for noncritical workloads.

To enable network connectivity for containers that run on your instance, the corresponding task definition must outline port mappings from the container to the host instance. When you create a container instance, you can select the instance type to use. The compute resources available to this instance type will determine how many containers can be run on the instance. For example, if a t2.micro instance has one vCPU and 1 GB of RAM, it will not be able to run containers that require two vCPUs.

After you add a container instance to a cluster and you place containers on it, there may be situations where you would need to remove the container from the cluster temporarily—for a regular patch, for example. However, if critical tasks run on a container instance, you may want to wait for the containers to terminate gracefully. Container instance draining can be used to drain running containers from an instance and prevent new ones from being started. Depending on the service’s configuration, replacement tasks start before or after the original tasks terminate.

• If the value of minimumHealthyPercent is less than 100 percent, the service will terminate the task and launch a replacement.
• If the value is greater than 100 percent, the service will attempt to launch a replacement task before it terminates the original.

AWS Fargate

AWS Fargate simplifies the process of managing containers in your environment and removes the need to manage underlying cluster instances. Instead, you only need to specify the compute requirements of your containers in your task definition. AWS Fargate automatically launches containers without your interaction.

With AWS Fargate, there are several restrictions on the types of tasks that you can launch. For example, when you specify a task definition, containers cannot be run in privileged mode. To verify that a given task definition is acceptable by AWS Fargate, use the Requires capabilities field of the Amazon ECS console or the --requires-capabilities command option of the AWS CLI.

Containers and Images

Any workloads that run on Amazon ECS must reside in Docker containers. In a virtual server environment, multiple virtual machines share physical hardware, each of which acts as its own operating system. In a containerized environment, you package components of the operating system itself into containers. This removes the need to run any nonessential aspects of a full-fledged virtual machine to increase portability. In other words, virtual machines share the same physical hardware, while containers share the same operating system.

Container images are similar in concept to AMIs. Images provision a Docker container. You store images in registries, such as a Docker Hub or an Amazon Elastic Container Repository (ECR).

Docker provides mobility and flexibility of your workload to allow containers to be run on any system that supports Docker. Compute resources can be better utilized when you run multiple containers on the same cluster, which makes the best possible use of resources and reduces idle compute capacity. Since you separate service components into containers, you can update individual components more frequently and at reduced risk.

Task Definition

Though you can package entire applications into a single container, it may be more efficient to run multiple smaller containers, each of which contains a subset of functionality of your full application. This is referred to as service-oriented architecture (SOA). In SOA, each unit of functionality for an overall system is contained separately from the rest. Individual services work with one another to perform a larger task. For example, an e-commerce website that uses SOA could have sets of containers for load balancing, credit card processing, order fulfillment, or any other tasks that users require. You design each component of the system as a black box so that other components do not need to be aware of inner workings to interact with them.

A task definition is a JSON document that describes what containers launch for your application or system. A single task definition can describe between one and 10 containers and their requirements. Task definitions can also specify compute, networking, and storage requirements, such as which ports to expose to which containers and which volumes to mount.

You should add containers to the same task definition under the following circumstances:

• The containers all share a common lifecycle.
• The containers need to run on the same common host or container instance.
• The containers need to share local resources or volumes.

An entire application does not need to deploy with a single task definition. Instead, you should separate larger application segments into separate task definitions. This will reduce the impact of breaking changes in your environment. If you allocate the right-sized container instances, you can also better control scaling and resource consumption of the containers.

After a task definition creates and uploads to Amazon ECS, it can launch one or more tasks. When a task is created, the containers in the task definition are scheduled to launch into the target cluster via the task scheduler.

{
  "containerDefinitions": [
    {
      "name": "wordpress",
      "links": [
        "mysql"
      ],
      "image": "wordpress",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80
        }
      ],
      "memory": 500,
      "cpu": 10
    },
    {
      "environment": [
        {
          "name": "MYSQL_ROOT_PASSWORD",
          "value": "password"
        }
      ],
      "name": "mysql",
      "image": "mysql",
      "cpu": 10,
      "memory": 500,
      "essential": true
    }
  ],
  "family": "hello_world"
}

Services

When creating a service, you can specify the task definition and number of tasks to maintain at any point in time. After the service creates, it will launch the desired number of tasks; thus, it launches each of the containers in the task definition. If any containers in the task become unhealthy, the service is responsible and launches replacement tasks.

When you define a service, you can also configure deployment strategies to ensure a minimum number of healthy tasks are available to serve requests while other tasks in the service update. The maximumPercent parameter defines the maximum percentage of tasks that can be in RUNNING or PENDING state. The minimumHealthyPercent parameter specifies the minimum percentage of tasks that must be in a healthy (RUNNING) state during deployments.

Suppose you configure one task for your service, and you would like to ensure that the application is available during deployments. If you set the maximumPercent to 200 percent and minimumHealthyPercent to 100 percent, it will ensure that the new task launches before the old task terminates. If you configure two tasks for your service and some loss of availability is acceptable, you can set maximumPercent to 100 percent and minimumHealthyPercent to 50 percent. This will cause the service scheduler to terminate one task, launch its replacement, and then do the same with the other task. The difference is that the first approach requires double the normal cluster capacity to accommodate the additional tasks.

Schedule Tasks

If you increase the number of instances in an Amazon ECS cluster, it does not automatically increase the number of running tasks as well. When you configure a service, the service scheduler determines how many tasks run on one or more clusters and automatically starts replacement tasks should any fail. This is especially ideal for long-running tasks such as web servers. If you configure it to do so, the service scheduler will ensure that tasks register with an elastic load balancer.

You can also run a task manually with the RunTask action, or you can run tasks on a cron-like schedule (such as every N minutes on Tuesdays and Thursdays). This works well for tasks such as log rotation, batch jobs, or other data aggregation tasks.

To dynamically adjust the run task count dynamically, you use Amazon CloudWatch Alarms in conjunction with Application Auto Scaling to increase or decrease the task count based on alarm status. You can use two approaches for automatically scaling Amazon ECS services and tasks: Target Tracking Policies and Step Scaling Policies.

"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]

"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type == t2.micro",
        "type": "memberOf"
    }
]

Amazon ECS Service Discovery

Amazon ECS Service Discovery allows you to assign Amazon Route 53 DNS entries automatically for tasks your service manages. To do so, you create a private service namespace for each Amazon ECS cluster. As tasks launch or terminate, the private service namespace updates to include DNS entries for each task. A service directory maps DNS entries to available service endpoints. Amazon ECS Service Discovery maintains health checks of containers, and it removes them from the service directory should they become unavailable.

Private Image Repositories

Amazon ECS can connect to private image repositories with basic authentication. This is useful to connect to Docker Hub or other private registries with a username and password. To do so, the ECS_ENGINE_AUTH_TYPE and ECS_ENGINE_AUTH_DATA environment variables must be set with the authorization type and actual credentials to connect. However, you should not set these properties directly. Instead, store your container instance configuration file in an Amazon S3 bucket and copy it to the instance with userdata.

Amazon Elastic Container Repository

Amazon Elastic Container Repository (Amazon ECR) is a Docker registry service that is fully compatible with existing Docker CLI tools. Amazon ECR supports resource-level permissions for private repositories and allows you to preserve a secure registry without the need to maintain an additional application. Since it integrates with IAM users and Amazon ECS cluster instances, it can take advantage of IAM users or instance profiles to access and maintain images securely without the need to provide a username and password.

Amazon ECS Container Agent

The Amazon ECS container agent is responsible for monitoring the status of tasks that run on cluster instances. If a new task needs to launch, the container agent will download the container images and start or stop containers. If any containers fail health checks, the container agent will replace them. Since the AWS Fargate launch type uses AWS-managed compute resources, you do not need to configure the agent.

To register an instance with an Amazon ECS cluster, you must first install the Amazon ECS Agent. This agent installs automatically on Amazon ECS optimized AMIs. If you would like to use a custom AMI, it must adhere to the following requirements:

• Linux kernel 3.10 or greater
• Docker version 1.9.0 or greater and any corresponding dependencies

The Amazon ECS container agent updates regularly and can update on your instance(s) without any service interruptions. To perform updates to the agent, replace the container instance entirely or use the Update Container Agent command on Amazon ECS optimized AMIs.

To configure the Amazon ECS container agent, update /etc/ecs/config on the container instance and then restart the agent. You can configure properties such as the cluster to register with, reserved ports, proxy settings, and how much system memory to reserve for the agent.

Using Amazon ECS with AWS CodePipeline

When you select Amazon ECS as a deployment provider, there is no option to create the cluster and service as part of the pipeline creation process. This must be done ahead of time. After the cluster is created, select the appropriate cluster and service names in the AWS CodePipeline console, as shown in Figure 9.16.

You must provide an image filename as part of this configuration. This is a JSON-formatted document inside your code repository or archive or as an output build artifact, which specifies the service’s container name and image tag. We recommend that the cluster contain at least two Amazon EC2 instances so that one can act as primary while the other handles deployment of new containers.