Skip to main content

Building an instance with CloudFormation

Welcome back and thank you for taking the time to read my blog. After the last few blog posts being about Docker, Kubernetes, and micro-apps, I wanted to switch gears and jump into some cloud based architecture. One of the blessings in disguise/new hotness is IaS (Infrastructure-As-Code). Essentially what IaS allows you to do is something similar to an AMI/OVA/template. However, there is one huge difference. when you create an AMI or a template, that's it. You have your golden image with all of your applications and configurations. What if you want to change things up? You have to recreate an entire golden image, build on it, capture it, etc. Time can add up if you do it often. That's where Infrastructure-As-Code comes into play.

Infrastructure-As-Code allows you to edit your template/AMI/OVA at ANY given time, whether it be a new application, a new file, a new instance size, etc. For our demo, we will be using CloudFormation. This is AWS's IaS solution. Azure has one called Templates. There is another very popular open-source called Terraform by Hashicorp.

The first thing we want to do is log into AWS and go to the CloudFormation panel.


Once we click on that, we will be in the CloudFormation dashboard. We're going to go ahead and click "Create Stack".


Once we hit "Create Stack", you see a few options:

Design template: Allows you to make an architecture diagram, and it puts itself into code for you.
Select a sample template: Selecting a sample template allows you to pull pre-made templates which is convenient instead of re-writing what already exists.
Upload a template to S3: Upload a template you already have saved locally.
Specify an Amazon S3 URL: This allows you to specify a template that you already have saved in S3

Today we're going to keep it simple and select a sample template. This is very helpful because a lot of this are 500+ lines of JSON, so instead of reinventing the wheel, we might as well see what AWS will provide for us.


We're going to go ahead and select the LAMP stack


Once you have the LAMP stack created, we're going to go ahead and click on "View/Edit template in Designer"

This is important because we want to take a look at the template. Chances are, there may be some things we want to edit. I'm going to just post what I edited because no one wants to read me post 500+ lines of JSON :)

I went through my template and edited the following:
1) "DBPassword": I wanted this to be a minimum of 8 characters. The template starts out with a minimum of 1.
2) "DBRootPassword": I wanted this to be a minimum of 10 characters. The template starts out with a minimum of 1.
3) "InstanceType": For instance type "Allowed Values", I want to ensure only t2.small is allowed. You may also want to edit this so not just anyone can create insanely large instances for no reason.
4) "AWSRegionArch2AMI": For this, I chose to just utilize RedHat's 7.5 AMI in the us-east-1 region. Ideally you want to cut this off to your companies approved AMI's and regions.

Below are some screenshots of what I changed.



Next thing we want to do is save the template. For our testing purposes, we will save it locally.



Now let's upload to S3 and click next.


Fill in your specified information.


For the next screen called "options", fill in any specific IAM roles, tags, or alarms you'd like on your CloudFormation stack.

At the "review" page, go ahead and review your entries and click next. You will see the following "creating in progress" status in CloudFormation.


This could take a little while, so grab yourself a coffee and pick up your XBOX One controller.

If all finished well and JSON decided to play nice, you should see the output below!



Your WebsiteURL will be different, but if you click on it, you should see your PHP splash page.


There ya have it folks. You have officially created a server with code! After your excitement and god-like feelings simmer down, remember to turn off your EC2 instance so you don't get charged.

Comments

Popular posts from this blog

DevOps tooling in the Microsoft realm

When I really started to dive into automation and practicing DevOps with specific tooling, there were a few key players. At the time Microsoft was not one of them. They were just starting to embrace the open source world, including the art and practice of DevOps. Since then Microsoft has went all in and the tech giant has made some incredible tooling. Recently I switched to a Microsoft-heavy environment and I love it. I went from AWS/Python/Ansible/Jenkins to Azure/PowerShell/ARM/Azure DevOps. My first programming language was PowerShell so being back in the saddle allowed me to do a full circle between all of the different types of tooling in both worlds. Today I want to share some of that tooling with you.

The first thing I want to talk about is ARM. What is ARM? ARM is a configuration management tool that allows you to perform software-defined-infrastructure. Much like Ansible and Terraform, ARM allows you to define what you want your environment to look like at scale. With ARM, yo…

Monitoring your containers in an AKS cluster with Prometheus

Monitoring and alerting is arguably one of the most important thing in Cloud Engineering and DevOps. It's the difference between your clients stack being up and a client being down. Most of us have SLA's to abide by (for good reason). Today we're going to learn how to spin up Prometheus in an AKS cluster to monitor our applications.

Pre-reqs;
1. Intermediate knowledge of Kubernetes
2. An AKS cluster spun up in Azure

Recently AKS supports Prometheus via Helm, so we'll use that for an automated solution to spin this up. This installs kube-prometheus, which is a containerized version of the application. With raw Prometheus, there are a few things that are needed for the operator;

1. Prometheus: Defines a desired deployment.
2. ServiceMonitor: Specifies how groups of services should be monitored
3. Alertmanager: Defines the operator to ensure services and deployments are running by matching the resource

With kube-prometheus, it is all packaged for you. This means configuri…

Run PowerShell code with Ansible on a Windows Host

Ansible is one of the Configuration Manager kings in the game. With it's easy-to-understand syntax and even easier to use modules, Ansible is certainly a go-to when you're picking what Configuration Management you want to use for your organization. Your question may be "but Ansible is typically on Linux and what happens when I'm in a Windows environment?". Luckily I'm here to tell you that Ansible will still work! I was pleasantly surprised with how easy it is to use Ansible on Windows with a little WinRM magic. Let's get started.

Pre-requisites for this post:
1) WinRM set up to connect to your Windows host from Ansible
2) Ansible set up for Windows Remote Management
3) SSH access to the Ansible host
4) Proper firewall rules to allow WinRM (port 5985) access from your Ansible host to your Windows host
5) Hosts file set up in Ansible that has your IP or hostname of your Windows Server.
6) At least one Linux host running Ansible and one Windows Server host …