, , , ,

Best Practices: Ansible

This entry is part 2 of 4 in the series Best Practices

Synopsis

This technical guide provides a detailed overview of best practices for working with Ansible in a busy DevOps team. It covers important concepts such as idempotency and how to secure sensitive information using Ansible Vault. The guide also includes information on how to organize Ansible code in a git repository and best practices for committing changes to a repository.

Summary

This technical guide provides best practices for working with Ansible in a busy DevOps team. It covers important concepts such as idempotency and how to use Ansible Vault to secure sensitive information. The guide also includes information on how to organize Ansible code in a git repository and best practices for committing changes to a repository.

Introduction

Ansible is a popular tool for automating the configuration and management of systems. In a busy DevOps team, it is important to follow best practices when working with Ansible to ensure that the codebase is maintainable and easy to work with.

One key concept to keep in mind when working with Ansible is idempotency. An idempotent operation is one that has the same result whether it is performed once or multiple times. In other words, if an operation is idempotent, it will not change the system
state if it is run multiple times with the same parameters. This is important in Ansible because it allows you to run plays multiple times without causing unintended changes to the system.

To ensure idempotency in ansible, it is important to use the state parameter in tasks. The state the parameter allows you to specify the desired state of a resource, such as whether a package should be installed or uninstalled. Using the state parameter ensures that ansible will only make changes to the system if the specified state is not already met.

Another important aspect of working with ansible is securing sensitive information. It is important to not store sensitive information such as passwords and access keys in plaintext in the ansible codebase. Instead, you can use ansible vault to encrypt sensitive information and store it securely. To use ansible vault, you can create a vault file and use the ansible-vault command to encrypt and decrypt the file as needed.

It is also important to consider how to organize ansible code in a git repository. One way to do this is to create a separate directory for each environment, such as production, staging, and development. This can make it easier to manage and track changes to the ansible codebase.

When committing changes to a git repository, it is important to follow best practices for commit messages and branch names. Commit messages should be concise and describe the changes made in the commit. Branch names should be descriptive and follow a consistent naming convention.

In addition to following best practices for commit messages and branch names, it is also important to use tickets to track development updates. Tickets should include a clear description of the work to be done and any relevant details such as links to relevant resources or dependencies.

Conclusion

By following best practices such as ensuring idempotency and securing sensitive information using ansible vault, and organizing ansible code in a git repository in a structured way, DevOps teams can effectively work with ansible to automate the configuration and management of systems. By following these guidelines, teams can ensure that their codebase is maintainable and easy to work with, enabling them to deliver new features and updates more efficiently.

/by
, , , , ,

Best Practices: Packer

This entry is part 1 of 4 in the series Best Practices

Synopsis

This technical guide provides a detailed overview of best practices for working with Packer in a busy DevOps team. It includes information on concepts such as idempotency and naming standards, as well as code examples and templates for organizing Packer code in a git repository. The guide also covers considerations for security and provides templates for a README file, HCL file, and .gitignore file for a Packer repository.

Summary

This technical guide provides best practices for working with Packer in a busy DevOps team. It covers important concepts such as idempotency and naming standards, as well as providing code examples and structured into appropriate sections. The guide also includes information on how to organize Packer code in a git repository, including considerations for security, as well as templates for a README file, HCL file, and .gitignore file for a Packer repository.

Introduction

Packer is a popular tool for automating the creation of machine images. In a busy DevOps team, it is important to follow best practices when working with Packer to ensure that the codebase is maintainable and easy to work with.

One key concept to keep in mind when working with Packer is idempotency. An idempotent operation is one that has the same result whether it is performed once or multiple times. In other words, if an operation is idempotent, it will not change the system state if it is run multiple times with the same parameters. This is important in Packer because it allows you to run builds multiple times without causing unintended changes to the system.

To ensure idempotency in Packer, it is important to use the only and except parameters in the provisioner block. The only and except parameters allow you to specify the conditions under which a provisioner should run, such as the operating system or the type of machine image being built. Using these parameters ensures that Packer will only run a provisioner if the specified conditions are met.

Naming standards are another important aspect of working with Packer in a busy DevOps team. It is a good idea to use consistent naming conventions for Packer templates and variables to make the codebase easier to read and understand.

Code Examples

Here is an example of a Packer template that follows a consistent naming convention:

{
  "variables": {
    "aws_access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
    "aws_secret_key": "{{env `AWS_SECRET_ACCESS_KEY`}}",
    "aws_region": "us-east-1"
  },
  "builders": [
    {
      "type": "amazon-ebs",
      "access_key": "{{aws_access_key}}",
      "secret_key": "{{aws_secret_key}}",
      "region": "{{aws_region}}",
      "source_ami": "ami-0f2176987ee50226e",
      "instance_type": "t2.micro",
      "ssh_username": "ec2-user",
      "ami_name": "packer-example {{timestamp}}"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "sudo yum update -y",
        "sudo yum install -y nginx"
      ]
    }
  ]
}

In this example, the variables are named aws_access_key, aws_secret_key, and aws_region, and the Packer template is named packer-template.json.

Organizing Packer Code in a Git Repo

When working with Packer in a busy DevOps team, it is important to organize the codebase in a way that is maintainable and easy to work with. One way to do this is to split the Packer code into different files and directories within a git repository.

One way to organize the Packer code is to separate the provisioners, builders, and variables into different files. This can make it easier to find and modify specific parts of the codebase. For example, you could create a provisioners directory to store all of the provisioner scripts, a builders directory to store the Packer templates, and a variables directory to store the variable definitions.

It is also important to consider security when organizing the Packer code in a git repository. Sensitive information such as access keys and secrets should not be stored in the repository in plaintext. Instead, you can use tools such as Hashicorp’s Vault to securely store and manage sensitive information.

Template README.md for a Packer Repo:

# Packer Repository

This repository contains Packer templates and scripts for building machine images.

## Directory Structure

The repository is organized as follows:

- `builders`: Packer templates for building machine images
- `provisioners`: Scripts for provisioning machine images
- `variables`: Variable definitions for Packer templates

## Usage

To build a machine image using a Packer template, run the following command:

```bash
packer build -var-file=variables/example.json builders/example.json
```

Replace example.json with the appropriate file names for your build.

## Contributing

To contribute to this repository, follow these steps:

+ Fork the repository
+ Create a new branch for your changes
+ Make your changes and commit them to the new branch
+ Push the branch to your fork
+ Create a pull request from your fork to the main repository

Please make sure to follow the repository's style guidelines and to run any relevant tests before submitting a pull request.

## License

This repository is licensed under the MIT License.

## Template HCL file with Headers Summarized:

## Packer Template

This Packer template is used to build a machine image.

### Builders

The following builders are used in this template:

 + Amazon Elastic Block Store (EBS)

### Provisioners

The following provisioners are used in this template:

 + Shell

### Variables

The following variables are used in this template:

+ `aws_access_key: AWS access key`
+ `aws_secret_key: AWS secret key`
+ `aws_region: AWS region`

### Usage

To build a machine image using this Packer template, run the following command:

```bash
packer build -var-file=variables/example.json template.json
```

Replace example.json with the appropriate file name for your variables.

### Contributing

To contribute to this Packer template, follow these steps:

+ Fork the repository
+ Create a new branch for your changes
+ Make your changes and commit them to the new branch
+ Push the branch to your fork
+ Create a pull request from your

Conclusion

By following best practices such as ensuring idempotency and using consistent naming conventions, and organizing Packer code in a git repository in a structured and secure way, DevOps teams can effectively work with Packer to automate the creation of machine images. By following these guidelines, teams can ensure that their codebase is maintainable and easy to work with, enabling them to deliver new features and updates more efficiently.

/by
, ,

Ansible Introduction Exercise

This entry is part 5 of 5 in the series Learning Ansible

Synopsis

The following guide covers the steps for setting up and configuring an Ansible project using git for source control. It covers the creation of a new git repository, installing and configuring a Python virtual environment, adding requirements to the repository, adding and committing changes to the repository, and configuring pre-commit for automated testing. It also covers basic git workflow principles and best practices, including the use of feature branches, pull requests, and automated testing.

Introduction

Ansible is a powerful tool for automating and managing IT infrastructure. When working with ansible, it is important to follow best practices, including using source control to manage your projects. Git is a popular choice for source control, and in this guide, we will cover how to set up a new ansible project using git.

In this exercise, we will create a new git repository for an ansible project, create a Python virtual environment (venv) to manage dependencies, and configure pre-commit to enforce best practices. We will also cover how to create a requirements.txt file for the repository, and how to exclude the virtual environment from the repository.

Exercise

Create a new git repository, this will be used for an Ansible project

cd $HOME
mkdir projects
cd projects
mkdir ansible-project
cd ansible-project
git init
echo "# ansible Project" > Readme.md
git add Readme.md
git commit -m "Initial commit"
git branch -M main
# Create a new repo in github
git remote add origin git@github.com:{username}/{repo}.git
# Substitute the real values for {username} and {repo} in the command above
git push -u origin main

Create a Python3 virtual environment (venv)

# Create a new virtual environment
virtualenv venv

# Activate the virtual environment
source venv/bin/activate

# Install Ansible
pip install ansible==2.9.7

# Install Pre Commit
pip install pre-commit

# Install Jinja2
pip install jinja2

The Python virtual environment allows us to create an isolated environment for our Python project. This enables us to have a consistent set of packages and versions that are required for the project, regardless of what other packages may be installed on the local machine.

Create a requirements.txt file for the repository

# Run pip freeze to list all the packages that are installed at the moment and their versions
pip freeze

# We want to take note of the main packages and their versions
pip freeze | egrep -i "ansible|pre-commit|jinja2" > requirements.txt

These commands assume that the terminal session that is in use is in an active Python virtual environment. The requirements.txt file will contain a list of the packages and their specific versions that are required for the project. This file is useful for keeping track of the packages that are required for the project, and for reproducing the same environment on other machines.

Add the requirements.txt file to the repository, commit, and push to GitHub

git add requirements.txt
git commit -m "Added python requirements.txt file to repository"
git push origin main

Deactivate the virtualenv

deactivate

The terminal session has now been returned to its previous state, and running a Python command at this point will not use the virtual environment to access modules.

Omit the virtual environment from the git repository

touch .gitignore 
echo "venv" >> .gitignore

Add the .gitignore file to the repository, commit and push to GitHub

git add .gitignore
git commit -m "Added git ignore file"
git push origin main

Note, using two right angle brackets >> will append the entry “venv” to the file .gitignore, if you run the command twice, you will get two entries in your ,gitignore file. If you would like to create and overwrite the file you can use a single right angle bracket e.g. >

Prepare the .pre-commit-config.yaml file

echo -e "repos:\n - repo: https://github.com/ansible/ansible-lint\n rev: stable\n hooks:\n - id: ansible-lint" >> .pre-commit-config.yaml 
echo -e "repos:\n - repo: https://github.com/pre-commit/mirrors-yamllint\n rev: v1.23.0\n hooks:\n - id: yamllint" >> .pre-commit-config.yaml 
echo -e "repos:\n - repo: https://github.com/pre-commit/mirrors-flake8\n rev: v3.8.4\n hooks:\n - id: flake8" >> .pre-commit-config.yaml

The .pre-commit-config.yaml file is used to configure pre-commit

Add the .pre-commit-config.yaml file to the repository, commit and push to GitHub

git add .pre-commit-config.yaml
git commit -m "Added .pre-commit-config.yaml file"
git push origin main

Configure pre-commit to run in the git repository

pre-commit install

Add the pre-commit hooks to the repository, commit and push to GitHub

git add .git/hooks/pre-commit
git commit -m "Added pre-commit hooks to repository"
git push origin main

Verify pre-commit has been installed correctly

Run the following command to confirm that pre-commit is installed correctly:

pre-commit run --all-files

If the installation was successful, you should see output similar to the following:

Checking for added files... 
[INFO] Initializing environment for https://github.com/pre-commit/pre-commit-hooks.
[INFO] Initializing environment for https://github.com/pre-commit/mirrors-ansible-lint.
[INFO] Initializing environment for https://github.com/pre-commit/mirrors-flake8. 
[INFO] Initializing environment for https://github.com/pre-commit/mirrors-yamllint.
[INFO] Installing environment for https://github.com/pre-commit/pre-commit-hooks.
[INFO] Installing environment for https://github.com/pre-commit/mirrors-ansible-lint.
[INFO] Installing environment for https://github.com/pre-commit/mirrors-flake8.
[INFO] Installing environment for https://github.com/pre-commit/mirrors-yamllint. ...

If you receive an error, it may be because pre-commit is not installed correctly. In this case, try uninstalling and reinstalling pre-commit:

pip uninstall
pre-commit
pip install pre-commit

Once pre-commit is installed correctly, you can begin using it to enforce your chosen coding standards and practices.

Conclusion

By following the steps in this guide, you should now have a fully configured ansible project that is ready for development. You should have installed ansible and other required python modules into a virtual environment created a requirements.txt file and set up pre-commit to enforce your chosen coding standards. You should now be able to start developing your ansible project with confidence, knowing that your code will be automatically checked and validated before it is committed to your git repository.

/by
,

Getting Started with Python

This entry is part 4 of 5 in the series Learning Ansible

Synopsis

This guide provides a quick introduction to Python for new developers. It covers the basics of installing and configuring Python, including creating and activating virtual environments. It also covers some best practices for working with Python, including naming conventions and using virtual environments to maintain a consistent environment.

Introduction

Python is a popular programming language known for its simplicity, readability, and flexibility. It is used for a wide range of tasks, including web development, data analysis, and automation. In this guide, we’ll cover the basics of installing and configuring Python so you can get started using it in your own projects.

Best Practices

When working with Python, it’s important to follow some best practices to ensure your code is easy to read, maintain, and debug. Here are a few tips to keep in mind:

  • Use descriptive, snake_case names for files, functions, classes, and variables.
  • Use comments to explain what your code is doing.
  • Keep lines of code to a maximum of 79 characters to make them easier to read.
  • Use whitespace to separate logical blocks of code.
  • Use docstrings to document your functions and classes.

Installation

To install Python on your machine, you can use the following commands:

mkdir -p $HOME/projects/webapp
cd $HOME/projects/webapp
sudo apt update
sudo apt install python3 python3-pip python3-virtualenv

These commands will create a new directory for your projects, navigate to that directory, update your package manager, and install the latest versions of Python, pip, and virtualenv.

Configuration

One of the benefits of using Python is the ability to create and activate virtual environments. A virtual environment is an isolated environment that contains a specific version of Python and its dependencies. This can be useful for keeping your main Python installation clean and for developing multiple projects with different requirements.

To create and activate a new virtual environment, use the following commands:

virtualenv venv
source venv/bin/activate

To install and configure the necessary dependencies for your Python project, you can use the following commands:

pip3 install ansible==2.9.7
pip3 install pre-commit
pip3 install jinja2

These commands will install the specified versions of ansible, pre-commit, and jinja2 in your virtual environment.

You can view a list of all the packages installed in your virtual environment by using the following command:

pip3 freeze

This is useful for creating a requirements.txt file for your project, which lists all the necessary dependencies.

To deactivate your virtual environment, use the following command:

deactivate

It is not necessary for everyone to use virtual environments, but they can be helpful tools for maintaining a consistent environment and isolating different projects from each other.

Conclusion

In this guide, we covered the basics of installing and configuring Python, including creating and activating virtual environments. We also covered some best practices for working with Python, including naming conventions and using virtual environments to maintain a consistent environment. With this foundation, you should be ready to start using Python in your own projects.

/by
,

Setting Up Git with GitHub

This entry is part 3 of 5 in the series Learning Ansible

This article provides a guide for setting up Git on a machine and linking it to a GitHub account. It covers the installation of Git, the generation of SSH keys, and the addition of the public key to a GitHub account. The article also includes instructions for creating a test repository on GitHub and pushing a change to it.

Introduction

It is important to set up a version control system like Git to help you track and manage your code changes. Git is a popular choice for version control and is widely used by developers and organizations around the world. In this guide, we’ll walk you through the steps of installing Git on your machine and setting it up to work with your GitHub account.

Prerequisites

Before you can set up Git, you’ll need to have the following:

  • A GitHub account (sign up for one at github.com)
  • The Windows Subsystem for Linux (WSL) with the Ubuntu 20.04 distribution is installed on your machine.

Install Git

To install Git on your machine, open a terminal or command prompt and type the following command:

sudo apt-get install git

This will install Git on your machine. You may be prompted to enter your password to complete the installation.

Configuration

Once Git is installed, you’ll need to configure it with your username and email address. This will help Git identify you as the author of any changes you make to your code. To set your username and email, type the following commands in your terminal or command prompt:

git config --global user.name "Your Name"
git config --global user.email "youremail@domain.com"

Set Up SSH Keys

In order to securely connect to your GitHub repository from your local machine, you’ll need to set up Secure Shell (SSH) keys. SSH keys are a pair of unique cryptographic keys that are used to authenticate your connection to GitHub.

  1. In your terminal or command prompt, type the following command to generate an SSH key:
ssh-keygen -t ed25519 -C "youremail@example.com"
  1. Press Enter to accept the default file location for the key.
  2. Type a passphrase for your SSH key and press Enter. Make sure to choose a strong, unique passphrase that you will remember.
  3. Type the passphrase again to confirm it and press Enter.
  4. Type the following command to view your public key:
cat ~/.ssh/id_ed25519.pub
  1. Select and copy the entire output.
  2. Go to your GitHub account settings and click on the “SSH and GPG keys” tab.
  3. Click on the “New SSH key” button.
  4. Type a name for your key in the “Title” field (e.g. “My local machine”).
  5. Paste your public key into the “Key” field.
  6. Click on the “Add SSH key” button.

Test Your Connection

To test your connection to GitHub, type the following command in your terminal or command prompt:

ssh -T git@github.com

If you are prompted to “continue connecting,” type “yes” and press Enter. If your connection is successful, you should see a message saying “Hi username! You’ve successfully authenticated, but GitHub does not provide shell access.”

Create a Test Repository

Now that you have Git and SSH set up, you can create a test repository on GitHub and push a change to it.

  1. In the GitHub web interface, create a new repository by clicking on the “New” button in the top-right corner of the page.
  2. Type a name for your repository and click on the “Create repository” button.
  3. Follow the instructions provided by GitHub to push a change to your repository.

The following steps walk through an example of creating a repository and pushing an update over to GitHub

  1. In the terminal or command prompt, navigate to the directory where you want to create your repository.
  2. Type the following commands to initialize your repository, add a file, and commit your changes:
# Initialize the repository
git init

# Add a file to the repository
echo "# test" >> README.md

# Add the file to the staging area
git add README.md

# Commit the file to the repository
git commit -m "first commit"
  1. Type the following command to create a main branch for your repository:
git branch -M main
  1. Type the following command to link your repository to the one you created on GitHub:
git remote add origin git@github.com:adamfordyce11/test.git
  1. Type the following command to push your changes to the main branch of your repository on GitHub:
git push -u origin main

This will push your changes to the main branch of your repository on GitHub. You can verify that the changes were successful by checking the repository on the GitHub web interface.

Conclusion

Congratulations! You have successfully set up Git and linked it to your GitHub account. You are now ready to track and manage your code changes with Git. Make sure to keep your private SSH key and passphrase secure, as anyone with access to them will be able to access your repositories.

/by
,

Setting Up WSL: A Guide

This entry is part 2 of 5 in the series Learning Ansible

This article provides a guide for setting up the Windows Subsystem for Linux (WSL) on a Windows machine. It explains how to install WSL, download a Linux distribution, and set up the preferred distribution (Ubuntu 20.04 in this case). The article also discusses the differences between WSL1 and WSL2 and provides some recommendations for further configuration, such as setting up Visual Studio Code (VSCode) and the Windows Terminal.

Introduction

Windows Subsystem for Linux (WSL) allows users to run a Linux environment on their Windows machines. This can be useful for developers who prefer to work in a Linux environment, as it allows them to use tools like Ansible on their Windows machine without the need for a separate Linux installation.

There are two versions of WSL available: WSL1 and WSL2. WSL1 is the default version and offers the functionality needed for working with ansible. WSL2 offers improved performance and is an option for those who need it.

In this guide, we will go through the steps needed to set up WSL on a Windows machine and install a Linux distribution, specifically Ubuntu 20.04, on top of it.

Installation

  1. Open a Windows command prompt as an Administrator.
  2. Type the following command to install WSL:
wsl --install
  1. Type the following command to list the available distributions and check their status:
wsl --list --online
  1. Set WSL1 as the default version by typing the following command:
wsl --set-default-version 1
  1. Download Ubuntu 20.04 by typing the following command:
wsl --install -d Ubuntu-20.04
  1. Wait for the download to complete.
  2. Restart your PC.

Configuration

  1. Once your machine has restarted, ensure that the WSL kernel is up-to-date by typing the following command:
wsl --update
  1. Shut down WSL by typing the following command:
wsl --shutdown
  1. Open Ubuntu from the Start Menu. This will install the downloaded Ubuntu distribution into WSL and register it with the operating system. You will be prompted to set a password for your Linux environment.

Further Configuration

After setting up WSL and installing a Linux distribution, there are a few additional steps you may want to take to optimize your development environment.

  1. Set up Visual Studio Code (VSCode) and configure it to work with WSL.
  2. Check out the Windows Terminal, a new tool that allows you to work with multiple concurrent terminal windows and link to your Azure account for a seamless cloud shell experience.

For more information on setting up a WSL development environment, see Best practices for setting up a WSL development environment.

Conclusion

By following the steps outlined in this guide, you should now have WSL set up on your Windows machine and have a Linux distribution installed on top of it. This will allow you to work with Linux tools and environments on your Windows machine, making it easier to develop and deploy applications.

/by
,

Setting Up Visual Studio Code (VSCode)

This entry is part 1 of 5 in the series Learning Ansible

This article explains how to install and configure Visual Studio Code (VSCode) on a machine. It discusses some of the features that make VSCode a useful tool for ansible practitioners, such as excellent git integration and support for various programming languages. The article also provides a list of recommended extensions to install in order to optimize the development environment for working with ansible and other tools. The article also mentions the special relationship between VSCode and GitHub, which allows users to open their GitHub projects in a web-based version of the editor.

Prerequisites

Before setting up VSCode, make sure that you have already set up WSL and installed the Ubuntu 20.04 distribution.

Introduction

Visual Studio Code (VSCode) is a popular text editor that offers many useful features for developers. Some of the features that are particularly useful for Ansible practitioners include:

  • Excellent git integration
  • GitHub integration
  • YAML support
  • Python support
  • Integration with WSL/WSL2
  • Built-in terminal

Additionally, GitHub has a special relationship with VSCode that allows you to open any of your GitHub projects in a web-based version of the editor simply by replacing the “www” in the GitHub URL with “dev”. This is a convenient feature that allows you to develop on devices such as iPads and Android tablets that may not have native VSCode support.

Installation

If you do not already have VSCode installed on your machine, you can download the latest version from the following website:

code.visualstudio.com

Run the installer and follow the prompts, accepting the default options.

Configuration

Once VSCode is installed, you can install the following extensions to enhance your development environment:

  • Remote WSL
  • YAML
  • Prettier
  • Ansible
  • Jinja2

For more information on setting up VSCode to work with WSL, see Get started using Visual Studio Code with WSL.

Conclusion

By following the steps outlined in this guide, you should now have VSCode installed and configured on your machine. You should also have the necessary extensions installed to optimize your development environment for working with ansible and other tools. VSCode’s integration with WSL and its various features for working with git and GitHub make it a valuable tool for any ansible practitioner.

/by
, ,

Deploying Infrastructure with Terraform

This entry is part 3 of 4 in the series DevOps

In this article, you will show how to use Terraform to deploy infrastructure in a cloud provider such as AWS, GCP, or Azure. You will cover tasks such as creating and modifying resources, applying configuration changes, and handling dependencies.

Terraform allows you to define the desired state of your infrastructure in a declarative manner, meaning that you only need to specify the resources that you want to create and their desired configuration, and terraform will take care of creating and configuring those resources for you. This can be especially useful when deploying complex infrastructure with many interdependent resources, as terraform can automatically handle the ordering and dependencies between tasks.

Terraform configurations are made up of one or more “resources” that represent the infrastructure resources that should be created. Each resource has a type (e.g., “aws_instance” for an Amazon EC2 instance) and a set of configuration parameters that define the desired state of the resource. Terraform also supports the use of variables, which can be used to parameterize configurations and make them more reusable.

Terraform has a number of built-in features that can be used to manage the lifecycle of infrastructure resources. This includes support for creating and updating resources, as well as destroying resources that are no longer needed. Terraform also has a concept called “providers” which are plugins that implement the logic for creating and managing resources in specific cloud providers or services.

Here is an example terraform configuration that creates an Amazon EC2 instance and an associated security group:

provider "aws" {
  region = "us-west-2"
}

resource "aws_security_group" "my_sg" {
  name        = "my-security-group"
  description = "My security group"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "my_instance" {
  ami           = "ami-0ff8a91507f77f867"
  instance_type = "t2.micro"

  security_groups = [aws_security_group.my_sg.name]
}

This configuration specifies the “aws” provider and the region to use when creating resources. It defines two resources: an “aws_security_group” resource and an “aws_instance” resource. The security group resource has a name and description, as well as ingress and egress rules that allow incoming and outgoing traffic on port 22. The instance resource specifies the AMI to use when creating the instance and the instance type, as well as the security group to use. The security group is referenced using the “aws_security_group.my_sg.name” syntax, which tells terraform to use the name of the “my_sg” security group resource when creating the instance.

When this configuration is applied, terraform will create the security group and the EC2 instance.

/by
, , ,

Introduction to Terraform

This entry is part 2 of 4 in the series DevOps

Terraform is an open-source infrastructure as code tool that allows you to define and manage infrastructure resources in a cloud provider such as AWS, GCP, or Azure. It uses a simple, declarative language called HashiCorp Configuration Language (HCL) to describe the resources that should be created and the desired state of those resources.

One of the key benefits of terraform is that it is cloud-agnostic, meaning that it can be used to manage resources in multiple cloud providers using a single configuration language. This makes it easy to migrate resources between cloud providers or to create multi-cloud environments. It also allows you to use a single tool to manage resources across different cloud providers, rather than having to use separate tools for each provider.

Terraform uses the concept of “providers” to interface with different cloud providers. Each provider is a separate plugin that implements the necessary logic to create and manage resources in a specific cloud provider. Terraform comes with a number of built-in providers, and there are also many third-party providers available that can be used to manage resources in other services and platforms.

Terraform configurations are made up of one or more “resources” that represent the infrastructure resources that should be created. Each resource has a type (e.g., “aws_instance” for an Amazon EC2 instance) and a set of configuration parameters that define the desired state of the resource. Terraform also supports the use of variables, which can be used to parameterize configurations and make them more reusable.

Terraform uses the concept of “workspaces” to allow you to manage multiple environments or configurations within a single configuration. This can be useful for scenarios such as managing multiple stages of a deployment (e.g., development, staging, and production) or for creating resource groups within a single cloud provider account.

Here is an example terraform configuration that creates an Amazon S3 bucket:

provider "aws" {
  region = "us-west-2"
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"
  acl    = "private"
}

This configuration specifies the “aws” provider and the region to use when creating resources. It also defines a single resource of type “aws_s3_bucket” with the name “my_bucket”. The resource has two configuration parameters: the name of the bucket, and the ACL to use when creating the bucket. When this configuration is applied, terraform will create an S3 bucket in the specified region with the specified name and ACL.

/by
, , ,

Introduction to Ansible

This entry is part 2 of 4 in the series DevOps

Ansible is an open-source automation platform that allows you to automate the configuration and management of systems and applications. It uses a simple, human-readable language called YAML to describe the tasks that need to be performed, and it can be used to automate a wide variety of tasks including provisioning and configuration of infrastructure, deploying applications, and managing software and system updates.

One of the key benefits of Ansible is that it is agentless, meaning that it does not require any software to be installed on the target systems in order to manage them. This makes it easy to get started with ansible, as there is no need to install and configure agents or other software on your servers. Instead, ansible relies on the use of SSH to connect to the target systems and execute tasks.

Ansible uses a concept called “playbooks” to describe the tasks that need to be performed. Playbooks are written in YAML and are made up of a series of “plays” that define the tasks to be executed and the systems on which they should be executed. Playbooks can be used to define the desired state of a system or application, and ansible will ensure that the system is configured accordingly.

Ansible also uses the concept of an “inventory” to define the systems that it should manage. The inventory is a list of the systems in your environment and can be defined in a variety of formats including INI and YAML. The inventory can be used to group systems together, making it easy to target specific subsets of systems when running ansible playbooks.

Here is an example ansible playbook that installs and starts the Apache web server on a group of systems:

---
- hosts: webservers
  tasks:
  - name: Install Apache
    yum:
      name: httpd
      state: present
  - name: Start Apache
    service:
      name: httpd
      state: started

This playbook consists of a single play that targets the “webservers” group in the inventory. The play consists of two tasks: the first task installs the Apache web server package using the yum package manager, and the second task starts the Apache service. When this playbook is run, ansible will connect to each of the systems in the “webservers” group and execute these tasks, ensuring that the Apache web server is installed and running on all of the systems.

/by