Have you, at least partially, adopted AWS CloudFormation to have better management of your Cloud Infrastructure?
Do you feel that your endeavours with CloudFormation get messy and cumbersome to handle?
Do you want to find a better way to handle cloud infrastructure better, without redoing all your work?
These articles are for you if you answer yes to most of the questions!
Hello all! I hope you have had a great week so far! There is a new article published on the Tidy Cloud AWS website about migration from CloudFormation to AWS…
Now it is time to build a service, running in Elastic Container Service (ECS)!
In part 4 of our series, we set up an ECS cluster to run our containers using Fargate, so that we do not need to bother with underlying server infrastructure for the containers. We also added a Task Definition, so that we could manually start the container and get the Apache web server running.
We had a list of goals, which we could cover partially:
Let us now address more points in the goal list, one by one. Since we got the Apache web server running, but had to start it manually. Let us remove that manual step. We can accomplish this by setting up an ECS Service for the web server.
It is now time to create an infrastructure in AWS to run container-based solutions!
We will use the Amazon Web Services (AWS) service Elastic Container Service (ECS) to run an application packaged as a container. We will also put a load balancer in front of it, so that we can run multiple copies of that containerised application and distribute the load among those copies.
This is part 4 in a series of articles about building cloud infrastructure solutions with AWS Cloud Development Kit (AWS CDK). If you have not already read them, I recommend checking out part 1, 2, and 3 as well, which are all on the Tidy Cloud AWS website.
In the previous article, we performed a basic set pf an EC2 virtual machine, using AWS CDK. Our goals were these:
If you have not read the previous article, I recommend you to start with that article first. When you are done there, jump back in here!
The goals in bold were the ones we managed to do in the previous article, so now we have one items on the list left to do - be able to login to the machine via the AWS Console, and still keep the machine private and not reachable from the internet.
If you have not read part 1 in this series of articles, you may want to have a look at that first. , Otherwise, let us get started with defining some AWS infrastructure!
First of all we should create an AWS CDK project. You should already have the CDK command-line tool installed. If not, go to the section about AWS CDK installation (in part 1) first to install the tool, then get back here. We will wait!
First, let us clarify what we want to accomplish here:
However, we will take smaller steps to reach this goal. Our first goal is simply to get an EC2 instance of any type up and running, in any VPC, subnet, availability zone - just get it up.
In part 1 we introduced an AWS CloudFormation feature called Drift Detection, with which we can detect (uncontrolled) changes to the resources we manage via CloudFormation. We showed this in the AWS Management Console.
In this part, we are creating simple scripts to start the drift detection process on our CloudFormation stacks, as well as checking the result of detected drifts on the stacks. This will allow us not only to check on a single stack at a time but also on multiple stacks and multiple regions in one operation.
If you use the principles of infrastructure as code to provision your cloud infrastructure, you get many benefits from it - repeatable, quick, and consistent deployments. You also need to apply discipline in how you update the infrastructure - it has to be through the same infrastructure as code workflow. If anyone modifies the infrastructure through other means, like the AWS Management Console, then all bets are off and you may end up with a mess.
Fortunately, some tools can help to keep your cloud infrastructure tidy. If you use AWS CloudFormation, then you have a feature called Drift Detection which may help you detect when someone changes the infrastructure through other means than CloudFormation. Read further to see how you can use Drift Detection for your benefit.
Are you excited about using AWS Cloud Development Kit (AWS CDK) to define infrastructure-as-code?
Do you think that the AWS CDK project initialization is a bit clunky and does not give you what you need to hit the ground running with a new AWS CDK project?
Do you use Typescript? (by choice or by request)
If most of these have the answer yes, you do want to continue reading this article!
(Photo by ThisisEngineering RAEng on Unsplash)