Merge pull request #3 from RadinPirouz/main

Update Dev Branch
2024-10-31 09:08:30 +03:30
parent bc1ba4cb46 b1e6552605
commit eb9ed35417
62 changed files with 2148 additions and 296 deletions
--- a/Ansible/Document.md
+++ b/Ansible/Document.md
@@ -1,76 +0,0 @@
 # Ansible Module Usage
 Ansible modules are standalone scripts that can be used within Ansible to perform various tasks on managed nodes. Here are some examples of using Ansible modules:
 ## Basic Module Execution
 To execute a module against all hosts in your inventory file:
 ```bash
 ansible -m <module> all -i <inventory_file>
 ```
 Example:
 ```bash
 ansible -m ping all -i server.ini
 ```
 ## Module Execution with Arguments
 You can pass arguments to modules using the `-a` flag:
 ```bash
 ansible -m <module> -a <arguments> -i <inventory_file> <group_of_servers>
 ```
 Examples:
 ```bash
 ansible -m command -a "uptime" -i server.ini all
 ansible -m command -a "uname -a" -i server.ini all
 ```
 ## Running Commands as sudo
 If the command requires root privileges, you can use the `--become` or `-b` flag:
 ```bash
 ansible -m <module> -a "<command>" --become -i <inventory_file> <group_of_servers>
 ```
 Example:
 ```bash
 ansible -m command -a "reboot" --become -i server.ini all
 ```
 ## More Examples
 Here are some additional examples demonstrating Ansible module usage:
 - Gathering facts from all hosts:
 ```bash
 ansible -m setup all -i server.ini
 ```
 - Copying a file to all hosts:
 ```bash
 ansible -m copy -a "src=/path/to/src/file dest=/path/to/destination/" -i server.ini all
 ```
 - Installing a package using apt module:
 ```bash
 ansible -m apt -a "name=<package_name> state=present" -i server.ini all
 ```
 - Restarting a service:
 ```bash
 ansible -m service -a "name=<service_name> state=restarted" -i server.ini all
 ```
--- a/Tools/TelegramBot/GettingStarted.md
+++ b/Tools/TelegramBot/GettingStarted.md
--- a/Tools/TelegramBot/LocalTelegramBotServer.md
+++ b/Tools/TelegramBot/LocalTelegramBotServer.md
--- a/Tools/TelegramBot/WebHooks.md
+++ b/Tools/TelegramBot/WebHooks.md
--- a/Management/Git/main.md
+++ b/Management/Git/main.md
@@ -0,0 +1,155 @@
 # Git Commands Guide
 ## Getting Started with Git
 ### 1. Installing Git
 Before you begin, ensure Git is installed on your machine. You can download it from [git-scm.com](https://git-scm.com/).
 ### 2. Check Git Installation
 To verify that Git is installed, run:
 ```bash
 git --version
 ```
 ### 3. Configure Git User Information
 Set up your name and email address, which will be used for your commits:
 ```bash
 git config --global user.name "Your Name"
 git config --global user.email "your.email@example.com"
 ```
 ## Configuring Git to Use a Custom SSH Key
 If you need to use a specific SSH key for your Git operations, you can configure Git as follows:
 ```bash
 git config --add --local core.sshCommand 'ssh -i <PATH_TO_SSH_KEY>'
 ```
 *Replace `<PATH_TO_SSH_KEY>` with the actual path to your SSH key file.*
 ## Creating and Managing a Local Git Repository
 ### 1. Initialize a Git Repository
 Start by creating a new Git repository in your local project directory:
 ```bash
 git init -b main
 ```
 *The `-b main` flag sets the default branch name to "main".*
 ### 2. Add Files and Commit Changes
 Next, stage all your files and create your initial commit:
 ```bash
 git add -A
 git commit -m "Initial Commit"
 ```
 *The `git add -A` command stages all changes, while the `git commit` command records those changes with a descriptive message.*
 ### 3. Connect to a Remote Repository
 Now, link your local repository to a remote GitHub repository:
 ```bash
 git remote add origin <Repo-Link>
 ```
 *Replace `<Repo-Link>` with the URL of your GitHub repository.*
 ### 4. Push Changes to GitHub
 Finally, push your initial commit to the remote repository:
 ```bash
 git push origin main
 ```
 ## Common Git Commands for Beginners
 ### 1. Check the Status of Your Repository
 To see which changes are staged, unstaged, or untracked:
 ```bash
 git status
 ```
 ### 2. View Commit History
 To view the commit history of your repository:
 ```bash
 git log
 ```
 *You can press `q` to exit the log view.*
 ### 3. Viewing Changes
 To see changes made to files before staging them:
 ```bash
 git diff
 ```
 ### 4. Staging Individual Files
 If you want to stage specific files instead of all changes:
 ```bash
 git add <filename>
 ```
 *Replace `<filename>` with the name of the file you wish to stage.*
 ### 5. Undoing Changes
 To unstage a file that you added by mistake:
 ```bash
 git reset <filename>
 ```
 To discard changes in a file and revert it to the last committed state:
 ```bash
 git checkout -- <filename>
 ```
 ### 6. Cloning a Repository
 If you want to create a copy of an existing remote repository:
 ```bash
 git clone <Repo-Link>
 ```
 *Replace `<Repo-Link>` with the URL of the repository you want to clone.*
 ### 7. Creating a New Branch
 To create a new branch for development:
 ```bash
 git checkout -b <branch-name>
 ```
 *Replace `<branch-name>` with your desired branch name.*
 ### 8. Merging Branches
 To merge changes from another branch into your current branch:
 ```bash
 git merge <branch-name>
 ```
--- a/Automation/Ansible/1-Inventory.md
+++ b/Automation/Ansible/1-Inventory.md
@@ -0,0 +1,84 @@
 # **Ansible Configuration Guide**
 Ansible is a powerful automation tool used to manage and configure servers. This guide provides examples of how to structure your inventory files, which are essential for defining the servers and groups that Ansible will manage. Additionally, it covers common Ansible commands for interacting with your servers.
 ## **Inventory File Examples**
 ### **INI Format**
 The INI format is one of the simplest ways to define your inventory. Below are two examples showcasing different use cases.
 #### **Example 1: Single Group Inventory**
 In this example, all servers are grouped under a single `[all]` group. Each server is defined with specific connection details:
 ```ini
 [all]
 <server-name> ansible_host=<server-ip> ansible_ssh_pass=<password> ansible_port=<ssh-port> ansible_connection=<connection-type>
 ```
 - **`<server-name>`**: A label or hostname for your server.
 - **`<server-ip>`**: The IP address of the server.
 - **`ansible_ssh_pass`**: The SSH password for connecting to the server.
 - **`ansible_port`**: The port used for SSH connections.
 - **`ansible_connection`**: The connection type (e.g., ssh, winrm).
 #### **Example 2: Grouped Inventory with Variables**
 This example demonstrates grouping servers by roles (e.g., `web`, `db`, `bk`). Group-specific variables are defined under `[all:vars]`:
 ```ini
 [all]
 <server1-name> ansible_host=<server1-ip>
 <server2-name> ansible_host=<server2-ip>
 <server3-name> ansible_host=<server3-ip>
 [web]
 <server1-name>
 [db]
 <server2-name>
 [bk]
 <server3-name>
 [all:vars]
 ansible_user=<username>
 ansible_port=<ssh-port>
 ```
 - **Groups**: Servers are organized into different groups (`web`, `db`, `bk`).
 - **`[all:vars]`**: Common variables for all groups.
 ### **YAML Format**
 The YAML format provides a more structured and readable way to define your inventory, especially useful for larger or more complex environments.
 #### **Example: Grouped Inventory with Host-Specific Variables**
 This example illustrates how to define an inventory with nested groups and host-specific variables:
 ```yaml
 all:
  children:
    webservers:
      hosts:
        192.168.1.100:
          ansible_port: 22
        192.168.1.110:
          ansible_port: 1357
      vars:
        http_port: 8080
    dbserver:
      hosts:
        db.main.local:
          db_user: admin
          db_pass: secret
 ```
 - **`children`**: Groups within the `all` group, such as `webservers` and `dbserver`.
 - **`hosts`**: List of servers under each group, with their specific variables.
 - **`vars`**: Group-specific variables, such as `http_port` for `webservers`.
--- a/Automation/Ansible/2-Commands.md
+++ b/Automation/Ansible/2-Commands.md
@@ -0,0 +1,106 @@
 # **Ansible Commands**
 Below are some frequently used Ansible commands for managing your servers.
 ### **Listing Hosts**
 List all hosts defined in the inventory file:
 ```bash
 ansible --list-hosts all -i servers.ini
 # or for YAML format
 ansible --list-hosts all -i servers.yaml
 ```
 ### **Ping All Servers**
 Check the connectivity of all servers:
 ```bash
 ansible -m ping all -i server.ini
 ```
 ### **Execute Commands**
 Run a command (e.g., `uptime`) on all servers:
 ```bash
 ansible -m command -a "uptime" all -i server.ini
 ```
 ### **Copy Files to Servers**
 Copy a file from the Ansible server to all target servers:
 ```bash
 ansible -m copy -a "src=<file-location-on-ansible-server> dest=<destination-location-on-server>" all -i server.ini
 ```
 ### **Run Commands with Sudo**
 Execute a command with elevated privileges (sudo) as the root user:
 ```bash
 ansible -m command -a "uptime" all -i server.ini --become --become-user root --become-method sudo 
 ```
 ### **Install a Package**
 Install the `nginx` package on all servers:
 ```bash
 ansible -m apt -a "name=nginx state=present" --become --become-user root --become-method sudo
 ```
 ### **Uninstall a Package**
 Remove the `nginx` package from all servers:
 ```bash
 ansible -m apt -a "name=nginx state=absent" --become --become-user root --become-method sudo
 ```
 ### **Update and Upgrade Packages**
 Update the package list and upgrade all packages:
 ```bash
 ansible -m apt -a "upgrade=yes update_cache=yes" --become --become-user root --become-method sudo
 ```
 ---
 ## **Advanced Usage and Notes**
 ### **Special Considerations**
 - **Module Limitations**: The `command` module does not support special characters or shell features. For commands requiring shell features (like pipes or redirection), use the `shell` module.
  Example:
  ```bash
  ansible -m shell -a "cat /etc/passwd | grep -l" all -i server.ini --become
  ```
 - **Raw Module**: Use the `raw` module for devices that do not have Python installed. It allows you to execute raw SSH commands directly.
  Example:
  ```bash
  ansible -m raw -a "hostnamectl" all -i server.ini --become
  ```
 ### **Gathering System Facts**
 Use the `setup` module to gather system facts from all servers:
 ```bash
 ansible -m setup --become all -i server.ini
 ```
 You can filter specific facts:
 ```bash
 ansible -m setup -a "filter=ansible_memory" --become all -i server.ini
 ansible -m setup -a "filter=ansible_distribution" --become all -i server.ini
 ```
--- a/Automation/Ansible/3-PlayBook.md
+++ b/Automation/Ansible/3-PlayBook.md
@@ -0,0 +1,374 @@
 # Ansible Playbook Guide
 Ansible Playbooks are YAML files that automate server configuration, deployment, and management tasks. This guide covers the basics of running a playbook, key concepts, and provides example playbooks to help you get started.
 ## Table of Contents
 - [Ansible Playbook Guide](#ansible-playbook-guide)
  - [Table of Contents](#table-of-contents)
  - [Running an Ansible Playbook](#running-an-ansible-playbook)
    - [Example](#example)
  - [Key Concepts](#key-concepts)
  - [Example Playbooks](#example-playbooks)
    - [1. Simple APT Cache Update](#1-simple-apt-cache-update)
    - [2. Update APT Cache and Install Nginx](#2-update-apt-cache-and-install-nginx)
    - [3. Install Nginx and Copy Configuration File](#3-install-nginx-and-copy-configuration-file)
    - [4. Full Nginx Deployment: Install, Configure, and Restart](#4-full-nginx-deployment-install-configure-and-restart)
    - [5. Show Debug Message](#5-show-debug-message)
    - [6. Use a Shell Command](#6-use-a-shell-command)
    - [7. Playbook with Conditional Statements](#7-playbook-with-conditional-statements)
    - [8. Check File Existence Using the `stat` Module](#8-check-file-existence-using-the-stat-module)
    - [9. Standalone Nginx Installation](#9-standalone-nginx-installation)
    - [10. Create a User](#10-create-a-user)
    - [11. Install Multiple Packages](#11-install-multiple-packages)
      - [Using a Loop](#using-a-loop)
      - [Using a List](#using-a-list)
    - [12. Create Multiple Users](#12-create-multiple-users)
    - [13. Import Playbook Files](#13-import-playbook-files)
    - [14. Remove `resolv.conf`](#14-remove-resolvconf)
    - [15. Enable SSH Login Banner](#15-enable-ssh-login-banner)
 ---
 ## Running an Ansible Playbook
 To run an Ansible playbook, use the following command:
 ```bash
 ansible-playbook <playbook.yaml> -i <inventory-file.ini>
 ```
 - **`<playbook.yaml>`**: The path to your playbook file.
 - **`<inventory-file.ini>`**: The path to your inventory file (can be in INI or YAML format).
 ### Example
 ```bash
 ansible-playbook deploy_nginx.yaml -i inventory.ini
 ```
 This command runs the `deploy_nginx.yaml` playbook on the hosts defined in `inventory.ini`.
 ## Key Concepts
 - **`hosts: all`**: Specifies the target hosts from the inventory on which the playbook should run.
 - **`become: yes`**: Executes tasks with elevated privileges (sudo).
 - **Handlers**: Special tasks triggered by other tasks using the `notify` directive.
 - **Variables**: Dynamic values that can be reused across tasks and playbooks for flexibility and maintainability.
 ---
 ## Example Playbooks
 ### 1. Simple APT Cache Update
 This playbook updates the APT package cache on all specified hosts.
 ```yaml
 - name: Update APT Cache
  hosts: all
  become: yes
  tasks:
    - name: Update apt-cache
      ansible.builtin.apt:
        update_cache: yes
 ```
 ### 2. Update APT Cache and Install Nginx
 This playbook updates the APT cache and installs the Nginx web server.
 ```yaml
 - name: Update APT Cache and Install Nginx
  hosts: all
  become: yes
  tasks:
    - name: Update apt-cache and install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: yes
 ```
 ### 3. Install Nginx and Copy Configuration File
 This playbook installs Nginx and copies a custom configuration file from the Ansible control node to the target hosts.
 ```yaml
 - name: Install Nginx and Copy Configuration
  hosts: all
  become: yes
  tasks:
    - name: Update apt-cache and install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: yes
    - name: Copy Nginx configuration file
      ansible.builtin.copy:
        src: /root/ansible/nginx.conf
        dest: /etc/nginx/nginx.conf
 ```
 ### 4. Full Nginx Deployment: Install, Configure, and Restart
 This playbook demonstrates a complete Nginx deployment, including installation, configuration, and restarting the service.
 ```yaml
 - name: Full Nginx Deployment
  hosts: all
  become: yes
  tasks:
    - name: Update apt-cache and install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: yes
    - name: Copy Nginx configuration file
      ansible.builtin.copy:
        src: /root/ansible/nginx.conf
        dest: /etc/nginx/nginx.conf
      notify: Restart Nginx
  handlers:
    - name: Restart Nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
 ```
 ### 5. Show Debug Message
 Use the `debug` module to display a message during playbook execution. This is useful for testing or providing feedback within your playbooks.
 ```yaml
 - name: Show Debug Message
  hosts: all
  tasks:
    - name: Display debug message
      ansible.builtin.debug:
        msg: "Test Message"
 ```
 ### 6. Use a Shell Command
 Run a shell command and capture the output for further use within the playbook.
 ```yaml
 - name: Execute Shell Command
  hosts: all
  tasks:
    - name: Run a shell command
      ansible.builtin.shell:
        cmd: echo "Hello, Ansible!"
      register: shell_output
    - name: Display Shell Output
      ansible.builtin.debug:
        msg: "Output is: {{ shell_output.stdout }}"
 ```
 ### 7. Playbook with Conditional Statements
 This playbook demonstrates using conditional statements to check if a file exists and take action based on the result.
 ```yaml
 - name: Check if File Exists
  hosts: all
  tasks:
    - name: Check if file exists
      ansible.builtin.shell:
        cmd: ls /path/to/file
      register: file_output
      ignore_errors: yes
    - name: File Exists
      ansible.builtin.debug:
        msg: "File exists"
      when: file_output.rc == 0
    - name: File Does Not Exist
      ansible.builtin.debug:
        msg: "File does not exist"
      when: file_output.rc != 0
 ```
 ### 8. Check File Existence Using the `stat` Module
 A more reliable method to check if a file exists using the `stat` module.
 ```yaml
 - name: Check if File Exists
  hosts: all
  tasks:
    - name: Check if file exists
      ansible.builtin.stat:
        path: /path/to/file
      register: file_stat
    - name: File Exists
      ansible.builtin.debug:
        msg: "File exists"
      when: file_stat.stat.exists
    - name: File Does Not Exist
      ansible.builtin.debug:
        msg: "File does not exist"
      when: not file_stat.stat.exists
 ```
 ### 9. Standalone Nginx Installation
 This playbook installs Nginx on both Debian-based and RedHat-based systems by detecting the operating system family.
 ```yaml
 - name: Install Nginx
  hosts: all
  become: yes
  tasks:
    - name: Install on Debian-based systems
      ansible.builtin.apt:
        name: nginx
        state: present
      when: ansible_facts['os_family'] == "Debian"
    - name: Install on RedHat-based systems
      ansible.builtin.yum:
        name: nginx
        state: present
      when: ansible_facts['os_family'] == "RedHat"
 ```
 ### 10. Create a User
 This playbook checks if a user exists and creates the user if it does not.
 ```yaml
 - name: Manage User Account
  hosts: all
  become: yes
  tasks:
    - name: Check if user exists
      ansible.builtin.command:
        cmd: id new_user
      register: user_data
      ignore_errors: yes
    - name: Create user
      ansible.builtin.user:
        name: new_user
        state: present
      when: user_data.rc != 0
 ```
 ### 11. Install Multiple Packages
 These examples show how to install multiple packages using either a loop or a list.
 #### Using a Loop
 ```yaml
 - name: Install Multiple Packages with Loop
  hosts: all
  become: yes
  tasks:
    - name: Install packages
      ansible.builtin.apt:
        name: "{{ item }}"
        state: present
      loop:
        - vim
        - git
        - nginx
 ```
 #### Using a List
 ```yaml
 - name: Install Multiple Packages as a List
  hosts: all
  become
 : yes
  tasks:
    - name: Install packages
      ansible.builtin.apt:
        name: ["vim", "nginx", "git"]
        state: present
 ```
 ### 12. Create Multiple Users
 This playbook creates multiple users with different groups.
 ```yaml
 - name: Create Multiple Users
  hosts: all
  become: yes
  tasks:
    - name: Create users
      ansible.builtin.user:
        name: "{{ item.name }}"
        group: "{{ item.group }}"
        state: "{{ item.state }}"
      loop:
        - { name: "radin", state: "present", group: "sudo" }
        - { name: "test", state: "present", group: "dev" }
        - { name: "test2", state: "present", group: "test_unit" }
 ```
 ### 13. Import Playbook Files
 You can split your playbooks into smaller, manageable files and include them as needed.
 ```yaml
 - name: Nginx Setup
  import_playbook: nginx.yaml
 - name: User Creation
  import_playbook: users.yaml
 ```
 ### 14. Remove `resolv.conf`
 This playbook removes the `resolv.conf` file from all specified hosts.
 ```yaml
 - name: Remove resolv.conf
  hosts: all
  become: yes
  tasks:
    - name: Remove resolv.conf
      ansible.builtin.file:
        path: /etc/resolv.conf
        state: absent
      ignore_errors: true  # Ignore errors if the file does not exist
 ```
 ### 15. Enable SSH Login Banner
 This playbook enables an SSH login banner by copying a banner file and updating the SSH configuration.
 ```yaml
 - name: Enable SSH Login Banner
  hosts: all
  become: yes
  tasks:
    - name: Copy Banner
      ansible.builtin.copy:
        src: "issue.net"
        dest: /etc/issue.net
      ignore_errors: true  # Ignore errors if the source file does not exist
    - name: Update SSHD Config File for Banner
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Banner'
        line: 'Banner /etc/issue.net'
    - name: Restart SSH Service
      ansible.builtin.service:
        name: sshd
        state: restarted
 ```
--- a/Automation/Ansible/4-Roles.md
+++ b/Automation/Ansible/4-Roles.md
@@ -0,0 +1,251 @@
 # Ansible Roles and Directory Structure
 Ansible roles help organize automation tasks, variables, files, and other resources into a structured format. This organization promotes reusability, simplifies management, and results in cleaner, more maintainable code.
 ## Creating a Role Directory Structure
 To create a new Ansible role, use the following command:
 ```bash
 ansible-galaxy init <role_name>
 ```
 This command generates the standard directory structure for an Ansible role, which includes the following directories:
 ### Ansible Role Directory Breakdown
 1. **`roles/`**: The top-level directory where all roles are stored. Each role has its own directory within this folder.
 2. **`<role_name>/`**: Each role directory, named after the role (e.g., `webserver`), contains the following subdirectories:
   - **`tasks/`**: Defines the list of tasks to be executed by the role, usually in a `main.yml` file.
   - **`handlers/`**: Contains handlers that are triggered by tasks, defined in a `main.yml` file.
   - **`defaults/`**: Holds default variables for the role in `defaults/main.yml`.
   - **`vars/`**: Contains variables with higher precedence than `defaults`, stored in `vars/main.yml`.
   - **`files/`**: Stores static files to be deployed to managed nodes.
   - **`templates/`**: Holds Jinja2 templates for dynamic file generation.
   - **`meta/`**: Contains metadata about the role, including dependencies.
   - **`library/`** (Optional): Stores custom modules.
   - **`module_utils/`** (Optional): Contains utilities for custom modules.
   - **`lookup_plugins/`** (Optional): Holds custom lookup plugins.
   - **`filter_plugins/`** (Optional): Stores custom filter plugins.
 This structure ensures roles are well-organized, making them easier to share and reuse.
 ## Host-Specific Variables (`host_vars`)
 `host_vars` define variables specific to individual hosts (managed nodes), allowing customization of configurations and behavior at the host level.
 ### Key Points:
 - **Location**: `host_vars` is typically located at the same level as your inventory file or playbook.
 - **Structure**: Inside `host_vars`, create files named after each host (e.g., `webserver1.example.com.yml`).
 - **Precedence**: Variables in `host_vars` override group variables and defaults.
 ### Example:
 ```yaml
 # host_vars/webserver1.example.com.yml
 http_port: 8080
 max_clients: 200
 ```
 ## Group-Specific Variables (`group_vars`)
 `group_vars` define variables for groups of hosts, reducing repetition and enhancing organization when configuring multiple hosts with common settings.
 ### Key Points:
 - **Location**: `group_vars` is typically located at the same level as your inventory file or playbook.
 - **Structure**: Inside `group_vars`, create files named after each group (e.g., `webservers.yml`).
 - **Precedence**: Variables in `group_vars` have a lower precedence than `host_vars` but higher than global variables.
 ### Example:
 ```yaml
 # group_vars/dbservers.yml
 db_port: 5432
 db_user: "dbadmin"
 ```
 ## The `files` Directory in Ansible Roles
 The `files` directory in an Ansible role stores static files that are copied to managed nodes.
 ### Usage:
 - **Static Files**: Files that do not require modification before being transferred.
 - **Task Example**:
 ```yaml
 # roles/my_role/tasks/main.yml
 - name: Copy a script to the target host
  ansible.builtin.copy:
    src: example_script.sh
    dest: /usr/local/bin/example_script.sh
    mode: '0755'
 ```
 ## The `templates` Directory in Ansible Roles
 The `templates` directory stores Jinja2 templates, which are dynamically processed to create files on managed nodes.
 ### Example:
 ```yaml
 # roles/my_role/tasks/main.yml
 - name: Configure application
  ansible.builtin.template:
    src: my_config_file.conf.j2
    dest: /etc/myapp/my_config_file.conf
 ```
 ### Sample Template:
 ```jinja
 # my_config_file.conf.j2
 server_name: {{ server_name_variable }}
 {% if enable_feature %}
 enable_feature: true
 {% else %}
 enable_feature: false
 {% endif %}
 {% for item in item_list %}
 item_name: {{ item.name }}
 item_value: {{ item.value }}
 {% endfor %}
 database_host: {{ database_host_variable | default('localhost') }}
 ```
 ## Handlers in Ansible Roles
 Handlers are tasks triggered by other tasks, typically used to perform actions like restarting a service when a configuration change occurs.
 ### Example:
 ```yaml
 # roles/my_role/tasks/main.yml
 - name: Install apache2
  ansible.builtin.apt:
    name: apache2
    state: present
  notify: restart apache2
 handlers:
  - name: restart apache2
    ansible.builtin.service:
      name: apache2
      state: restarted
 ```
 ## Default Variables in Ansible Roles (`defaults` Directory)
 The `defaults` directory contains role-specific default variables with the lowest precedence, allowing them to be easily overridden.
 ### Example:
 ```yaml
 # roles/my_role/defaults/main.yml
 web_server_port: 80
 max_clients: 100
 ```
 ## The `tasks` Directory in Ansible Roles
 The `tasks` directory is where the main actions of a role are defined. It typically contains a `main.yml` file, which outlines the tasks Ansible should perform.
 ### Example:
 ```yaml
 # roles/my_role/tasks/main.yml
 - name: Include setup tasks
  import_tasks: setup.yml
 - name: Install required packages
  import_tasks: install.yml
 - name: Configure application
  import_tasks: configure.yml
 ```
 ## Importing Roles in a Playbook
 You can import multiple roles within a playbook as shown below:
 ```yaml
 - hosts: all
  roles:
    - role: role1
    - role: role2
    - role: role3
  gather_facts: yes
 ```
 ## Importing Other Tasks
 In addition to roles, you can also include specific task files within a playbook:
 ```yaml
 - name: Basic Setup
  include_tasks: task_file.yaml
 ```
 ## Working with Tags
 Tags allow you to run specific parts of your playbook or roles. They are useful when you want to execute only a subset of tasks.
 ### Example:
 ```yaml
 - hosts: all
  roles:
    - role: role1
  gather_facts: yes
  tags: [install]
 ```
 ### Running Playbooks with Tags
 ```bash
 ansible-playbook -i inventory.ini main.yml -t install
 ```
 ### Listing Tasks with Tags
 To see which tasks will run under a specific tag, use:
 ```bash
 ansible-playbook -i inventory.ini main.yml -t install --list-tasks
 ```
 ## Copying `resolv.conf` with a Jinja Template
 Use a Jinja template to dynamically generate the `resolv.conf` file.
 ### Playbook:
 ```yaml
 - name: Copy resolv.conf
  ansible.builtin.template:
    src: resolv.conf.j2
    dest: /etc/resolv.conf
    mode: 0644
 ```
 ### Jinja Template (`resolv.conf.j2`):
 ```jinja
 nameserver {{ DNS1 }}
 nameserver {{ DNS2 }}
 ```
 ### Group Variables (`group_vars`):
 ```yaml
 # group_vars/all.yml
 DNS1: 8.8.8.8
 DNS2: 4.2.2.4
 ```
--- a/Automation/Ansible/5-Vault.md
+++ b/Automation/Ansible/5-Vault.md
@@ -0,0 +1,93 @@
 ## Ansible Vault Guide
 ### 1. Creating an Encrypted File with Ansible Vault
 To create a new encrypted file using Ansible Vault, use the following command:
 ```bash
 ansible-vault create secret.yaml
 ```
 You will be prompted to enter a password to encrypt the file. After that, you can add your variables, like in the example below:
 ```yaml
 password: 123
 ```
 Once you save and exit, the file will be encrypted. The content of the `secret.yaml` file will look like this:
 ```yaml
 $ANSIBLE_VAULT;1.1;AES256
 33653733613264663235353662336132376134313266666561363932373236653130393135373562
 3838613763626464343334306661643634323537376537630a333833356462616666303833613066
 35653039343366336233613164313365373466643262303761623363383530396336613438326263
 3536633236376635320a396430353564356331623133653866663138373265363466353663353034
 3830
 ```
 ### 2. Using Encrypted Variables in a Playbook
 To use the encrypted variables stored in `secret.yaml`, include the file in your playbook using `vars_files`.
 #### Example Playbook
 ```yaml
 - hosts: all
  become: yes
  vars_files:
    - secret.yaml
  tasks:
    - name: Print Secret Password
      debug:
        msg: "Password is {{ password }}"
 ```
 This playbook reads the encrypted `password` variable from `secret.yaml` and prints it.
 ### 3. Running the Playbook with Vault
 To run a playbook that uses an encrypted file, use the following command:
 ```bash
 ansible-playbook main.yaml -i servers.ini --ask-vault-pass --become
 ```
 - **`--ask-vault-pass`**: Prompts for the Vault password before executing the playbook.
 - **`--become`**: Ensures that the tasks are executed with elevated privileges (e.g., root).
 When you run the command, you will be prompted to enter the Vault password to decrypt `secret.yaml` and access the `password` variable.
 ### 4. Additional Vault Commands
 - **Edit an existing encrypted file**:
  ```bash
  ansible-vault edit secret.yaml
  ```
 - **Rekey (change the Vault password)**:
  ```bash
  ansible-vault rekey secret.yaml
  ```
 - **View the contents of an encrypted file (without decrypting it)**:
  ```bash
  ansible-vault view secret.yaml
  ```
 - **Decrypt a Vault file permanently**:
  ```bash
  ansible-vault decrypt secret.yaml
  ```
 - **Encrypt a previously unencrypted file**:
  ```bash
  ansible-vault encrypt secret.yaml
  ```
 Ansible Vault provides a powerful way to securely manage sensitive data in your automation processes.
--- a/Automation/Ansible/Additional.md
+++ b/Automation/Ansible/Additional.md
@@ -0,0 +1,19 @@
 ### Exit Codes Overview
 Understanding exit codes is crucial when dealing with shell commands:
 | Exit Code | Description                                   |
 |-----------|-----------------------------------------------|
 | 0         | Success: The command completed successfully.  |
 | 1         | General error: Catchall for general errors.   |
 | 2         | Misuse of shell builtins (e.g., `cd`).        |
 | 126       | Command invoked cannot execute.               |
 | 127       | Command not found.                            |
 | 128       | Invalid argument to exit.                     |
 | 130       | Script terminated by Control-C.               |
 | 137       | Script terminated by `kill` (or OOM).         |
 | 139       | Segmentation fault.                           |
 | 141       | Script terminated by `kill -13` (SIGPIPE).    |
 | 143       | Script terminated by `kill -15` (SIGTERM).    |
 | 255       | Exit status out of range (exceeds 255).       |
--- a/Orchestration/Docker/1-Information.md
+++ b/Orchestration/Docker/1-Information.md
@@ -0,0 +1,34 @@
 # Docker Overview
 ## What is Docker?
 [Docker](https://www.docker.com/) is an open-source platform that streamlines the development, shipping, and deployment of applications using containers. Containers are lightweight, self-contained environments that bundle everything required to run an application, including code, runtime, libraries, and dependencies. By using Docker, developers can ensure that applications run consistently across different environments, whether in development, testing, or production.
 ## Core Docker Concepts
 ### Stateless vs. Stateful Applications
 - **Stateless**: These applications do not retain user data between sessions. For example, web servers like Nginx are typically stateless, as they don’t need to save any data between requests.
 - **Stateful**: These applications retain data across sessions, which means they store information that can be retrieved later. Databases are common examples of stateful applications.
 ## Key Docker Components
 ### Docker Images
 A Docker image is a read-only template that defines the environment in which your application runs. It includes the application code, along with all necessary runtime components, libraries, and dependencies. Images are created using a Dockerfile—a script that automates the process of setting up the environment. Once an image is built, it can be used to create one or more containers.
 ### Docker Containers
 A Docker container is a runnable instance of an image. It encapsulates everything the application needs to run, ensuring isolation from the host system and other containers. Containers are highly portable and can be moved across different environments without affecting their functionality. This makes them ideal for developing, testing, and deploying applications in a consistent manner.
 ### Dockerfile
 A Dockerfile is a simple text file that contains a set of instructions for building a Docker image. These instructions specify the base image to use, the environment variables, dependencies, and commands required to assemble the application environment. By defining these steps in a Dockerfile, developers can automate the image creation process, ensuring that the application behaves the same way in every environment.
 ### Docker Hub
 [Docker Hub](https://hub.docker.com/) is a centralized cloud-based repository service where Docker images are stored, shared, and managed. It allows developers to pull pre-built images from public repositories or to push and distribute their own images. Docker Hub simplifies the process of finding and using images created by others, fostering collaboration within the developer community.
 ## Conclusion
 Docker revolutionizes the way applications are developed, shipped, and deployed by providing a consistent environment that works across various platforms. Through the use of containers, Docker makes applications portable, scalable, and easy to manage. Its comprehensive ecosystem of tools and services has established Docker as a critical component in modern software development pipelines, enabling faster, more reliable deployment of applications.
--- a/Orchestration/Docker/2-Commands.md
+++ b/Orchestration/Docker/2-Commands.md
@@ -0,0 +1,270 @@
 # **Docker Commands Guide**
 ## **1. Docker Data Directories**
 Docker stores essential data, including images, containers, and volumes, in specific directories.
 - **`/var/lib/docker/`**: Main directory for Docker's data, including images, containers, and volumes.
 - **`/var/lib/docker/containers/`**: Stores configuration files for individual containers.
 - **`/var/lib/docker/volumes/`**: Stores data for Docker volumes, which persist beyond the container’s lifecycle.
 ---
 ## **2. Installing Docker on Ubuntu**
 ### **Step 1: Update Package List and Install Dependencies**
 ```bash
 sudo apt update && sudo apt install -y ca-certificates curl
 ```
 - **`sudo apt update`**: Refreshes the package list.
 - **`sudo apt install -y ca-certificates curl`**: Installs certificates and `curl` to securely download Docker packages.
 ### **Step 2: Add Docker’s GPG Key**
 ```bash
 sudo install -m 0755 -d /etc/apt/keyrings 
 curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc 
 sudo chmod a+r /etc/apt/keyrings/docker.asc
 ```
 - **`install -m 0755 -d /etc/apt/keyrings`**: Creates the `/etc/apt/keyrings` directory with appropriate permissions.
 - **`curl -fsSL <url> -o <file>`**: Downloads Docker’s GPG key.
 - **`chmod a+r`**: Grants read permissions for all users to the GPG key.
 ### **Step 3: Add Docker’s Official Repository**
 ```bash
 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
 ```
 - Adds Docker’s repository to the Apt sources list.
 ### **Step 4: Install Docker**
 ```bash
 sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
 ```
 - **`docker-ce`**: Installs Docker Community Edition.
 - **`docker-ce-cli`**: Docker command-line interface.
 - **`containerd.io`**: Container runtime.
 - **`docker-buildx-plugin`**: Provides advanced build functionality.
 - **`docker-compose-plugin`**: Manages multi-container applications.
 ---
 ## **3. Docker CLI Commands**
 ### **3.1 Authentication**
 ```bash
 docker login
 ```
 - **`docker login`**: Logs into Docker Hub or a private registry by prompting for credentials.
 ### **3.2 Image Management**
 - **Download an image:**
  ```bash
  docker pull <repo-addr>
  ```
  - Downloads an image from a repository.
 - **List images:**
  ```bash
  docker images
  ```
  - Displays all available images.
 - **Remove an image:**
  ```bash
  docker rmi -f <image-id>
  ```
  - Forcefully removes a specific image.
 - **Save an image as a `.tar` file:**
  ```bash
  docker save -o <file-location-and-name> <image-name>
  ```
 - **Load an image from a `.tar` file:**
  ```bash
  docker load -i <file-location>
  ```
 ### **3.3 Container Management**
 - **Run a container:**
  ```bash
  docker run <options> <image-name>
  ```
 - **Run an interactive container with a terminal:**
  ```bash
  docker run -it <image-name>
  ```
 - **Run a container in detached mode:**
  ```bash
  docker run -dit <image-name>
  ```
 - **Set a container to always restart:**
  ```bash
  docker run -dit --restart=always <image-name>
  ```
 - **Name a container:**
  ```bash
  docker run -dit --name <container-name> <image-name>
  ```
 - **Assign a hostname:**
  ```bash
  docker run -dit --hostname=<hostname> <image-name>
  ```
 - **Set environment variables:**
  ```bash
  docker run -dit -e var1=data --name <container-name> --hostname=<hostname> <image-name>
  ```
 - **Map host and container ports:**
  ```bash
  docker run -dit -p <host-port>:<container-port> <image-name>
  ```
 - **Run a container with memory and CPU limits:**
  ```bash
  docker run -dit --name nginx --memory-reservation 150m --memory 500m nginx
  ```
  - Limits memory reservation to 150MB and usage to a maximum of 500MB.
  ```bash
  docker run -dit --name nginx --cpus 2 --cpu-shares 100 nginx
  ```
  - Limits the container to 2 CPUs.
 - **Stream container logs in real-time:**
  ```bash
  docker logs -f <container-name>
  ```
 - **Access a container’s terminal:**
  ```bash
  docker exec -it <container-name> /bin/bash
  ```
 - **Stop a container:**
  ```bash
  docker stop <container-name>
  ```
 - **Remove a container:**
  ```bash
  docker rm <container-name>
  ```
 - **Forcefully remove a running container:**
  ```bash
  docker rm -f <container-name>
  ```
 - **List all container IDs (including stopped):**
  ```bash
  docker ps -aq
  ```
 - **Prune stopped containers:**
  ```bash
  docker container prune
  ```
 - **Commit a container to an image:**
  ```bash
  docker commit <container-name> <new-image-name>
  ```
 - **Inspect container details:**
  ```bash
  docker inspect <container-name>
  ```
 - **Copy files between host and container:**
  ```bash
  docker cp <file-on-local> <container-name>:/<container-path>
  ```
  ```bash
  docker cp <container-name>:/<container-path> <local-path>
  ```
 - **View real-time container resource usage:**
  ```bash
  docker stats
  ```
 - **Build an image from a Dockerfile:**
  ```bash
  docker build -t <app-name>:<app-version> <path-to-dockerfile>
  ```
 ---
 ## **4. Volume Management**
 Volumes store data that persists even when a container is deleted.
 - **List all volumes:**
  ```bash
  docker volume ls
  ```
 - **Create a volume:**
  ```bash
  docker volume create <volume-name>
  ```
 - **Inspect a volume:**
  ```bash
  docker volume inspect <volume-name>
  ```
 - **Mount a volume to a container:**
  ```bash
  docker run -dit --name <container-name> -v <volume-name>:<container-path> <image-name>
  ```
 - **Mount a file with read-only access:**
  ```bash
  docker run -dit --name nginx -v /etc/resolv.conf:/etc/resolv.conf:ro nginx
  ```
 - **Mount temporary filesystem in memory:**
  ```bash
  docker run -dit --name nginx --tmpfs /opt:100M nginx
  ```
 ---
 ## **5. Network Management**
 Docker networks allow communication between containers.
 - **List all networks:**
  ```bash
  docker network ls
  ```
 - **Create a network:**
  ```bash
  docker network create <network-name>
  ```
 - **Create a custom network with subnet and gateway:**
  ```bash
  docker network create --subnet <subnet> --gateway <gateway-ip> --driver=<network-type> <network-name>
  ```
 - **Run a container on a specific network:**
  ```bash
  docker run -dit --name <container-name> --network <network-name> <image-name>
  ```
 - **Connect a running container to a network:**
  ```bash
  docker network connect <network-name> <container-name>
  ```
 - **Disconnect a container from a network:**
  ```bash
  docker network disconnect <network-name> <container-name>
  ```
--- a/Orchestration/Docker/3-Docker-File.md
+++ b/Orchestration/Docker/3-Docker-File.md
@@ -0,0 +1,148 @@
 ## What is a Dockerfile?
 A **Dockerfile** is a simple text file containing instructions to create a Docker image. Docker images provide a consistent and reproducible environment for running applications in containers. By defining dependencies, configurations, and the operating system, Dockerfiles automate the image creation process, ensuring version-controlled and portable environments.
 ### Key Concepts:
 - **Base Image**: The foundational layer of your image, typically an official operating system like Ubuntu, CentOS, or Alpine Linux.
 - **Instructions**: Commands such as `RUN`, `COPY`, and `CMD` define what’s installed, how the image behaves, and which files to include.
  Common instructions include:
  - **`RUN`**: Executes commands (e.g., installing software) inside the container.
  - **`COPY`**: Copies files from your local machine to the image.
  - **`CMD`**: Specifies the default command to run when the container starts.
 ---
 ## Step-by-Step Guide to Creating a Dockerfile
 ### 1. Create a File Named `Dockerfile`
 Start by creating a file called `Dockerfile` in your project directory. If you name it something else, you'll need to specify the file name during the build process.
 #### Example Dockerfile:
 ```dockerfile
 # Use Ubuntu 22.04 as the base image
 FROM ubuntu:22.04
 # Add metadata such as version information
 LABEL version="0.0.1"
 # Update package lists and install essential tools
 RUN apt update && apt install -y bash vim curl
 # Install Nginx web server
 RUN apt install -y nginx
 ```
 #### Breakdown of Instructions:
 - **`FROM ubuntu:22.04`**: Defines Ubuntu 22.04 as the base image.
 - **`LABEL version="0.0.1"`**: Adds metadata, such as the version label.
 - **`RUN`**: Runs commands inside the container. In this case, it updates package lists and installs `bash`, `vim`, `curl`, and `nginx`.
 ---
 ### 2. Example Using Alpine Linux
 Alpine Linux is a lightweight option that results in smaller images. Here's an example of a Dockerfile using Alpine:
 ```dockerfile
 # Use Alpine as the base image
 FROM alpine
 # Add version metadata
 LABEL version="0.0.1"
 # Update package lists and install essential tools
 RUN apk update && apk add bash vim curl
 ```
 This example is perfect for when you need a compact, minimalistic image.
 ---
 ### 3. Complex Dockerfile with a Script
 In this example, you'll learn how to copy a script into the container, set a working directory, and make the script executable.
 ```dockerfile
 # Start with Alpine as the base image
 FROM alpine
 # Add metadata
 LABEL version="0.0.1"
 # Update package lists and install essential tools
 RUN apk update && apk add bash vim curl iputils-ping
 # Copy the script into the image
 COPY <local-file-path> <container-destination-path>
 # Set the working directory for subsequent commands
 WORKDIR <container-destination-path>
 # Add environment variables
 ENV API_KEY="123445"
 # Set user and expose ports
 USER deploy
 EXPOSE 3210
 # Give execution permissions to the script
 RUN chmod +x app.sh
 # Define the default command to run
 CMD ["./app.sh"]
 # Alternatively, you can use ENTRYPOINT
 ENTRYPOINT ["bash", "./app.sh"]
 ```
 #### Key Concepts in This Example:
 - **`COPY`**: Copies a file from your local machine to the container.
 - **`WORKDIR`**: Sets the working directory inside the container for subsequent commands.
 - **`RUN chmod +x app.sh`**: Grants execution permissions to the `app.sh` script.
 - **`CMD` vs. `ENTRYPOINT`**: `CMD` provides default behavior, while `ENTRYPOINT` is used when you want to ensure the container always runs a specific executable.
 ---
 ### 4. Build Your Docker Image
 Once your `Dockerfile` is ready, build the Docker image using the `docker build` command.
 ```bash
 docker build -t <app-name> <path-to-dockerfile>
 ```
 #### Usage Examples:
 - To build with a `Dockerfile` in the current directory:
  ```bash
  docker build -t app-test .
  ```
  Here, the `.` indicates the current directory as the build context.
 - If your file is named something other than `Dockerfile` (e.g., `CustomDockerfile`):
  ```bash
  docker build -t app-test -f <CustomDockerfile> .
  ```
 - If you want build file without use cache 
  ```bash
    docker build -t app-test:v1 -f <Custom-Dir> . --no-cache
  ```
 #### Explanation:
 - **`docker build`**: Builds a Docker image.
 - **`-t <app-name>`**: Tags the image with a name (e.g., `app-test`).
 - **`<path-to-dockerfile>`**: Specifies the location of the `Dockerfile`. Use `.` for the current directory or provide an absolute path.
 ---
 ## Summary
 A **Dockerfile** is a powerful tool for automating the creation of Docker images. Here’s a quick recap:
 1. **Create a Dockerfile**: Use instructions like `FROM`, `RUN`, `COPY`, and `CMD` to define the image.
 2. **Build the Image**: Run the `docker build` command to turn your Dockerfile into a Docker image.
 3. **Run the Container**: Once the image is built, use `docker run` to create and run a container based on it.
--- a/Orchestration/Docker/4-Docker-Compose.md
+++ b/Orchestration/Docker/4-Docker-Compose.md
@@ -0,0 +1,83 @@
 # **Docker Compose Guide**
 Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to manage services, networks, and volumes using a YAML configuration file.
 ---
 ## **1. Basic Docker Compose Structure**
 Before defining the services in Docker Compose, we need to specify the Docker Compose version and the services we want to run. Here's a basic YAML template:
 ```yaml
 version: "<python-version>"  
 services:
    <service-name>:  # The name of your service (e.g., web, db)
        container_name: <container-name>  # The name of the container
        image: <image-name>  # Docker image to be used for this service
        restart: always  # Ensure the container restarts if it stops or fails
        ports:
            - "<sv-port>:<container-port>"  # Map the host port to the container port
        volumes: 
            - <vol-name>:<container-loc>  # Attach a volume to a specific location in the container
        environment:
            - <env1>=<value1>  # Environment variables to be passed to the container
 ```
 ### **Explanation**:
 - **`services:`**: The core section where you define different services (containers) that make up your application.
 - **`<service-name>`**: Replace with the name of the service (e.g., `web`, `database`). Each service corresponds to a container.
 - **`container_name`**: The name given to the container.
 - **`image`**: The Docker image used to run the service (e.g., `python:3.9`, `nginx`).
 - **`restart: always`**: Ensures the container will always restart if it stops, providing higher availability.
 - **`ports`**: Maps ports from the host to the container, allowing the container to be accessed externally. The syntax is `<host-port>:<container-port>`.
 - **`volumes`**: Links a Docker volume or host directory to a directory inside the container, enabling persistent data or sharing of resources. Example: `myvolume:/usr/src/app`.
 - **`environment`**: Defines environment variables to be passed to the container at runtime. For example, setting an environment variable like `DB_HOST=localhost`.
 ---
 ## **2. Defining Volumes**
 Docker Compose allows you to define persistent volumes that can be attached to containers. Here's how to define a volume:
 ```yaml
 volumes:
    <vol-name>:  # Define the volume here
 ```
 ### **Explanation**:
 - **`volumes:`**: This section allows you to define named volumes that can be used in the services.
 - **`<vol-name>`**: Replace this with the name of the volume (e.g., `data-volume`, `db-volume`). The volume can be attached to different services to persist data beyond the container's lifecycle.
 ---
 ## **3. Useful Docker Compose Commands**
 ### **3.1 Start the Docker Compose Application**
 To bring up the application defined in the `docker-compose.yml` file, use:
 ```bash
 docker compose up
 ```
 ### **3.2 Run Docker Compose in Detached Mode (Background)**
 To run your Docker Compose services in the background (detached mode):
 ```bash
 docker compose up -d
 ```
 ### **3.3 Stop and Remove Docker Compose Services**
 To stop the services and remove the containers, networks, and volumes created by Docker Compose:
 ```bash
 docker compose down
 ```
 ### **Explanation of Commands**:
 - **`docker compose up`**: Builds, (re)creates, and starts all services defined in the `docker-compose.yml` file.
 - **`docker compose up -d`**: Runs the services in the background, keeping your terminal free while the containers continue running.
 - **`docker compose down`**: Stops and removes all running services, containers, and networks created by Docker Compose. You can add the `-v` flag to remove volumes as well.
--- a/Orchestration/Docker/Additional.md
+++ b/Orchestration/Docker/Additional.md
@@ -0,0 +1,102 @@
 # HTTP Status Codes Table
 | Status Code | Category               | Description                                                                           |
 |-------------|------------------------|---------------------------------------------------------------------------------------|
 | **100**     | Informational (1xx)     | Continue: The client should continue with its request.                                |
 | **101**     | Informational (1xx)     | Switching Protocols: Server is switching protocols.                                   |
 | **102**     | Informational (1xx)     | Processing (WebDAV): Server has received and is processing the request.               |
 | **200**     | Success (2xx)           | OK: The request was successful.                                                       |
 | **201**     | Success (2xx)           | Created: The request was successful and a resource was created.                       |
 | **202**     | Success (2xx)           | Accepted: The request has been accepted for processing.                               |
 | **203**     | Success (2xx)           | Non-Authoritative Information: The server is a proxy, not the original.               |
 | **204**     | Success (2xx)           | No Content: The server successfully processed the request, but no content is returned.|
 | **205**     | Success (2xx)           | Reset Content: The client should reset the view.                                      |
 | **206**     | Success (2xx)           | Partial Content: The server is delivering part of the resource (range requests).       |
 | **300**     | Redirection (3xx)       | Multiple Choices: Multiple options for the resource are available.                    |
 | **301**     | Redirection (3xx)       | Moved Permanently: The resource has moved permanently to a new URI.                   |
 | **302**     | Redirection (3xx)       | Found: The resource is temporarily at a different URI.                                |
 | **303**     | Redirection (3xx)       | See Other: The response is at another URI.                                            |
 | **304**     | Redirection (3xx)       | Not Modified: The resource has not been modified since the last request.              |
 | **305**     | Redirection (3xx)       | Use Proxy: The requested resource is available only through a proxy.                  |
 | **307**     | Redirection (3xx)       | Temporary Redirect: The resource resides temporarily at a different URI.              |
 | **308**     | Redirection (3xx)       | Permanent Redirect: The resource has moved permanently, and this URI should be used.  |
 | **400**     | Client Errors (4xx)     | Bad Request: The server could not understand the request due to invalid syntax.       |
 | **401**     | Client Errors (4xx)     | Unauthorized: Authentication is required and has failed.                              |
 | **402**     | Client Errors (4xx)     | Payment Required: Reserved for future use.                                            |
 | **403**     | Client Errors (4xx)     | Forbidden: The request was understood but refuses to authorize it.                    |
 | **404**     | Client Errors (4xx)     | Not Found: The resource could not be found.                                           |
 | **405**     | Client Errors (4xx)     | Method Not Allowed: The request method is not supported for the resource.             |
 | **406**     | Client Errors (4xx)     | Not Acceptable: The resource cannot produce content acceptable to the client.         |
 | **407**     | Client Errors (4xx)     | Proxy Authentication Required: The client must authenticate with the proxy first.     |
 | **408**     | Client Errors (4xx)     | Request Timeout: The server timed out waiting for the request.                        |
 | **409**     | Client Errors (4xx)     | Conflict: The request could not be processed because of a conflict.                   |
 | **410**     | Client Errors (4xx)     | Gone: The resource is no longer available.                                            |
 | **411**     | Client Errors (4xx)     | Length Required: The request did not specify the length.                              |
 | **412**     | Client Errors (4xx)     | Precondition Failed: The preconditions set by the client were not met.                |
 | **413**     | Client Errors (4xx)     | Payload Too Large: The request is too large to process.                               |
 | **414**     | Client Errors (4xx)     | URI Too Long: The URI provided was too long for the server to process.                |
 | **415**     | Client Errors (4xx)     | Unsupported Media Type: The media type of the request is not supported.               |
 | **416**     | Client Errors (4xx)     | Range Not Satisfiable: The client requested a portion that cannot be supplied.        |
 | **417**     | Client Errors (4xx)     | Expectation Failed: The server cannot meet the expectation of the request.            |
 | **418**     | Client Errors (4xx)     | I'm a teapot (RFC 2324): An April Fools' joke code.                                   |
 | **421**     | Client Errors (4xx)     | Misdirected Request: The request was directed at a wrong server.                      |
 | **422**     | Client Errors (4xx)     | Unprocessable Entity (WebDAV): The request was well-formed but semantic errors exist. |
 | **423**     | Client Errors (4xx)     | Locked (WebDAV): The resource being accessed is locked.                               |
 | **424**     | Client Errors (4xx)     | Failed Dependency (WebDAV): A previous request failed, causing this one to fail.      |
 | **425**     | Client Errors (4xx)     | Too Early: The server is unwilling to process this request yet.                       |
 | **426**     | Client Errors (4xx)     | Upgrade Required: The client needs to switch to a different protocol.                 |
 | **428**     | Client Errors (4xx)     | Precondition Required: The server requires the request to be conditional.             |
 | **429**     | Client Errors (4xx)     | Too Many Requests: Too many requests sent in a given amount of time.                  |
 | **431**     | Client Errors (4xx)     | Request Header Fields Too Large: The request's header fields are too large.           |
 | **451**     | Client Errors (4xx)     | Unavailable For Legal Reasons: The resource is unavailable for legal reasons.         |
 | **500**     | Server Errors (5xx)     | Internal Server Error: An unexpected server error occurred.                           |
 | **501**     | Server Errors (5xx)     | Not Implemented: The server lacks the ability to fulfill the request.                 |
 | **502**     | Server Errors (5xx)     | Bad Gateway: Received an invalid response from the upstream server.                   |
 | **503**     | Server Errors (5xx)     | Service Unavailable: The server is overloaded or down for maintenance.                |
 | **504**     | Server Errors (5xx)     | Gateway Timeout: No timely response from the upstream server.                         |
 | **505**     | Server Errors (5xx)     | HTTP Version Not Supported: The server does not support the HTTP version.             |
 | **506**     | Server Errors (5xx)     | Variant Also Negotiates: Internal configuration error.                                |
 | **507**     | Server Errors (5xx)     | Insufficient Storage (WebDAV): The server cannot store the representation.            |
 | **508**     | Server Errors (5xx)     | Loop Detected (WebDAV): The server detected an infinite loop while processing.        |
 | **510**     | Server Errors (5xx)     | Not Extended: Extensions are required for the server to fulfill the request.          |
 | **511**     | Server Errors (5xx)     | Network Authentication Required: Client must authenticate to gain network access.     |
 ---
 # Docker Image Layers
 A **Docker image** is composed of multiple layers that work together to create a fully functional container. Each layer represents a step in the build process, and layers are stacked on top of one another to form the complete image.
 ### Structure of a Docker Image:
 1. **BootFS (Boot File System):**
   - **Description:** This is the bottom-most layer in the Docker image. It includes files and directories needed to boot up a system.
   - **Function:** It sets up the foundation for the base operating system within the container, similar to the host machine’s `/boot` folder.
 2. **Base Image:**
   - **Description:** The base image is typically a minimal operating system (e.g., Ubuntu, Alpine Linux) or any other image that acts as a starting point for your container.
   - **Examples:** Ubuntu, Alpine, Debian.
   - **Function:** Provides the core OS functionalities and dependencies needed for the higher layers.
 3. **Libraries:**
   - **Description:** Libraries required by the applications running in the container.
   - **Examples:** libc, libssl, or any other standard libraries needed by the applications.
   - **Function:** Provides necessary functionality for applications, ensuring they can function correctly within the container.
 4. **Packages and Applications:**
   - **Description:** Specific software, tools, or libraries that your application depends on.
   - **Examples:** vim, curl, git, node.js, or custom software required by your application.
   - **Function:** These packages allow you to run applications and scripts necessary for the container's purpose.
 5. **User Application (Optional):**
   - **Description:** The main application code that you intend to run within the container.
   - **Examples:** A web server like Apache, Nginx, or any microservice application.
   - **Function:** It is the purpose of the container, which could be serving web traffic, processing data, or any other specific task.
 ### Writable Layer (Container-Specific):
 - **Description:** Once a container is created from a Docker image, a writable layer is added on top of the image layers.
 - **Function:** Any changes made during the container's runtime (like creating files or modifying configurations) are stored in this writable layer.
 - **Key Point:** Changes to the writable layer do not impact the underlying image layers.
 ---
--- a/Orchestration/Docker/Docker-Dirs.md
+++ b/Orchestration/Docker/Docker-Dirs.md
@@ -0,0 +1,81 @@
 # Docker Directory Structure in `/var/lib/docker`
 In Linux, Docker stores its container data under `/var/lib/docker`. Each subdirectory here serves a specific purpose related to Docker's functionality. Below is a breakdown of each important directory under `/var/lib/docker`.
 ## 1. **/var/lib/docker/containers**
 This directory contains the data for each Docker container. Each container has its own subdirectory, named after the container's unique ID. Inside each container’s directory, you’ll find files like:
 - `config.v2.json`: Configuration data for the container.
 - `hostconfig.json`: Configuration related to how the container was launched.
 - `log.json`: The logs generated by the container.
 **Example:**
 ```bash
 /var/lib/docker/containers/[container_id]/config.v2.json
 ```
 ## 2. **/var/lib/docker/image**
 This directory contains Docker images. Images are stored in subdirectories based on their storage driver (e.g., `overlay2`, `aufs`, etc.). 
 **Key subdirectories:**
 - `/var/lib/docker/image/overlay2/`: Stores metadata and layers for images using the `overlay2` storage driver.
 ## 3. **/var/lib/docker/overlay2**
 The `overlay2` directory contains the layers of the Docker images and containers. Each image and container is made up of multiple layers, which are stored in this directory. The overlay filesystem merges these layers to create a unified view of the container's filesystem.
 **Key subdirectories:**
 - `diff/`: Stores the content changes for each layer.
 - `merged/`: Represents the merged view of the layers for running containers.
 - `work/`: Temporary working directories for file operations.
 ## 4. **/var/lib/docker/plugins**
 This directory is where Docker stores data related to plugins. Docker plugins extend the platform's capabilities by adding features such as storage drivers, networking plugins, and logging mechanisms.
 **Subdirectory structure:**
 - `/var/lib/docker/plugins/[plugin_id]/`: Each installed plugin has its own subdirectory.
 ## 5. **/var/lib/docker/network**
 This directory stores data related to Docker's networking functionality. Docker allows containers to communicate with each other through networks, and this directory holds information about those networks.
 **Key subdirectories:**
 - `files/`: Contains JSON files that describe the networks.
 - `local-kv.db`: A database that stores network state information.
 ## 6. **/var/lib/docker/swarm**
 This directory holds data related to Docker Swarm mode, which allows you to deploy and manage a cluster of Docker nodes. The swarm directory is used for storing cluster state, such as node configurations and services.
 **Key files:**
 - `worker/`: Contains information specific to the worker nodes in a swarm.
 - `raft/`: Contains data for the Raft consensus algorithm used to manage the swarm cluster state.
 ## 7. **/var/lib/docker/volumes**
 This directory contains data for Docker volumes, which are used for persisting data outside of the container lifecycle. Each volume is stored in its own subdirectory.
 **Example:**
 ```bash
 /var/lib/docker/volumes/[volume_name]/_data/
 ```
 The `_data` subdirectory inside each volume contains the actual persistent data for that volume.
 ## 8. **/var/lib/docker/builder**
 This directory stores information related to the Docker image build process. It includes cache data and temporary files generated while building Docker images.
 **Key files:**
 - `cache/`: Contains cached layers used during the image building process to speed up future builds.
 ## 9. **/var/lib/docker/runtimes**
 This directory contains data related to different container runtimes. While Docker primarily uses `runc`, other runtimes like `nvidia` can also be installed here.
 ## 10. **/var/lib/docker/tmp**
 Temporary files used by Docker are stored in this directory. These are usually short-lived and can include things like temporary layers during builds or container creation processes.
--- a/Orchestration/Docker/Docker-Swarm.md
+++ b/Orchestration/Docker/Docker-Swarm.md
--- a/Orchestration/kubernetes/commands.md
+++ b/Orchestration/kubernetes/commands.md
@@ -0,0 +1,102 @@
 # Kubernetes
 ## `kubectl` Command Reference
 ### Get State of API Resources
 ```bash
 kubectl api-resources
 ```
 ### Node Management
 - **Show all nodes:**
  ```bash
  kubectl get node
  ```
 ### Namespace Management
 - **List all namespaces:**
  ```bash
  kubectl get namespaces
  ```
  ```bash
  kubectl get ns
  ```
 - **Create a custom namespace:**
  ```bash
  kubectl create ns <namespace-name>
  ```
 ### Pod Management
 - **Get the list of pods in the default namespace:**
  ```bash
  kubectl get pod
  ```
 - **Get the list of pods in the default namespace with full information:**
  ```bash
  kubectl get pod -o wide
  ```
 - **Get the list of pods in a custom namespace with full information:**
  ```bash
  kubectl get pod -o wide -n <name-space>
  ```
 ### Running a Pod
 - **Run a new pod:**
  ```bash
    kubectl run <pod-name> <switch> {
    --image=<image-name>,                # Specifies the container image to use
    --port=<portnumber>,                 # Specifies the port that the container exposes
    -n <namespace-name>,                 # Specifies the namespace
    --env="KEY=VALUE",                   # Sets environment variables in the container
    --command,                           # Treats the rest of the arguments as the command to run in the container
    --replicas=<number>,                 # Specifies the number of replicas for the deployment
    --labels="key=value,key2=value2",    # Adds labels to the pod(s)
    --dry-run=client,                    # Prints the object that would be sent, without creating it
    --restart=<Always|OnFailure|Never>,  # Determines the restart policy for the pod
    --overrides='<json>',                # Provides a JSON override for the generated object
    --image-pull-policy=<policy>,        # Specifies the image pull policy (Always, IfNotPresent, Never)
    --limits=cpu=<cpu>,memory=<memory>,  # Specifies resource limits for the container
    --requests=cpu=<cpu>,memory=<memory> # Specifies resource requests for the container
    }
  ```
  - *Example:*
    ```bash
      kubectl run mypod --image=nginx --port=80 -n mynamespace \
      --env="ENV_VAR_NAME=VALUE" --command -- nginx -g "daemon off;" \
      --replicas=3 --labels="app=myapp,env=prod" --dry-run=client \
      --restart=Always --overrides='{"spec": {"containers": [{"name": "nginx", "image": "nginx"}]}}' \
      --image-pull-policy=IfNotPresent --limits=cpu=100m,memory=256Mi \
      --requests=cpu=50m,memory=128Mi
    ```
 ### Deleting a Pod
 - **Delete a pod in a custom namespace:**
  ```bash
  kubectl delete pod -n <namespace-name> <pod-name>
  ```
 ### API Resource Documentation
 - **Get documentation of an API resource:**
  ```bash
  kubectl explain <api-resource-name>
  ```
  - *Example:*
    ```bash
    kubectl explain pod
    ```
 ### Logging and Pod Information
 - **Get and follow logs of a pod (pod must be created and running):**
  ```bash
  kubectl logs -f -n <namespace-name> <podname>
  ```
 - **Get logs and state information of a pod (works at any time):**
  ```bash
  kubectl describe pod -n <namespace-name> <podname>
  ```
 ### Apply Yaml File
 ```bash
 kubectl apply -f <yaml-file> -n <namespace-name>
 ```
--- a/Orchestration/kubernetes/information.md
+++ b/Orchestration/kubernetes/information.md
--- a/Orchestration/kubernetes/instaltion.md
+++ b/Orchestration/kubernetes/instaltion.md
--- a/Orchestration/kubernetes/workloads/all.md
+++ b/Orchestration/kubernetes/workloads/all.md
@@ -0,0 +1,208 @@
 # Kubernetes YAML Files
 This document provides explanations and details for various Kubernetes YAML configurations, describing how different Kubernetes objects such as Namespaces, Pods, and other specifications are defined and utilized. The examples cover creating namespaces, deploying pods, setting resource limits, and using node selectors.
 ## Namespace Definition
 ```yaml
 apiVersion: v1
 kind: Namespace
 metadata:
  name: my-ns
 ```
 - **apiVersion**: Specifies the version of the Kubernetes API.
 - **kind**: Defines the type of Kubernetes object, here it's a `Namespace`.
 - **metadata**: Contains data that helps uniquely identify the object, including a `name`.
 This YAML file creates a namespace named `my-ns` which isolates a group of resources within Kubernetes.
 ## Pod Definitions
 ### Nginx Pod
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  namespace: my-ns
  name: nginx-pod
  labels:
    app: app1
    zone: staging
    version: v1.0.1
    app.kubernetes.io/product: nginx-pod
 spec:
  containers:
    - name: naginx-container
      image: nginx:latest
      ports:
        - containerPort: 80
 ```
 - **metadata.namespace**: Specifies the namespace the pod belongs to (`my-ns`).
 - **metadata.name**: The name of the pod (`nginx-pod`).
 - **metadata.labels**: Key-value pairs for organizing and selecting resources.
 - **spec.containers**: Specifies the containers within the pod. Each container has:
  - **name**: Container name.
  - **image**: The Docker image to run (`nginx:latest`).
  - **ports**: List of ports to expose from the container (`containerPort: 80`).
 This file defines a pod named `nginx-pod` running the latest Nginx container in the `my-ns` namespace.
 ### Test Pod 1
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  namespace: my-ns
  name: testpod1
 spec:
  containers:
    - name: c00
      image: ubuntu
      command: ["/bin/bash", "-c", "while true; do echo Hello-Coder; sleep 5 ; done"]
    - name: c01
      image: ubuntu
      command: ["/bin/bash", "-c", "while true; do echo Hello-Programmer; sleep 5 ; done"]
 ```
 - **spec.containers.command**: Overrides the default command for the container, in this case, running a looped bash script that prints a message every 5 seconds.
 This defines a pod named `testpod1` with two Ubuntu containers in the `my-ns` namespace, each running a different command.
 ## Pod with Resource Requests and Limits
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  namespace: my-ns
  name: testpod1
 spec:
  containers:
    - name: c00
      image: ubuntu
      command:
        - /bin/bash
        - -c
        - while true; do echo Hello-Coder; sleep 5 ; done
    - name: c01
      image: ubuntu
      command:
        - /bin/bash
        - -c
        - while true; do echo Hello-Programmer; sleep 5 ; done
      resources:
        limits:
          memory: "128Mi"
          cpu: "500m"
        requests:
          memory: "64Mi"
          cpu: "250m"
 ```
 - **resources.limits**: Specifies the maximum amount of resources a container can use.
 - **resources.requests**: Specifies the amount of resources a container is guaranteed.
 This pod configuration defines resource limits and requests for the containers to ensure they do not exceed specific memory and CPU usage.
 ## Pod with NodeSelector
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  namespace: my-ns
  name: testpod3
 spec:
  containers:
    - name: c00
      image: ubuntu
      command:
        - /bin/bash
        - -c
        - while true; do echo Hello-Coder; sleep 5 ; done
    - name: c01
      image: ubuntu
      command:
        - /bin/bash
        - -c
        - while true; do echo Hello-Programmer; sleep 5 ; done
      resources:
        limits:
          memory: "128Mi"
          cpu: "500m"
        requests:
          memory: "64Mi"
          cpu: "250m"
  nodeSelector:
    kubernetes.io/hostname: k8s2
    kubernetes.io/disk: ssd
 ```
 - **nodeSelector**: Ensures the pod is scheduled on nodes with the specified labels (`kubernetes.io/hostname: k8s2` and `kubernetes.io/disk: ssd`).
 This configuration places the pod on specific nodes that match the given labels.
 ## Simple Pod Templates
 ### Basic Pod
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  name: myapp
  labels:
    name: myapp
 spec:
  containers:
  - name: myapp
    image: <Image>
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: <Port>
 ```
 This is a template for a basic pod named `myapp` with configurable image and port settings.
 ### Nginx Pod
 ```yaml
 apiVersion: v1
 kind: Pod
 metadata:
  name: my-pod
  labels:
    app: MyApp
 spec:
  containers:
  - name: my-container
    image: nginx:latest
    ports:
    - containerPort: 80
 ```
 This defines a pod named `my-pod` running an Nginx container exposing port 80.
 ## Useful Kubernetes Commands
 ### View Pod Details
 ```bash
 kubectl get pod -n my-ns <pod-name> -o yaml
 ```
 This command retrieves and displays the YAML configuration of the pod `testpod1` in the namespace `my-ns`.
 ### Label a Node
 ```bash
 kubectl label node <node-name> kubernetes.io/<var-name>=<var-value>
 kubectl get nodes --show-labels
 ```
--- a/Django/sysinfo
+++ b/Django/sysinfo
--- a/Docker/Docker.md
+++ b/Docker/Docker.md
@@ -1,78 +0,0 @@
 # Docker Commands and Concepts
 ## Docker Concepts
 - **Stateless**: Do not save your data (like Nginx).
 - **Stateful**: Save your data.
 ## Docker Data Directory
 - `/var/lib/docker/`: Docker data directory.
 - `/var/lib/docker/containers/`: Container configuration and file directory.
 - `/var/lib/docker/volumes`: Directory where docker volumes are saved.
 ## Docker Installtion (Ubuntu)
 ```bash
 apt update && apt install ca-certificates curl && install -m 0755 -d /etc/apt/keyrings && curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc && chmod a+r /etc/apt/keyrings/docker.asc
 # Add the repository to Apt sources:
 echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
 apt update && apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
 ```
 ## Docker CLI Commands
 ### Authentication
 - `docker login`: Login to Docker Hub with CLI.
 ### Image Management
 - `docker pull <repo-addr>`: Pull a Docker image.
 - `docker images`: Show pulled images.
 - `docker rmi -f <image-id>`: Remove an image.
 - `docker save -o <file-location-and-name> <image-name>`: Save image as an external file.
 - `docker load -i <file-location>`: Import a Docker image.
 ### Container Management
 - `docker run <options> <img-name>`: Run a Docker container.
  - `docker run`: Run Docker (after run exited).
  - `docker run -it`: Run and give bash to me.
  - `docker run -dit`: Run and give bash to me and run in the background.
 - `docker exec -it <container-name>`: Go to container shell.
 - `docker rm <container-name>`: Remove Docker container.
 - `docker stop <container-name>`: Stop Docker container.
 - `docker rm -f <container-name>`: Stop and remove Docker container.
 - `docker ps -aq`: Give all Docker container IDs.
 - `docker ps -aq -f status=exited`: Give all Docker container IDs with exited status.
 - `docker container prune`: Remove all stopped containers.
 - `docker commit <container-name> <new-name>`: Make a custom Docker image.
 - `docker inspect <container-name>`: Get all data about container information.
 - `docker inspect --format '{{ .NetworkSettings.IPAddress }}' <container-name>`: Get IP of the container.
 - `docker cp <file_on_local> <container-name>:/<location>`: Copy from local to container.
 - `docker cp <container-name>:/<location> <local-location>`: Copy from container to local.
 - `docker stats`: Monitor Docker stats.
 - `docker run -dit --name server --restart=always ubuntu`: Run container again after restarting the service or main server.
 - `docker build -t <appname>:<appver> <location-of-docker-file>`: Build Docker image from a Dockerfile.
 ### Volume Management
 - `docker volume ls`: List all volumes.
 - `docker volume create <name-of-volume>`: Create a volume for Docker.
 - `docker volume inspect <vol-name>`: Give information about the volume.
 - `docker run -dit --name <container-name> -v <volume-name>:<location-in-container> <img-name>`: Run Docker image and save target location data in volume.
 ### Network Management
 - `docker network ls`: List all Docker networks.
 - `docker network create <network-name>`: Create a Docker network.
 - `docker network create --subnet <ip>/<subnet> --gateway <gateway-ip> --driver=<network-type> <net-name>`: Create network with custom settings.
 - `docker run -dit --name <container-name> --network <network-name> <img-name>`: Run a container and connect it to a custom network.
 - `docker network connect <network-name> <container-name>`: Connect a container to a custom network.
 - `docker network disconnect <network-name> <container-name>`: Disconnect a network from a container.
--- a/Docker/Info.md
+++ b/Docker/Info.md
@@ -1,27 +0,0 @@
 # Docker Information
 ## What is Docker?
 [Docker](https://www.docker.com/) is a platform for developing, shipping, and running applications in containers. Containers are lightweight, portable, and self-sufficient environments that contain everything needed to run an application, including the code, runtime, libraries, and dependencies. Docker provides a way to package and distribute applications as containers, allowing them to run consistently across different environments.
 ## Key Concepts
 ### Images
 An image is a read-only template used to create containers. It contains the application code, runtime, libraries, and dependencies needed to run the application. Images are built using a Dockerfile, which specifies the instructions for creating the image.
 ### Containers
 A container is a runnable instance of an image. It encapsulates the application and its dependencies, providing isolation from the host system and other containers. Containers are lightweight, portable, and can be easily moved between different environments.
 ### Dockerfile
 A Dockerfile is a text file that contains the instructions for building a Docker image. It specifies the base image, environment variables, dependencies, and commands needed to set up the application environment. Dockerfiles allow developers to automate the process of building images and ensure consistency across environments.
 ### Docker Hub
 [Docker Hub](https://hub.docker.com/) is a cloud-based registry service that hosts Docker images. It provides a centralized repository for sharing, storing, and managing Docker images. Docker Hub allows developers to pull pre-built images from public repositories or publish their own images for others to use.
 ## Conclusion
 Docker simplifies the process of developing, shipping, and running applications by providing a consistent environment across different platforms. It enables developers to package applications as containers, making them portable, scalable, and easy to deploy. With its rich ecosystem of tools and services, Docker has become a key technology in modern software development workflows.
--- a/Info/CICD.md
+++ b/Info/CICD.md
@@ -1,91 +0,0 @@
 # CI/CD Overview
 Continuous Integration (CI) and Continuous Deployment (CD) are essential practices in modern software development. They aim to automate and streamline the process of building, testing, and deploying code changes, ensuring a faster and more reliable development cycle.
 ## Table of Contents
 - [What is CI/CD?](#what-is-cicd)
 - [Key Concepts](#key-concepts)
  - [Continuous Integration (CI)](#continuous-integration-ci)
  - [Continuous Deployment (CD)](#continuous-deployment-cd)
 - [Benefits of CI/CD](#benefits-of-cicd)
 - [CI/CD Pipeline](#cicd-pipeline)
 - [Tools for CI/CD](#tools-for-cicd)
 - [Best Practices](#best-practices)
 - [Conclusion](#conclusion)
 ---
 ## What is CI/CD?
 **Continuous Integration (CI)** is the practice of frequently integrating code changes from multiple contributors into a shared repository. Each integration is verified by automated tests, ensuring that new code does not break existing functionality.
 **Continuous Deployment (CD)** is the practice of automatically deploying code changes to production or staging environments after passing the automated tests in the CI phase.
 ## Key Concepts
 ### Continuous Integration (CI)
 CI involves the following key steps:
 1. **Version Control**: Developers use a version control system (e.g., Git) to manage code changes.
 2. **Automated Builds**: Whenever a new code change is pushed to the repository, an automated build process is triggered. This compiles the code and checks for basic errors.
 3. **Automated Testing**: Automated tests (unit tests, integration tests, etc.) are run to verify that the code changes do not introduce new bugs.
 4. **Code Quality Checks**: Static code analysis tools check for code style violations, security issues, and other quality metrics.
 ### Continuous Deployment (CD)
 CD builds on CI and includes the following steps:
 1. **Automated Deployment**: If all tests pass in the CI phase, the code is automatically deployed to a staging environment.
 2. **User Acceptance Testing (UAT)**: Stakeholders or QA teams conduct additional tests in the staging environment to ensure the changes meet business requirements.
 3. **Automated Deployment to Production**: If UAT is successful, the code is automatically deployed to the production environment.
 ## Benefits of CI/CD
 - **Faster Development**: CI/CD reduces the time it takes to develop, test, and deploy code changes.
 - **Improved Quality**: Automated testing and code checks catch bugs early, reducing the likelihood of production issues.
 - **Consistency**: Builds and deployments are automated, ensuring that the process is consistent and repeatable.
 - **Increased Collaboration**: CI encourages frequent integration, leading to better collaboration among developers.
 ## CI/CD Pipeline
 A CI/CD pipeline is a set of automated steps that code changes go through from development to deployment. It typically includes:
 - **Source Control**: Where code is stored (e.g., Git repository).
 - **Build and Test**: Compilation and automated testing of the code.
 - **Deployment**: Automated deployment to staging and production environments.
 - **Monitoring and Feedback**: Monitoring the deployed code for performance and issues.
 ## Tools for CI/CD
 There are several popular CI/CD tools available:
 - **Jenkins**
 - **GitLab CI/CD**
 - **Travis CI**
 - **CircleCI**
 - **Azure DevOps**
 ## Best Practices
 1. **Automate Everything**: Automate as much of the process as possible, including testing, builds, and deployments.
 2. **Isolate Environments**: Keep development, staging, and production environments separate to prevent conflicts.
 3. **Monitor and Feedback**: Continuously monitor deployed code for performance and issues. 
 4. **Version Everything**: Keep track of versions to easily identify and roll back changes if needed.
 5. **Security**: Integrate security checks into the pipeline to catch vulnerabilities early.
 ## Conclusion
 CI/CD practices are crucial for modern software development. They enable faster, more reliable, and higher quality code delivery. By automating the development pipeline, teams can focus on creating value for users and stakeholders.
--- a/Logging/Grafana/Install-Grafana-Prometheus.md
+++ b/Logging/Grafana/Install-Grafana-Prometheus.md
--- a/Logging/Grafana/Install-Inflx.md
+++ b/Logging/Grafana/Install-Inflx.md
--- a/Logging/Grafana/introduction.md
+++ b/Logging/Grafana/introduction.md
--- a/Logging/Librenms/librenms.wiki
+++ b/Logging/Librenms/librenms.wiki
--- a/Logging/Zabbix/Zabbix-dashboard.png
+++ b/Logging/Zabbix/Zabbix-dashboard.png
--- a/Logging/Zabbix/doc.wiki
+++ b/Logging/Zabbix/doc.wiki
--- a/Logging/Zabbix/install_zabix.sh
+++ b/Logging/Zabbix/install_zabix.sh
--- a/Logging/Zabbix/mysql.png
+++ b/Logging/Zabbix/mysql.png
--- a/Logging/netdata/netdata-install.md
+++ b/Logging/netdata/netdata-install.md
--- a/README.md
+++ b/README.md
@@ -1,41 +1,56 @@
 # Linux Documents
-Welcome to the This Document! This collection serves as a comprehensive resource for various Linux-related configurations, setups, and management scripts. It is designed to assist system administrators, developers, and enthusiasts in deploying and managing different services and applications on Linux-based systems.
+Welcome to the Linux Documents repository! This collection serves as a comprehensive resource for various Linux-related configurations, setups, and management scripts. It is designed to assist system administrators, developers, and enthusiasts in deploying and managing different services and applications on Linux-based systems.
 ## Table of Contents
- [Ansible](Ansible)
+### Configuration Management & Automation
- [CronJob](CronJob)
+- [Ansible](https://github.com/RadinPirouz/linux-documents/tree/main/Configuration%20Management%20%26%20Automation/Ansible)
- [Django](Django)
+- [CronJob](https://github.com/RadinPirouz/linux-documents/tree/main/Configuration%20Management%20%26%20Automation/CronJob)
- [Docker](Docker)
+
- [FileSharing](FileSharing)
+### Web Development & Frameworks
- [Grafana](Grafana)
+- [Django](https://github.com/RadinPirouz/linux-documents/tree/main/Web%20Development%20%26%20Frameworks/Django)
- [Info](Info)
+- [LaravelAPI](https://github.com/RadinPirouz/linux-documents/tree/main/Web%20Development%20%26%20Frameworks/LaravelAPI)
- [Iptables](Iptables)
+- [LaravelOnNginx](https://github.com/RadinPirouz/linux-documents/tree/main/Web%20Development%20%26%20Frameworks/LaravelOnNginx)
- [Kernel](Kernel)
+
- [LaravelAPI](LaravelAPI)
+### Containerization & Orchestration
- [LaravelOnNginx](LaravelOnNginx)
+- [Docker](https://github.com/RadinPirouz/linux-documents/tree/main/Containerization%20%26%20Orchestration/Docker)
- [Librenms](Librenms)
+- [Kubernetes](https://github.com/RadinPirouz/linux-documents/tree/main/Containerization%20%26%20Orchestration/Kubernetes)
- [NextCloud](NextCloud)
+
- [TelegramBot](TelegramBot)
+### Monitoring & Logging
- [Zabbix](Zabbix)
+- [Grafana](https://github.com/RadinPirouz/linux-documents/tree/main/Monitoring%20%26%20Logging/Grafana)
- [Kubernetes](kubernetes)
+- [Librenms](https://github.com/RadinPirouz/linux-documents/tree/main/Monitoring%20%26%20Logging/Librenms)
- [Netdata](netdata)
+- [Netdata](https://github.com/RadinPirouz/linux-documents/tree/main/Monitoring%20%26%20Logging/Netdata)
- [Nginx](nginx)
+- [Zabbix](https://github.com/RadinPirouz/linux-documents/tree/main/Monitoring%20%26%20Logging/Zabbix)
- [Nmap](nmap)
+
 ### Networking & Security
 - [Iptables](https://github.com/RadinPirouz/linux-documents/tree/main/Networking%20%26%20Security/Iptables)
 - [Nmap](https://github.com/RadinPirouz/linux-documents/tree/main/Networking%20%26%20Security/Nmap)
 - [Nginx](https://github.com/RadinPirouz/linux-documents/tree/main/Networking%20%26%20Security/Nginx)
 - [FileSharing](https://github.com/RadinPirouz/linux-documents/tree/main/Networking%20%26%20Security/FileSharing)
 ### Bots & Automation Tools
 - [TelegramBot](https://github.com/RadinPirouz/linux-documents/tree/main/Bots%20%26%20Automation%20Tools/TelegramBot)
 ### System Management
 - [Kernel](https://github.com/RadinPirouz/linux-documents/tree/main/System%20Management/Kernel)
 ### Miscellaneous
 - [Info](https://github.com/RadinPirouz/linux-documents/tree/main/Miscellaneous/Info)
 ## Getting Started
-To get started with any of the resources, simply navigate to the corresponding directory and follow the instructions provided in the README or script files. Each directory contains configuration files, setup guides, and examples to help you implement and manage the specific service or tool.
+To get started, navigate to the corresponding directory and follow the instructions provided in the README or script files. Each directory contains configuration files, setup guides, and examples to help you implement and manage the specific service or tool.
 ## Contributing
-We welcome contributions! If you have any improvements, bug fixes, or additional configurations that you'd like to share, please fork the repository and submit a pull request. Make sure to follow the existing structure and provide clear documentation for any new additions.
+We welcome contributions! If you have improvements, bug fixes, or additional configurations to share, please fork the repository and submit a pull request. Follow the existing structure and provide clear documentation for any new additions.
 ## Contact
-For any questions, suggestions, or issues, please open an issue on GitHub or contact the repository owner.
+For questions, suggestions, or issues, please open an issue on GitHub or contact the repository owner.
 Happy managing!
 [GitHub Repository Link](https://github.com/RadinPirouz/linux-documents)
--- a/Networking/CronJob/CronJob.md
+++ b/Networking/CronJob/CronJob.md
--- a/Networking/FileSharing/smb.md
+++ b/Networking/FileSharing/smb.md
--- a/Networking/Iptables/iptables.md
+++ b/Networking/Iptables/iptables.md
--- a/Networking/nmap/Nmap.md
+++ b/Networking/nmap/Nmap.md
--- a/Management/Kernel/Kernel_Compile.md
+++ b/Management/Kernel/Kernel_Compile.md
--- a/Frameworks/Django/db.sqlite3
+++ b/Frameworks/Django/db.sqlite3
--- a/Frameworks/Django/info/init.py
+++ b/Frameworks/Django/info/init.py
--- a/Frameworks/Django/info/pycache/init.cpython-39.pyc
+++ b/Frameworks/Django/info/pycache/init.cpython-39.pyc
--- a/Frameworks/Django/info/pycache/serializers.cpython-39.pyc
+++ b/Frameworks/Django/info/pycache/serializers.cpython-39.pyc
--- a/Frameworks/Django/info/pycache/urls.cpython-39.pyc
+++ b/Frameworks/Django/info/pycache/urls.cpython-39.pyc
--- a/Frameworks/Django/info/pycache/views.cpython-39.pyc
+++ b/Frameworks/Django/info/pycache/views.cpython-39.pyc
--- a/Frameworks/Django/info/admin.py
+++ b/Frameworks/Django/info/admin.py
--- a/Frameworks/Django/info/apps.py
+++ b/Frameworks/Django/info/apps.py
--- a/Frameworks/Django/info/migrations/init.py
+++ b/Frameworks/Django/info/migrations/init.py
--- a/Frameworks/Django/info/models.py
+++ b/Frameworks/Django/info/models.py
--- a/Frameworks/Django/info/serializers.py
+++ b/Frameworks/Django/info/serializers.py
--- a/Frameworks/Django/info/tests.py
+++ b/Frameworks/Django/info/tests.py
--- a/Frameworks/Django/info/urls.py
+++ b/Frameworks/Django/info/urls.py
--- a/Frameworks/Django/info/views.py
+++ b/Frameworks/Django/info/views.py
--- a/Frameworks/Django/manage.py
+++ b/Frameworks/Django/manage.py
--- a/Frameworks/Django/sys_info.md
+++ b/Frameworks/Django/sys_info.md
--- a/Frameworks/LaravelAPI/LearnAPI.zip
+++ b/Frameworks/LaravelAPI/LearnAPI.zip
--- a/Frameworks/LaravelOnNginx/LaravelOnNginx
+++ b/Frameworks/LaravelOnNginx/LaravelOnNginx
--- a/Proxies/NextCloud/NextCloud.md
+++ b/Proxies/NextCloud/NextCloud.md
--- a/Proxies/nginx/django.md
+++ b/Proxies/nginx/django.md
--- a/Proxies/nginx/dotnet.md
+++ b/Proxies/nginx/dotnet.md