Abstract: Working with an established infrastructure platform includes performing complex deployments requiring careful planning and execution. Static documents, in this case, are unsuitable and can easily result in production incidents. This challenge can be solved by using a custom interactive runbook solution.
Introduction After the initial creation of the infrastructure in the production environments, all subsequent work is devoted to supporting the platform evolution by performing iterative changes. The requirement to do it with minimum downtime can lead to complex multistep deployment procedures, which require thorough planning to avoid production incidents and unexpected platform downtime.
Abstract: A natural evolution of the growing platform is splitting it into almost isolated pieces of the infrastructure deployed from separate TF repositories. These TF repositories contain a lot of similar code, and having a template makes their creation easy and fast, as well as provides additional benefits.
Introduction Having infrastructure monorepo for the whole platform works well in its early life stage but usually creates challenges during its growth.
Abstract: Global infrastructure platform, which uses shared modules, is demanding Terraform to provide a global cache solution for saving disk space and developers’ time, which directly translates to cost savings. Due to the absence of an out-of-the-box solution baked into Terraform, the custom global cache has been developed. It significantly saves time to perform TF init process and dramatically reduces TF cache size by making it shareable across all TF repositories and environments.
Abstract: Working with multiple Terraform repositories can bring some inconveniences due to them using different configurations. This article is devoted to improving developer experience by creating a solution which abstracts away Terraform binary names for Terraform repositories.
Introduction Imagine that your infrastructure lives in a lot of Terraform repositories. Over time, these repositories will start using distinct Terraform versions for different reasons, for example, because different teams own them.
Abstract: This article proposes a simple CD pipeline solution for your applications, which run in AWS Fargate, and uses AWS Developer Tools and ECS. Pipeline design considerations and their architecture are discussed. Necessary changes to the application resources provisioning code are proposed. Source code is provided.
Introduction Note: This article assumes that you have solid experience in AWS Developer Tools, AWS Fargate, Terraform and bash scripting.
In my previous articles I described solutions for:
Abstract: To run containerized applications in AWS Fargate, many resources need to be created. Depending on the requirements, different types of applications (batch, web and L4 applications, as well as services) might need to be run in ECS clusters, which further complicates the solution. In addition to that, you might want to reuse load balancers and other resources in your staging AWS account to give every development team it’s own ECS cluster.