Skip to content

Infrastructure

Jump to bottom
atfops edited this page Jan 28, 2024 · 37 revisions

Deployment Overview

This section outlines the deployment architecture of the WebCube solution, explaining how various components are deployed and interact in the production environment.

Environment Setup

Detailed steps for setting up the necessary infrastructure for different environments:

  • Development Environment: Mainly did through local development for year 1, maybe can be improve through CI/CD & real dev deployment in the future.
  • Production Environment: Deployed through OpsWebCube repository that stored Terraform code.

Prerequires before using this project

First you will need to learn more about :

What is Terraform ? What is OpenStack ? What is Docker ?

Understanding the code & infra architecture

WebCube Architecture

Capture d’écran 2024-01-25 à 15 21 36

First of all, the infra conception was done through several ideas the first year of this project according to needs. You will see of course a DNS that will be used for the communication facilities between instances.
The main part will be the Web-App instance that store a docker-compose which deploy 3 containers (nginx proxy, frontend, backend).

NOTE: nginx folder contains the conf of nginx reverse-proxy and an SSL auto-signed certificate with its keys so it is not added directly with WebCube but through deployment it's added by OpsWebCube (see data/files/nginx).

There was an LSP server that wasn't deployed on this project but maybe can be used in the future (see source code of container here).
We choose MariaDB database, so there is a server in the backend for that (which store data for application used purpose) Then we choose to implement a RabbitMQ server that will manage compilation/test jobs and communicate with both Compiler that will create .jar files by compiling java code. (see source code of workers here )
Finally, we choose to use NFS server for the synchronisation of users code (/code) between web-app & compiler, so it will centralize and allow them to share files between each others.

Actually, 7 instances were deployed, but of course it's scalable so you can expand infra if needed.

You should read attentively the OpsWebCube README.md file in order to understand the Terraform code :
https://github.com/IDE-PFE-S9/OpsWebCube/blob/main/README.md

Understanding networking of the project

See network tabs below:

Instance Public Network Private Network DNS front name DNS back name
dns True False pfewc-dns.webcube.pfe.dns X
web-app True True pfewc-web-app-front.webcube.pfe.dns pfewc-web-app-back.webcube.pfe.dns
mariadb False True pfewc-mariadb-front.webcube.pfe.dns (X) pfewc-mariadb-back.webcube.pfe.dns
rabbitmq False True pfewc-rabbitmq-front.webcube.pfe.dns (X) pfewc-web-app-back.webcube.pfe.dns
nfs False True pfewc-nfs-front.webcube.pfe.dns (X) pfewc-nfs-back.webcube.pfe.dns
compiler False True pfewc-compiler-front.webcube.pfe.dns (X) pfewc-compiler-back.webcube.pfe.dns
compiler2 False True pfewc-compiler2-front.webcube.pfe.dns (X) pfewc-compiler2-back.webcube.pfe.dns

Public (Front) Network = 192.168.1.0/24
Private (Back) Network = 172.24.0.0/24

NOTE: All public network with False boolean are by default UNACTIVATED (X) .

Tips to manipulate Infra

First of all, before deployment you will have to use an ssh key in order to ssh into all instances, follow next steps to correctly set up that :

  1. Create an ssh key :
Capture d’écran 2023-12-21 à 09 34 42
  1. Copy public-key to OpsWebCube/data/scripts/user_data.sh AND save pivate-key in your laptop :
Capture d’écran 2023-12-21 à 09 37 56

Secondly, in order to deploy infra follow README.md of OpsWebCube repository :

https://github.com/IDE-PFE-S9/OpsWebCube/blob/main/README.md#usage-with-gitlab-cicd-pipelines

Now you need to check which are IPs of your instances on OpenStack Dashboard :

Capture d’écran 2023-12-21 à 09 32 24

Thirdly, you can ssh into web-app instance and check containers status :

SSH command will be the same for you to ssh to web-app instance :
ssh -i <your-ssh-private-key> debian@172.24.6.X

Capture d’écran 2023-12-21 à 09 43 59

Finally, in order to ssh into all over instances (that are in private network), you will need to copy your private ssh key to web-app instance :

SCP command will be the same for you to copy private-key to web-app instance :
scp -i <your-ssh-private-key> <your-ssh-private-key> debian@172.24.6.43:/home/debian/.

Capture d’écran 2023-12-21 à 09 56 11

Now you can use the ssh key to connect to all over instances (located in public & private network) using DNS resolved names :
ssh -i <your-ssh-private-key> debian@pfewc-<service-name>-<back-or-front>.webcube.pfe.dns

Capture d’écran 2023-12-21 à 10 01 52 Capture d’écran 2023-12-21 à 10 02 52 Capture d’écran 2023-12-21 à 10 05 16

Troubleshooting

Providing solutions to common deployment and infrastructure-related issues:

Common Issue 1: Networks issues behind OpenStack solutions so instances are not launching as expected --> Restart deployment
Common Issue 2: Sometimes containers are not launched as expected --> you can follow next part to relaunch them

Relaunch docker containers through SSH

  1. SSH to according instance
  2. As sudo, go to correct directory where docker-compose.yml is located
  3. Check existing containers with docker ps -a
  4. Identify the reason why stop containers didn't launched as expected with docker logs <container-name>
  5. Stop existing containers with docker-compose stop
  6. Delete passed build cache and containers docker-compose rm
  7. Fix the issue for stopped containers
  8. Rerun all containers docker-compose up --build -d
  9. Verify that containers are launched correctly with docker ps -a

ESEO WebCube
Copyright © 2018 | Written by Théo L.

Clone this wiki locally