51 networking service neutron automation(Openstack Networking Project Installation)

.github/styles/config/vocabularies/Ansible/accept.txt

@@ -34,6 +34,10 @@
 (?i)vms?
 (?i)macoss?
 (?i)oss?
+(?i)subnet?
+(?i)subnets?
+(?i)subnetworks?
+(?i)IPs?
 (?i)config
 (?i)configs
 (?i)Cirros
@@ -44,3 +48,4 @@
 (?i)OAuth
 (?i)APIs
 (?i)cirros
+

.gitignore

@@ -441,3 +441,4 @@ FodyWeavers.xsd
 # JetBrains Rider
 *.sln.iml
 
+scripts/ansible_scripts/automated_openstack_installation/key.txt

docs/VLAN.md

@@ -1,11 +1,8 @@
 # Understanding VLANs and Their Operation
 
-A VLAN (Virtual LAN) is an overlay layer 2 network that helps us organize devices
-into different groups connected to a virtual network on the physical network.
-
-VLANs help us partition a LAN into smaller virtual networks for security
-purposes. This allows us to have different logically distinct virtual networks
-rather than having many physical small LANs.
+VLANs help us partition a LAN into smaller virtual networks for security purposes.
+This allows us to have different logically distinct virtual networks rather than
+having many physical small LANs.
 
 Computers on the same network (LAN) communicate either through wireless access
 points (AP) or through ethernet cables. All computers on a LAN are connected to
@@ -17,30 +14,30 @@ There are two types of VLANs:
 
 - **Port-Based VLAN**: A VLAN is assigned to a particular port, and any machine
   connected to that port automatically joins that VLAN
-- **User-Based or Dynamic VLAN**: VLANs are assigned based on user
-  authentication or other dynamic criteria
+- **User-Based or Dynamic VLAN**: VLANs are assigned based on user authentication
+  or other dynamic criteria
 
 ## Network Architecture
 
 ```mermaid
 flowchart TD
     subgraph "Physical Network Infrastructure"
-        SW["Switch"] 
+        SW["Switch"]
     end
 
     subgraph "VLAN 10 (Marketing)"
-        PC1["Computer 1\nIP: 192.168.10.2\nVLAN 10"]
-        PC2["Computer 2\nIP: 192.168.10.3\nVLAN 10"]
+        PC1["Computer 1\nIP address: 192.168.10.2\nVLAN 10"]
+        PC2["Computer 2\nIP address: 192.168.10.3\nVLAN 10"]
     end
 
     subgraph "VLAN 20 (Engineering)"
-        PC3["Computer 3\nIP: 192.168.20.2\nVLAN 20"]
-        PC4["Computer 4\nIP: 192.168.20.3\nVLAN 20"]
+        PC3["Computer 3\nIP address: 192.168.20.2\nVLAN 20"]
+        PC4["Computer 4\nIP address: 192.168.20.3\nVLAN 20"]
     end
 
     subgraph "VLAN 30 (Finance)"
-        PC5["Computer 5\nIP: 192.168.30.2\nVLAN 30"]
-        PC6["Computer 6\nIP: 192.168.30.3\nVLAN 30"]
+        PC5["Computer 5\nIP address: 192.168.30.2\nVLAN 30"]
+        PC6["Computer 6\nIP address: 192.168.30.3\nVLAN 30"]
     end
 
     SW --- PC1

docs/ansible_docs.md

@@ -1,42 +1,40 @@
 # Ansible
 
 Ansible is an open-source automation tool used for automating applications,
-service orchestration, and server configuration management.
+service orchestration, and the configuration and management of servers.
 
 ## Prerequisites
 
-Before diving into Ansible, installation is necessary. Follow the tutorial on
-how to install Ansible here:
+Before diving into Ansible, its installation is greatly necessary. To do so,
+follow the tutorial on how to install Ansible here:
 
 - [Ansible Installation](/docs/tutorials/ansible_tuto.md)
 
 ## Features
 
 Ansible provides several tools to facilitate server management:
 
-- **OpenSSH**: Used for setting up SSH and generating keys for server
-  authentication
-- **Ad-hoc Commands**: Used as alternatives to playbooks for quick and simple
-  tasks
-- **Playbooks**: YAML files containing specific tasks to manage servers, used
-  for complex tasks
-- **Inventory File**: Contains the list of servers grouped by categories for
-  organized management
+- **OpenSSH**: Used for setting up SSH and generating keys for authenticating
+  with servers
+- **Ad-hoc Commands**: Used as alternatives to playbooks, typically for quick
+  and simple tasks
+- **Playbooks**: YAML files containing specific tasks to manage servers,
+  commonly used for more complex tasks
+- **Inventory File**: Contains the list of servers grouped by categories,
+  allowing for organized management of your infrastructure
 
 ## How It Works
 
 ### SSH Configuration
 
 Ansible relies on SSH to authenticate and configure servers. While you can use a
 single SSH key for managing all servers, it is often recommended to use two
-separate keys:
-
-- One for personal SSH logins
-- Another specifically for automation with Ansible
+separate keys for different tasks: one for personal SSH logins and another
+specifically for automation with Ansible.
 
 #### Creation of SSH Keys
 
-SSH is a key aspect that Ansible uses to connect remotely to servers,
+SSH is a key aspect that Ansible uses to connect remotely to all the servers,
 eliminating the need for credential passwords each time a user logs in.
 
 To create SSH keys for both personal use and automation, follow these steps:
@@ -50,18 +48,18 @@ To create SSH keys for both personal use and automation, follow these steps:
 - **Ansible Key (for automation tasks):**
 
   ```sh
-  ssh-keygen -t ed25519 -f ~/.ssh/ansible_key -C "ansible@$(hostname)"
+  ssh-keygen -t ed25519 -f ~/.ssh/ansible_key -C "ansible@$(host name)"
   ```
 
-After creating the keys, copy them to the servers using:
+After creating the keys, copy them to the servers using the following commands:
 
 ```sh
 ssh-copy-id -i ~/.ssh/ansible_key.pub user@server_ip
 ssh-copy-id -i ~/.ssh/personal_key.pub user@server_ip
 ```
 
-Replace `user@server_ip` with the appropriate username and IP address or
-hostname of your target server.
+Replace `user@server_ip` with the appropriate username and IP address or host
+name of your target server.
 
 For more details, see:
 
@@ -70,11 +68,9 @@ For more details, see:
 ### Launching a Playbook
 
 Playbooks define the automation logic in a structured way. When you run a
-playbook, Ansible:
-
-1. Loads temporary modules to the remote server
-2. Executes the tasks (e.g., install packages, start services)
-3. Removes the modules after execution
+playbook, Ansible loads temporary modules to the remote server to execute the
+tasks (e.g., install packages, start services). After execution, these modules
+are removed.
 
 For more details on playbooks:
 
@@ -92,30 +88,33 @@ To learn more about ad-hoc commands, see:
 
 ## Server Management
 
-Ansible excels at server management by providing:
+Ansible is very good for server management due to the fact that it provides:
 
-- **Playbooks**: Makes task handover between teams seamless, as all required
-  tasks are documented in playbooks
-- **Inventory Files**: Organizes server IP addresses by groups, making it easy
-  to manage and assign tasks
-- **SSH Key**: Automates authentication, making server access and management
-  more efficient
+- **Playbooks**: If the group managing the servers is shifted and another one is
+  placed, as the tasks that are to be run are in the playbook, this will be easy
+  for the new group to understand what is to be done
+- **Inventory Files**: Placing all the servers' IP addresses in a file makes it
+  easy to recall and know for which tasks are for which server. Just like in an
+  inventory file, there is a group of servers for databases and more
+- **SSH Key**: The fact that Ansible uses SSH keys to handle authentication
+  makes it ideal for movement as the login is already an automated action
 
 ## What If Ansible Becomes Outdated?
 
-If Ansible becomes outdated or no longer maintained, other modern tools can be
-used for infrastructure automation and server management:
+If Ansible becomes outdated or no longer maintained, there are other modern
+tools that can be used for infrastructure automation and server management:
 
 - [Chef](https://docs.chef.io/manage/)
 - [SaltStack](https://github.com/saltstack/salt)
 - [Pulumi](https://www.pulumi.com/)
 - [Puppet](https://www.puppet.com/)
 
-Each tool has its specific strengths:
+Each of them is based on specific aspects:
 
-| Tools     | Language    | Best Used For                                |
-|-----------|-------------|---------------------------------------------|
-| Chef      | Ruby        | Complex enterprise environments              |
-| SaltStack | YAML        | Large-scale deployments                     |
-| Pulumi    | Various     | Cloud infrastructure and resource management |
-| Puppet    | Puppet DSL  | Large-scale environments                    |
+| Tools    | Language             | Best Used For                      |
+|-----------|-------------------------|----------------------------------|
+| Chef    | Ruby       | Complex enterprise environments   |
+|SaltStack| YAML       | Large-scale deployments |
+| Pulumi    | Programming language | Infrastructure provision and |
+|           | (various)            | cloud resource management|
+| Puppet | Puppet DSL| Large-scale environments |