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.
Abstract: AWS Developer Tools provide a strong foundation for building CI/CD solutions. This article shows how to add automatic creation/starting and deletion of pipelines on create branch/push and delete branch operations in a CodeCommit source repository. The source code for the solution is included.
Introduction Releasing of SVN pipelines, described in my previous article, had a huge success. This inspired us to create a similar automation solution for projects, migrated from SVN to Git-based AWS CodeCommit repositories.
Abstract: AWS CodePipeline source action is typically used to download source code, which is used in its build action. It is convenient, available out-of-the-box and supports a variety of different code repositories. This article describes a solution to develop a pipeline for almost any source code repository or storage, which is not supported by AWS CodePipeline source action yet. Using the example of SVN pipelines, we will show how to build a working solution for real-life usage with automatic creation/starting and deletion of pipelines, which are triggered by SVN create branch/commit and delete branch operations.