Part 8. Clock-in/out System: Deploy frontend (Angular 6+) using environments

by Carlos Caballero

This post is part of a Series of post which I'm describing a clock-in/out system if you want to read more you can read the following posts:

Introduction

In the last post (Part 7. Clock-in/out System: Deploy backend (nestJS) using docker/docker-compose), we deployed our system's backend using environment variables and docker/docker-compose in a production server. In this post, we will deploy our frontend, developed in Angular, using environment variables (created with Angular CLI) and docker/docker-compose.

Here is a common solution for the management of environment variables in angular, using angular-cli (which we will use shortly). Another solution is to create your own deployment system by using a tool such as gulp or webpack.

Finally, our code is deployed using docker's containers. We will create an image from our code, and docker-compose.

Angular's Environment variables

By default, the Angular CLI creates an src/environments folder which contains environment files. Initially, there are two files: 1) environment.ts and 2) environment.prod.ts.

The environment.ts file is used for a development environment, while the environment.prod.ts file is used in production environments. These files are both referenced in the angular.json file.

"configurations": {
  "production": {
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.prod.ts"
      }
    ],
    "optimization": true,
    "outputHashing": "all",
    "sourceMap": false,
    "extractCss": true,
    "namedChunks": false,
    "aot": true,
    "extractLicenses": true,
    "vendorChunk": false,
    "buildOptimizer": true
  }
}

The fileReplacements array is angular's environment key, since it is used to indicate which file will be replaced when production configuration is used.

In our code, we only need to import the object from the environment file to use our environment variables. The following code shows a component which imports said environment file.

import { Component } from '@angular/core';
import { environment } from '../environments/environment';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent {
  env = environment;
}

The method to switch between different environments is to use the --configuration option , which may be used in both ng serve and ng build commands:

ng serve --configuration=prod
ng build --configuration=prod // then `environment.prod.ts` will be used instead.

We can have as many configuration environments as we like. For example:

  1. environment.test.ts. This configuration can be used to change several variables in unit test environment.
  2. environment.e2e-test.test. This configuration can be used to change several variables in e2e test environment.
  3. environment.qa.ts . This configuration can be used to change several variables in QA environment.

Therefore, the content of our environment files is the following:

  1. environment.ts
export const environment = {
  production: false,
  APIENDPOINT_BACKEND: 'http://localhost:3000',
};
  1. environment.prod.ts
export const environment = {
  production: true,
  APIENDPOINT_BACKEND: 'http://192.168.0.60:3000',
};

The variables which change between environmnent files are APIENDPOINT_BACKEND and production. The production variable is used in the main.tsfile to call the enableProdMode which is used to make several optimizations in the final bundle.

  1. main.ts
import { enableProdMode } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { AppModule } from './app/app.module';
import { environment } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

platformBrowserDynamic().bootstrapModule(AppModule)
  .catch(err => console.log(err));

In our project, there is a file which contains the project's constants. This file contains the list of endpoints, which are relations using the APIENDPOINT_BACKEND. The idea is to use the environment file (environment), as you may observe in the following code:

import { environment } from 'src/environments/environment';

export class AppSettings {
  static readonly TYPE_ACTION = {
    INPUT: 'input',
    OUTPUT: 'output',
  };
  static readonly DATE_FORMAT = 'DD/MM/YYYY HH:mm:ss';
  static readonly APIENDPOINT = environment.APIENDPOINT_BACKEND;
  static readonly APIENDPOINT_USER = `${AppSettings.APIENDPOINT}/user`;
  static readonly APIENDPOINT_USERS = `${AppSettings.APIENDPOINT}/users`;
}

Deploy: Docker and Docker-compose

The idea is to use the same environment in both development and production. In this context, Docker is the perfect tool, due to it allowing us to configure different containers, which switch the environment's configuration. We need to build our own image, a docker container, which will be orchestrated by using Docker-compose.

Docker

Our dockerfile file is based on the nginx:alpine image, due to the project not needing a system library. This image merely copies the nginx.conf configuration and the angular project after it built to distribution (using the command ng build --configuration=prod.

FROM nginx:alpine

COPY deploy/nginx.conf /etc/nginx/nginx.conf

WORKDIR /usr/share/nginx/html
COPY dist/ticketing-frontend .

It is very important for the angular code to be deployed in a webserver, such as apache or ngnix.

The nginx configuration is now the following:

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    server {
        listen 80;
        server_name  localhost;

        root   /usr/share/nginx/html;
        index  index.html index.htm;
        include /etc/nginx/mime.types;

        gzip on;
        gzip_min_length 1000;
        gzip_proxied expired no-cache no-store private auth;
        gzip_types text/plain text/css application/json 
        application/javascript application/x-javascript text/xml 
        application/xml application/xml+rss text/javascript;

        location / {
            try_files $uri $uri/ /index.html;
        }
    }
}

Docker-compose

In our project, we have a docker-compose file which is used to deploy our docker image. The file is very simple, since it merely deploys the container which contains the compiled code of our Angular project.

version: '3.1'

services:
  clock-frontend:
    image: 'ccaballerog/clock-frontend'
    build: '.'
    restart: always
    ports:
      - 8181:80
    networks:
      - clock-net

networks:
  clock-net:
    driver: bridge

Shell script to deploy

The last step of our process would be to automate the construction and execution of the containers. I have two scripts to do this task; the first script creates the image (first removing the image, should there be one) and the second script deploys the code by using docker-compose.

#!/usr/bin/env bash
sh create-image.sh
docker-compose -f ../docker-compose.production.yml up --force-recreate

#!/usr/bin/env bash
docker rm -f clock-backend # remove the container
docker rmi -f ccaballerog/clock-backend  # remove the image
docker image prune # remove all images without use
docker volume prune # remove all volumes without use
docker build -t ccaballerog/clock-backend .. # create the image

Conclusion

In this post I've explained how you can deploy your frontend with Angular by using docker and docker-compose. The most interesting feature of this code, is the fact that we can load our own environment variables, switching between development and production environments using Angular-CLI.