Skip to content

Commit

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

* PUSH NOTE : 02 Setting up SSH Server and SSH Client.md

* PUSH NOTE : 01 Fundamentals of SSH.md

* PUSH NOTE : Secure Shell.md

* PUSH NOTE : Linux.md

* PUSH NOTE : 01 Introduction to Linux.md

* PUSH NOTE : 01 Ansible Architecture.md
  • Loading branch information
@PatrickAmbrosso
PatrickAmbrosso authored Mar 19, 2024
1 parent 4aa89d5 commit c567f19
Show file tree
Hide file tree
Showing 6 changed files with 658 additions and 434 deletions.
212 changes: 106 additions & 106 deletions content/Expeditions/Ansible/Learning Ansible/01 Ansible Architecture.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,109 +4,109 @@ 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:
```
Loading

0 comments on commit c567f19

Please sign in to comment.