One place for hosting & domains

      Ansible

      Creating and Running your First Ansible Playbook



      Part of the Series:
      How To Write Ansible Playbooks

      Ansible is a modern configuration management tool that doesn’t require the use of an agent software on remote nodes, using only SSH and Python to communicate and execute commands on managed servers. This series will walk you through the main Ansible features that you can use to write playbooks for server automation. At the end, we’ll see a practical example of how to create a playbook to automate setting up a remote Nginx web server and deploy a static HTML website to it.

      Playbooks use the YAML format to define one or more plays. A play is a set of ordered tasks that are arranged in a way to automate a process, such as setting up a web server or deploying an application to production.

      In a playbook file, plays are defined as a YAML list. A typical play starts off by determining which hosts are the target of that particular setup. This is done with the hosts directive.

      Setting the hosts directive to all is a common choice because you can limit the targets of a play at execution time by running the ansible-playbook command with the -l parameter. That allows you to run the same playbook on different servers or groups without the need to change the playbook file every time.

      Start by creating a new directory on your home folder where you can save your practice playbooks. First, make sure you’re in your Ubuntu user’s home directory. From there, create a directory named ansible-practice and then navigate into that directory with the cd command:

      • cd ~
      • mkdir ansible-practice
      • cd ansible-practice

      If you followed all prerequisites, you should already have a working inventory file. You can copy that file into your new ansible-practice directory now. For instance, if you created your test inventory file in an ansible directory in your home folder, you could copy the file to the new directory with:

      • cp ~/ansible/inventory ~/ansible-practice/inventory

      Next, create a new playbook file:

      The following playbook defines a play targeting all hosts from a given inventory. It contains a single task to print a debug message.

      Note: We’ll learn more about tasks in the next section of this series.

      Add the following content to your playbook-01.yml file:

      ~/ansible-practice/playbook-01.yml

      ---
      - hosts: all
        tasks:
          - name: Print message
            debug:
              msg: Hello Ansible World
      

      Save and close the file when you’re done. If you’re using nano, you can do that by typing CTRL+X, then Y and ENTER to confirm.

      To try this playbook on the server(s) that you set up in your inventory file, run ansible-playbook with the same connection arguments you used when running a connection test within the introduction of this series. Here, we’ll be using an inventory file named inventory and the sammy user to connect to the remote server, but be sure to change these details to align with your own inventory file and administrative user:

      • ansible-playbook -i inventory playbook-01.yml -u sammy

      You’ll see output like this:

      Output

      PLAY [all] *********************************************************************************** TASK [Gathering Facts] *********************************************************************** ok: [203.0.113.10] TASK [Update apt cache] ********************************************************************** ok: [203.0.113.10] => { "msg": "Hello Ansible World" } PLAY RECAP *********************************************************************************** 203.0.113.10 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

      You might have noticed that even though you have defined only one task within your playbook, two tasks were listed in the play output. At the beginning of each play, Ansible executes by default an additional task that gathers information — referred to as facts — about the remote nodes. Because facts can be used on playbooks to better customize the behavior of tasks, the fact-gathering task must happen before any other tasks are executed.

      We’ll learn more about Ansible facts in a later section of this series.



      Source link

      How To Define Tasks in Ansible Playbooks



      Part of the Series:
      How To Write Ansible Playbooks

      Ansible is a modern configuration management tool that doesn’t require the use of an agent software on remote nodes, using only SSH and Python to communicate and execute commands on managed servers. This series will walk you through the main Ansible features that you can use to write playbooks for server automation. At the end, we’ll see a practical example of how to create a playbook to automate setting up a remote Nginx web server and deploy a static HTML website to it.

      A task is the smallest unit of action you can automate using an Ansible playbook. Playbooks typically contain a series of tasks that serve a goal, such as to set up a web server, or to deploy an application to remote environments.

      Ansible executes tasks in the same order they are defined inside a playbook. Before automating a procedure such as setting up a LEMP server, you’ll need to assess which manual steps are necessary and the order in which they must be completed to get everything done. Then, you’ll be able to determine which tasks you’ll need and which modules you can use to reach your goals in less steps.

      Modules offer shortcuts to execute operations that you would otherwise have to run as raw bash commands. These are also often used to abstract commands across different operating systems.

      When you created your first playbook in a previous part of this guide, you defined a single task that outputs a message using debug. Let’s have a look at that playbook once again. You can use the cat command to print the contents of that file for examination:

      • cat ~/ansible-practice/playbook-01.yml

      This playbook contains a single task that prints a message in the output of a play:

      ~/ansible-practice/playbook-01.yml

      ---
      - hosts: all
        tasks:
          - name: Print message
            debug:
              msg: Hello Ansible World
      

      Tasks are defined as a list under the name tasks inside a play, at the same level as the hosts directive that defines the targets for that play. The name property defines the output that will be printed out when that task is about to be executed.

      The example task invokes the debug module, which allows you to display messages in a play. These messages can be used to show debug information such as the contents of a variable or the output message returned by a command, for instance.

      Each module has its own set of options and properties. The debug module expects a property named msg containing the message to be printed out. Pay special attention to the indentation (2 spaces), since msg must be a property inside debug.



      Source link

      How To Use Variables in Ansible Playbooks



      Part of the Series:
      How To Write Ansible Playbooks

      Ansible is a modern configuration management tool that doesn’t require the use of an agent software on remote nodes, using only SSH and Python to communicate and execute commands on managed servers. This series will walk you through the main Ansible features that you can use to write playbooks for server automation. At the end, we’ll see a practical example of how to create a playbook to automate setting up a remote Nginx web server and deploy a static HTML website to it.

      Ansible supports the use of variables to better customize the execution of tasks and playbooks. This way, it’s possible to use the same playbook with different targets and environments.

      Variables can come from different sources, such as the playbook file itself or external variable files that are imported in the playbook. Special precedence rules will apply when working with multiple variable sources that define a variable with the same name.

      To see how variables work in practice, we’ll create a new test playbook that will print the value of two variables, username and home_dir. Create a new file called playbook-02.yml in your ansible-practice directory:

      • nano ~/ansible-practice/playbook-02.yml

      Then add the following lines to the new playbook file:

      ~/ansible-practice/playbook-02.yml

      ---
      - hosts: all
        vars:
          - username: sammy
          - home: /home/sammy   
        tasks:
          - name: print variables
            debug:
              msg: "Username: {{ username }}, Home dir: {{ home }}"
      

      Save and close the file when you’re done editing.

      The vars section of the playbook defines a list of variables that will be injected in the scope of that play. All tasks, as well as any file or template that might be included in the playbook, will have access to these variables.

      To try this playbook on servers from your inventory file, run ansible-playbook with the same connection arguments you’ve used before when running our first example. Again, we’ll be using an inventory file named inventory and the sammy user to connect to the remote servers:

      • ansible-playbook -i inventory playbook-02.yml -u sammy

      You’ll see output like this:

      Output

      PLAY [all] *********************************************************************************************************************************************************************************** TASK [Gathering Facts] *********************************************************************************************************************************************************************** ok: [203.0.113.10] TASK [print variables] *********************************************************************************************************************************************************************** ok: [203.0.113.10] => { "msg": "Username: sammy, Home dir: /home/sammy" } PLAY RECAP *********************************************************************************************************************************************************************************** 203.0.113.10 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

      The print variables task will use the debug module to print the values of the two variables we defined in the vars section of the playbook.



      Source link