shariq.site

Octopus Deploy is a neat product...

I really like Octopus Deploy, have used it at a Client for deploying .Net applications and I like the visibility it provides for the CD side of the DevOps process.

Migrating to AWS 101

Cloud Team

How do you assemble a Cloud Team, this is one way:

AWS Certified DevOps Engineer - Professional Completed

Supercharge your CloudFormation templates with Jinja2 Templating Engine

If you are working in an AWS public cloud environment chances are that you have authored a number of CloudFormation templates over the years to define your infrastructure as code. As powerful as this tool is, it has a glaring shortcoming: the templates are fairly static having no inline template expansion feature (think GCP Cloud Deployment Manager.) Due to this limitation, many teams end up copy-pasting similar templates to cater for minor differences like environment (dev, test, prod etc.) and resource names (S3 bucket names etc.)

Enter Jinja2. A modern and powerful templating language for Python. In this blog post I will demonstrate a way to use Jinja2 to enable dynamic expressions and perform variable substitution in your CloudFormation templates.

First lets get the prerequisites out of the way. To use Jinja2, we need to install Python, pip and of course Jinja2.

Install Python

$ sudo yum install python

Install pip

$ curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
$ sudo python get-pip.py

Install Jinja2

$ pip install Jinja2

To invoke Jinja2, we will use a simple python wrapper script.

$ vi j2.py

Copy the following contents to the file j2.py

import os
import sys
import jinja2

sys.stdout.write(jinja2.Template(sys.stdin.read()).render(env=os.environ))

Save and exit the editor

Now let’s create a simple CloudFormation template and transform it through Jinja2:

$ vi template1.yaml

Copy the following contents to the file template1.yaml

—

AWSTemplateFormatVersion: ‘2010-09-09’
Description: Simple S3 bucket for {{ env[‘ENVIRONMENT_NAME’] }}
Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: InstallFiles-{{ env[‘AWS_ACCOUNT_NUMBER’] }}

As you can see it’s the most basic CloudFormation template with one exception, we are using Jinja2 variable for substituting the environment variable. Now lets run this template through Jinja2:

Lets first export the environment variables

$ export ENVIRONMENT_NAME=Development
$ export AWS_ACCOUNT_NUMBER=1234567890

Run the following command:

$ cat template1.yaml | python j2.py

The result of this command will be as follows:

—
AWSTemplateFormatVersion: ‘2010-09-09’
Description: Simple S3 bucket for Development
Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: InstallFiles-1234567890

As you can see Jinja2 has expanded the variable names in the template. This provides us with a powerful mechanism to insert environment variables into our CloudFormation templates.

Lets take another example, what if we wanted to create multiple S3 buckets in an automated manner. Generally in such a case we would have to copy paste the S3 resource block. With Jinja2, this becomes a matter of adding a simple “for” loop:

$ vi template2.yaml

Copy the following contents to the file template2.yaml

—
AWSTemplateFormatVersion: ‘2010-09-09’
Description: Simple S3 bucket for {{ env[‘ENVIRONMENT_NAME’] }}
Resources:
{% for i in range(1,3) %}
  S3Bucket{{ i }}:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: InstallFiles-{{ env[‘AWS_ACCOUNT_NUMBER’] }}-{{ i }}
{% endfor %}

Run the following command:

$ cat template2.yaml | python j2.py

The result of this command will be as follows:

AWSTemplateFormatVersion: ‘2010-09-09’
Description: Simple S3 bucket for Development
Resources:
  S3Bucket1:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: InstallFiles-1234567890-1
  S3Bucket2:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: InstallFiles-1234567890-2

As you can see the resulting template has two S3 Resource blocks. The output of the command can be redirected to another template file to be later used in stack creation.

I am sure you will appreciate the possibilities Jinja2 brings to enhance your CloudFormation templates. Do note that I have barely scratched the surface of this topic, and I highly recommend you to have a look at the Template Designer Documentation found at http://jinja.pocoo.org/docs/2.10/templates/ to explore more possibilities. If you are using Ansible, do note that Ansible uses Jinja2 templating to enable dynamic expressions and access to variables. In this case you can get rid of the Python wrapper script mentioned in this article and use Ansible directly for template expansion.

Enable Cost Allocation Tags to differentiate project based billing

When running in an AWS public cloud environment, many times there is a need to dissect the billing across different projects for accounting and accrual purposes. AWS provides a mechanism to aggregate related platform costs using a feature known as Cost Allocation Tags. With this feature you can designate Tags on your AWS resources to track costs on a detailed level.

From the AWS Documentation:

Activating tags for cost allocation tells AWS that the associated cost data for these tags should be made available throughout the billing pipeline. Once activated, cost allocation tags can be used as a dimension of grouping and filtering in Cost Explorer, as well as for refining AWS budget criteria.

For example, to view cost allocation based on various project resources in your AWS account, you can tag these resources (EC2 instances, S3 buckets, etc) with a tag named “Project”. Next the Project tag can be activated as a Cost Allocation Tag. From then on AWS will include this tag in associated cost data to allow for filtering based in the tag in Cost Explorer reports.

Let’s walk through the steps of setting this up:

1. Log in to your AWS Management Console
2. Tag all the resources with a Tag Key as Project and Value as per your various projects. Understand that this may not be possible for every resource type.
3. Navigate to My Billing Dashboard > Cost Allocation Tags
4. Under User-Defined Cost Allocation Tags section, select the tag “Project” and click the “Activate” button.

Once a tag is activated it will take around 24 hours for billing data to appear under this tag.

Next, to view the costs under a project, do the following:

1. Log in to your AWS Management Console
2. Navigate to My Billing Dashboard > Cost Explorer
3. Click “Launch Cost Explorer”
4. On the right side of the page under Filters section, click the Tag filter and select the Project tag, then the Tag Value to filter cost by the Project

As you can see from the screenshot below, now we can see exactly how much each project is costing per day (or month, if selected)

Some important points to consider:

• Cost allocation tagging is “managed” via the master billing account at the root of the AWS organization. If your account is part of an organization you will have to contact this account administrator to enable the cost allocation tags.
• The error message in the previous screenshot will always appear in tenancies not allocated the management permission.
• Some resources notably bandwidth charges cannot be tagged and thus cannot be accounted under cost allocation tagging. A common pattern in such cases is to calculate percentage cost on each project and cost the unaccounted charges based on this percentage.

Having fun patching WannaCry...

An approach to Cloud Computing...