Showing posts sorted by relevance for query devops. Sort by date Show all posts
Showing posts sorted by relevance for query devops. Sort by date Show all posts

Wednesday, August 26, 2020

Ansible - Prerequisites Configuration

Introduction

In this post, we will be configuring the prerequisites on the ansible control and all the client machines. All the virtual machines in this series are CentOS 7.5. 

The prerequisites for ansible control are:

  1. Packages - Python and ansible
  2. Users - Ansible user with sudo privileges
The prerequisites for Ansible clients are:
  1. Packages - Python
  2. Users - Ansible user with sudo privileges
After the above steps are executed, we need to configure control and client machines for passwordless SSH login. This part is crucial because our objective is not to have manual intervention and enter passwords for each login but to automate as much as possible.

1. Prerequisites Configuration On Ansible Control

Install required packages.
 [root@anscontrol ~]# yum -y install ansible python
Create ansible user 'devops'.
 [root@anscontrol ~]# useradd devops  
 [root@anscontrol ~]# passwd devops  
 Changing password for user devops.  
 New password:   
 Retype new password:   
 passwd: all authentication tokens updated successfully.  

2. Prerequisites Configuration On Ansible Client

Install required package.
 [root@ansapp ~]# yum -y install python
Create ansible user 'devops'.
 [root@ansapp ~]# useradd devops  
 [root@ansapp ~]# passwd devops  
 Changing password for user devops.  
 New password:   
 Retype new password:   
 passwd: all authentication tokens updated successfully.  

3. Configure Passwordless SSH Configuration

Create public/private rsa key pair for 'devops' user on ansible control.
[devops@anscontrol ~]$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/devops/.ssh/id_rsa): 
Created directory '/home/devops/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/devops/.ssh/id_rsa.
Your public key has been saved in /home/devops/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:AWQwdxuvA+ZsQ/Q0Jm24FK44HLIIKeTOndMiW7HIj/s devops@anscontrol
The key's randomart image is:
+---[RSA 2048]----+
| .  ooO+*        |
|o.   *oBo=       |
|=... .=o+ .      |
|B+oo=*.. o       |
|o*+B..= S        |
|  *.o. . .       |
| o .             |
|  .              |
| ..E             |
+----[SHA256]-----+


Now we copy the above created key to the 'ansapp' SSH server's authorized_keys file for passwordless login.
[devops@anscontrol ~]$ ssh-copy-id devops@ansapp
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/devops/.ssh/id_rsa.pub"
The authenticity of host 'ansapp (192.168.200.19)' can't be established.
ECDSA key fingerprint is SHA256:2hMPl7/RsaNC+sCcyA676pJtPTYyFJADUHDxpzX4Ovk.
ECDSA key fingerprint is MD5:38:6b:10:70:c6:77:a9:69:9f:53:96:4e:a4:8f:15:09.
Are you sure you want to continue connecting (yes/no)? yes
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
devops@ansapp's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'devops@ansapp'"
and check to make sure that only the key(s) you wanted were added.

Now we can login into 'ansapp' without password.
 [devops@anscontrol ~]$ ssh devops@ansapp  
 Last login: Tue Aug 25 13:12:56 2020 from 192.168.200.13  
 [devops@ansapp ~]$ hostname  
 ansapp  
This configuration needs to be completed for each ansible client.

4. Configure Ansible User As Privileged User

Finally we need to configure the above created 'devops' user as a sudo privileged user. This step needs to be done on ansible control as well as the client machines. Here, we are going to demonstrate it on ansible control.
 [root@anscontrol ~]# visudo  
We type the following text to allow 'devops' user to be allowed access to all sudo privileges and no password will be prompted for all commands.
 # Allowing devops user to be super user  
 devops ALL=(ALL) NOPASSWD: ALL  

Conclusion

So, we have finally completed the prerequistes for ansible automation. In the next post we will configure ansible configuration and inventory files.

Friday, September 11, 2020

Ansible - Configuration File and Inventory

Introduction

In this second post from the ansible series, we are going to check and configure the ansible configuration file and also the inventory file. The configuration file is for ansible parameters whereas the inventory file consists of hosts or the ansible client machines.

Ansible Configuration File

Ansible looks for configuration in four locations as listed below. 

  • ANSIBLE_CONFIG (environment variable)
  • ansible.cfg (current directory)
  • ~/.ansible.cfg (home directory)
  • /etc/ansible/ansible.cfg

If ansible configuration is found in the environment variable other configurations will be ignored. The process is similar for all configurations in other locations downwards.

For this series we will be using the second method. 

The working directory:
 [devops@anscontrol ansible]$ pwd  
 /home/devops/ansible  
The configuration file:
 [devops@anscontrol ansible]$ cat ansible.cfg  
 [defaults]  
 inventory = /home/devops/ansible/hosts  
 remote_user = devops  
   
 [privilege_escalation]  
 become = True  
Two sections are listed in the ansible.cfg file. First is the defaults section, where the inventory file and remote user on the client machines are listed. Second is the privilege_escalation section, where we allow the remote user to run commands as a privileged user.

Inventory File

In the ansible.cfg file we have listed the inventory file and named it hosts. So, we have to create a file named hosts with a list of all the ansible clients.

The contents of the hosts file:
 [devops@anscontrol ansible]$ cat hosts  
 [jenkins]  
 192.168.200.11  
   
 [tomcat]  
 192.168.200.12  
   
 [ansible-control]  
 192.168.200.13  
   
 [docker]  
 192.168.200.14  
   
 [kubemaster]  
 192.168.200.15  
   
 [kubenodes]  
 192.168.200.16  
 192.168.200.17  
   
 [nagios]  
 192.168.200.18  
   
 [ansible-clients]  
 192.168.200.19  
 192.168.200.20  
 192.168.200.21  

Listing Hosts

We can finally test our configuration by listing the hosts or ansible clients.
 [devops@anscontrol ansible]$ ansible kubemaster --list-hosts  
  hosts (1):  
   192.168.200.15  
   
 [devops@anscontrol ansible]$ ansible ansible-clients --list-hosts  
  hosts (3):  
   192.168.200.19  
   192.168.200.20  
   192.168.200.21  

In the next post we will run some ad hoc commands.

Sunday, February 28, 2021

Ansible - Ad Hoc Commands

There are two ways of executing ansible commands and making configuration changes in the clients. First is executing ad hoc commands and the second is creating playbooks. In this blog post, we are going to demonstrate the use of ansible ad hoc commands.

Ad hoc commands are useful when we have to execute minor commands without creating playbooks. The syntax of ad hoc command is:

$ ansible <managed host> -m <module> -a 'arguments of the module'

The following example shows the use of ping module. We are pinging the ansible-clients group whose members are ansapp, ansdb and answeb. The ping is successful for all hosts.

 [devops@anscontrol ansible]$ ansible -m ping ansible-clients  
 ansapp | SUCCESS => {  
   "changed": false,  
   "ping": "pong"  
 }  
 ansdb | SUCCESS => {  
   "changed": false,  
   "ping": "pong"  
 }  
 answeb | SUCCESS => {  
   "changed": false,  
   "ping": "pong"  
 }  
The following example shows the use of user module. We have created the user named testuser5 with the shell /bin/false. The user is successfully created in the host ansapp.
 [devops@anscontrol ansible]$ ansible ansapp -m user -a 'name=testuser5 shell=/bin/false'  
 ansapp | SUCCESS => {  
   "changed": true,  
   "comment": "",  
   "createhome": true,  
   "group": 1002,  
   "home": "/home/testuser5",  
   "name": "testuser5",  
   "shell": "/bin/false",  
   "state": "present",  
   "system": false,  
   "uid": 1002  
The following example shows the use of the same user module. But this time we are deleting the above created user named testuser5. The user is successfully deleted in the host ansapp.
 [devops@anscontrol ansible]$ ansible ansapp -m user -a 'name=testuser5 state=absent remove=yes'  
 ansapp | SUCCESS => {  
   "changed": true,  
   "force": false,  
   "name": "testuser5",  
   "remove": true,  
   "state": "absent"  
 }  
The following example shows the use of yum module. We are installing the package named httpd using yum module on the ansible-clients hosts.
 [devops@anscontrol ansible]$ ansible ansible-clients -m yum -a 'name=httpd state=present'  
The following example shows the use of the same yum module. We are removing the package named httpd using yum module on the ansible-clients hosts.
 [devops@anscontrol ansible]$ ansible ansible-clients -m yum -a 'name=httpd state=absent'  

In the next blog posts we will demonstrate playbooks.

Sunday, November 14, 2021

Ansible - Playbooks

Ansible playbooks are used to accomplish complex and repetitive tasks. Playbooks are in YAML format. A playbook is composed of plays. A play executes one or more tasks with each task calling an Ansible module.

YAML format can be tricky and lead to many errors, so we are going to make some changes in vim to eradicate such errors.

[devops@anscontrol ansible]$ cat /home/devops/.vimrc  
set tabstop=2 shiftwidth=2 expandtab autoindent cursorcolumn cursorline  

Playbook is executed in the below format. It also accepts various arguments.

[devops@anscontrol ansible]$ ansible-playbook example.yml

Each Ansible playbook consists of plays. Each play has three sections:

  1. Target - The target hosts.
  2. Variable - Defined variables while running plays.
  3. Task - All the modules to run in order.
Below is an example Ansible playbook.

--- 
-  name: This playbook will create some users (comment of entire playbook)
   hosts: devhosts
   vars:
      version:  latest
   tasks:
   -  name: create a user named user1 - comment of this module only
      user:
        name: user1
        comment: first user
        uid: 3010
        shell: /bin/bash
   -  name: install httpd
      yum:
        name:  httpd
        state:  "{{ version }}"
   -  name: allow http in firewall
      firewalld:
        service: http
        state: enabled

In the above playbook, we have defined the target which are the hosts under the group 'devhosts'. 

The variable 'version' has the value 'latest' which is called in the second task module named 'yum'.

We have defined three tasks:

1. Create 'user1'

Create user named 'user1' with UID '3010' and shell '/bin/bash'.

2. Install package 'httpd'

Install the latest package 'httpd' in the hosts under the group 'devhosts'.

3. Allow 'http' service in the 'firewalld' module.

Change the state of 'http' service to enabled/allowed in firewall.

We can also verify the syntax of a playbook as given below.
[devops@anscontrol ansible]$ ansible-playbook --syntax-check example.yml
No errors should be given in the output from above command.

Now we run the above playbook:
[devops@anscontrol ansible]$ ansible-playbook example.yml

PLAY [This playbook will create some users (comment of entire playbook)] ******************************************************************************************

TASK [Gathering Facts] ********************************************************************************************************************************************
ok: [192.168.116.5]
ok: [192.168.116.4]

TASK [create a user named user1 - comment of this module only] ****************************************************************************************************
changed: [192.168.116.5]
changed: [192.168.116.4]

TASK [install httpd] **********************************************************************************************************************************************
changed: [192.168.116.5]

changed: [192.168.116.4]

TASK [allow http service] *****************************************************************************************************************************************
changed: [192.168.116.5]
changed: [192.168.116.4]

PLAY RECAP ********************************************************************************************************************************************************
192.168.116.4              : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
192.168.116.5              : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
We have successfully run our first playbook.