The more you write code regardless of application or infrastructure, the more you desire to bring the best outcome of your writing when they are running as a realtime entity. And no way to deny that testing helps us to gain our confidence before going for production. So, why leave your infrastructure code without testing? In this blog post, I am going to introduce writing unit tests for your infrastructure in AWS.
Errors are sneaky, often remain hidden, smart and somehow get past no matter they are caused by any human action or any prevailing bug. This error often causes incidents in the running system causing a great negative impact on the team. To avoid the same mistakes in the future it is needed to document them properly which is often referred to as incident postmortem writing.
If you are familiar with IaC then you must have heard about terraform, right? Terraform is an awesome tool letting you to create, destroy, provision and configure your infrastructure as code. When terraform is instructed to run against some of its configuration then it creates a state file in the developer machine. This state file contains infrastructure configuration as applied by Terraform. But if you want to work on the terraform codebase as a team allowing terraform to create state file locally then every member will be in a great dilemma.
After installing Wordpress when you setup application it will create a file named
wp-config.php in the root of the source code. This file contains sensitive informations like database url, username, password and database name. We need mask those values with fake one and replace them with original one before build process. In this post, I will discuss on keeping these values secret with EC2 parameter store and using them in Jenkins pipeline.
Regularly a DevOps has to perform different types of server provisioning, configuration with different architectures for deployment testing, applying and testing IaaC modules or for building dev/stage environment. Terraform is such a tool which helps us to build & manage infrastructure using different cloud vendor API. Ansible is another tool to automate infrastructure configuration changes. In this post, I will discuss on using Terraform and Ansible together to bring infrastructure in desired state quickly.
We write Dockerfile for packaging our application into Docker images. Dockerfile is a set of plaintext instructions with predeclared environment variables. These environment variable contains sensitive information such as username, password, remote database URL, bastion host IP etc. When secret variables will be visible in source code repository then code repository members can see them easily. Obviosuly, we need to tackle this situation! In this post, I will discuss on keeping these values secret in AWS, fetching and using them in docker runtime.
Jenkins is a task server which is highly used in performing CI/CD jobs. AWS CodeBuild is a service for performing source code compilation, build, testing and artifact generation for deployment. We can integrate these two services to scale our build, reduce build time, minimize billing and exploit the combined power of CodeBuild and Jenkins.
Travis CI is another popular CI/CD service which is free for open source projects with limited functionalities. In the free version, unlike Jenkins, Travis CI builds application in a dockerized environment whose underlying architecture can be seen in Travis build log. Travis CI comes with single YAML configuration file where we need specify parameters and configure them to perform successful build and remote deployment. In this topic I will be focusing only on writing Travis CI/CD configuration not signing up Travis CI and integrating it with github source code repository.
Using AWS RDS has added ease of database infrastructure setup and administration. Still as an Ops engineer you need to manage the database log files and archive them to storage. In this post I will discuss backing up RDS logfile to S3 bucket. This post is written not focusing on tight AWS security principles (such as not using AWS CLI key in EC2 instances) rather focused on general ideas to make the backup process succeed.
Docker is a tool for building application image and packer is a tool for creating golden image from single source configuration. So docker images can be built from both docker and packer. If you bake them with Jenkins then application image creation and uploading process to docker image repository (e.g. Docker Hub, ECR) will be automated. In this article, I have provided an infrastructure-as-code example to demonstrate the idea.