I took these notes while ramping up on Python, to be able to contribute to a few Github projects, deploy AWS Lambdas quicker, and use boto3 for quite a few projects. Plus I find it a very light, frictionless, quick and easy scripting language to have in the arsenal. This information can be particularly useful to anyone who is coming from a Java background, and wants to compare and contrast the two languages’ basic constructs and syntax.
After working with Amazon Web Services for a few years, I decided to take Google Cloud Platform for a spin. In this post we will get set up with Google Cloud Platform (GCP), and use the CLI to interact with it for a very basic use case (launch, delete an instance). I will also refer to AWS counterpart(s) as and when it makes sense. The idea is to conceptualize automated creation and teardown of entire environments using the idea of projects in GCP.
Amazon Route53 is a highly available and scalable DNS service. Route53 provides Domain Registrations and Transfers, DNS service to route traffic to the infrastructure (either within AWS or non-AWS), advanced routing policies like weighted and geo, and health check services that can be leveraged to perform traffic routing to different destination in the event of a failure. It provides more flexibility and seamless integration with AWS Services than any other DNS host can.
One of the most common scenarios is the need to send traffic from a site registered at non-Route53 providers to an ELB, which Route53 supports via an Alias Record.
In this post we will discuss moving the DNS - where requests to a domain hosted on a non-Route53 provider would resolve to Route53, and then point to an ELB which could be hosting a web property. However, the destination does not have to be an ELB, it can be any public IP. The other part is that of the Domain Registration itself, which can be transferred to Route53 if needed.
For beginners, Amazon Web Services has a Free Tier, which is very generous. However, as you start to stretch the free tier to it’s limits, it’s good to have billing alerts set up. Essentially you’ll get an email when your bill approaches a certain amount.
Setting up billing alerts uses CloudWatch, which is not really the first service the beginners run into. This post shows how to set up AWS Billing Alerts, with screenshots, so you do not have to be familiar with CloudWatch to set one up. I strongly recommend setting the Billing Alerts up, regardless of free tier - having heard and seen horror stories in the recent past.
In the world of MicroServices, immutable deployments is a highly recommended strategy. It demands that every release get a fresh environment, all the way down to the lowest level - or in case of AWS, the AMI.
An AMI can bundle the base operating system, application server/runtime, scripts, agents, etc. along with a versioned application artifact. In the spirit of Infrastructure as Code, the AMI itself can be versioned as a simple json file, as we will see in this post.
With respect to Automation, creation of the AMI can be triggered as a downstream Jenkins Job, after successful pre-release tests, and can then act as an upstream Job for the Infrastructure Build-out using CloudFormation, or Terraform. Once the infrastructure is built, it can be made live via blue/green, red/black or any other deployment plan.
In this post, we will build an AMI that can be used to launch 100% identical instances in the infrastructure. We will use Packer to build the AMI, and create Jenkins Jobs to simulate a simplified, real-world CI/CD pipeline.