Deploy an Angular app on S3 in 5 minutes

In this post I’ll be showing you how to deploy an Angular application to AWS S3. This post assumes that you already have an AWS account.

Advantages of hosting you Angular application on S3:

  • Cheap
  • Almost no maintenance
  • Easy to deploy

Step 1 – Create a new Angular app

Install the Angular command line interface

npm install -g @angular/cli

Create a new Angular app with the cli

ng new my-app

You can click “Enter” twice in the console to not include Angular Routing and include CSS in the newly generated Angular app on your local machine.

angular create new app command
ng new my-app

With a fresh new Angular app ready to go, it’s time to build the static production bundle.

Step 2 – Build the app

Build the production bundle of the application

ng build --prod

This will generate a dist/ folder, as specified in angular.json in the root directory of your project like so.

Angular build production bundle command line interface
ng build –prod

Once the build process is done you will the generated static files where index.html will be the entry point of the app.

Angular production build

Step 3 – Deploy to S3

In your AWS S3 console, create a new bucket to host your web application and make sure you uncheck “Block all public access” during the “Configure Options” step in the creation process.

Once the bucket is created, drag and drop all the files of the my-app folder that resides inside the dist folder into your S3 bucket. When setting the S3 permissions, select “Grant public read access to this object(s)” as seen below.

set S3 permissions
set S3 permissions

Click “next” through the other options and then AWS will upload your static files to the S3 bucket.

files deployed to S3
files deployed to S3

Lastly, we now hove to tell S3 to serve index.html as the starting point of our application. Navigate to the bucket properties and turn on static website hosting. Set index.html as the entry point of the application and save the configuration. Once you save the configuration click the “Endpoint” link and you will see your hosted Angular app live on the web! Congrats!

static web hosting configuration on S3
static web hosting configuration on S3

Do you need more granular control of how you host your Angular app? Check out my other post on how you can create you own custom configuration with EC2 and Nginx to deploy your Angular app.

Configure Angular for Multiple Development Environments

In this post I’ll show you how I set up my angular.json file to support multiple build environments for an Angular 6 application. I’ve used the configuration below in a development stack where I had a development, staging, and production server.

Configuration

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

Each configuration tells Angular to replace /environment.ts with the correct environment file in the "with": block.

Now when you run

ng build --configuration=development

The Angular CLI will build an optimized static bundle in the newly generated dist/ directory with the environment variables in environment.dev.ts.

CI/CD Possibilities

With this setup I was able to create an AWS CI/CD pipeline using CodeCommit, CodeBuild, CodeDeploy, and CodePipeline. The AWS CodeBuild service allowed me to set variables at build time so making an automated pipeline for each EC2 instance was as simple as replacing the above command with:

ng build --configuration=$ENVIRONMENT

For those of you interested here is the buildspec.yml I used for my AWS CI/CD pipeline:

version: 0.2

phases:
install:
commands:
- echo $CODEBUILD_SRC_DIR
- npm install -y npm@latest
- npm install -g @angular/cli
- rm package-lock.json
pre_build:
commands:
- npm install
build:
commands:
- echo build started on `date`
- ng build --configuration=$ENVIRONMENT
- ls -l -F
post_build:
commands:
- echo Production build ended on `date`
artifacts:
files:
- appspec.yml
- dist/my-app/**/*
cache:
paths:
- node_modules/

Comment below if you would like me to write a post on how I made the all AWS CI/CD pipeline!

Upgrade CPU of EC2 instance on AWS

The purpose of the article is to show you how to increase the CPU of your instance on AWS. In this case, I will upgrade my t2.micro instance to a t2.medium instance. You may need to upgrade the CPU on your EC2 instance as the demand for internal operations increases or you see a noticeable decrease in overall performance. Be mindful of the added cost of upgrading your EC2 instance because your bill can accumulate quickly. 

You can find the breakdown of general purpose EC2 instances here https://aws.amazon.com/ec2/instance-types/

Step 1 – Stop your currently running instance

Select the EC2 instance you want to upgrade, then click Actions>Instance State>Stop

Step 2 – Change instance type

Once your EC2 instance has stopped, got to Actions>Instance Settings>Change Instance Type

Once you click on Change Instance Type you will select which instance you want to upgrade to. In this case, I will upgrade my t2.micro to a t2.medium

Step 3 – Start the instance 

Start the instance in Actions>Instance State>Start

Once the instance starts back up you will have successfully upgraded your EC2 instance! In the case that you want to downgrade your instance, you would follow the same steps and select an instance with a lower CPU.

Simple Angular CI/CD pipeline with GitLab & AWS

In this tutorial, I will show you how to set up a simple CI/CD pipeline that compiles code on GitLab and then deploys to AWS EC2 via AWS CodeDeploy. This tutorial assumes:

  1. You have a working EC2 Ubuntu instance set up with a web server such as Nginx or Apache running and configured. 
  2. You have an existing code repository hosting an Angular project on GitLab.

Technologies Used: 

  • Angular 7
  • Gitlab CI/CD
  • AWS S3
  • AWS CodeDeploy
  • AWS EC2 Ubuntu 18.04 LTS

I’ve made a start project that I will be referencing throughout this project on Github will all the files you need already built in. Check it out here!

Step 1 – Create an S3 to AWS CodeDeploy Pipeline

I really don’t like dropping links in tutorials like this, however, for the sake of not re-writing Amazon’s documentation, I will have to tell you to follow all instructions in the tutorial in the link below. Only once you finished the tutorial will you be able to continue with the rest of this tutorial. Once you’re done with Amazon’s tutorial, you will have a CD pipeline ready to go waiting for GitLab to send the code.

https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-simple-s3.html

If you have successfully completed the above tutorial, any changes pushed to your S3 bucket will be deployed immediately to your EC2 instance. Then steps below will show you how to upload your production bundle to S3 from Gitlab to complete the CI/CD pipeline.

Step 2 – Create an appspec.yml 

Welcome back! The first thing we’ll have to do is create an appspec.yml file in the src/ folder of our project. The appspec.yml will tell AWS CodeDeploy to deploy your code in a specific file directory on the server – in our case, it’s the /var/www/ directory. 

version: 0.0
os: linux
files:
  - source: ./
    destination: /var/www/

Then we have to tell angular to include this file as an asset so it stays preserved during the production build. To do this, we edit the assets block in our angular.json file to include "src/appspec.yml":

...
"tsConfig": "src/tsconfig.app.json",
            "assets": [
              "src/favicon.ico",
              "src/assets",
              "src/manifest.json",
              "src/appspec.yml"
            ],
            "styles": [
...

Step 3 – Create .gitlab-ci.yml

Gitlab offers a continuous integration service if you add a

.gitlab-ci.yml

file to the root directory fo your code repository. I’ve provided a sample .gitlab-ci.yml file as seen in example Github project. Please be sure to update the group name and repository name for your own project. If you copy this code please be sure to use your own repository name.

image: node:10

stages:
  - build
  - deploy

build:
  stage: 'build'
  script:
    - apt update
    - apt-get install -y nodejs
    - npm install -y npm@6.11.0
    - nodejs -v
    - npm -v
    - ls -la -F
    - npm ci
    - npx ng build --prod
  cache:
    paths:
      - node_modules/
  artifacts:
    when: on_success
    name: '$CI_JOB_NAME-$CI_COMMIT_REF_NAME'
    paths:
      - dist/angular-gitlab-ci-cd-example/
  only:
    - dev
    - master

deploy:
  stage: 'deploy'
  environment:
    name: production
  script:
    - apt update
    - apt install -y software-properties-common
    - apt install -y python-dev
    - apt install -y python-pip
    - pip install awscli
    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
    - aws configure set region us-east-1
    - ls -la -F
    - mv dist/angular-gitlab-ci-cd-example/appspec.yml dist/
    - cd dist
    - ls -al -F
    - cd ..
    - aws deploy push --application-name angular-gitlab-ci-cd-example --s3-location $AWS_S3_LOCATION --ignore-hidden-files --source dist
  only:
    - master

If you commit to your master branch with this file in the root directory of your project, a CI pipeline will initiate with two steps outlined line-by-line below:

The Build Stage

1.Update the packages in the node:10 Docker container

- apt update

2. Install node & npm

- apt-get install -y nodejs
- npm install -y npm@6.11.0
- nodejs -v
- npm -v

3. Run npm install

- npm install

4. Build the production bundle of Angular using the local cli

- npx ng build --prod

6. Tell GitLab to cache your node_modules so that your project builds faster next time around

cache: 
    paths: 
      - node_modules/

7. This code block creates a build artifact that will be passed onto the next stage in the pipeline if all operations in the container run without error. In the case of Angular7, I’m passing the created dist/ directory to the next stage so that GitLab can send it to AWS to be deployed

  artifacts: 
    when: on_success    
    name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
    paths: 
      - dist/angular-gitlab-ci-cd-example/

8. This keyword tells GitLab only to run this stage when a commit is pushed to either the master and dev branches. You can customize any stage to run a specific set of branched or all branches if that’s what you need. 

  only:
    - dev
    - master

The Deploy Stage

1. Update the packages on the node:10 Docker image, install the python libraries needed for AWS CLI and then install the AWS CLI.

script: 
    - apt update
    - apt install -y software-properties-common
    - apt install -y python-dev  
    - apt install -y python-pip
    - pip install awscli

2. Navigate to your CI/CD settings in GitLab and add the following variables for your $AWS_ACCESS_KEY_ID and $AWS_SECRET_ACCESS_KEY from the CodeDeploy IAM User you created earlier from following the AWS tutorial in Step 1. You should also include the $AWS_S3_LOCATION as a CI/CD variable as well in the following format:

s3://your-bucket-name/your-bundle-name.zip

The <key> will be by the same name as the zip created from the build stage.

3. In this step, we are configuring the AWS CLI with the IAM Credentials of a user with the correct CodePipeline policies attached.

    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID
    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY
    - aws configure set region us-east-1

4. Remember from step 1 how we made sure the appspec.yml was preserved in the dist/ production bundle? Well, now we have to move it out it to the same directory level as the dist/ folder so that it sits on the same level as the dist/ folder. We have to do this to make the appspec.yml visible to AWS. If we do not do this, the AWS CLI will throw an error stating that it cannot find the appspec.yml file in the next step.

- mv dist/angular-gitlab-ci-cd-example/appspec.yml dist/
- cd dist
- cd .. 

5. Use the AWS CLI to deploy the dist/ bundle to AWS S3

 - aws deploy push --application-name angular-gitlab-ci-cd-example --s3-location $AWS_S3_LOCATION --ignore-hidden-files --source dist
only:
    - master

You’re Done!

Once you push your code to the master branch, navigate to the CI/CD pipeline and watch your code being built. Once GitLab is done building the production bundle, it will send it to AWS S3, which in turn will be deployed onto your live server moments later. I would love to hear your feedback on how I can improve this simple pipeline. 

How to connect Navicat to your remote PostgreSQL server on EC2

The purpose of this article is to show you how to connect you Navicat Database Admin Software tool to PostgreSQL server hosted on AWS EC2. Navicat is a vendor that offers a series of database management tools for PostgreSQL, Oracle, MariaDB, Microsoft SQL Server, MySQL and more. This article will assume that you already have a running EC2 Ubuntu 16.04 LTS instance with a PostgreSQL server running.

Step overview

  • Step 1 – Configure Security Group on EC2
  • Step 2 – Update PostgreSQL Configuration Files
  • Step 3 – Connect from Navicat

Step 1 – Configure Security Group on EC2

Log into your AWS account and select the AWS instance running the PostgreSQL server you would like to connect to on the EC2 dashboard. Next, you will edit the Security Group Inbound Rules.

Add an inbound rule with the following parameters:

  • Type: PostgreSQL
  • Protocol: TCP
  • Port Range: 5432 (This is the PostgreSQL port by default. If you changed the default port then use your custom port instead of the default one)
  • Source: [Write the single IP or IP range that you will be accessing your PostgreSQL database. Please be sure to restrict inbound port access to those who should not be able to access your database]

Once the inbound rules have been updated let’s proceed to update the PostgreSQL configuration files on the server.

Step 2 – Update PostgreSQL Configuration Files

First, we will ssh into the server via the command line and edit the postgresql.conf file with the following command.

$ sudo vim /etc/postgresql/9.5/main/postgresql.conf

Once in the file, we will include this line below which means the PostgreSQL server will listen for inbound communications from all IP addresses.

... listen_address='*' ... 

Next, we’ll edit the user access in the pg_hba.conf file.

$ sudo vim /etc/postgresql/9.5/main/pg_hba.conf 

Once in the file, we will include this line below which means the PostgreSQL server will allow access to only those who have the username and password to the database.

host    all    all    0.0.0.0/0    md5 

Keep in mind that these configurations may be too open to your preferences. I encourage you to update your database access to more exclusive IPs.

Step 3 – Connect from Navicat

All the hard work is done! Now the easy part. Open up the Navicat application and add a new connection. All you’ll need to do is enter the following information to make a new connection:

  • Host: [The Public IP of your EC2]
  • Port: [The port your PostgreSQL server is accessed thorugh]
  • Initial Database: [The name of the database you want to connect to on the server first]
  • User Name: [The username of the PostgreSQL user that has permissions to access the database]
  • Password: [The password of the PostgreSQL user that has permissions to access the database]

Once all of this information is filled out you should be able to connect no problem!

Final Notes

After you are connected you can begin to utilize the full potential of Navicat by generating relational diagrams, update your database, running backups, and so much more. I used to be a user of phppgadmin and I longed for the days I could seriously upgrade my database admin tool and Navicat was the answer.

Please like, share or comment if you found this article useful!

Deploy an Angular App in Production with Nginx & Ubuntu on EC2

This purpose of this tutorial is to show you how to configure Nginx to serve an Angular app on AWS EC2. This tutorial assumes the following:

  • You already have an Amazon Web Services account (if not you can make one here) and have basic knowledge of security groups
  • You already have a purchased a domain name and have associated it with a publicly accessible IP address
  • You have an existing Angular Project hosted on a code repository (Github, GitLab, BitBucket, etc.) and have some basic knowledge of Angular

Summary of technologies used

  • Ubuntu 16.04 LTS
  • Nginx 1.10.3
  • AWS EC2
  • Angular 6.1.3

Step overview

  • Step 1 – Open an EC2 instance
  • Step 2 – Install packages and dependencies
  • Step 3 – Configure Nginx
  • Step 4 – Deployment

Step 1 – Open an EC2 instance

Log into your AWS account, navigate to the EC2 Dashboard, and select “Launch Instance”. From the list of AMIs select Ubuntu Server 16.04 LTS (HVM).

While setting up the instance, you will be brought to a page where you select the instance type. Select t2.micro (free tier eligible). Once selected, click “Review and Launch” at the bottom of the page. On the next page click “Launch” on the bottom of the page as well.

Once launched it will take a few minutes for AWS to boot up your very own EC2 instance. Store your generated key pair in a safe place on your local computer. (Here’s documentation from AWS on how to handle your key pair)

Note: You may have to adjust the security group on your EC2 instance so that your website is publicly available. There’s plenty of resources and stack overflow questions solving this potential issue.


Step 2 – Install packages and dependencies

Time to ssh into your Ubuntu server with:

ssh -i ~/path-to-your-key-pair ubuntu@ec2-your-public-ip.compute-1.amazonaws.com

Once you have successfully logged into your public server it’s time to install some packages. Execute these commands from within your Ubuntu machine:

# update Ubuntu's local package index 
$ sudo apt-get update 

# install git 
$ sudo apt-get install -y git 

# install Nginx 
$ sudo apt-get install -y nginx 

# clear out the local repository of retrieved package files 
$ sudo apt-get -s clean 

Step 3 – Configure Nginx

If you are new to Nginx I highly recommend reading the following to understand what these next steps actually do.

Common Pitfalls using Nginx

Nginx Quick Start

Nginx Configuration

Navigate the sites-available directory.

$ cd /etc/nginx/sites-available

and use your preferred editor (I use vim) to create a new file. In this case we’re storing our nginx configuration as example.com.

$ sudo vim example.com

Enter the following in your new file:

server {     
    listen 80;      
    listen [::]:80;            
    root /var/www/your-angular-app-name/dist;   
    server_tokens off;   
    index index.html index.htm;     
 
    location / {         
        # First attempt to server request as file, then         
        # as directory, then fall back to displaying a 404.          
        try_files $uri $uri/ /index.html =404;      
    } 
}

***The line root /var/www/your-angular-app-name/dist will tell Nginx where the index.html file is for your compiled Angular app.

Save your new file and symlink it to the sites-enabled folder.

$ cd /etc/nginx/sites-enabled 
$ sudo ln -s ../sites-available/example.com 
$ ls -l

Remove the default file that comes with Nginx in the sites-enabled directory. This default file was placed here by Nginx when it was installed.

$ sudo rm default

For good practice run a test on your Nginx configuration to correct any configuration or syntax errors (syntax always gets the best of us).

$ sudo nginx -t

• Restart Nginx:

$ sudo nginx -s reload

Step 4 – Deployment

Before deploying an angular application we must use the Angular CLI to create the production build that will be served on our EC2. You have the option of building the production bundle right on your local or on your live server. If you are working by yourself on a project, it’s okay to build and add the generated dist folder to git source control. Otherwise you should avoid adding the compiled dist bundle to git when working with others to avoid merge conflicts from everyone’s own build.

Angular CLI documentation on deployments

Below I will show you two ways to deploy your app. Both methods below are ok to “test the waters” to build small applications to understand how to deploy an Angular app but I don’t recommend you keep deploying Angular in the ways detailed below. It is well worth your time to learn how to build an automation pipeline that takes care of this process for you. See my article building a simple CI/CD pipeline from GitLab to AWS. (You can build and deploy your Angular app virtually free!)

Path 1: Building the production bundle locally

In the case that you are building the production build on your local you will need to run:

$ ng build --prod

If there are no errors when Angular is building the production bundle then a dist directory will be generated in the root directory (/) of your project.

Check in the new dist dist folder to source control so that you can pull it into your server.

You will then have to ssh into your EC2 and clone the git repository into the /var/www/ directory.

$ cd /var/www
var/www $ git clone https://your-project-name

Note: You may need to use the $ sudo flag if your user inside the server does not have the right permissions to run these commands.

Restart Nginx:

$ sudo nginx -s reload

Navigate to your URL or Elastic IP address and your site should be live! If all you see is an Nginx 404 page then double check the directory on the root ...; line in your Nginx sites-available file is pointing to the right directory.

Path 2: Building on the server

DISCLAIMER: Depending on how large your application is this following method can run up your cloud provider bill.

In the case that you are building the production build on your server, you will then have to ssh into your EC2 and clone the git repository into the /var/www/ directory:

$ cd /var/www
var/www $ git clone https://your-project-name

Note: You may need to use the $ sudo flag if your user inside the server does not have the right permissions to run these commands.

Now it’s time to create the production build right on the server by making sure you currently are in your source code directory. First we must install some additional dependencies on the EC2 instance with the following commands:

# install node package manager 
$ sudo apt-get install -y npm 

# install curl 
$ sudo apt-get install -y curl  
  
# install node.js $ curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - 
 

# update node.js 
$ sudo apt-get install -y nodejs 
 
# install the Angular CLI 
$ sudo npm install -g @angular/cli  

Next we navigate to the directory where we cloned the repository

$ cd /var/www/the-project-you-just-cloned

Once in the project directory, you will run:

$ ng build --prod

If there is an issue with the production build then your website will display the generic Nginx 404 page. To avoid this I highly recommend testing the production build process by running the $ ng build --prod command on your local first for testing.

Once the dist folder has been built we will restart Nginx. Nginx has already been configured to look at the var/www/your-project/dist from our configuration above.

Restart Nginx:

$ sudo nginx -s reload

Navigate to your URL or Elastic IP address and your site should be live! If all you see is an Nginx 404 page then double check the directory on the root ...; line in your Nginx sites-available file is pointing to the right directory.


If you have this process down pat and want more of a challenge then check out my next post on building a simple CI/CD pipeline from GitLab to AWS.

How to preserve your static assets in the production bundle

If you want your static assets (images, svgs, etc.) to show up in production you’ll have to do the following:

  1. In your angular.json make sure that your assets folder holding your static assets is included in the assets block like so:
“tsconfig”:…
“assets”: [
  “src/favicon.ico”,
  “src/assets”,
  “src/robots.txt”,
  “src/sitemap.xml”
],
“styles”:…

With this addition to angular.json, you’re telling angular where to find the assets when you reference them throughout your code in the build process.

2. Make sure that you’re referencing the correct directory path to your assets in your HTML blocks. In the configuration above, each asset in the assets folder should be accessed like the following:

<img src="/assets/images/my_cool_image.jpg" /> 

Now when you build and deploy, the assets should show up because Angular knows where to find them now.

You’re done!

If you’ve followed all these steps, you’ll be able to navigate to your site domain in any browser and see your basic angular app up and running. If not, remember it can take up to 48 hours for any DNS changes to fully propagate if you’ve just associated your Elastic IP to your domain name manager! Thanks for reading!