Developer documentation
Getting Started
AirLab application is split into four separate packages:
- shared: common package used by other three packages.
- backend: main API gateway. Deployed in a separate container.
- worker: background worker that handles long-running tasks, like sending emails. Deployed in a separate container.
- frontend: front-end Vue application, served as a static content by nginx server.
There are other services deployed together with AirLab application:
- Postgres database
- Redis (cache/pub-sub)
- RabbitMQ (job queue)
- Traefik (load-balancer)
- pgAdmin (Postgres admin app)
- RedisInsight (Redis admin app)
- Portainer (Docker admin app)
Info
Services configuration is defined in .deploy/shared.yml
file. Please also check .deploy/development.yml
, .deploy/production.yml
or .deploy/staging.yml
depending on your deployment scenario.
Three deployment configurations are available by default: development
, staging
and production
.
It is highly recommended to use make
commands (see Makefile
for available options) to manage all tasks.
By default, there is a .env.template file in the repo with default values.
Please rename it to .env
and set all environment variables values according to your needs and server configuration.
Warning
.env
file is ignored by Git in order to avoid putting sensitive information to Git repository!
As you can see, some variables values are duplicated across several env variables.
This is due to some existing limitations: for instance, in order for a Webpack bundler to inject env variable values into the compiled Vue front-end application, they should have a prefix VUE_APP_
.
This could be improved in the future for sure.
Important
Main setting you should care about is DOMAIN
environment variable. In case of local development (with hot-reloading dev proxy server) it should be set to localhost
.
Development deployment
Local development deployment supports debugging and hot-reloading both on back-end and front-end. To get a local development instance up and running please follow the following steps.
Recommended and tested environment for development and deployment is Ubuntu Linux distribution. If you are going to use another OS or distribution please make changes accordingly. Make sure that the following tools are installed globally on your machine:
Installation
Clone the AirLab repo
git clone https://github.com/BodenmillerGroup/airlab-web.git
Install all necessary NPM packages on your local machine
make bootstrap
Deploy development Docker containers locally
make deploy-development
Run database migrations to initialize database
make db-migration
One can access locally deployed version of AirLab at http://localhost.
Run development version of front-end app (with automatic hot-reloading).
make serve-frontend
One can access locally deployed version of AirLab with hot-reloading and debugging capabilities at http://localhost:9999.
Please keep in mind that this functionality is only supported on local machines with DOMAIN
env variable set to localhost
!
Staging deployment
staging
build is used to test production build of AirLab in environment similar to production
environment, but it runs on a separate test server.
The difference is another domain name address.
Unlike production deployment, staging deployment doesn't require pre-build Docker images as it will build them during deployment process.
Installation
Clone the AirLab repo
git clone https://github.com/BodenmillerGroup/airlab-web.git
Later on you can update the repo by running:
git pull
Rename .env.template
file in the root repo folder to .env
and set all environment variables values accordingly to staging configuration. (Usually it should be done only once as .env
file is ignored by Git and it won't be overwritten by git pull
command).
Warning
Please check that env variable DOMAIN
is properly set in .env
file on staging server before deployment!
Build and deploy Docker containers on the staging server:
make deploy-staging
Production deployment
Preparing production Docker images
Production deployment requires pre-build production Docker images to be available. Images names are defined by the following env variables:
- DOCKER_IMAGE_BACKEND
- DOCKER_IMAGE_WORKER
- DOCKER_IMAGE_FRONTEND
Important
It is strongly recommended to use tagged Docker images in production deployment scenario to enforce stability! DOCKER_TAG
env variable in .env
file defines Docker image tag used during build and deployment.
In order to build these images and then push them to Docker image registry (e.g. Docker Hub), run the following command in your development environment:
make build-push
This operation should be done each time you are planning to release new production version.
Installation
As soon as Docker images are build and published to a registry, one can deploy production version of AirLab by running the following commands on a production server:
Clone the AirLab repo
git clone https://github.com/BodenmillerGroup/airlab-web.git
Later on you can update the repo by running:
git pull
Rename .env.template
file in the root repo folder to .env
and set all environment variables values accordingly to production configuration. (Usually it should be done only once as .env
file is ignored by Git and it won't be overwritten by git pull
command).
Warning
Please check that env variable DOMAIN
is properly set in .env
file on production server before deployment!
Deploy production Docker containers
make deploy-production
Run database migrations to initialize database (usually should be used only once during first deployment).
make db-migration
Info
Production deployment doesn't support debugging and hot-reloading because it is compiled to minimize bundle size and optimize performance.