Too Many Study Resources for a Simple Cert

My prep for the AZ-104 has been a bit all over the place, in part because of the transition from the 103 to 104, but the quality disparities from one content provider to another leaves a student a bit dioriented.

Pluralsight: My company provides this subscription, so I tried it out. Death by Powerpoint, no hands on labs, no sandboxes, no case studies, just hours of mind numbing powerpoints. Kill me now.

Linux Academy / A Cloud Guru: The consolidation of these two companies and the migration of test versions made using these resources quite challenging. My first pass through the AZ-103 course on LinuxAcademy was similarly mind numbing, just power points and screen captures of console walkthroughs. No labs or sandboxes that I am used to with LinuxAcademy. Then, the test version changed, the course was deprecated and the bright, colorful, cheerful and no more illuminating CloudGuru version became prominent, yet is was yet another 10,000 foot overview with little depth.

Microsoft Learn: I’m more of a kinesthetic learner, I have to build it and take it apart to really learn something. MS Learn is the equivalent of reading the book for the test. It might work, but it is slow going.

Whizlabs: I bought the practice exams, but after dying hard on the first exam, I’ve been avoiding them, as I do not want to spend 3 hours (170 minutes!) taking an exam I can’t ace. It’s a bit chicken and egg, I know.

Other resources:

  • https://www.thomasmaurer.ch/2020/03/az-104-study-guide-azure-administrator/
  • https://docs.microsoft.com/en-us/learn/certifications/azure-administrator

First Azure Cert Complete

I didn’t want to take a fundamentals cert, since I’ve been in the cloud 5 years and the basic concepts don’t change, just the arrangement and color of the deck chairs. However, my boss said the more certs the merrier and the company will reimburse the test cost, so I figure it’s an easy $99 gamble to take the AZ-900. And so, in the comfort of my bed via online proctoring, I did take and pass the Azure Cloud Fundamentals exam.

I was concerned about the online proctor process, as I had heard some horror stories from the early days of quarantine about proctors not showing up and voiding the exam. There was some incorrect info on the web site about the requirement for a second government issued photo ID for online exams, but luckily the ol’ driver’s license was sufficient. The process was pretty straight forward:

  1. Register for the test. I figured I’d take the test quickly, so I tried to get a test slot as soon as possible, but not in work hours. I’d pick a slot, go through the payment process and hit enter, only to for the time slot I had chosen was no longer available. This happened THREE TIMES. I would like PearsonVue to redo their interface so that a slot is “claimed” for a time period until purchased and then released, rather than the blind duck hunt it is now.
  2. Set up an area to take the test. I had intended to take the test outside on my patio office, but when the temperature was going to break 115 degrees Fahrenheit and my test was in the afternoon hours, I figured I wanted to survive the test as well as pass it. So, I cleared everything away from my bed, covered my robot assistant’s screen, and made ready to sit on my bed for the test, figuring that I wouldn’t have to really focus that hard. There is some cognitive dissonance around having to keep your self phone close in case the proctor has to contact you but all electronic devices out of arm’s length, but whatevs.
  3. Download the client. I chose to take it on a Mac, rather than my work or home PC, mainly for the size of the laptop screen (15″).. I ran the system test the day before and made sure it all worked. On the day of the test, I downloaded the client again, as the test credentials are embedded in the client, and fired it up.The app sent me a link via text to a web app that took photos of my ID, front and back, and also took photos of my test area, from 4 different views. Once complete, the test was ready to start. It took about 10 minutes for the proctor to start the test session. All I saw was a window of my face from the camera that said ‘Recording’ and that the test would be failed if I left the screen view.
  4. Take the test. Pretty straight forward. My only complaint is that some of the questions were a bit ambiguous, and that one of the graphics had to be scrolled all the way up to get the correct answer, but you wouldn’t know it scrolled unless you experimented, no visual cues. Once I passed, I was asked to review the questions and comment, but the app abruptly quit after my score breakdown showed, so I didn’t get to comment on the questions I had marked.
  5. Get your results. I had this dance with Amazon too years ago, but the results came in faster with Microsoft these days. I checked on the Pearson site for my score, and the test was marked still in progress. I was worried that the app had crashed and my test session was stuck.  As I waited for an hour in the chat bot line to ask, the test reverted to Pass and then my score was available in the Certification Portal. So, the lesson here is be patient, your score will show up soon.

On the content side, I didn’t have all the little distinctions and features of some of the more higher level ‘Centers’ (Privacy, Trust, Security, etc) in Azure memorized, so I lost a few points remembering what feature belonged with each center. Not a lot of points, but enough to make me go hmmmm…. Not a fan of scoring essentially a B+ on a fundamentals exam that I should be able to smoke handily. I did take some prep courses, such as the ACloudGuru exam prep course. The instructor was funny and informative, but is is still a high level over view and missed all the fiddly stuff I had trouble with on the exam. I also reviewed the Microsoft Learn pages, which got me closer, but still wasn’t enough for a 100% pass.

So, good run through for the next exam I’ll attempt, the AZ-104 (Azure Administrator) in three weeks. I’ve been taking PluralSight, LinuxAcademy, and MS Learn content, plus the practical stuff I done in my Azure subscription as well as at work, and yet I still don’t feel like I am ready. Probably over thinking it….

My Azure Learning

As the new job requires me to be proficient in Azure and Terraform, I took the opportunity to practice deploying resources and taking notes. It’s been really interesting and is an ongoing effort, as I prepare for the first of 5 certifications in Azure. If you are interested, check out my Github repo.

Gigging as a contractor, those days are over…

The last two years as an IT contractor have been really intense, with both of my contracts ending early and giving that uneasy unemployed feeling. My last assignment with a major media company has been a great opportunity to get exposed to lots of design patterns and best practices. Life as a systems reliability engineer was exactly what I needed to see what operating at scale under enterprise conditions. I got an opportunity to get better at terraform and cloudformation, use chef and gitlab-ci, build containers and deploy them to a kubernetes cluster in AWS. Just brain meltingly  cool stuff!

Sadly, the pandemic shut down my time as an SRE prematurely, so back into the world of job hunting. Very scary, as the day I got my layoff notice the recruiters stopped calling because the talent pool became an ocean, so many IT people were being let go. My SRE team got cut 40%, and others I thought would be critical an un-cut-able are looking for work.

Luckily, I had maintained contact with a friend from a previous contract (at yet another major media company), and he turned me onto an opportunity in financial technology. I’m now working as devops engineer (I know, it’s not a job title, but it is here)
 in Azure for a well known bank. That is something of a sea change for me, but I’m looking forward to it, and it is a proper J.O.B. and not a contract, so that is pretty nice to have some semblance of security.  I’m certainly blessed and grateful to be so lucky in this these times of trial. Watching the Linkedin and Twitter has been really depressing for the last 3 months, as so many of my peers are scrambling to keep working while tech companies fold all around us. Time to focus, improve my skills, and keep swinging for the fences.

SSM Parameter Store

As part of my disaster recovery process, I make a daily AMI snapshot of the servers and copy it to my disaster recovery target region. As that AMI ID changes each day, I need a way to get the current day’s ID into my CloudFormation template so that AMI can be used when creating a copy of our server in the new region. Short of having to use python and Lambda to discover the AMI ID and recreate the template, there had to be a better way to do it.

Enter Parameter Store.

This is an AWS service that acts like a region bound scratchpad, where you can store data and have it retrieved from a few other services, one of which is CloudFormation.

My first step is to create the AMIs and store their IDs in SSM:

# snippet, local_ami_list is list of local instances and names with date pre-pended.
# this section creates the AMIs, tags them, and adds to a list for copying to DR
for line in local_ami_list:
    image_data_combined_list = line.split(',')
    #pprint(image_data_combined_list)
    local_instance_id = image_data_combined_list[0]
    local_instance_name = current_date_tag + '-' + image_data_combined_list[1]
    image = ec2_local.create_image(InstanceId=local_instance_id, Description=local_instance_name, DryRun=False,
                                    Name = local_instance_name, NoReboot=True)
    tag_image = ec2_local.create_tags(Resources=[image['ImageId']], Tags=[{'Key': 'Name', 'Value': local_instance_name},])
    entry = local_instance_name + ',' + image['ImageId']
    ami_list_to_copy.append(entry)

sleep(90)

# this snippet copies the AMIs to the DR region

for line in ami_list_to_copy:
    ami_list_combined_data = line.split(',')
    local_ami_name = ami_list_combined_data[0]
    local_ami_id = ami_list_combined_data[1]
    try:
        image_copy = ec2_dr.copy_image(Description=local_ami_name, Name=local_ami_name, SourceImageId=local_ami_id,
                                        SourceRegion=local_region, DryRun=False)
        entry = local_ami_name + ',' + image_copy['ImageId']
        dr_ami_list.append(entry)
# this snippet is a bit of kludgy hack, but it gets me in the ballpark. Anonymized for my protection

# 5. lists amis in dr region and writes the current day to SSM parameters for further use in cf-scripts

sv1_ami_parameter = '/org/env/ec2/ServerName1/ami'
sv2_ami_parameter = '/org/env/ec2/ServerName2/ami'
sv3_ami_parameter = '/org/env/ec2/ServerName3/ami'
sv4_ami_parameter = '/org/env/ec2/ServerName4/ami'
sv5_ami_parameter = '/org/env/ec2/ServerName5/ami'
current_ami_list = []

ssm_dr = boto3.client('ssm',region_name=dr_region)
dr_amis = ec2_dr.describe_images(Owners=['self'])
for ami in dr_amis['Images']:
    match = re.search(current_date_tag, str(ami['Name']))
    if match:
        entry = str(ami['Name']) + ',' + str(ami['ImageId'])
        current_ami_list.append(entry)

for ami in current_ami_list:
    line = ami.split(',')

    match1 = re.search('ServerName1', line[0])
    match2 = re.search('ServerName2', line[0])
    match3 = re.search('ServerName3', line[0])
    match4 = re.search('ServerName4', line[0])
    match5 = re.search('ServerName5', line[0])
    if match1:
        set_parameter = ssm_dr.put_parameter(Name=sv1_ami_parameter,
                                            Value=line[1],
                                            Type='String',
                                            Overwrite=True)
    elif match2:
        set_parameter = ssm_dr.put_parameter(Name=sv2_ami_parameter,
                                            Value=line[1],
                                            Type='String',
                                            Overwrite=True)
    elif match3:
        set_parameter = ssm_dr.put_parameter(Name=sv3_ami_parameter,
                                            Value=line[1],
                                            Type='String',
                                            Overwrite=True)

    elif match4:
        set_parameter = ssm_dr.put_parameter(Name=sv4_ami_parameter,
                                            Value=line[1],
                                            Type='String',
                                            Overwrite=True)

    elif match5:
        set_parameter = ssm_dr.put_parameter(Name=sv5_ami_parameter,
                                            Value=line[1],
                                            Type='String',
                                            Overwrite=True)

As you can see, the set_parameter function of the boto3 ssm client module puts the data as a plain text value. To retrieve it in a cloudformation script, you have to reference it:

Parameters:

  sv1:
    Description:  'pre-baked AMI copied from ops region, ID retrieved from SSM Parameter Store'
    Type: 'AWS::SSM::Parameter::Value<String>'
    Default: '/org/env/ec2/ServerName1/ami'

# then reference it in the Resources ec2 instance code block as the ImageId.

No more hard coded values, or a need to dynamically generate the script on a daily basis.

You can encrypt values and store them as SecureStrings. However, to retrieve them you will need an understanding of the version number, and I’ve yet to figure that out. Once I do that, then I can more securely store usernames and passwords and avoid hard coding them. So, very cool indeed! (And now I know the answer to an interview question that I bombed!)

First Jenkins success build disaster recovery stacks

Now that I have most of the disaster recovery scripts built (still testing and solving little issues, but getting close!), I thought I’d give Jenkins a try. I’ve built a freestyle job and used the AWS CloudFormation plugin, pointed it at the root stack in S3, and voila! It builds. A couple of things to figure out:

  • I’m not having any luck auto-building from commits. I need to work out a process that will take the steps of pulling the code, and syncing it to my S3 bucket so that Jenkins can build it.
  • As I am using a jenkins container, I don’t have the awscli installed and can’t script the commands. So far, building my own jenkins install with all the tools built seems the way to go, but if there are CloudFormation plugins, there should be something similar to what I need. That, or build it myself (hmm…..).
  • I can’t get an update to work through Jenkins. The build throws an error about a badly formatted template when I try an update, but that update works fine if I do a manual stack update. I I delete the stack and build again, it works fine. Weird….

So, so more troubleshooting ahead. I’m still working on why the load balance instances keep initializing and then get replaced, I think it is a health check setting… Back at it!

python : amiCreateCopyRotate.py

This script creates  an AMI of each running instance, tags them with a datestamp, copies them to a disaster recovery region, and trims images that are 7 days old. This script needs some refactoring, but works at the moment. I think I would like to decouple it a bit so that the sleep timers can be removed.

#!/usr/bin/python

import boto3
import botocore
from datetime import datetime, timedelta
from time import sleep
import re

# variables

local_region = 'us-west-2'
dr_region = 'us-east-1'

current_date = datetime.now().today()
last_week = current_date - timedelta(days=7)
current_date_tag = str(current_date.strftime("%Y-%m-%d"))
last_week_date_tag = str(last_week.strftime("%Y-%m-%d"))

local_ami_list = []
dr_ami_list = []
ami_list_to_copy = []

ec2_local = boto3.client('ec2', region_name=local_region)
ec2_dr = boto3.client('ec2', region_name=dr_region)


# 1. pull list of running instances in us-west-2

try:
    local_instances = ec2_local.describe_instances()
    for key in local_instances['Reservations']:
        for instance in key['Instances']:
            if instance['State']['Name'] == 'running':
                local_instance_id = instance['InstanceId']
                local_instance_tags= instance['Tags'][0]
                local_instance_name = str(local_instance_tags.get('Value'))
                entry = local_instance_id + ',' + local_instance_name
                local_ami_list.append(entry)
            else:
                pass

except botocore.exceptions.ClientError as error:
    print('error: {0}'.format(error))


# 2. Creates an AMI of each instance and tags it with the current date and name

for line in local_ami_list:
    image_data_combined_list = line.split(',')
    #pprint(image_data_combined_list)
    local_instance_id = image_data_combined_list[0]
    local_instance_name = current_date_tag + '-' + image_data_combined_list[1]
    image = ec2_local.create_image(InstanceId=local_instance_id, Description=local_instance_name, DryRun=False,
                                   Name = local_instance_name, NoReboot=True)

    entry = local_instance_name + ',' + image['ImageId']
    ami_list_to_copy.append(entry)

sleep(90)


# 3. Copies the AMIs to the DR region us-east-1

for line in ami_list_to_copy:
    ami_list_combined_data = line.split(',')
    local_ami_name = ami_list_combined_data[0]
    local_ami_id = ami_list_combined_data[1]
    try:
        image_copy = ec2_dr.copy_image(Description=local_ami_name, Name=local_ami_name, SourceImageId=local_ami_id,
                                       SourceRegion=local_region, DryRun=False)
        entry = local_ami_name + ',' + image_copy['ImageId']
        dr_ami_list.append(entry)

    except botocore.exceptions.ClientError as error:
        print('error: {0}'.format(error))

sleep(90)


# 4. Pulls a list of current private AMIs in us-west-2 and drops AMIs that are tagged 7 days older

local_amis_to_prune = ec2_local.describe_images(Owners=['self'])
local_amis = local_amis_to_prune['Images']
for ami in local_amis:
    entry = str(ami['Name']) + ',' + str(ami['ImageId'])
    match = re.search(last_week_date_tag,entry)
    if match:
        ec2_local.deregister_image(ImageId=ami['ImageId'])
        #print('deleting: ', ami['Name'])
    else:
        pass
        #print('not deleting', ami['Name'])

# 5. same for dr region

remote_amis_to_prune = ec2_dr.describe_images(Owners=['self'])
remote_amis = remote_amis_to_prune['Images']
for ami in remote_amis:
    entry = str(ami['Name']) + ',' + str(ami['ImageId'])
    match = re.search(last_week_date_tag,entry)
    if match:
        ec2_dr.deregister_image(ImageId=ami['ImageId'])
        #print('deleting: ', ami['Name'])
    else:
        pass
        #print('not deleting', ami['Name'])

Ansible vs Tf vs Cf: Disaster Recovery

At this point, I am working on my disaster recovery plan by developing templates of my school’s current resources. I have come to understand that CloudFormation is great if you are only working with AWS resources. Terraform works well with AWS but also with other cloud providers, so if you are multi-cloud or opposed to vendor lock in, then Terraform makes a lot of sense. As for Ansible… I can configure servers with it, but deploying cloud resources is not as easy as I would like, and I think that is why everywhere I interview, CF & TF are for Infrastructure as Code, and Ansible is for configuration management. However, I am still working on replicating my resource stacks in all three languages, just for the practice. Today, I am making some serious headway with CloudFormation.

My first task was to get a sense of what is deployed in my organization’s region. This was greatly aided by CloudFormer. I ran the template for the CloudFormer server, then changed it for a larger instance, since it seemed to be grinding on the size of our DNS record stacks. Once I did that, I walked through the interface and was rewarded with about 7K lines of yaml code that declared everything that was built. I ran it two more times, splitting the DNS records (2700 lines) from the main output file (4600 lines). This gave me a good understanding of what all I had built in the console over the last three years. Now I have a baseline from which to build a copy for another region. I am also considering deploying it in the current region and rebuilding all the resources, then deleting the old resources, clearing out the cruft of experimentation.

The next step was to recreate the VPC stack. This began my first use of the !Ref intrinsic function to refer to the parameters I added to the template:

Parameters:

  EnvironmentName:
    Description: An environment name that will be prefixed to resource names
    Type: String
    Default: DR-Prod

  VpcCIDR:
    Description: Please enter the IP range (CIDR notation) for this VPC
    Type: String
    Default: 10.0.0.0/16

  PublicSubnet1CIDR:
    Description: Please enter the IP range (CIDR notation) for the public subnet in the first Availability Zone
    Type: String
    Default: 10.0.0.0/24

## truncated for example

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCIDR
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Ref EnvironmentName

  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: !Ref EnvironmentName

  InternetGatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC

# subnets
  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 0, !GetAZs '' ]
      CidrBlock: !Ref PublicSubnet1CIDR
      MapPublicIpOnLaunch: true
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName} Public Subnet (AZ1)

# routing
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub ${EnvironmentName} Public Routes

  DefaultPublicRoute:
    Type: AWS::EC2::Route
    DependsOn: InternetGatewayAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PublicSubnet1RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PublicRouteTable
      SubnetId: !Ref PublicSubnet1

## truncated for example

 This also allowed me to use the !Select function to get the availability zones without having to name them explicitly, and the !Sub function to add some variety to my tags.

As I began to build other stacks, such as the security stack, I found that I needed to use dynamically generated values like resource IDs, which lead me to the Outputs section, which I had only ever used to generate a URL as part of a tutorial.


Outputs:
  VPC:
    Description: A reference to the created VPC
    Value: !Ref VPC
    Export:
      Name: VP

  PublicSubnet1:
    Description: A reference to the public subnet in the 1st Availability Zone
    Value: !Ref PublicSubnet1
    Export:
      Name: PublicSubnet1

Each named value is then available to other stacks in the region, so you can use the !ImportValue function to retrieve them for your follow on scripts. Here’s part of the security stack, which handles security groups and ingress rules. Later I’ll add a NACLs set, which will be good practice for my Networking Specialty exam coming up.

Description: "This template applies the network security stack, implementing security groups, egress and ingress rules, network access control lists, sets up the bastion host, and applies the NAT and route rules for the private subnets."


Resources:

# security groups and ingress rules

# mdm security groups
  sgMdmProd:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Mdm server in production
      VpcId: !ImportValue VPC
      Tags:
      - Key: Name
        Value: MdmProd

# all access 8443
  ingressMdmProd01:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !Ref sgMdmProd
      IpProtocol: tcp
      FromPort: '8443'
      ToPort: '8443'
      CidrIp: 0.0.0.0/0

# ldap 389 only to ldap server
  ingressMdmProd05:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId: !Ref sgMdmProd
      IpProtocol: tcp
      FromPort: '389'
      ToPort: '389'
      SourceSecurityGroupId: !Ref sgOdProd
      SourceSecurityGroupOwnerId: '<redacted>'

# truncated for examples

I exported my security groups so they could be used by other scripts that create resources which require security groups. The best part about having the network stack separate is that I can look at it closely and make sure there are no extraneous rules, and that no traffic is incoming from anywhere I don’t want.

As my list of stacks got larger and larger, I learned about nested stacks and DependsOn conditions. This is my root stack example:

AWSTemplateFormatVersion: '2010-09-09'
Description: "disaster recovery / automatic failover"

Resources:
  DrVpc:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.amazonaws.com/<redacted>/DrVpc.yaml
      TimeoutInMinutes: '5'
  
  DrSecGroupRules:
    Type: AWS::CloudFormation::Stack
    DependsOn: DrVpc
    Properties:
      TemplateURL: https://s3.amazonaws.com/<redacted>/DrSecurityRules.yaml
      TimeoutInMinutes: '5'

  DrRds:
    Type: AWS::CloudFormation::Stack
    DependsOn: DrSecGroupRules
    Properties:
      TemplateURL: https://s3.amazonaws.com/<redacted>/DrRds.yaml
      TimeoutInMinutes: '20'

Normally, CloudFormation will try to build all the stacks at the same time. If one stack requires the IDs of resources from another stack, the DependsOn directive will cause CloudFormation to wait to create that stack until after the required stack is finished.

The TimeoutInMinutes property value was so that I would not wait an hour for a stack to fail. I had a situation where a resource in the Vpc stack was not getting created, but not failing. I think the default wait time in CloudFormation is 60 minutes before declaring a failure ( I think that was a test question somewhere), so I lowered it to reduce the suspense. As I tested each stack individually, I took note of how long it took to build each stack of resources, and set my timeouts accordingly. The RDS stack took the longest, with each database taking about 5 minutes to spin up, which is important to know 🙂

At present, I have stacks for VPC, security, load balancers, EFS volumes and databases. I’m working on the individual server stacks, trying to figure out how to get the necessary data from the backups to the EFS volumes and the databases. I may have to build some lambda functions to auto copy AMIs over and update the scripts with the AMI IDs. That bears some consideration, and probably some googling 🙂

My disaster recovery drill is scheduled for Friday night, so I have three more days to finish these CloudFormation templates. We’ll see how it goes, and as I learn about helper functions and init scripts I’ll post it here. Once the CF scripts are done, time to do it all over again in Terraform!

Passed the DevOps Pro exam!

I just got back from taking the test, and I am so relieved. That test was much harder than the Solutions Architect Pro exam, and even though I’ve been reading and practicing for a month, I didn’t score as high as I would have liked. Since I haven’t had the need to use Elastic Beanstalk and OpsWorks yet, I had trouble with the highly detailed questions about those services. The test was even more challenging than the practice tests on Whizlabs, so while they were useful for practice, the practice tests were no guarantee.

The testing conditions were much better this time, everything was snappy and no construction noise. There was an accident on the freeway that kept me parked for 30 minutes, which I used to review. The rain was pretty intense, worse when I got out. Definitely grateful to have made it to the testing center in one piece, and to have been able to study and pass this certification. Now, on to Jenkins and Ansible certs! 

Ansible vs Terraform vs CloudFormation

Studying for my AWS professional certifications introduced me to the wonderfully difficult to read world of JSON and CloudFormation templates. Once I discovered you can write them in YAML they became a bit less intimidating, and on the whole pretty amazing. CF templates were my first introduction to Infrastructure as Code, and it has been a lot of fun trying auto reproduce my school’s infrastructure in another region using them. I also had a chance to work with them on my log aggregation project, and wrote a template to install my log transport function, which was pretty cool.

I picked up Terraform as I was applying for a job which had it as a requirement, and I found it easier to pierce than CF templates, mainly because the syntax and variables were easier to read than straight JSON ( I didn’t know about YAML CF templates till later), and I could comment the terraform templates easily, where you can’t comment a JSON file. So, most of my IoC scripts are in Terraform.

I just started working with ansible to solve a server deployment issue at my school where I am deploying a container cluster. I seized on ansible to manage the configurations, and it made deploying the 5 servers a snap.

What I didn’t realize at the time is that ansible can be used for so much more than configuration management. To paraphrase an old Steve Martin joke, it’s like ansible has a module for everything! I had a friend, who uses ansible in production, take a look at my first playbook, and he showed me that instead of treating it like a glorified init script, ansible could create resources and deploy containers as easy as terraform and cloudformation.

Mind blown!

So, my challenge is to create all of my IoC code in each flavor (ansible, terraform and cloudformation) and build automation pipelines for each. As I get them built and tested, I’ll post anonymized versions here. What an adventure!