This presentation brings up the concepts related to Infrastructure as Code using Ansible

1. Infrastructure as Code (IaC)
with Ansible

2. Definition
• Infrastructure as Code (IaC) is the management of
infrastructure (networks, virtual machines, load balancers,
and connection topology) in a descriptive model. Like the
principle that the same source code generates the same
binary, an IaC model generates the same environment
every time it is applied.

3. Why?
• IaC evolved to solve the problem of environment drift in the
release pipeline. Without IaC, teams must register
somewhere and maintain the settings of each individual
deployment environments. Over time, each environment
becomes a snowflake, that is, a unique configuration that
cannot be reproduced automatically. Inconsistency among
environments leads to issues during deployments. With
snowflakes, administration and maintenance of
infrastructure involves manual processes, which were hard
to track and more susceptible to errors.
Microsoft

4. Benefits
• The value of IaC can be broken down into three measurable categories:
Cost (reduction), speed (faster execution) and risk (remove errors and
security violations).
• Cost reduction aims at helping not only the enterprise financially, but also
in terms of people and effort, meaning that by removing the manual
component, people are able to refocus their efforts towards other
enterprise tasks.
• Infrastructure automation enables speed through faster execution when
configuring your infrastructure and aims at providing visibility to help
other teams across the enterprise work quickly and more efficiently.
• Automation removes the risk associated with human error, like manual
misconfiguration; removing this can decrease downtime and increase
reliability.
Wikipedia

5. Approaches
• Declarative
Defines the desired state and the system executes what
needs to happen to achieve that desired state.
• Imperative
Imperative defines specific commands that need to be
executed in the appropriate order to end with the desired
conclusion.

6. Methods
• Push vs. Pull
The main difference is the manner in which the servers are
told how to be configured. In the pull method the server to be
configured will pull its configuration from the controlling
server. In the push method the controlling server pushes the
configuration to the destination system.

7. Idempotence
• Idempotence is a principle of Infrastructure as Code. It is
the property that a deployment command always sets the
target environment into the same configuration, regardless
of the environment’s starting state. Idempotency is
achieved by either automatically configuring an existing
target or by discarding the existing target and recreating a
fresh environment.

8. Good Practices
1. Codify everything
The configuration files represent the single source of truth of
your infrastructure specifications and describe exactly which
components you’ll use, how they relate to one another, and
how the entire environment is configured.
Infrastructure can then be deployed quickly and seamlessly,
and ideally no one should log into a server to manually make
adjustments.
Codify all the infrastructure things!

9. Good Practices
2. Document as little as possible
Your IaC code will essentially be your documentation, so
there shouldn’t be many additional instructions than that.

10. Good Practices
3. Maintain version control
Just like with application code, source control tools like Git,
Mercurial, Subversion, or others should be used to maintain
versions of your IaC codebase. Not only will this provide an
audit trail for code changes, it will also provide the ability to
collaborate, peer-review, and test IaC code before it goes live.

11. Good Practices
4. Continuously test, integrate, and deploy
Continuous testing, integration, and deployment processes
are a great way to manage all the changes that may be made
to your infrastructure code.

12. Good Practices
5. Make your infrastructure code modular
Developing smaller, modular units of code that can be
deployed independently of the rest of a product’s
components, is a trend in software development
(microservices), as it's a good idea in IaC as well.

13. Good Practices
6. Make your infrastructure immutable (when possible)
The idea behind immutable infrastructure is that IT
infrastructure components are replaced for each deployment,
instead of changed in-place.
Making your infrastructure immutable provides consistency,
avoids configuration drift, and restricts the impact of
undocumented changes to your stack. It also improves
security and makes troubleshooting easier due to the lack of
configuration edits.

14. Tools

15. Why Ansible?

16. What for?

17. Benefits

18. Demo
• Hello world
1. Install Ansible in controller and set up SSH in nodes
2. Edit (or create) hosts file
3. Run Ansible (ad hoc)
ansible all --user=dbezerra -k -m ping
ansible all --user=dbezerra -k -m shell -a "echo 1234 > /tmp/numbers.txt"

19. Demo
• Hello world (Playbook)
1. Install Ansible in the controller and set up SSH in nodes
2. Create playbook (provisioning.yml)
3. Run playbook
ansible-playbook -i hosts provisioning.yml

20. Demo
• GLPI 9.3.3 (MariaDB 10.3) Playbook

21. References
• https://docs.ansible.com/
• https://docs.ansible.com/ansible/latest/user_guide/
intro_getting_started.html
• https://www.ansible.com/resources/videos/quick-start-video
• https://docs.ansible.com/ansible/latest/modules/
modules_by_category.html
• https://docs.ansible.com/ansible/latest/user_guide/
playbooks_best_practices.html?highlight=best%20practices
• https://galaxy.ansible.com/docs/