diff --git a/wiki_readme/CICD-Pipeline.md b/wiki_readme/CICD-Pipeline.md new file mode 100644 index 000000000..02c105528 --- /dev/null +++ b/wiki_readme/CICD-Pipeline.md @@ -0,0 +1,313 @@ +### CI/CD Pipeline + +The CI/CD pipeline for our NestJS project automates the build, test, and deployment processes, ensuring code quality and efficient delivery. We utilize GitHub Actions to orchestrate these operations across different environments—development, staging, and production. + +#### GitHub Actions Workflow + +Our CI/CD workflow is defined across three GitHub Actions configuration files: `dev.yml`, `staging.yml`, and `main.yml`. These workflows handle the continuous integration and deployment tasks specific to their respective branches. Below are the key components of each workflow: + +1. **Build**: Checks out the codebase, sets up Node.js, installs dependencies, and builds the application. +2. **Test**: Executes unit tests to validate code quality and functionality. +3. **Deploy**: Deploys the application to the provided remote environment, controlled by branch-specific triggers. + +#### Detailed Workflow Configuration + +##### Development Environment (`dev.yml`) + +```yaml +name: CI/CD-Dev + +on: + pull_request: + branches: + - dev + push: + branches: + - dev + +jobs: + test-and-build-dev: + runs-on: ubuntu-latest + if: github.event_name == 'pull_request' + + steps: + - name: Checkout code + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '18' + + - name: Install dependencies + run: npm install --include=dev + + - name: Build project + run: npm run build + + - name: Run tests + run: npm run test + + deploy-push: + runs-on: ubuntu-latest + if: github.event_name == 'push' + + steps: + - name: Checkout code + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '18' + + - name: Install dependencies + run: npm install --include=dev + + - name: Build project + run: npm run build + + - name: Run tests + run: npm run test + + - name: Deploying to virtual machine + uses: appleboy/ssh-action@v1.0.3 + with: + host: ${{ secrets.SERVER_HOST }} + username: ${{ secrets.SERVER_USER }} + # key: ${{ secrets.SERVER_PRIVATE_KEY }} + password: ${{ secrets.SERVER_PASSWORD }} + port: ${{ secrets.SERVER_PORT }} + script: | + echo "hello" + export PATH=$PATH:/home/teamalpha/.nvm/versions/node/v20.15.1/bin + bash ~/deployment.sh +``` + +This workflow is triggered on both pull requests and pushes to the `dev` branch. + +**1. Pull Request Triggered:** + +- **Checkout Code:** The repository's code is checked out. +- **Set up Node.js:** The specified Node.js version (18) is set up on the runner. +- **Install Dependencies:** Project dependencies, including development dependencies, are installed using `npm install --include=dev`. +- **Build Project:** The project is built using `npm run build`. +- **Run Tests:** Unit and integration tests are executed to ensure code quality using `npm run test`. + +**2. Push Triggered:** + +- **Checkout Code:** The repository's code is checked out. +- **Set up Node.js:** The specified Node.js version (18) is set up on the runner. +- **Install Dependencies:** Project dependencies, including development dependencies, are installed using `npm install --include=dev`. +- **Build Project:** The project is built using `npm run build`. +- **Run Tests:** Unit and integration tests are executed to ensure code quality using `npm run test`. +- **Deploying to Virtual Machine:** + - The workflow uses the `appleboy/ssh-action@v1.0.3` GitHub Action to establish an SSH connection to the development server. + - Authentication is handled securely using the server's host, username, and password, which are stored as encrypted secrets within the GitHub repository settings. + - Once connected, the workflow executes the `~/deployment.sh` script located on the server. This script handles the environment-specific deployment tasks, such as building and deploying the Docker image, updating environment variables, and restarting the application. + +##### Staging Environment (`staging.yml`) + +```yaml +name: CI/CD--Staging + +on: + pull_request: + branches: + - staging + push: + branches: + - staging + +jobs: + test-and-build-staging: + runs-on: ubuntu-latest + if: github.event_name == 'pull_request' + + steps: + - name: Checkout code + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '18' + + - name: Install dependencies + run: npm install --include=dev + + - name: Build project + run: npm run build + + - name: Run tests + run: npm run test + + deploy-staging: + runs-on: ubuntu-latest + # needs: test-and-build-main + if: github.event_name == 'push' + + steps: + - name: Checkout code + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '18' + + - name: Install dependencies + run: npm install --include=dev + + - name: Build project + run: npm run build + + - name: Run tests + run: npm run test + + - name: Deploying to virtual machine + uses: appleboy/ssh-action@v1.0.3 + with: + host: ${{ secrets.SERVER_HOST }} + username: ${{ secrets.SERVER_USER }} + # key: ${{ secrets.SERVER_PRIVATE_KEY }} + password: ${{ secrets.SERVER_PASSWORD }} + port: ${{ secrets.SERVER_PORT }} + script: | + echo "hello" + export PATH=$PATH:/home/teamalpha/.nvm/versions/node/v20.15.1/bin + bash ~/staging-deployment.sh +``` + +This workflow is very similar to the `dev.yml` workflow but is specifically designed for the `staging` branch and deploys to the staging environment. + +**1. Pull Request Triggered:** + +- **Checkout Code:** The repository's code is checked out. +- **Set up Node.js:** The specified Node.js version (18) is set up on the runner. +- **Install Dependencies:** Project dependencies, including development dependencies, are installed using `npm install --include=dev`. +- **Build Project:** The project is built using `npm run build`. +- **Run Tests:** Unit and integration tests are executed to ensure code quality using `npm run test`. + +**2. Push Triggered:** + +- **Checkout Code:** The repository's code is checked out. +- **Set up Node.js:** The specified Node.js version (18) is set up on the runner. +- **Install Dependencies:** Project dependencies, including development dependencies, are installed using `npm install --include=dev`. +- **Build Project:** The project is built using `npm run build`. +- **Run Tests:** Unit and integration tests are executed to ensure code quality using `npm run test`. +- **Deploying to Virtual Machine:** + - The workflow uses the `appleboy/ssh-action@v1.0.3` GitHub Action to establish an SSH connection to the staging server. + - Authentication is handled securely using the server's host, username, and password, which are stored as encrypted secrets within the GitHub repository settings. + - Once connected, the workflow executes the `~/staging-deployment.sh` script located on the server. This script handles the staging-specific deployment tasks, such as building and deploying the Docker image, updating environment variables, and restarting the application. + +##### Production Environment (`main.yml`) + +```yaml +name: CI/CD--Main + +on: + pull_request: + branches: + - main + push: + branches: + - main + +jobs: + test-and-build-main: + runs-on: ubuntu-latest + if: github.event_name == 'pull_request' + + steps: + - name: Checkout code + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '18' + + - name: Install dependencies + run: npm install --include=dev + + - name: Build project + run: npm run build + + - name: Run tests + run: npm run test + + deploy-main: + runs-on: ubuntu-latest + # needs: test-and-build-main + if: github.event_name == 'push' + + steps: + - name: Checkout code + uses: actions/checkout@v3 + + - name: Set up Node.js + uses: actions/setup-node@v3 + with: + node-version: '18' + + - name: Install dependencies + run: npm install --include=dev + + - name: Build project + run: npm run build + + - name: Run tests + run: npm run test + + - name: Deploying to virtual machine + uses: appleboy/ssh-action@v1.0.3 + with: + host: ${{ secrets.SERVER_HOST }} + username: ${{ secrets.SERVER_USER }} + # key: ${{ secrets.SERVER_PRIVATE_KEY }} + password: ${{ secrets.SERVER_PASSWORD }} + port: ${{ secrets.SERVER_PORT }} + script: | + echo "hello" + export PATH=$PATH:/home/teamalpha/.nvm/versions/node/v20.15.1/bin + bash ~/main-deployment.sh +``` + +This workflow manages the deployment to the production environment and is triggered by pull requests and pushes to the `main` branch. + +**1. Pull Request Triggered:** + +- **Checkout Code:** The repository's code is checked out. +- **Set up Node.js:** The specified Node.js version (18) is set up on the runner. +- **Install Dependencies:** Project dependencies, including development dependencies, are installed using `npm install --include=dev`. +- **Build Project:** The project is built using `npm run build`. +- **Run Tests:** Unit and integration tests are executed to ensure code quality using `npm run test`. + +**2. Push Triggered:** + +- **Checkout Code:** The repository's code is checked out. +- **Set up Node.js:** The specified Node.js version (18) is set up on the runner. +- **Install Dependencies:** Project dependencies, including development dependencies, are installed using `npm install --include=dev`. +- **Build Project:** The project is built using `npm run build`. +- **Run Tests:** Unit and integration tests are executed to ensure code quality using `npm run test`. +- **Deploying to Virtual Machine:** + - The workflow uses the `appleboy/ssh-action@v1.0.3` GitHub Action to establish a secure SSH connection to the production server. + - Authentication is handled using server credentials (host, username, password) stored as encrypted secrets within the GitHub repository settings. + - Once connected, the workflow executes the `~/main-deployment.sh` script located on the production server. This script handles the production-specific deployment tasks, such as building and deploying the Docker image, updating environment variables, and restarting the application. + +#### Branching Strategy + +- **Main**: Represents the production-ready codebase. +- **Dev**: Serves as the main development branch. Changes here are merged into `main` for releases. +- **Staging**: Used for final testing before production. Deployed to a subdomain or a specific path mimicking production settings. + +#### Security and Secrets + +GitHub Secrets are used to securely handle deployment credentials and configurations, ensuring that sensitive information is not exposed in the workflow files. These secrets are set in the repository settings under "Settings > Secrets and variables." + +#### Deployment Scripts + +Each environment uses a custom deployment script (`deployment.sh`, `main-deployment.sh`, `staging-deployment.sh`) executed via SSH to the virtual machine. This script is responsible for additional setup tasks and bringing the application online in the respective environments. + +This setup not only ensures the application's stability and security but also facilitates a streamlined development-to-deployment flow. diff --git a/wiki_readme/Database-Setup.md b/wiki_readme/Database-Setup.md new file mode 100644 index 000000000..170856097 --- /dev/null +++ b/wiki_readme/Database-Setup.md @@ -0,0 +1,73 @@ +## Database Setup: PostgreSQL with Docker Compose + +This section of the documentation details the setup and configuration of the PostgreSQL databases for the development and staging environments using Docker Compose. + +**1. Docker Compose Configuration** + +The `docker-compose.yml` file defines the configuration for both PostgreSQL databases: + +```yaml +version: '3.3' +services: + postgresdb-prod: + image: postgres:13 + restart: always + env_file: + - .env + ports: + - '5432:5432' + volumes: + - db-data-prod:/var/lib/postgresql/data + postgresdb-staging: + image: postgres:13 + restart: always + env_file: + - ./.env.staging + ports: + - '5433:5432' + volumes: + - db-data-staging:/var/lib/postgresql/data + +volumes: + db-data-prod: + driver: local + db-data-staging: + driver: local +``` + +**2. Database Details** + +- **`postgresdb-prod`:** + + - **Image:** `postgres:13` (Official PostgreSQL 13 image) + - **Environment Variables:** Loaded from `.env` file. + - **Port Mapping:** Exposes PostgreSQL on port `5432` on the host machine. + - **Data Persistence:** Uses a named volume `db-data-prod` to persist database data. + +- **`postgresdb-staging`:** + - **Image:** `postgres:13` + - **Environment Variables:** Loaded from `.env.staging` file. + - **Port Mapping:** Exposes PostgreSQL on port `5433` on the host machine. + - **Data Persistence:** Uses a named volume `db-data-staging` to persist data. + +**3. Environment Variables** + +- **`.env` and `.env.staging`:** These files contain environment-specific configurations for the databases, such as: + - `POSTGRES_DB`: Database name + - `POSTGRES_USER`: Database username + - `POSTGRES_PASSWORD`: Database password + +**4. Data Persistence** + +Both database containers use Docker volumes (`db-data-prod` and `db-data-staging`) to ensure data persistence. This means that even if the containers are stopped and restarted, the database data will be preserved. + +**5. Accessing the Databases** + +- **`postgresdb-prod`:** Accessible from the host machine via `localhost:5432`. +- **`postgresdb-staging`:** Accessible from the host machine via `localhost:5433`. + +**6. Connecting from the Application** + +The NestJS application is configured to connect to the appropriate database based on the current environment using the environment variables loaded from the respective `.env` files. + +This section outlines the configuration and setup of the PostgreSQL databases using Docker Compose. It ensures data isolation between environments and facilitates easy management and scaling of the database infrastructure. diff --git a/wiki_readme/Home.md b/wiki_readme/Home.md new file mode 100644 index 000000000..c0dd48493 --- /dev/null +++ b/wiki_readme/Home.md @@ -0,0 +1,161 @@ +## NestJS Boilerplate Project Documentation + +Welcome to the comprehensive documentation for our NestJS boilerplate project. This guide will walk you through the setup and integration of advanced CI/CD pipelines, messaging queues, and deployment processes using GitHub Actions. Our goal is to automate build, test, and deployment tasks, improve service communication via messaging queues, and ensure reliable deployments. + +**Table of Contents** + +- [Introduction](#introduction) +- [CI/CD Setup](#cicd-setup) + - [Choosing CI/CD Tool](#choosing-cicd-tool) + - [Pipeline Setup](#pipeline-setup) + - [Branching Strategy](#branching-strategy) +- [Database Setup](#database-setup) + - [Configuration](#configuration) +- [Messaging Queue Integration](#messaging-queue-integration) + - [RabbitMQ Setup](#rabbitmq-setup) + - [Integration with NestJS](#integration-with-nestjs) +- [Deployment](#deployment) + - [Server Setup](#server-setup) + - [Deployment Process](#deployment-process) + - [Domain Name Configuration](#domain-name-configuration) +- [Documentation](#documentation) +- [Getting Started](#getting-started) + +## Introduction + +This project aims to streamline the management, deployment, and communication of boilerplate projects. Using GitHub Actions for CI/CD, RabbitMQ for messaging queues, and Docker for database management, we ensure a robust and efficient development environment. + +## CI/CD Setup + +The CI/CD pipeline automates the build, test, and deployment processes of the application, ensuring code quality and efficient delivery. + +### Choosing CI/CD Tool + +For this project, we selected GitHub Actions due to its seamless integration with our GitHub repository and powerful automation capabilities. + +### Pipeline Setup + +We have configured the CI/CD pipelines to automate the build, test, and deployment processes for the NestJS boilerplate project. The pipeline runs on each pull request and push to the `dev`, `staging`, and `main` branches. + +CI/CD Workflow + +- **Build**: This job checks out the codebase, installs dependencies, and builds the application. +- **Test**: Executes unit and integration tests to ensure code quality and functionality. +- **Deploy**: Deploys the application to the designated environment (development, staging, or production). + +The workflow is triggered on every push to the repository and on pull requests. + +### Branching Strategy + +The project follows a Gitflow-like branching strategy: + +- **main**: Represents the production-ready codebase. +- **dev**: The main development branch. Merged into main for releases. +- **staging**: The main staging branch. + +## Database Setup + +Two separate PostgreSQL databases are set up using Docker containers: one for the development environment and one for production. This approach ensures data isolation and allows for independent database configurations. + +### Configuration + +The databases are configured in the `docker-compose.yml` file and connected to the application through environment variables. + +## Messaging Queue Integration + +We utilize RabbitMQ as the message broker for this project. + +### RabbitMQ Setup + +RabbitMQ is installed and runs on the remote server. + +### Integration with NestJS + +The NestJS application is configured to connect to the RabbitMQ server. We use the @nestjs/microservices package to implement message producers and consumers within the application. + +## Deployment + +The deployment process is automated through the CI/CD pipeline, aiming for 99% uptime. Projects are accessible via their respective domain names, and DNS settings are configured accordingly. + +### Server Setup + +The application is deployed to a remote server. Ensure the server meets the following requirements: + +- Node.js and npm installed +- Docker and Docker Compose installed +- Nginx installed and configured as a reverse proxy + +### Deployment Process + +The CI/CD pipeline builds and tests the application to ensure code quality and functionality. The deployment process involves several steps to set up and configure the environment, including database setup, RabbitMQ installation, NGINX proxy configuration, and using PM2 as the process manager to reload the NestJS application. + +#### Steps for Deployment + +1. **CI/CD Pipeline Execution** + + - The pipeline is triggered by a push or pull request to the repository. + - The pipeline checks out the code, installs dependencies, runs tests, and builds the project. + - Upon successful build and test, the pipeline deploys the application to the target environment (development, staging, or production). + +2. **Database Setup** + + - Two separate PostgreSQL databases are configured using Docker containers: one for development and one for production. + - Docker Compose is used to manage the database containers, ensuring they are isolated and correctly configured. + - Environment variables are set to connect the NestJS application to the appropriate database. + +3. **RabbitMQ Installation** + + - RabbitMQ is installed on the remote server to handle messaging queues for the application. + - The RabbitMQ service is configured to start on boot and is integrated into the NestJS application using environment variables. + +4. **NGINX Proxy Configuration** + + - NGINX is used as a reverse proxy to route incoming requests to the NestJS application. + - The NGINX configuration file is set up to forward requests to the appropriate port where the NestJS application is running. + - SSL certificates are configured in NGINX for secure communication if necessary. + - The NGINX service is restarted to apply the new configuration. + +5. **Using PM2 as the Process Manager** + + - PM2 is used to manage the NestJS application processes. + - The application is started using PM2, which ensures it runs in the background and restarts automatically on failure. + - The deployment script reloads the application using PM2 to apply any new changes. + +6. **Deployment Script Execution** + - A deployment script (`deployment.sh`, `main-deployment.sh`, `staging-deployment.sh`) is used to automate the deployment tasks. + - The script includes steps to pull the latest code, install dependencies, build the project, and reload the application using PM2. + - Environment variables are sourced to ensure all configurations are correctly applied. + +### Domain Name Configuration + +- We configured DNS records for [Main](https://api-nestjs.boilerplate.hng.tech), + [Staging](https://staging.api-nestjs.boilerplate.hng.tech), + [Dev](https://deployment.api-nestjs.boilerplate.hng.tech) to point to the server's IP address. +- Set up Nginx to act as a reverse proxy, directing traffic to the appropriate application based on the domain name. + +## Documentation + +All processes are documented comprehensively in this GitHub Wiki. Each section covers detailed steps, configurations, and commands used in the setup and deployment of the application. + +### [CI/CD Pipelines](cicd-pipeline) + +Automated processes for build, test, and deployment are detailed, including YAML configurations and environment setups. + +### [Messaging Queue Integration](rabbitmq-installation-and-setup) + +Documentation covers the installation, configuration, and integration of RabbitMQ into the NestJS project. + +### [NGINX Configuration ](nginx-configuration) + +This outlines the NGINX configuration used for routing traffic to our NestJS applications deployed on different ports and subdomains. + +### [Database Setup](database-setup) + +Step-by-step guides on setting up and configuring Postgres databases in Docker containers for development and production. + +## Getting Started + +1. Clone the repository. +2. Install dependencies: `npm install` +3. Configure environment variables (database connection details, RabbitMQ credentials, etc.). +4. Start the application: `npm run start:dev`, `npm run start:staging`, `npm run start:prod` diff --git a/wiki_readme/NGINX-Configuration.md b/wiki_readme/NGINX-Configuration.md new file mode 100644 index 000000000..e2f4b17bf --- /dev/null +++ b/wiki_readme/NGINX-Configuration.md @@ -0,0 +1,102 @@ +## NGINX Configuration for NestJS Applications + +This outlines the NGINX configuration used for routing traffic to our NestJS applications deployed on different ports and subdomains. + +**Configuration Breakdown:** + +The provided NGINX configuration defines four server blocks: + +**1. Production Server (api-nestjs.boilerplate.hng.tech:443)** + +```nginx +server { + server_name api-nestjs.boilerplate.hng.tech; + + access_log /var/log/nginx/access.log; + error_log /var/log/nginx/error.log; + + location / { + proxy_pass http://localhost:3007; + } + + listen 443 ssl; + ssl_certificate /etc/letsencrypt/live/api-nestjs.boilerplate.hng.tech/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/api-nestjs.boilerplate.hng.tech/privkey.pem; + include /etc/letsencrypt/options-ssl-nginx.conf; + ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; +} +``` + +- This block handles HTTPS traffic for the main application domain `api-nestjs.boilerplate.hng.tech`. +- It listens on port 443 (default HTTPS port). +- Traffic is forwarded to the NestJS application running on `http://localhost:3007` using `proxy_pass`. +- SSL is enabled using certificates obtained from Let's Encrypt. + +**2. Deployment Server (deployment.api-nestjs.boilerplate.hng.tech:443)** + +```nginx +server { + listen 443 ssl; + server_name deployment.api-nestjs.boilerplate.hng.tech; + + ssl_certificate /etc/letsencrypt/live/deployment.api-nestjs.boilerplate.hng.tech/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/deployment.api-nestjs.boilerplate.hng.tech/privkey.pem; + + access_log /var/log/nginx/access.log; + error_log /var/log/nginx/error.log; + + location / { + proxy_pass http://localhost:3008; + } +} +``` + +- This block handles HTTPS traffic for the subdomain `deployment.api-nestjs.boilerplate.hng.tech`, likely used for a deployment preview environment. +- Traffic is forwarded to the application instance running on `http://localhost:3008`. +- Similar to the production server, SSL is enabled with Let's Encrypt certificates. + +**3. Staging Server (staging.api-nestjs.boilerplate.hng.tech:443)** + +```nginx +server { + listen 443 ssl; + server_name staging.api-nestjs.boilerplate.hng.tech; + + ssl_certificate /etc/letsencrypt/live/staging.api-nestjs.boilerplate.hng.tech/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/staging.api-nestjs.boilerplate.hng.tech/privkey.pem; + + access_log /var/log/nginx/access.log; + error_log /var/log/nginx/error.log; + + location / { + proxy_pass http://localhost:3009; + } +} +``` + +- This block handles HTTPS traffic for the subdomain `staging.api-nestjs.boilerplate.hng.tech`, likely used for a staging environment. +- Traffic is forwarded to the application instance running on `http://localhost:3009`. +- SSL is enabled using Let's Encrypt certificates. + +**4. HTTP Redirection Server (port 80)** + +```nginx +server { + listen 80; + server_name api-nestjs.boilerplate.hng.tech staging.api-nestjs.boilerplate.hng.tech deployment.api-nestjs.boilerplate.hng.tech; + + location /.well-known/acme-challenge/ { + allow all; + root /var/www/certbot; + } + + location / { + return 301 https://$host$request_uri; + } +} +``` + +- This block listens on port 80 (default HTTP port) for all defined server names. +- It handles two types of requests: + - Requests for the Let's Encrypt ACME challenge used for certificate renewal are allowed and served from `/var/www/certbot`. + - All other requests are redirected to their HTTPS equivalent using a 301 redirect (`return 301 https://$host$request_uri;`). diff --git a/wiki_readme/RabbitMQ-Installation-and-Setup.md b/wiki_readme/RabbitMQ-Installation-and-Setup.md new file mode 100644 index 000000000..1cc5172d5 --- /dev/null +++ b/wiki_readme/RabbitMQ-Installation-and-Setup.md @@ -0,0 +1,124 @@ +## RabbitMQ Installation and Setup + +This document details the process of installing and setting up RabbitMQ on a remote server, enabling its use as a message broker for the NestJS application. + +**Server Requirements:** + +- Ubuntu or a compatible Linux distribution +- Root or sudo access +- Stable internet connection + +### Installation Steps: + +1. **Update System Packages:** + + ```bash + sudo apt-get update -y + ``` + +2. **Install Prerequisite Packages:** + + ```bash + sudo apt-get install curl gnupg apt-transport-https -y + ``` + + - **curl:** Used to download files from the internet. + - **gnupg:** Used for verifying package signatures. + - **apt-transport-https:** Enables HTTPS support for APT package manager. + +3. **Import Signing Keys:** + + ```bash + ## Team RabbitMQ's main signing key + curl -1sLf "https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73A36E6026DFCA" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/com.rabbitmq.team.gpg > /dev/null + + ## Community mirror of Cloudsmith: modern Erlang repository + curl -1sLf https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-erlang.E495BB49CC4BBE5B.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/rabbitmq.E495BB49CC4BBE5B.gpg > /dev/null + + ## Community mirror of Cloudsmith: RabbitMQ repository + curl -1sLf https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-server.9F4587F226208342.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/rabbitmq.9F4587F226208342.gpg > /dev/null + ``` + + - This step imports the necessary GPG keys for verifying the authenticity of the RabbitMQ and Erlang packages. + +4. **Add RabbitMQ Repositories:** + + ```bash + sudo tee /etc/apt/sources.list.d/rabbitmq.list <