The one with the Ansible (First playbook #2)


Ok, as I promised, here is the second part of my ansible journey. Previously (Ansible #1) I suggested that you can rent a server for free to follow my series. I hope you did it, because in this article I assume you already have a running remote machine. I have one with ubuntu distribution inside for the purpose of this article. Remember to install python on it, because ansible is dependent on it (ssh to your remote – you can check aws documentation to see how to do it, and if you have ubuntu type sudo apt-get install python-minimal in your console).

At first we need to install ansible on our computer, and check if everything went well. Click the link and follow instructions for your distribution and it’ll be fine

After you installed it you can check if you really did:

ansible --version

Example output (fedora):

config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
python version = 2.7.13 (default, Jun 26 2017, 10:20:05) [GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]

Now you have the tool for managing your remote host, but we need it to know to which machine it should refer. Ansible have its hosts file, that defaults to /etc/ansible/hosts. Open it with sudo privileges and your favourite text editor. I used vi.

sudo vi /etc/ansible/hosts

Now, open your browser and go to your aws console, onto ec2 tab and copy IPv4 public address of your server and paste it to your hosts file. It should look similar to mine (I x’ed part of my IP for privacy)

Save and exit. And as with install, we can check if everything we did went fine. Let’s ping our remote!
You should already know from aws documentation that you can’t connect to your remote without ssh key. I keep my key inside my_keyname.pem file. We will need it to ping our server. If you too have ubuntu on your remote, we need to become remote ubuntu user from ansible. Full command for ping should look like this (given that you have your terminal open in the same directory you have your .pem file in)

ansible all -m ping -u ubuntu --private-key "my_keyname.pem"

-m method is for module we are using to ping the remote.
-u user is for as which user we are connecting with.
–private-key “filename” is to point ansible where it should look for ssh key to connect, you can use ssh-agent ignore it, but I will leave that for you to check out single-handedly.

If output is green and response includes “pong”, you got the connection! Congratulations!

Now let’s use it for something. As an example I will install a small program called “ctop” ( As you can see from its readme page, installation is trivial, so it is a good example to begin with.

Basically we need to do two things to make this work

1. Download ctop
2. Make it executable

Let’s start and create a playbook to provide a task for our host. First let’s create .yml file, e.g. install_ctop.yml. Open it in your favourite editor. Now we need to tell on which hosts we want our tasks to be done, but since we have only one host, we can use “all” argument.

- hosts: all

Line starts with dash sign, because we create a list. For more information about YAML syntax I recommend to look at this site:

Next we need to tell as who we are logging in to our host. Because I have ubuntu and aws automatically creates ubuntu user on it, it looks like this

remote_user: ubuntu

Now the essence of whole playbook – tasks. First we name the task, and let ansible know if we need sudo privileges to do this task

  name: install ctop
  become: yes
  become_method: sudo

And finally we use ansible method, that I found by typing “wget ansible” in google search, and we use arguments given in readme for ctop.

  dest: /usr/local/bin/ctop
  mode: 0555

We defined mode with 0555, to make file readable and executable. If you don’t know what mode to pick when you want your file to be executable/readable/writable I suggest you visit this site: GNU/Linux permissions
If you don’t know what am I talking about here, google chmod and chown, it will ease your pain in Linux environment by a lot 😉

So at the end our first playbook should look like that

- hosts: all
  remote_user: ubuntu
    - name: install ctop
      become: yes
      become_method: sudo
        dest: /usr/local/bin/ctop
        mode: 0555

But let’s say you are afraid you messed up the indentation. No problem, just run your playbook with –syntax-check flag

ansible-playbook install_ctop.yml --syntax-check

And if it outputs the filename instead of error, you are the king of yaml!

Ok, so now we know that its syntax is ok, but what if we still are afraid that this task will ruin our host, because we got it all wrong or we maybe mistyped hosts in which it should run. You just need to add –check flag and it will run the playbook without making any changes to remote.

Ansible-playbook install_ctop.yml --private-key “my_filename.pem” --check

If everything looks fine after all, you can just erase –check flag and make your first ansible dream come true 😉

Remember to ssh to your remote to check if everything went fine, just to cherish the moment, when you feel like a professional DevOps

ctop -v

Example output:

ctop version 0.6.0, build 617b1b2 (version may vary)

Don’t worry if you tried to run ctop without -v flag and it gave you error, it still means you have installed it – you just need to have docker installed for it to run. But that’s another tool for another story 😉

If something went wrong, contact me, we will figure it out together!

Well, It was fun for me and if you feel the same and you want me to help you configure/install something more complicated next time – let me know!

The one with the Ansible (Introduction #1)


So, as I said in a previous post – I like to tinker around gnu/linux stuff. That’s why when I was told that there is a tool called Ansible I really wanted to try it out.

Basically Ansible is really powerful! You can use it when you need to install/configure/deploy something on a remote server more than once. It’s an automation tool. Maybe you are thinking now “oh no, server thingies, even if I want to know about them a little more, I don’t have the money to try it out”. Well, that’s not true – you can register an aws account and rent a free tier ec2 machine and follow my ansible series just for fun.

Ansible has those fancy “Playbooks” that you can basically call its language, well, I wouldn’t call it a language per se, because you are just using slightly modified yaml syntax.

Disclaimer: There is only one requirement to use Ansible for your servers – they have to have python installed (from Ansible 2.2+ python 3 is allright).

you can register an aws (Amazon) account and rent a free tier ec2 machine and follow my ansible series just for fun.

So servers need to have python installed, we need to write tasks in .yml files, but we didn’t say where to put addresses for where we want those tasks to be run.

Besides playbooks there are “Inventory” files where you can set variables needed for your tasks and your servers IPs are no exception here. Syntax for them is easy to grasp, because they are just ini’ish text files.

That’s all for the introduction part!

In the next part, we will configure inventory for ec2 machines that I will run for the purpose of this blog and we will configure/install something just to show you how easy it can be.

If you want something specific to be configured and/or installed from ansible playbooks – please let me know.