Skip to content

Commit

Permalink
[PUBLISHER] Publish from Obsidian #7
Browse files Browse the repository at this point in the history
* PUSH NOTE : Linux.md

* PUSH NOTE : Secure Shell.md

* PUSH NOTE : 01 Ansible Architecture.md

* PUSH NOTE : Ansible.md

* PUSH NOTE : Ansible Semaphore.md
  • Loading branch information
PatrickAmbrosso authored Mar 19, 2024
1 parent 4927c9a commit f58eb35
Show file tree
Hide file tree
Showing 4 changed files with 1,130 additions and 125 deletions.
214 changes: 107 additions & 107 deletions content/Expeditions/Ansible/Learning Ansible/01 Ansible Architecture.md
Original file line number Diff line number Diff line change
@@ -1,112 +1,112 @@
---
title: 01 Ansible Architecture
title: Ansible Architecture
description:
tags:
publish: true
---

Ansible follows a client-server architecture, but it's important to note that Ansible is agentless, meaning it doesn't require any software agents to be installed on the nodes managed by ansible.

## Send Nodes

There are two types of nodes in ansible
1. **Control Node**
- The control node is where Ansible is installed and from where automation tasks are managed.
- This can be a personal computer, a dedicated server running on premises or even a cloud machine running with a cloud service provider.
- The control node contains the code essential to manage the remote machines.
2. **Managed Node**
- Managed nodes are the systems or devices that Ansible manages.
- They can be servers, virtual machines, networking devices, cloud instances, or any other infrastructure component that can be SSH'ed into and python can be installed.
- Ansible communicates with managed nodes over SSH (for Linux/Unix) or PowerShell Remoting (for Windows).
- There is no persistent agent running on managed nodes; Ansible connects to them temporarily to execute tasks and then disconnects.

## Managing the Machines

Managed Nodes in ansible are governed with the help of the `inventory file`. An inventory file is usually written in the `INI` or `YAML` syntax, however formats like `JSON` is also supported.

The file is generally named `hosts` (just hosts without extension) and is usually found at `/etc/ansible/hosts` on a Unix/Linux file system. Custom inventory files can be passed to ansible by using `-i` or `--inventory` flag. Generally inventory files group the nodes managed into logical groups on the basis of functionality, environment, location or role

Ansible also takes in per-host variables in the inventory file. This allows to manage hosts with varied configuration.

Ansible supports dynamic inventories generated by external scripts or plugins. Dynamic inventories fetch host information from sources such as cloud providers, virtualization platforms, or external databases, allowing dynamic scaling and management of infrastructure.

```ini
# Inventory file for Ansible

# Grouping hosts into categories
[web_servers]
web1 ansible_host=192.168.1.101 ansible_user=admin ansible_ssh_private_key=~/.ssh/id_rsa

[db_servers]
db1 ansible_host=192.168.1.102 ansible_user=admin ansible_ssh_private_key=~/.ssh/id_rsa
db2 ansible_host=192.168.1.103 ansible_user=admin ansible_ssh_private_key=~/.ssh/id_rsa

# Grouping hosts by attributes
[linux_servers]
web1
db1
db2

[windows_servers]
win1 ansible_host=192.168.1.104 ansible_user=administrator ansible_password=Pa$$w0rd!
win2 ansible_host=192.168.1.105 ansible_user=administrator ansible_password=Pa$$w0rd!
```

```yaml
# Inventory file for Ansible

# All hosts definition
all:
hosts:

# Linux Servers
web1:
ansible_host: 192.168.1.101
ansible_user: admin
ansible_ssh_private_key: ~/.ssh/id_rsa
db1:
ansible_host: 192.168.1.102
ansible_user: admin
ansible_ssh_private_key: ~/.ssh/id_rsa
db2:
ansible_host: 192.168.1.103
ansible_user: admin
ansible_ssh_private_key: ~/.ssh/id_rsa

# Windows Servers
win1:
ansible_host: 192.168.1.104
ansible_user: administrator
ansible_password: Pa$$w0rd!
win2:
ansible_host: 192.168.1.105
ansible_user: administrator
ansible_password: Pa$$w0rd!

# Children Section - Grouping of hosts
children:

# Grouping of Web Servers
web_servers:
hosts:
web1:

# Grouping of Database Servers
db_servers:
hosts:
db1:
db2:

# Grouping of Linux Servers
linux_servers:
hosts:
web1:
db1:
db2:

# Grouping of Windows Servers
windows_servers:
hosts:
win1:
win2:
```

Ansible follows a client-server architecture, but it's important to note that Ansible is agentless, meaning it doesn't require any software agents to be installed on the nodes managed by ansible.

## Send Nodes

There are two types of nodes in ansible
1. **Control Node**
- The control node is where Ansible is installed and from where automation tasks are managed.
- This can be a personal computer, a dedicated server running on premises or even a cloud machine running with a cloud service provider.
- The control node contains the code essential to manage the remote machines.
2. **Managed Node**
- Managed nodes are the systems or devices that Ansible manages.
- They can be servers, virtual machines, networking devices, cloud instances, or any other infrastructure component that can be SSH'ed into and python can be installed.
- Ansible communicates with managed nodes over SSH (for Linux/Unix) or PowerShell Remoting (for Windows).
- There is no persistent agent running on managed nodes; Ansible connects to them temporarily to execute tasks and then disconnects.

## Managing the Machines

Managed Nodes in ansible are governed with the help of the `inventory file`. An inventory file is usually written in the `INI` or `YAML` syntax, however formats like `JSON` is also supported.

The file is generally named `hosts` (just hosts without extension) and is usually found at `/etc/ansible/hosts` on a Unix/Linux file system. Custom inventory files can be passed to ansible by using `-i` or `--inventory` flag. Generally inventory files group the nodes managed into logical groups on the basis of functionality, environment, location or role

Ansible also takes in per-host variables in the inventory file. This allows to manage hosts with varied configuration.

Ansible supports dynamic inventories generated by external scripts or plugins. Dynamic inventories fetch host information from sources such as cloud providers, virtualization platforms, or external databases, allowing dynamic scaling and management of infrastructure.

```ini
# Inventory file for Ansible

# Grouping hosts into categories
[web_servers]
web1 ansible_host=192.168.1.101 ansible_user=admin ansible_ssh_private_key=~/.ssh/id_rsa

[db_servers]
db1 ansible_host=192.168.1.102 ansible_user=admin ansible_ssh_private_key=~/.ssh/id_rsa
db2 ansible_host=192.168.1.103 ansible_user=admin ansible_ssh_private_key=~/.ssh/id_rsa

# Grouping hosts by attributes
[linux_servers]
web1
db1
db2

[windows_servers]
win1 ansible_host=192.168.1.104 ansible_user=administrator ansible_password=Pa$$w0rd!
win2 ansible_host=192.168.1.105 ansible_user=administrator ansible_password=Pa$$w0rd!
```

```yaml
# Inventory file for Ansible

# All hosts definition
all:
hosts:

# Linux Servers
web1:
ansible_host: 192.168.1.101
ansible_user: admin
ansible_ssh_private_key: ~/.ssh/id_rsa
db1:
ansible_host: 192.168.1.102
ansible_user: admin
ansible_ssh_private_key: ~/.ssh/id_rsa
db2:
ansible_host: 192.168.1.103
ansible_user: admin
ansible_ssh_private_key: ~/.ssh/id_rsa

# Windows Servers
win1:
ansible_host: 192.168.1.104
ansible_user: administrator
ansible_password: Pa$$w0rd!
win2:
ansible_host: 192.168.1.105
ansible_user: administrator
ansible_password: Pa$$w0rd!

# Children Section - Grouping of hosts
children:

# Grouping of Web Servers
web_servers:
hosts:
web1:

# Grouping of Database Servers
db_servers:
hosts:
db1:
db2:

# Grouping of Linux Servers
linux_servers:
hosts:
web1:
db1:
db2:

# Grouping of Windows Servers
windows_servers:
hosts:
win1:
win2:
```
36 changes: 18 additions & 18 deletions content/Expeditions/Ansible/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,21 +4,21 @@ description: About the Ansible Configuration Management Tool
tags:
publish: true
---

Ansible is an open-source automation tool that simplifies the management and configuration of computer systems. It is designed to streamline tasks such as software deployment, configuration management, and orchestration, making it a popular choice for DevOps professionals and system administrators.

Key features of Ansible include:
1. **Agentless Architecture** - Ansible operates in an agentless manner, which means that ansible need not be installed on the managed nodes. Instead, it uses SSH for communication and python (should be installed in the nodes), making it lightweight and easy to deploy.
2. **Infrastructure as Code (IaC)** - Ansible allows defining infrastructure as code using YAML-based playbooks. This approach ensures consistency, repeatability, and version control of your infrastructure configurations.
3. **Declarative Language** - Ansible uses a declarative language, allowing to define the desired state rather than writing procedural scripts/code. This makes it easier to understand and maintain Ansible code.
4. **Modularity and Reusability** - Ansible promotes modularity and reusability through roles, which are self-contained units of tasks, variables, and handlers. Roles enable organizing automation code effectively and share it across projects.
5. **Extensibility** - Ansible's extensible architecture allows extending its functionality by creating custom modules or leveraging community-contributed modules. This flexibility enables to automate a wide range of tasks across different systems and applications.
6. **Orchestration** - Ansible can orchestrate complex workflows and tasks across multiple hosts, making it suitable for managing large-scale infrastructure deployments and configurations.

## Learning Ansible


## Ansible Projects & Playbooks


## Resources

Ansible is an open-source automation tool that simplifies the management and configuration of computer systems. It is designed to streamline tasks such as software deployment, configuration management, and orchestration, making it a popular choice for DevOps professionals and system administrators.

Key features of Ansible include:
1. **Agentless Architecture** - Ansible operates in an agentless manner, which means that ansible need not be installed on the managed nodes. Instead, it uses SSH for communication and python (should be installed in the nodes), making it lightweight and easy to deploy.
2. **Infrastructure as Code (IaC)** - Ansible allows defining infrastructure as code using YAML-based playbooks. This approach ensures consistency, repeatability, and version control of your infrastructure configurations.
3. **Declarative Language** - Ansible uses a declarative language, allowing to define the desired state rather than writing procedural scripts/code. This makes it easier to understand and maintain Ansible code.
4. **Modularity and Reusability** - Ansible promotes modularity and reusability through roles, which are self-contained units of tasks, variables, and handlers. Roles enable organizing automation code effectively and share it across projects.
5. **Extensibility** - Ansible's extensible architecture allows extending its functionality by creating custom modules or leveraging community-contributed modules. This flexibility enables to automate a wide range of tasks across different systems and applications.
6. **Orchestration** - Ansible can orchestrate complex workflows and tasks across multiple hosts, making it suitable for managing large-scale infrastructure deployments and configurations.

## Learning Ansible


## Ansible Projects & Playbooks


## Resources
Loading

0 comments on commit f58eb35

Please sign in to comment.