<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Ansible &amp;mdash; sandeepk</title>
    <link>https://blogs.dgplug.org/sandeepk/tag:Ansible</link>
    <description></description>
    <pubDate>Sun, 19 Apr 2026 07:47:39 +0000</pubDate>
    <item>
      <title>Ansible: Roles</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-roles</link>
      <description>&lt;![CDATA[Ansible&#39;s roles allow grouping the content, which can be reused and easily share with other users. The role consists of vars, files, tasks, and other artifacts in a standard directory structure which have these subdirectories.&#xA;&#xA;Tasks&#xA;Handlers&#xA;Library&#xA;Default&#xA;Vars&#xA;Files&#xA;Templates&#xA;Meta&#xA;&#xA;We can use roles in the playbook or task with the help of Include and Import. To know more about Import/Include, you can check here&#xA;&#xA;At Playbook level with the At task level with At task level with &#xA;Playbook&#xA;Roles at playbook level are imported statically and executes the playbook in this order&#xA;&#xA;Pre tasks&#xA;Roles listed in the playbook&#xA;Tasks define in the playbook and any handler triggered by the tasks&#xA;Post tasks define after the role&#xA; &#xA;---&#xA;hosts: webservers&#xA;  roles:&#xA;    aws&#xA;&#xA;Task with Include&#xA;---&#xA;hosts: all&#xA;  tasks:&#xA;    name: Use a dynamic roles&#xA;       includeroles:&#xA;           name: rolename  &#xA;Task with Import&#xA;---&#xA;hosts: all&#xA;  tasks:&#xA;    name: Use a static roles&#xA;       importrole:&#xA;           name: rolename  &#xA;&#xA;Passing parameter to the roles&#xA;---&#xA;hosts: all&#xA;  roles:&#xA;    { role: aws, message: &#34;ec2&#34; }&#xA;    { role: aws, message: &#34;s3&#34; }&#xA;&#xA;Conditionally adding roles&#xA;---&#xA;hosts: all&#xA;  tasks:&#xA;    name: Include the somerole role&#xA;      includerole:&#xA;        name: somerole&#xA;      when: &#34;ansiblefacts[&#39;os_family&#39;] == &#39;Ubuntu&#39;&#34;&#xA; &#xA;Ansible&#39;s roles are really helpful to group the similar content and use in the different playbook and give the feasibility to the user to share with other which saves a lot of work. It&#39;s worth using them and shares your roles in the community to help others.&#xA;&#xA;Cheers!&#xA;&#xA;100DaysToOffload&#xA;Ansible]]&gt;</description>
      <content:encoded><![CDATA[<p>Ansible&#39;s roles allow grouping the content, which can be reused and easily share with other users. The role consists of vars, files, tasks, and other artifacts in a standard directory structure which have these subdirectories.</p>
<ul><li>Tasks</li>
<li>Handlers</li>
<li>Library</li>
<li>Default</li>
<li>Vars</li>
<li>Files</li>
<li>Templates</li>
<li>Meta</li></ul>

<p>We can use roles in the playbook or task with the help of Include and Import. To know more about Import/Include, you can check <a href="https://blogs.dgplug.org/sandeepk/ansible-import-and-include" rel="nofollow">here</a></p>
<ul><li>At Playbook level with the <code>roles</code></li>
<li>At task level with <code>include_roles</code></li>
<li>At task level with <code>import_roles</code></li></ul>

<p><strong>Playbook</strong>
Roles at playbook level are imported statically and executes the playbook in this order</p>
<ul><li>Pre tasks</li>
<li>Roles listed in the playbook</li>
<li>Tasks define in the playbook and any handler triggered by the tasks</li>
<li>Post tasks define after the role</li></ul>

<pre><code class="language-yml">---
- hosts: webservers
  roles:
    - aws
</code></pre>

<p><strong>Task with Include</strong></p>

<pre><code class="language-yml">---
- hosts: all
  tasks:
    - name: Use a dynamic roles
       include_roles:
           name: role_name  
</code></pre>

<p><strong>Task with Import</strong></p>

<pre><code class="language-yml">---
- hosts: all
  tasks:
    - name: Use a static roles
       import_role:
           name: role_name  
</code></pre>

<p><strong>Passing parameter to the roles</strong></p>

<pre><code class="language-yml">---
- hosts: all
  roles:
    - { role: aws, message: &#34;ec2&#34; }
    - { role: aws, message: &#34;s3&#34; }
</code></pre>

<p><strong>Conditionally adding roles</strong></p>

<pre><code class="language-yml">---
- hosts: all
  tasks:
    - name: Include the some_role role
      include_role:
        name: some_role
      when: &#34;ansible_facts[&#39;os_family&#39;] == &#39;Ubuntu&#39;&#34;
</code></pre>

<p>Ansible&#39;s roles are really helpful to group the similar content and use in the different playbook and give the feasibility to the user to share with other which saves a lot of work. It&#39;s worth using them and shares your roles in the community to help others.</p>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a>
<a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-roles</guid>
      <pubDate>Wed, 01 Sep 2021 05:16:22 +0000</pubDate>
    </item>
    <item>
      <title>Ansible: Import &amp; Include</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-import-and-include</link>
      <description>&lt;![CDATA[In Ansible playbooks are a collection of different tasks. It&#39;s a good idea to break the tasks into the different files, which make it easier to include/import these task in different playbooks. Now the question is when to use include or import and how these two are different from each other?&#xA;&#xA;Ansible provides four distributed&#xA;Variables&#xA;Task&#xA;Playbook&#xA;Role&#xA;&#xA;Include&#xA;&#xA;Including variables, tasks, or role adds them into the playbook dynamically. This means when Ansible processes these files as they come up they are included in the current playbook as its variable, task, or role. So, these can be affected by the previous tasks.&#xA;&#xA;Playbook&#39;s can not be used with the include&#xA;&#xA;Import&#xA;&#xA;Importing task, playbook, or role add them into playbook statically. Ansible pre-processes these files before it runs any task in the playbook, which means these are not affected by other tasks.&#xA;&#xA;Tip: Import variables if you want to use these more than once in the playbook.&#xA;&#xA;Import and Include differ with the way Ansible loads these files into the playbook. So, it is good to use the one which best fits your use case.&#xA;&#xA;Cheers!&#xA;&#xA;100DaysToOffload&#xA;Ansible]]&gt;</description>
      <content:encoded><![CDATA[<p>In Ansible playbooks are a collection of different tasks. It&#39;s a good idea to break the tasks into the different files, which make it easier to include/import these task in different playbooks. Now the question is when to use <em>include</em> or <em>import</em> and how these two are different from each other?</p>

<p>Ansible provides four distributed
– Variables
– Task
– Playbook
– Role</p>

<p><strong>Include</strong></p>

<p>Including variables, tasks, or role adds them into the playbook <strong>dynamically</strong>. This means when Ansible processes these files as they come up they are included in the current playbook as its variable, task, or role. So, these can be affected by the previous tasks.</p>

<p><em>Playbook&#39;s can not be used with the include</em></p>

<p><strong>Import</strong></p>

<p>Importing task, playbook, or role add them into playbook <strong>statically</strong>. Ansible pre-processes these files before it runs any task in the playbook, which means these are not affected by other tasks.</p>

<p>Tip: Import variables if you want to use these more than once in the playbook.</p>

<p>Import and Include differ with the way Ansible loads these files into the playbook. So, it is good to use the one which best fits your use case.</p>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a>
<a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-import-and-include</guid>
      <pubDate>Mon, 30 Aug 2021 05:26:54 +0000</pubDate>
    </item>
    <item>
      <title>Ansible: Error Handling</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-error-handling</link>
      <description>&lt;![CDATA[Ansible stops executing on the host whenever it receives a non-zero return code from a command. We can handle these situations with the helps of settings and tools to behave as it we want.&#xA;&#xA;Ignoring Errors&#xA;Ansible stops executing commands on the host when it receives non-zero code, but we can ignore these errors and run the rest of the tasks as it is.&#xA;name: I will cause an error&#xA;  ...configs&#xA;  ignoreerrors: yes&#xA;&#xA;Failed when&#xA;Ansible let you define the condition when you want explicitly fail when a certain condition is true.&#xA;name: Fail task under certain condition true&#xA;  command: ls/tmp/dirnotexist&#xA;  register: result&#xA;  failedwhen: result.rc == 0&#xA;&#xA;Aborting on first error&#xA;anyerrorsfatal finishes the  fatal task on all hosts in the current batch, then stops executing on all hosts.&#xA;hosts: somehosts&#xA;  anyerrorsfatal: true&#xA;  tasks:&#xA;    block:&#xA;         includetasks: sometask.yml&#xA;Handling errors with blocks&#xA;Ansible let you control errors in a block with rescue and always section. In rescue, we can define tasks which we want to run when an earlier task in a block fails. You can also think of rescue as except  and always as finally in other languages to handle errors.&#xA;task:&#xA;name: tasks to be run&#xA;  block:&#xA;     name: task 1&#xA;       // code&#xA;     name: task 2&#xA;       // code&#xA;     name: task 3&#xA;       // code&#xA;rescue:&#xA;     name: Run when one of the above task fails&#xA;       // code&#xA;always:&#xA;     name: Always run &#xA;       // code&#xA;&#xA;Ansible provide ignore, rescue, always, failedwhen to easily handle the behavior of playbook when we face any errors. We can use these commands/settings to gracefully record errors and take specific action.&#xA;&#xA;Cheers!&#xA;&#xA;100DaysToOffload&#xA;Ansible&#xA;&#xA;   &#xA;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p>Ansible stops executing on the host whenever it receives a non-zero return code from a command. We can handle these situations with the helps of settings and tools to behave as it we want.</p>

<p><strong>Ignoring Errors</strong>
Ansible stops executing commands on the host when it receives non-zero code, but we can ignore these errors and run the rest of the tasks as it is.</p>

<pre><code class="language-yml">- name: I will cause an error
  ...configs
  ignore_errors: yes
</code></pre>

<p><strong>Failed when</strong>
Ansible let you define the condition when you want explicitly fail when a certain condition is true.</p>

<pre><code class="language-yml">- name: Fail task under certain condition true
  command: ls/tmp/dir_not_exist
  register: result
  failed_when: result.rc == 0
</code></pre>

<p><strong>Aborting on first error</strong>
<em>any<em>errors</em>fatal</em> finishes the  fatal task on all hosts in the current batch, then stops executing on all hosts.</p>

<pre><code class="language-yml">- hosts: somehosts
  any_errors_fatal: true
  tasks:
    - block:
         - include_tasks: sometask.yml
</code></pre>

<p><strong>Handling errors with blocks</strong>
Ansible let you control errors in a block with rescue and always section. In rescue, we can define tasks which we want to run when an earlier task in a block fails. You can also think of rescue as except  and always as finally in other languages to handle errors.</p>

<pre><code class="language-yml">task:
- name: tasks to be run
  block:
     - name: task 1
       // code
     - name: task 2
       // code
     - name: task 3
       // code
rescue:
     - name: Run when one of the above task fails
       // code
always:
     - name: Always run 
       // code
</code></pre>

<p>Ansible provide <em>ignore</em>, <em>rescue</em>, <em>always</em>, <em>failed_when</em> to easily handle the behavior of playbook when we face any errors. We can use these commands/settings to gracefully record errors and take specific action.</p>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a>
<a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-error-handling</guid>
      <pubDate>Fri, 27 Aug 2021 05:31:47 +0000</pubDate>
    </item>
    <item>
      <title>Ansible: Tags</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-tags</link>
      <description>&lt;![CDATA[Ansible&#39;s tags are helpful to run a specific part of the playbook, rather running the whole playbook. Using tags, you can run or skip the tasks.&#xA;&#xA;Tags can be added to one task or multiple tasks or role, block etc. Let see how to do that&#xA;&#xA;Adding tags to a task&#xA;&#xA;  tasks:&#xA;  name: Assign the var&#xA;    apt:&#xA;      name: apache2&#xA;      state: latest&#xA;    tags:&#xA;      vars&#xA;  name: Enable and run httpd&#xA;    apt:&#xA;      name: httpd&#xA;      state: started&#xA;      enabled: &#39;yes&#39;&#xA;    tags:&#xA;      httpd&#xA;      vars&#xA;Adding tags to role&#xA;roles:&#xA;  role: config&#xA;    vars:&#xA;      port: 8003&#xA;    tags: [ web, flask ]&#xA;&#xA;Adding tags to block&#xA;All the tasks in the block will share the same tag&#39;s &#xA;tasks:&#xA;name: git tasks&#xA;  tags: git&#xA;  block:&#xA;  name: install apache&#xA;    apt:&#xA;      name: git&#xA;      state: latest&#xA;&#xA;Special tags&#xA;Ansible have two special tags, never and always. If you add always tag to task, play, Ansible will always run the task or play, unless explicitly asked to skip with the help of (--skip-tags always)&#xA;&#xA;On the other hand, never tag if assign to a task or play, Ansible will skip that task or play unless you explicitly asked it (--tags never).&#xA;&#xA;Running the Playbook with tags&#xA;&#xA;will run tasks with tag git : &#xA;will not run tasks with tag git : &#xA;list all the tags : &#xA;run all tasks, ignore tags (default behavior):  &#xA;run only tasks with either the tag tag1 or the tag tag2: &#xA;run all tasks, except those with either the tag tag3 or the tag tag4: &#xA;&#xA;run only tasks with at least one tag: &#xA;run only tasks with no tags:  &#xA;&#xA;That&#39;s all about the Ansible tags. Now go and tag your tasks :).&#xA;&#xA;Cheers!&#xA;&#xA;100DaysToOffload&#xA;Ansible&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p>Ansible&#39;s tags are helpful to run a specific part of the playbook, rather running the whole playbook. Using tags, you can run or skip the tasks.</p>

<p>Tags can be added to one task or multiple tasks or role, block etc. Let see how to do that</p>

<p><strong>Adding tags to a task</strong></p>

<pre><code class="language-yml">  tasks:
  - name: Assign the var
    apt:
      name: apache2
      state: latest
    tags:
      - vars
  - name: Enable and run httpd
    apt:
      name: httpd
      state: started
      enabled: &#39;yes&#39;
    tags:
      - httpd
      - vars
</code></pre>

<p><strong>Adding tags to role</strong></p>

<pre><code class="language-yml">roles:
  - role: config
    vars:
      port: 8003
    tags: [ web, flask ]
</code></pre>

<p><strong>Adding tags to block</strong>
All the tasks in the block will share the same tag&#39;s</p>

<pre><code class="language-yml">tasks:
- name: git tasks
  tags: git
  block:
  - name: install apache
    apt:
      name: git
      state: latest
</code></pre>

<p><strong>Special tags</strong>
Ansible have two special tags, <em>never</em> and <em>always</em>. If you add always tag to task, play, Ansible will always run the task or play, unless explicitly asked to skip with the help of (—skip-tags always)</p>

<p>On the other hand, <em>never</em> tag if assign to a task or play, Ansible will skip that task or play unless you explicitly asked it (—tags never).</p>

<p><strong>Running the Playbook with tags</strong></p>
<ul><li><p>will run tasks with tag <em>git</em> : <code>ansible-playbook example.yml --tags &#34;git&#34;</code></p></li>

<li><p>will not run tasks with tag <em>git</em> : <code>ansible-playbook example.yml --skip-tags &#34;git&#34;</code></p></li>

<li><p>list all the tags : <code>ansible-playbook example.yml --list-tags</code></p></li>

<li><p>run all tasks, ignore tags (default behavior):  <code>--tags all</code></p></li>

<li><p>run only tasks with either the tag tag1 or the tag tag2: <code>--tags [tag1, tag2]</code></p></li>

<li><p>run all tasks, except those with either the tag tag3 or the tag tag4:
<code>--skip-tags [tag3, tag4]</code></p></li>

<li><p>run only tasks with at least one tag: <code>--tags tagged</code></p></li>

<li><p>run only tasks with no tags:  <code>--tags untagged</code></p></li></ul>

<p>That&#39;s all about the Ansible tags. Now go and tag your tasks :).</p>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a>
<a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-tags</guid>
      <pubDate>Sat, 14 Aug 2021 06:07:09 +0000</pubDate>
    </item>
    <item>
      <title>Ansible: Command Line Arguments</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-command-line-arguments</link>
      <description>&lt;![CDATA[While running your Ansible playbook, we can have the option of passing the argument from the command line. With the help of this, we define a generic playbook and use command line arguments to control the play. Let see how&#xA;&#xA;Let&#39;s first start with the playbook, where we have defined the variable x is the playbook.&#xA;---&#xA;hosts: all&#xA;  vars:&#xA;    x: 45&#xA;  tasks:&#xA;    debug: var=x&#xA;In this playbook, we will pass the value of x from the command line arguments with the help -e &#34;value&#34;.&#xA;---&#xA;hosts: all&#xA;  tasks:&#xA;    debug: var=x&#xA;    ansible-playbook playbooknmae.yml -e &#34;x=56&#34;&#xA;Now let&#39;s write a playbook which can uninstall/install a package with the help of command line arguments.&#xA;---&#xA;name: Install/Unistall pacakges with command line&#xA;  hosts: all&#xA;  became: &#39;yes&#39;&#xA;  tasks:&#xA;    name: &#39;working with {{pkg}}&#39;&#xA;      apt:&#xA;        name: &#39;{{pkg}}&#39;&#xA;        state: &#39;{{reqstate}}&#39;&#xA;&#xA;Now, from the command line, we can pass the package name and state of the package.&#xA;    ansible-playbook playbookname.yml -e  &#34;pkg=nginx reqstate=present&#34;&#xA;&#xA;    ansible-playbook playbookname.yml -e  &#34;pkg=nginx reqstate=absent&#34;&#xA;&#xA;Cheers!&#xA;&#xA;100DaysToOffload &#xA;Ansible&#xA;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p>While running your Ansible playbook, we can have the option of passing the argument from the command line. With the help of this, we define a generic playbook and use command line arguments to control the play. Let see how</p>

<p>Let&#39;s first start with the playbook, where we have defined the variable <em>x</em> is the playbook.</p>

<pre><code class="language-yml">---
- hosts: all
  vars:
    x: 45
  tasks:
    - debug: var=x
</code></pre>

<p>In this playbook, we will pass the value of <em>x</em> from the command line arguments with the help <em>-e “value”</em>.</p>

<pre><code class="language-yml">---
- hosts: all
  tasks:
    - debug: var=x
</code></pre>

<pre><code class="language-shell">&gt;&gt; ansible-playbook playbook_nmae.yml -e &#34;x=56&#34;
</code></pre>

<p>Now let&#39;s write a playbook which can uninstall/install a package with the help of command line arguments.</p>

<pre><code class="language-yml">---
- name: Install/Unistall pacakges with command line
  hosts: all
  became: &#39;yes&#39;
  tasks:
    - name: &#39;working with {{pkg}}&#39;
      apt:
        name: &#39;{{pkg}}&#39;
        state: &#39;{{req_state}}&#39;

</code></pre>

<p>Now, from the command line, we can pass the package name and state of the package.</p>

<pre><code class="language-shell">&gt;&gt;ansible-playbook playbook_name.yml -e  &#34;pkg=nginx req_state=present&#34;

&gt;&gt;ansible-playbook playbook_name.yml -e  &#34;pkg=nginx req_state=absent&#34;
</code></pre>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a>
<a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-command-line-arguments</guid>
      <pubDate>Wed, 07 Jul 2021 15:12:28 +0000</pubDate>
    </item>
    <item>
      <title>Ansible: Group and Group of Group&#39;s in Inventory</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-group-and-group-of-groups-in-inventory</link>
      <description>&lt;![CDATA[Inventory(Hosts) file contains the information of the Ansible nodes. We can group based on our use case like web servers, DB servers and uses these groups to execute commands on them. But you have to create a group in the inventory file, let see how to do that.&#xA;&#xA;[webserver]&#xA;IPADDRESS1&#xA;IPADDRESS2&#xA;IPADDRESS3&#xA;&#xA;[webserverduck]&#xA;IPADDRESS1&#xA;&#xA;[dbserver]&#xA;IPADDRESS1&#xA;IPADDRESS2&#xA;IPADDRESS3&#xA;&#xA;[clientduck:children]&#xA;dbserver&#xA;webserverduck&#xA;You can even assign variable nodes or group wise in inventory file&#xA;[webserverduck:vars]&#xA;ansibleconnection=ssh&#xA;ansibleuser=myotheruser&#xA;gatherfact=no&#xA;&#xA;[dbserver]&#xA;IPADDRESS1 ansibleuser=myuser&#xA;IPADDRESS2&#xA;IPADDRESS3&#xA;Cheers!&#xA;&#xA;#100DaysToOffload #Ansible #dgplug&#xA;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p>Inventory(Hosts) file contains the information of the Ansible nodes. We can group based on our use case like web servers, DB servers and uses these groups to execute commands on them. But you have to create a group in the inventory file, let see how to do that.</p>

<pre><code class="language-YML">[webserver]
IP_ADDRESS_1
IP_ADDRESS_2
IP_ADDRESS_3

[webserverduck]
IP_ADDRESS_1

[dbserver]
IP_ADDRESS_1
IP_ADDRESS_2
IP_ADDRESS_3

[clientduck:children]
dbserver
webserverduck
</code></pre>

<p>You can even assign variable nodes or group wise in inventory file</p>

<pre><code class="language-YML">[webserverduck:vars]
ansible_connection=ssh
ansible_user=myotheruser
gather_fact=no


[dbserver]
IP_ADDRESS_1 ansible_user=myuser
IP_ADDRESS_2
IP_ADDRESS_3
</code></pre>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a> <a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a> <a href="/sandeepk/tag:dgplug" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">dgplug</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-group-and-group-of-groups-in-inventory</guid>
      <pubDate>Wed, 23 Jun 2021 15:10:09 +0000</pubDate>
    </item>
    <item>
      <title>Ansible Architecture</title>
      <link>https://blogs.dgplug.org/sandeepk/ansible-architecture</link>
      <description>&lt;![CDATA[Ansible Architecture&#xA;&#xA;What is Ansible&#xA;Ansible is a simple IT automation tool that make application&#xA;and system easier to deploy and maintain. With the help of Ansible, you can automate task like network configuration, code deployment and cloud management. Ansible is an agent less  system, which means that you don&#39;t need to install any software on the client system.&#xA;&#xA;Inventory&#xA;Inventory file is the one which contains the lists of the host servers  on which Ansible works, it can be the IP Addresses, Domain name ...&#xA;&#xA;Hosts&#xA;It contains the IP addresses or Fully qualified domain name of the node servers which you want to configure.&#xA;&#xA;Ansible.cfg&#xA;This file contains the configuration for the Ansible, like the path of the Inventory file and values for the default variable in the Ansible&#xA;&#xA;Ansible Nodes&#xA;Ansible&#39;s nodes are the client system on which we want to execute, deploy or maintain the code(servers on which we want to work).&#xA;&#xA;Ansible Engine&#xA;Ansible engine/master/controller from which we manage all the server nodes.&#xA;&#xA;Cheers!&#xA;&#xA;#100DaysToOffload #Ansible #dgplug&#xA;&#xA;]]&gt;</description>
      <content:encoded><![CDATA[<p><img src="https://raw.githubusercontent.com/Skchoudhary/blog-asset/master/dgplug-blog/ansible-arch.png" alt="Ansible Architecture" title="Ansible Architecture"></p>

<p><strong>What is Ansible</strong>
Ansible is a simple IT automation tool that make application
and system easier to deploy and maintain. With the help of Ansible, you can automate task like network configuration, code deployment and cloud management. Ansible is an agent less  system, which means that you don&#39;t need to install any software on the client system.</p>

<p><strong>Inventory</strong>
Inventory file is the one which contains the lists of the host servers  on which Ansible works, it can be the IP Addresses, Domain name ...</p>

<p><strong>Hosts</strong>
It contains the IP addresses or Fully qualified domain name of the node servers which you want to configure.</p>

<p><strong>Ansible.cfg</strong>
This file contains the configuration for the Ansible, like the path of the Inventory file and values for the default variable in the Ansible</p>

<p><strong>Ansible Nodes</strong>
Ansible&#39;s nodes are the client system on which we want to execute, deploy or maintain the code(servers on which we want to work).</p>

<p><strong>Ansible Engine</strong>
Ansible engine/master/controller from which we manage all the server nodes.</p>

<p>Cheers!</p>

<p><a href="/sandeepk/tag:100DaysToOffload" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">100DaysToOffload</span></a> <a href="/sandeepk/tag:Ansible" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">Ansible</span></a> <a href="/sandeepk/tag:dgplug" class="hashtag" rel="nofollow"><span>#</span><span class="p-category">dgplug</span></a></p>
]]></content:encoded>
      <guid>https://blogs.dgplug.org/sandeepk/ansible-architecture</guid>
      <pubDate>Wed, 16 Jun 2021 15:52:26 +0000</pubDate>
    </item>
  </channel>
</rss>