About this lab

vTeam Specialization Program

Recently I was nominated to join the Pure Storage vTeam Specialization Program for New Stack. The idea behind the program is to provide a community within Pure for Puritans to learn and develop skills and grow into a subject matter expert.

The program consists of training and lab exercises that are focussed on developing experience in the New Stack space (Kubernetes, Ansible, Open Stack and more). And since I think there are more people out there how want to learn more about New Stack, I though I’d blog my progress of the lab exercises.

Lab instructions

The purpose of this lab is to get started on Ansible and run some ad-hoc command.

This should be a very short blog, since the tasks are limited, but I’ve covered some of these steps (installing ansible and copying SSH keys) already in a previous lab.

Install Ansible

There are several ways to install Ansible. Some Linux distributions come with default versions of Ansible as part of their repo, however I always like to run the latest version, so I’ll use the Python Package manager pip.

sudo apt install python3-pip

Once we have python and pip installed, we want to make sure that we are using the latest version of pip:

sudo pip3 install --upgrade pip

And now we are ready to install Ansible:

pip install ansible

Should install Ansible and we can check if it was succesful using:

ansible --version

Password less login

As mentioned earlier, I’ve documented the procedure to setup passwordless login here in the paragraph SSH password less login.

Basically we need to create our private and public key on our local host (control host) using =:

ssh-keygen -t rsa

Then we use the ssh-copy-id to copy our public key to the remote hosts for password less login:

ssh-copy-id 192.168.10.121
ssh-copy-id 192.168.10.122
ssh-copy-id 192.168.10.123

Ansible Ad Hoc

Ansible Ad Hoc is a method to quickly run commands against a remote host. It can be used for example to quickly execute some tasks on multiple hosts, that only need to execute once. In a future lab we’ll start using playbooks which is used for more repetitive actions to run against our hosts.

For this exercise we’re going to execute the Ansible module ping against our Kubernetes nodes, since the ping module allows us to validate if we can connect to the remote host and if Python is installed on the remote host, since Python is required for most Ansible modules. If the ping module is successful, it will return the message pong… nothing more to be said there.

Inventory file

Before we execute our ad-hoc commands, we need to define an inventory file. Inventory files are used by Ansible to target one or more hosts. For example we could create an inventory file with all our servers, so we can execute actions on all server, but we could also define roles that are only applicable to some servers. Here is the inventory file, which I’ll use for this blog:

nano inventory.yaml

all:
  hosts:
    node1:
      ansible_host: 10.21.142.218
    node2:
      ansible_host: 10.21.142.219
    node3:
      ansible_host: 10.21.142.220
  children:
    masters:
      hosts:
        node1:
        node2:

Learn more on the format of the inventory file here. Some highlights about the file:

Line 1 – 8: Here I define the three hosts I’ll be working with, defining a name (node1 – node3) and the IP address for the node (required, since I don’t have internal DNS setup in my lab environment).

Line 9 – 13: Here I define a sub-group of hosts called masters, which only contains node1 and node2.

With this inventory file I can reference all hosts in the inventory by using all or just the sub-group by using masters.

Running PING module ad-hoc

Now that we have defined our hosts, we are able to run PING to check if we’re ready to start using Ansible.

Localhost

First we’ll run ping against our local host (also because that’s one of the success criteria for this lab…):

ansible localhost -m ping 

We run the command ansible to run a ad-hoc command. We specify the pattern of host(s) to target next, where we specified localhost. The localhost does not need to be specified in an inventory file, so we can always run ad-hoc commands directly to our localhost. Finally we use the -m flag to specify we want to run the ping module. Since the ping module does not require any arguments, we do not need to specify the options -a flag. The command should return the following:

localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}

Remote hosts

Now we’ll run the ping module against our remote hosts, for this we need the inventory file we created earlier and we need to specify the hosts to target. Using the following targets all hosts in our inventory file:

ansible all -m ping -i inventory.yaml

The command is similar to what we used earlier, however now instead of localhost we are specifying all to target all of our hosts. In addition we need to specify the inventory file to use, for which we use the flag -i inventory.yaml. Our command yields the following result:

node2 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
node3 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
node1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}

So the ping module was executed successfully on all of our hosts in the inventory file.

Now for fun, lets just run the ping module only against the masters sub- group we defined, just so that we can see that that works as well:

ansible masters -m ping -i inventory.yaml

Much like the previous command we get success messages, however only node1 and node2 are targeted.

node1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}

node2 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}

Conclusion

As I mentioned in the beginning, this is not a long blog, but rather a quick take at Ansible ad-hoc and inventory files.

Thanks once more for reading and see you in the next blog!