The goal for these blog post series is to show how we can make SAP Solutions deployments easy and reliable using Ansible automation.
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
We are going to focus on the configuration management and application deployment capabilities for SAP Solutions during these post series, focusing on how to automate SAP HANA and S/4HANA by SAP on Red Hat Enterprise Linux systems.
But before going any further on the details of this process, we are going to explain first what Ansible is, what are the benefits of using Ansible, what are the best practices while using Ansible and finally we will have a look into Ansible Tower product.
As we mentioned before, Ansible is an automation engine which uses declarative models focused on ‘what’ rather than ‘how’, this means that while creating Ansible playbooks, we will describe what is the desired state of our system and Ansible will figure out how to get there.
A full description of Ansible best practices can be found here but as a “simplified” version for starters, these ones could help to start writing your Ansible playbooks.
Project structure best practices
Ansible is very flexible when it comes to Project structure. The suggested way is one example of how to handle it.
├─── ansible.cfg
├─── inventory
│ ├── group_vars
│ │ ├── group1.yml
│ │ ├── group2.yml
│ └── hosts
├─── master.yml
├─── playbooks
│ ├── playbook1.yml
│ └── playbook2.yml
├─── README.md
├─── roles
│ └── role1
│ ├── defaults
│ │ └── main.yml
│ ├── files
│ │ └── main.yml
│ ├── handlers
│ │ └── main.yml
│ ├── meta
│ │ └── main.yml
│ ├── tasks
│ │ └── main.yml
│ ├── templates
│ │ └── template.conf.j2
│ └── vars
│ └── main.yml
└─── vault.yml
Name conventions
Ansible has a powerful variable processing system that collects metadata from various sources and manages their merge and context as a play runs on your hosts. A lot of effort goes into making that power as easy and transparent as possible to users. Variable scoping and namespacing was intentionally limited and shallow by design to make it easier to understand and debug. As a best practice, we recommend prefixing variables with the source or target of the data it represents. Prefixing variables is particularly vital with developing reusable and portable roles. By adding the role name to a variable as prefix simplifies search and helps to understand its context.
Keep it simple
When you can do something simply, do something simply. Do not reach to use every feature of Ansible together, all at once. Use what works for you. For example, you will probably not need vars, vars_files, vars_prompt and –extra-vars all at once, while also using an external inventory file. If something feels complicated, it probably is and maybe a good opportunity to simplify things. Strive for simplification in what you automate.
Think declaratively
Ansible is a desired state engine by design. If you are trying to “write code” in your Ansible Playbooks and Roles, you are setting yourself up for failure. Ansible Playbooks were never meant to be for programming.
Idempotence
Idempotence is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application.
◉ Always make idempotent Ansible Roles
◉ Distinguish between idempotent and not idempotent Ansible Playbooks
◉ Use appropriate names, so:
◉ “Install X” becomes “Ensure X is present”
◉ “Add line X to file Y” becomes “Ensure line X is present in file Y”
Version control
Use version control. Keep your Playbooks and inventory file in git (or another version control system), and commit when you make changes to them. This way you have an audit trail describing when and why you changed the rules that are automating your infrastructure.
Use Roles
Roles in Ansible build on the idea of including files and combine them to form clean, reusable abstractions – they allow you to focus more on the big picture and only dive down into the details when needed. We recommend the usage of Ansible Roles whenever is possible, it will increase reusability and ensure that the code is organised according to the standard folder structure.
Documentation and Readability
If your plays are written properly, they can easily be used as the documentation of your workflow automation.
Always Name Playbooks and Tasks
It is possible to leave off the ‘name’, though it is recommended to provide a description about why something is being done instead. This name is shown when the Playbook is run. Adding a name with a human meaningful description better communicates the intent to users when running a Playbook.
Use Default Values
By using default values you can make sure your Playbook runs without additional parameters. Overwriting these variables can be done in various locations please check variable precedence from Ansible documentation.
Tasks/Playbooks should begin by checking for any variables that they require
If Ansible requires certain variables to be set, it’s best to check for these upfront before any other actions have been performed. In this way, the user knows exactly what needs to be passed into the playbook/task.
Use Native YAML Syntax
At its core, the Ansible Playbook runner is a YAML parser with added logic such as command-line key=value pairs shorthand. While convenient when cranking out a quick playbook or a docs example, that style of formatting reduces readability and maintainability. The recommendation is to refrain from using that shorthand (even with YAML folded style) as a best practice.
This is an example of a bad syntax practice while writing Playbooks.
- name: install Chrony
yum:
name: chrony state=present update_cache=yes disable_gpg_check=yes
- name: configure Chrony
template: src=chrony.conf.j2 dest=/etc/chrony.conf
notify: Restart chrony
- name: start Chrony
service: name=chronyd state=started enabled=yes
This is an example of a good syntax for the same Playbook.
- name: Ensure Chrony is installed
yum:
name: chrony
state: present
- name: Ensure custom configuration is in place
template:
src: chrony.conf.j2
dest: /etc/chrony.conf
notify: Restart chrony
- name: Ensure Chrony is running and enabled
service:
name: chronyd
state: started
enabled: yes
Benefits of using Ansible
There is an obvious advantage while using Ansible, which is the ability to automate all your IT landscape for your organization from a single tool. This is not only a time-saving mechanism for your IT departments but will also result in a more reliable infrastructure where your business will run. Using a single tool will reduce context switch for your Engineers at the same time that increases the sharing understanding between all your different IT departments. Ansible learning curve is very low and you will see the benefits of using it very quickly.
Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled.
Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized–it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems.
Ansible Tower
One of the challenges while using automation tools is the ability to manage very complex automation strategies that use different automation sources to get to the desired state. While using Ansible, the required roles to manage the end to end deployment of a new Data Center as an example, have probably been developed by different IT teams, and these need to be put together in a specific order to cover the whole process.
Many times these automation flows need to react and decide the path to take based on a previous execution result and at the same time we want to keep our Ansible roles independent from others.
Ansible Tower is providing all these capabilities and much more. It helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments. You can centralize and control your IT infrastructure with a visual dashboard, role-based access control, job scheduling, integrated notifications and graphical inventory management. Easily embed Ansible Tower into existing tools and processes with REST API and CLI.
We will show these capabilities in the coming posts, where we will showcase how to use Ansible Tower’s Workflows as an example to achieve end to end deployments for SAP Solutions.
What is Ansible
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
We are going to focus on the configuration management and application deployment capabilities for SAP Solutions during these post series, focusing on how to automate SAP HANA and S/4HANA by SAP on Red Hat Enterprise Linux systems.
But before going any further on the details of this process, we are going to explain first what Ansible is, what are the benefits of using Ansible, what are the best practices while using Ansible and finally we will have a look into Ansible Tower product.
As we mentioned before, Ansible is an automation engine which uses declarative models focused on ‘what’ rather than ‘how’, this means that while creating Ansible playbooks, we will describe what is the desired state of our system and Ansible will figure out how to get there.
Ansible best practices
A full description of Ansible best practices can be found here but as a “simplified” version for starters, these ones could help to start writing your Ansible playbooks.
Project structure best practices
Ansible is very flexible when it comes to Project structure. The suggested way is one example of how to handle it.
├─── ansible.cfg
├─── inventory
│ ├── group_vars
│ │ ├── group1.yml
│ │ ├── group2.yml
│ └── hosts
├─── master.yml
├─── playbooks
│ ├── playbook1.yml
│ └── playbook2.yml
├─── README.md
├─── roles
│ └── role1
│ ├── defaults
│ │ └── main.yml
│ ├── files
│ │ └── main.yml
│ ├── handlers
│ │ └── main.yml
│ ├── meta
│ │ └── main.yml
│ ├── tasks
│ │ └── main.yml
│ ├── templates
│ │ └── template.conf.j2
│ └── vars
│ └── main.yml
└─── vault.yml
Name conventions
Ansible has a powerful variable processing system that collects metadata from various sources and manages their merge and context as a play runs on your hosts. A lot of effort goes into making that power as easy and transparent as possible to users. Variable scoping and namespacing was intentionally limited and shallow by design to make it easier to understand and debug. As a best practice, we recommend prefixing variables with the source or target of the data it represents. Prefixing variables is particularly vital with developing reusable and portable roles. By adding the role name to a variable as prefix simplifies search and helps to understand its context.
Keep it simple
When you can do something simply, do something simply. Do not reach to use every feature of Ansible together, all at once. Use what works for you. For example, you will probably not need vars, vars_files, vars_prompt and –extra-vars all at once, while also using an external inventory file. If something feels complicated, it probably is and maybe a good opportunity to simplify things. Strive for simplification in what you automate.
Think declaratively
Ansible is a desired state engine by design. If you are trying to “write code” in your Ansible Playbooks and Roles, you are setting yourself up for failure. Ansible Playbooks were never meant to be for programming.
Idempotence
Idempotence is the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application.
◉ Always make idempotent Ansible Roles
◉ Distinguish between idempotent and not idempotent Ansible Playbooks
◉ Use appropriate names, so:
◉ “Install X” becomes “Ensure X is present”
◉ “Add line X to file Y” becomes “Ensure line X is present in file Y”
Version control
Use version control. Keep your Playbooks and inventory file in git (or another version control system), and commit when you make changes to them. This way you have an audit trail describing when and why you changed the rules that are automating your infrastructure.
Use Roles
Roles in Ansible build on the idea of including files and combine them to form clean, reusable abstractions – they allow you to focus more on the big picture and only dive down into the details when needed. We recommend the usage of Ansible Roles whenever is possible, it will increase reusability and ensure that the code is organised according to the standard folder structure.
Documentation and Readability
If your plays are written properly, they can easily be used as the documentation of your workflow automation.
Always Name Playbooks and Tasks
It is possible to leave off the ‘name’, though it is recommended to provide a description about why something is being done instead. This name is shown when the Playbook is run. Adding a name with a human meaningful description better communicates the intent to users when running a Playbook.
Use Default Values
By using default values you can make sure your Playbook runs without additional parameters. Overwriting these variables can be done in various locations please check variable precedence from Ansible documentation.
Tasks/Playbooks should begin by checking for any variables that they require
If Ansible requires certain variables to be set, it’s best to check for these upfront before any other actions have been performed. In this way, the user knows exactly what needs to be passed into the playbook/task.
Use Native YAML Syntax
At its core, the Ansible Playbook runner is a YAML parser with added logic such as command-line key=value pairs shorthand. While convenient when cranking out a quick playbook or a docs example, that style of formatting reduces readability and maintainability. The recommendation is to refrain from using that shorthand (even with YAML folded style) as a best practice.
This is an example of a bad syntax practice while writing Playbooks.
- name: install Chrony
yum:
name: chrony state=present update_cache=yes disable_gpg_check=yes
- name: configure Chrony
template: src=chrony.conf.j2 dest=/etc/chrony.conf
notify: Restart chrony
- name: start Chrony
service: name=chronyd state=started enabled=yes
This is an example of a good syntax for the same Playbook.
- name: Ensure Chrony is installed
yum:
name: chrony
state: present
- name: Ensure custom configuration is in place
template:
src: chrony.conf.j2
dest: /etc/chrony.conf
notify: Restart chrony
- name: Ensure Chrony is running and enabled
service:
name: chronyd
state: started
enabled: yes
Benefits of using Ansible
There is an obvious advantage while using Ansible, which is the ability to automate all your IT landscape for your organization from a single tool. This is not only a time-saving mechanism for your IT departments but will also result in a more reliable infrastructure where your business will run. Using a single tool will reduce context switch for your Engineers at the same time that increases the sharing understanding between all your different IT departments. Ansible learning curve is very low and you will see the benefits of using it very quickly.
Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled.
Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized–it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems.
Ansible Tower
One of the challenges while using automation tools is the ability to manage very complex automation strategies that use different automation sources to get to the desired state. While using Ansible, the required roles to manage the end to end deployment of a new Data Center as an example, have probably been developed by different IT teams, and these need to be put together in a specific order to cover the whole process.
Many times these automation flows need to react and decide the path to take based on a previous execution result and at the same time we want to keep our Ansible roles independent from others.
Ansible Tower is providing all these capabilities and much more. It helps teams manage complex multi-tier deployments by adding control, knowledge, and delegation to Ansible-powered environments. You can centralize and control your IT infrastructure with a visual dashboard, role-based access control, job scheduling, integrated notifications and graphical inventory management. Easily embed Ansible Tower into existing tools and processes with REST API and CLI.
We will show these capabilities in the coming posts, where we will showcase how to use Ansible Tower’s Workflows as an example to achieve end to end deployments for SAP Solutions.
No comments:
Post a Comment