DevOps Posts

New Section! Building Docker Images & ECS Rolling Deployments With AWS CodePipeline

New Docker & ECS Rolling Deployments Section on AWS CodePipeline Step by Step

I am excited to share our newest section in my Udemy bestseller AWS CodePipeline Step by Step course, Building Docker Images & ECS Rolling Deployments With AWS CodePipeline.

If you’ve not joined yet, for the next five days, you can join this course with a best-price coupon special to the launch of the new section using the link below:

https://www.udemy.com/course/aws-codepipeline-step-by-step/?couponCode=CDP-DOCKER-ECS-2022

Our newest section focuses on building your Docker images, publishing them to Docker Hub or Amazon ECR with AWS CodePipeline and AWS CodeBuild, and deploying them to Amazon ECS as rolling deployments** using the direct integration of CodePipeline with ECS. Read more at New Section! Building Docker Images & ECS Rolling Deployments With AWS CodePipeline post.

AWS CloudFormation Stack Policy Conditions: Don't Replace or Delete My DB Instances on Stack Updates

AWS CloudFormation Stack Policy Conditions: Never Replace or Delete My DB Instances on Stack Updates

Stack policies are among the most helpful features of AWS CloudFormation for protecting your stacks from unintended updates. Let’s say that you have an Amazon RDS instance that you manage with AWS CloudFormation. After a while, you change one of its attributes and update your stack. Guess what! The update you considered innocent was not so after all. It replaces your database instance with all the data inside. It’s a nightmare, isn’t it? So, you wish there were a CloudFormation feature preventing this from happening.

Luckily, CloudFormation has stack policies to help you in situations like this. In this post, I will talk about stack policies and how to use them as a supplementary protection mechanism in your stack updates. Read more at AWS CloudFormation Stack Policy Conditions: Don't Replace or Delete My DB Instances on Stack Updates post.

CI vs. CD: What are Continuous Integration, Delivery or Development?

CI vs. CD - Continuous Integration, Delivery or Development

Today, applying CI/CD is one of the most crucial DevOps practices. CI means Continous Integration, whereas CD can be applied as either Continuous Development or Continuous Deployment. Sometimes the terminology may seem confusing and people talking about them often assume that you know them from the beginning. So, as a developer applying CI/CD for years and having launched a course about the native CI/CD solution of AWS, AWS CodePipeline, I may help you understand these DevOps concepts. In this post, I will discuss what CI and CD practices mean and explain their differences. Read more at CI vs. CD: What are Continuous Integration, Delivery or Development? post.

Configuring Amazon EC2 Instances With AWS CloudFormation

Managing Amazon EC2 Instance configurations With AWS CloudFormation

In this blog, I talk about the benefits of defining your infrastructure as code using AWS CloudFormation from time to time. You define the properties of your AWS resources in a template and create a stack from it. When you need an update, you edit your template accordingly and update your stack. Don’t need a resource anymore? Just remove it from your template and update your stack again. Or, delete your stack if you no longer wish to keep any of its resources. In an ideal scenario, you keep your infrastructure code, your CloudFormation templates, in the same repository as your project and use a CI/CD pipeline to deploy it.

You can manage most AWS resources with AWS CloudFormation like this. However, Amazon EC2 instances are somewhat different. Again, you have properties like the subnet, instance type, or security groups of an EC2 instance as in other resource types. But, you also make custom, OS-level changes after creation, such as installing software packages, downloading or configuring files, etc. Besides, you may need to update this configuration later. It is why configuring an EC2 instance with CloudFormation needs more attention, and we have a dedicated section about it in my AWS CloudFormation Step by Step: Intermediate to Advanced course.

In this post, I will summarize how to manage EC2 instances using AWS CloudFormation. Firstly, we will discuss the UserData property. Then, we will continue with AWS CloudFormation helper scripts: cfn-signal, cfn-init and cfn-hup. We will also see the CreationPolicy attribute along the way. So, let’s start! Read more at Configuring Amazon EC2 Instances With AWS CloudFormation post.

Deploying CloudFormation Nested Stacks With AWS CodePipeline & AWS CodeBuild

Deploying AWS CloudFormation Nested Stacks with AWS CodePipeline

AWS CodePipeline provides AWS CloudFormation Create or update stack and Create or replace change set action types to deploy your CloudFormation stacks from your pipeline. If you have joined my AWS CodePipeline Step by Step course, you would remember our example there. We automatically create a staging stack from a CloudFormation template before the manual approval action in our pipeline.

However, AWS CodePipeline’s CloudFormation action types only create stacks from deployable stack templates. Therefore, you cannot deploy your CloudFormation nested stacks with local path template definitions directly without packaging and uploading them to an S3 bucket first. In this post, I will talk about achieving this on an AWS CodePipeline pipeline using AWS CodeBuild. Read more at Deploying CloudFormation Nested Stacks With AWS CodePipeline & AWS CodeBuild post.