What's created by the Template
If you haven't read the overview of how you can use CloudMunch to build and deploy your Docker based application using ECS, please read this first.
To review the steps for setting up your Application in CloudMunch, please check this article.
Let's review what is created after using the Template. The newly created Application will have the following:
Based on the inputs gathered as the application is created using the template, several application specific configurations are created. These configurations are used in the Tasks that are part of the Template and the output of these Tasks which are Insights and Environments.
Three distinct configuration objects created are:
- Integrations: These encapsulate the configuration for an external Service/Tool used. For example, AWS configuration is an Integration that holds authentication details and provides CloudMunch access to the ECS Cluster configuration
- Tasks: Automation actions to initiate Pipeline, create Environments, perform Environment update and generate Insights. For example, Update Service is a Task that helps Scale up or down the number of Services.
- Assets: Assets represent the physical infrastructure that is launched and associated with an Environment. For example, ECS Service is a type of Asset that is created.
Let's look at each of these configurations in detail.
This Template creates the following Integrations. During the Application Add process, you will be asked to configure these Integrations:
Source - GitHub
- OAuth as authentication to list repositories
- You can allow CloudMunch to access private or public repositories as well as Organization level data
- Tasks for using the repository are updated to use the configured Integration
- Insights are created at the repository and Organization level
- repository level metrics like commits, pull requests will be created (see more details in the Insights section below)
- organization level access of the repository allows CloudMunch to provide Insights at the org level
Container Registry - ECR
- Captures repository URL for your application's image registry
- Tasks that push and pull images to/from the Hub are updated to use this Integration
- Captures credentials for your AWS account Docker Hub or your private Hub
- Tasks that use the Docker Host with Compose and ECS clusters use this Integration
While creating an application using the Template, you can also optionally configure other tools that you use in your application lifecycle for getting Insights. These Integrations include JIRA for Requirements and SonarQube for Code Quality. We will be adding more Integrations like NewRelic and Google Analytics, so that you can get complete Application level Insights.
Assets represent the physical infrastructure that is launched using Tasks like Container or Host, ECS Service. This Template creates the following Assets:
Server - Docker Host
This Template uses a Docker Host to launch the Application containers using Docker Compose. Currently, Docker Hosts are supported only on AWS. So a Server Asset type is created with necessary information to ssh into the Host.
When the Main Task is executed and the Dev Environment is created, Assets of type Container are created. Depending on the number of roles in your Compose file, that many Container Assets are created.
This Template expects configuring a Cluster for Test and Release stage of the Pipeline. This Asset type uses the AWS Integration created to list all the available Clusters in the AWS account and you can pick the Cluster you want to use for each Pipeline Stage. The Tasks to launch Environments in Test and Release will create these Assets.
Tasks are automation actions in CloudMunch that execute a series of Steps. These Tasks range from Pipeline actions, Environment actions to Insights actions. Here are the list of Tasks that the Docker with ECS Template creates:
Task that initiates the Pipeline by building the Docker Container(s) and launching an Environment in the Dev Stage of the Pipeline. In this DevOps Template, the Docker Compose is used for launch Containers in the Dev Environment. When this Task is triggered, an Application build is available in the Dev Stage and a Dev Environment is launched if the Build is successful with the latest code.
The Task also includes a simple validation for the launched Environment, by checking if the launched Application URL is accessible. You can add additional Steps to this Task to implement your Application specific validations.
Task to manually approve the Build, promote it to the Test Stage and push the Docker Image to Hub with "approved" tag. It additionally stops the Dev Environment, and deletes the Containers associated with the Dev Environment.
This Task will pull the Docker Image that is tagged "approved" and launch a new environment in Test stage using that Image. The host for the Test Environment can be either a single host of clustered host depending on the template.
With the Test Environment up and running, you can now create Tasks for further testing and validating that the application revision is ready. The Release Task updates the tag for the Docker Image as "released" and promotes the application to Release.
This Task will pull theh4Docker Image tagged as "release" and launches a new environment in Release stage. The host for the Test Environment can be either a single host of clustered host depending on the template.
This Task starts a stopped Container running in the Host for Dev Stage and marks the Dev Environment as Running.
This Task stops a running Container running in the Host for Dev Stage and marks the Dev Environment as Stopped.
This Task enables taking the Pipeline action of rejecting a build. By selecting Reject, the Container in the Dev Environment is Stopped and the corresponding Containers are deleted. Additionally, the Docker Image is untagged and deleted.
Another set of Tasks that are created are Tasks to gather data and build Dashboard views for a different kinds of metrics. Based on the Integrations configured during the Application add process, the number of these Tasks will vary. Currently, the Insights Tasks are GitHub Repo Metrics, JIRA Metrics, SonarQube Metrics, CloudMunch Metrics, GitHub Org Metrics.
Templates have Tasks that perform specific action and these Tasks create Environments and Insights. Environments provide a logical representation of the physical deployment of your Application. In the Docker Templates, these encapsulate all the Containers that make up your Application.
CloudMunch is focused on bringing Application Centricity to the DevOps world. One key part of that is keeping the Application architecture core to any action you perform whether you create a Build or perform a deployment. You can read more about what an Environment is and what metadata it holds here.
All Docker Templates minimally create a Dev Environment using the Main Task. This is to demonstrate how Tasks can be triggered and how Environments can be created to bring the deployment and the latest version of the Application code.
There are also additional Tasks that are created by the Template for performing Actions on a running Environment like Stop, Start, Scale (in the case of ECS).
All Docker Templates also create Insights based on the Integrations that have been provided. Minimally, all the Templates create the following categories of Insights
- Code Commit Metrics
- Operational Metrics
If other Integrations are configured these following categories of Insights are also generated
- Code Quality Metrics
- Organization Level Code Commit Metrics
- Project/Requirements Metrics
Code Commit Metrics
These are basic metrics that show Commits by user for the repository that was configured as Source Integration.
These are metrics that show up in the Dashboard as CloudMunch metrics. These include operational metrics like CPU, Disk and Memory usage on the Docker Host and Containers Host metrics like count by state.
Code Quality Metrics
These are metrics gathered from a Code Quality tool like SonarQube. The key metrics are Code Blockers and TechDebt based on the code analysis performed on your Application Code
Organization Level Code Commit Metrics
If the access to GitHub Organization data is enabled, these metrics will show Code Commits across all the repositories in the GitHub Organization. These metrics provide a great way to compare activity across all the repos in the company.
These are metrics gathered from a Project and Requirements management tool like JIRA. The key metrics include Stories, Sprints, Defects and Risks. These metrics provide a complete view of how your Application is progressing against the plan that was created and where are the risks in the plan that you need to handle