Purpose Of Having Naming Conventions For An Ansible Project

• Consistency: Adopting a naming convention standardizes naming across the project and organization. This makes it easier for developers to switch between projects. Typically, an organization with an infrastructure team will have several Ansible projects and source code repositories. A developer working on one such Ansible project can seamlessly switch to another given a standard naming convention.
• Error Reduction: With improper naming there can be pitfalls. For instance, using hyphens(-) in variable names can cause parsing errors since Ansible might interpret them as the minus operator. Standardizing naming for variables can help avoid collisions.
• Readability: With a standard naming convention, it helps developers to find variables, files and tasks quickly.

Naming Conventions For Ansible Roles And Playbooks

• Role name : use lowercase letters and hyphens to separate words: For example, web-server or database-backup.
• Task file name: user lowercase letters and underscores to separate words. When statements such as include are used, it is convenient to have file names without hyphens. For example: install_web_ubuntu.yml
• YAML file extension: yml instead yaml. To be consistent and succinct.
• Task name: start with a verb: Use an action verb at the beginning of the task name to indicate what the role does. For example, Install Nginx or Configure firewall. Start with a capital letter. No need to end with a period for a few words of task description.
• Variable name: lowercase letters and underscores to separate words. The variable must start with the role name. For example, if the role name is nginx, the variable name should be nginx_default_hostname.

Content Guide

• Always include a README file for the role. Describe in detail how to use the role. Create a table to show the role variables and their defaults.
• Include automated tests using Molecule.

Ansible Prerequisites

Before jumping on to learning Ansible, have a firm grounding in Linux system administration and shell scripting. You can use Ansible for a lot of automation projects. The primary target audience for this blog post are DevOps engineers, IT infrastructure engineers and system administrators who create and manage IT infrastructure to run workloads. A good understanding of YAML is required before starting to write Ansible playbooks. A background in at least one programming language helps. Python programing is not a requirement per se. But Python programming familiarity helps put together some automated testing.

Introduction

The Linux Kernel parameters are settings that can be configured to control the behavior of the Linux kernel. They are typically used to fine-tune system performance or to enable/disable certain features.

Some examples of kernel parameters include:

Memory-related parameters: These parameters control how the kernel manages system memory, including how much memory is allocated to user processes and how aggressively the kernel caches data.

Processor-related parameters: These parameters control how the kernel interacts with the system’s processors, including how it schedules processes and how it handles interrupts.

If you are wondering how to automate the installation and configuration of Jenkins using code, this post is for you.

Jenkins is a popular open source tool to build CI/CD pipelines.

Ansible is a popular open source tool to automate a lot of things in IT, including CI/CD and infrastructure orchestration.

Ansible can be used to deploy applications in the cloud. Ansible is a nice tool to execute steps such as:

This is a blog post in IAC with Terraform series.

IAC stands for Infrastructure As Code. Modern IT infrastructure can be orchestrated using programmatic methods. Terraform is(was?) a popular open source software used to orchestrate infrastructure in the cloud and elsewhere too.

Terraform has the concept of modules. With modules, you can code abstract infrastructure. For example, if you are creating a pattern of infrastructure over and over again, you could abstract the pattern into a Terraform module. Let’s take the example of a web application. It consists of:

Introduction

The article explains how to run your own OpenVPN server. We will create a Certificate Authority Server and an OpenVPN server. We will also generate certificates for the clients. We will also learn how to manage revocation of client certificates using the Ansible roles.

Use the Ansible roles gavika.openvpn and gavika.easy_rsa to install and configure your OpenVPN server.

You can install the OpenVPN server on any public cloud or hosting provider or on-premise servers. The Ansible roles are designed to install the OpenVPN server and a Certificate Authority server.

We are pleased to announce gavika.administrators.

The Ansible role provides a declarative method to create Linux user accounts with administrative privileges. In other words, these users have sudo access without password and are empowered to run all commands on the system.

You might be wondering why you would need a role when you can write a couple tasks yourselves in an Ansible playbook. The reason is, Do Not Repeat Yourself(DRY). Instead of writing such tasks over and over, use the abstraction provided by the role. You just have to write some YAML declaration and be done with it. Moreover, the maintenance is outsourced to an Apache licensed open source software. The role has Molecule tests to boost your confidence.

Short answer: use ipify

ipify provides a simple public address API.

Using the tool, you can determine your public IP address programmatically. If you are using the shell:

curl 'https://api.ipify.org'

Using it in a shell script:

my_ip=$(curl 'https://api.ipify.org' -s)
echo $my_ip

Using the Ansible ipify module:

- hosts: localhost
  vars:
  tasks:
    - name: Get my public IP
      ipify_facts:
        timeout: 20
      delegate_to: localhost
      register: public_ip
    - name: output
      debug: msg="{{ ipify_public_ip }}"

Sample output of Ansible playbook execution:

ansible-playbook ipify.yml 
 [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'


PLAY [localhost] **************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************
ok: [localhost]

TASK [Get my public IP] *******************************************************************************************************************************************************************************************
ok: [localhost -> localhost]

TASK [output] *****************************************************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "49.206.13.205"
}

PLAY RECAP ********************************************************************************************************************************************************************************************************
localhost                  : ok=3    changed=0    unreachable=0    failed=0   

Yesterday, we announced the launch of Ansible role to install and configure AWS CloudWatch Agent.

You might have seen my other open source Ansible roles on Ansible Galaxy and Github.

In the same spirit, the company, Gavika Information Technologies Pvt. Ltd. Bangalore, has started publishing open source projects on Github.
Ansible role to install and configure AWS CloudWatch Agent is the first project. Expect more projects in the future.

These are some guidelines for the Ansible role projects that Gavika follows:

Install the Ansible role gavika.aws_cloudwatchagent via Galaxy

ansible-galaxy install gavika.aws_cloudwatchagent

Create The Playbook File - cw-play.yml :

---
- hosts: all
  become: true
  vars:
  roles:
    - role: gavika.aws_cloudwatchagent

Prepare the AWS CloudWatch Agent configuration

In your variables file, use aws_cloudwatch_agent_config

agent:
    metrics_collection_interval: 60
    run_as_user: "cwagent"
    metrics:
      namespace: "Gavika"
      append_dimensions:
        InstanceId: "${aws:InstanceId}"
      metrics_collected:
        disk:
          measurement:
            - used_percent
          metrics_collection_interval: 60
          resources:
            - "*"
        mem:
          measurement:
            - mem_used_percent
          metrics_collection_interval: 60

In this example, I am using the namespace, Gavika. Feel free to change it. We collect the cpu, disk, diskio, mem and swap metrics. The agent will send these metrics once in 360 seconds.

Ansible comes with a vault feature. It is meant to be used in the context of configuration management. But you can also use it as a standalone simple password vault for your personal or organization’s use.

Initial setup of password vault:

• Create or clone a Git or another SCM repository

git init 

• Create the password vault

ansible-vault create myvault.secret

Type the new master password and confirm, ansible-vault will open your text editor. Type your secrets in the editor and save and quit. To open your vault for viewing or editing in the future, you will need your vault password.