Scribd
Upload
51 views

NodeJs Deploy Using Github Actions

GitHub Actions can be used to automate software builds, tests, and deployments directly from a GitHub repository. This document outlines setting up continuous integration and deployment (CI/CD) workflows using GitHub Actions for a Node.js project. It describes generating SSH keys to access servers for deployment, adding the keys as secrets to the GitHub repository, and configuring workflows to run tests on pull requests and deploy to staging and production servers on pushes to different branches.

Uploaded by

Tech Devils
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
51 views

NodeJs Deploy Using Github Actions

GitHub Actions can be used to automate software builds, tests, and deployments directly from a GitHub repository. This document outlines setting up continuous integration and deployment (CI/CD) workflows using GitHub Actions for a Node.js project. It describes generating SSH keys to access servers for deployment, adding the keys as secrets to the GitHub repository, and configuring workflows to run tests on pull requests and deploy to staging and production servers on pushes to different branches.

Uploaded by

Tech Devils
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Deploy NodeJs Production on AWS EC2

Introduction
GitHub Actions was launched less than a year ago and since then has been receiving numerous positive
remarks. It allows us to have the important things about our project integration and deployment in a
central place. In other words, your code can be built, tested, and deployed from GitHub without using
external CI/CD services to do the job for you.

In this article, we will be exploring a hands-on approach to managing your CI/CD processes using GitHub
Actions.

Prerequisites

● A GitHub account. If you don’t have one, you can sign up here

● A server with SSH access

● Basic knowledge of writing valid YAML

● Basic knowledge of GitHub and Git


Our plan
In this tutorial, we will be covering the major parts that will form a basic CI/CD setup for our demo
application. Our CI/CD setup will monitor pushes and pull requests made to our repository. We want to be
able to:

● Run tests on pushes

● Run tests on pull requestDeploy when pushes are made to specific branches

● Deploy to staging server when push is on staging branch

● Deploy to production server when push is on master branchDeploy when a release is tagged The
sample project

To make this article focused and swift, I have created a sample NodeJs project that will be used in this

article. The project contains some tests, both frontend tests, and backend tests to follow appropriately.
To clone the project run:

git clone https://github.com/example-repo/deploy

What is a workflow?
A workflow defines the steps required to complete a CI/CD process. According to GitHub’s
documentation:

Workflows are custom automated processes that you can set up in your repository to build, test, package, release,
or deploy any project on Github

A workflow is defined within the repository and committed as part of the repository. When you commit a
workflow and push to GitHub, GitHub Actions will automatically detect the workflow and immediately
parse the workflow and start processing your CI/CD process based on the instruction defined there.
Workflows are written with YAML and stored inside .github/workflows directory of your project root.

Configuring workflows
Run tests on a pull request workflow

This workflow is very useful when a large team is collaborating on the same project. You would want to
run some checks whenever a pull request is created and not wait until it is merged before testing it. For
this, we will define a workflow that will run when a pull request is made.

name: Deploy Remote website

on: [push]

jobs:

build:

runs-on: ubuntu-latest
steps:

- uses: actions/checkout@master

- name: Create project dir

uses: appleboy/ssh-action@master

with:

HOST: ${{ secrets.SSH_HOST_NAME }}

USERNAME: ${{ secrets.SSH_USER_NAME }}

KEY: ${{ secrets.SERVER_PRIVATE_KEY }}

script: |

cd /home/ec2-user

/usr/bin/bash test.sh

echo 'Deployment to server succesful!'

Note:

The above should be saved in the .github/workflows directory as node-prod.yml.

Bash Script Workflow

#!/bin/bash

cd /path/to/your/project-prod

git checkout master

git stah

git pull origin master

npm install

pm2 restart apps.js

Obtaining server credentials


The aim here is to give GitHub actions access to our server to deploy the changes, you will obtain the
private key for your server and add it in the secret. To do this, you will need to generate an SSH key if you
haven’t done that already, log in to your server and run:

Ssh-keygen

There will be some prompts and you can accept the default values. Ensure there is no passphrase given to
your SSH key during the prompt setup. If you already have your SSH Key generated, this step can be
skipped. After running through the prompts, you should have something like this:
Two files named id_rsa.pub and id_rsa will be generated for you in the ~/.ssh directory. Next, copy the
content of id_rsa, not id_rsa.pub. id_rsa.pub contains your public key while id_rsa contains your private
key:

cat ~/.ssh/id_rsa

You need to add the public key generated by SSH keygen to the authorized_keys so that any connection
attempted using the private key will be allowed. This is done by running this command:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

The command above will produce no output so do not worry if nothing happens after running the
command. Next, you will head over to GitHub, go to the Settings tab of the project. Then click on Secrets
as shown in the image below:
You need to give a name to the secret that corresponds to what has been defined in the Workflow i.e
SSH_PRIVATE_KEY and then put the content you copied as the value like so:

After adding the secret, we will have a view looking like this:
Obtain the SSH Known Hosts of the server and also add it to the Secrets section. From your local machine
you have to run to get the ssh known hosts:

ssh-keyscan rsa -t {server_ip_address}

Note:

Replace {server_ip_address} with your server public IP address

Copy the output of this command and add it to the secrets with the name SSH_KNOWN_HOSTSand the
content will be copied.
Note:

The part to copy begins with {server_ip_address} sh-rsa

Observe that, not all the contents, in this case, were copied. Only the part highlighted was copied. After
adding it to Github Secrets we will have something like this:

To achieve our plan of deploying to different server appropriately, you will need to repeat this process for
the staging server and the production Server or else you will need to give appropriate names to the
secrets you’re adding to the repository. You must ensure that this naming takes effect in the workflow
written above since you’re using different servers for your production and staging environments.

You might also like