I wanted to write this guide for a while because DevOps is one of the things that is not discussed much yet there are a few straightforward actions that you can integrate into your workflow that will make your developer life easier. much I'm by no means a DevOps expert, I'm just sharing what stuck with me over the last year of experimenting with it. Here are a few reasons why you should try it: You can achieve a significant productivity boost. Once everything is set, it doesn't require much attention. It feels amazing every time you push code. In this series: I will talk about continuous delivery (CD), reporting, error logging, and Github Actions. Good thing is that you can choose for yourself what you need and ignore the rest, as the pieces are mostly independent. I will use Javascript for project examples and all the services that we going to make. Oh, and we also will need a VPS to deploy our server. You can use your own computer though. We will start by making a simple CD server that deploys your code each time you commit to master. There are two parts: Setting up CD server Configuring push Webhooks Setting up CD server : this code is based on by Nikita Kolmogorov. Note node-cd I won't go into the basics of setting a server up. If you have questions on that, you can refer to , written by yours truly. this guide Our goal here will be to create a simple server that runs a Shell script each time it receives a message from outside. That script will download recent codebase from Github, install new dependencies (if any), and then restart the app via . pm2 First, we will need to make sure that the webhook request is authentic. Thing is, knowing the URL at which we expect to receive a webhook, anyone can send a request, thus being able to restart our app at his will. We want to give that power only to GitHub. One way to solve that is to check the sender's IP and match it with a known list of GitHub addresses. That should work, but it's not a bulletproof solution, as IPs might change over time. We will use a much more robust solution: cryptography, specifically HMAC. HMAC, or hash-based message authentication code, is a way to sign a message with a secret key. In essence, it concatenates a message and a secret to hash the result. Since a slight change of input will drastically change the hash, the only way to produce "correct" hash is to know the secret key. For HMAC, we will need to generate a key which we will provide to GitHub. GitHub will sign all webhook requests with that key. In our server code, once a request is received we calculate the hash ourselves and compare it to what we got. If two hashes are identical, it means that the sender knows the key and therefore it's indeed GitHub that sent the request. HMAC doesn't a message, though. So if someone will be able to intercept that message from GitHub, he will be able to see that you pushed a commit to the repository. It's not a big deal for us, but you should be careful if you're going to use HMAC for something confidential. encrypt Alright, enough talking, let's write some code. We will start with two helper functions that will deal with HMAC. secret = process.env.GITHUB_SECRET; { hmac = crypto.createHmac( , secret); bodyString = .stringify(body); bodySignature = hmac.update(bodyString).digest( ); ;
} { source = Buffer.from(signature); comparison = Buffer.from(comparisonSignature); crypto.timingSafeEqual(source, comparison);
} const ( ) function createComparisonSignature body const 'sha1' const JSON const 'hex' return `sha1= ` ${bodySignature} ( ) function compareSignatures signature, comparisonSignature const const return Function calculates a hash and compares our hash and what we got from the request. We will need to import which is a built-in Node.js module that deals with, you guessed it, cryptography. createComparisonSignature compareSignatures crypto Also, note the part. You will need to create a file and put your GitHub key there. const secret .env crypto = ( ); const require 'crypto' In our router code, we will get the key, check it using the functions above, and act based on that check. signature = req.header( ); comparisonSignature = createComparisonSignature(req.body); (!compareSignatures(signature, comparisonSignature)) { .log( );
    res.status( ).end(); ;
} const 'X-Hub-Signature' const if console 'Bad signature' 403 return As you can see, if we got an invalid key, we simply send and drop the request. If the hash is correct, we continue… 403 Now, the next step is optional, but it's really simple and might make things more readable. What we will do is to map the repository name with an "internal" project name. Best to see it in the code: projects = { : , : ,
}; repository = req.body.repository.name; project = projects[repository]; const 'project-abc-server' 'abc' 'project-xyz-backend' 'xyz' const const Now we can refer to our projects as and in the code, which will be handy later. Also, we can keep a list of "approved" projects and throw status code if it's something we didn't expect: abc xyz 400 (!project) { .log( );
    res.status( ).end(); ;
} if console 'Project not found' 400 return Finally, the magic part: we execute a Shell script based on the project that was updated. We will start with a helper function that can run any script: { (!fs.existsSync(filePath)) { ;
    } execCallback = { (error) { .log( ); ;
        } (stderr.length > ) { .log( ); ;
        } .log( );
    }
    childProcess.execFile(filePath, execCallback);
} ( ) function execScript project, filePath if return const ( ) => error, stdout, stderr if console `Failed to deploy ` ${project} return if 0 console `Failed to deploy ` ${project} return console `Deployed ` ${project} Here, we again leverage Node.js API, namely and to check the file existence and execute a binary file, respectively. We log the result of the execution to the console. fs child_process : npm warnings are treated as errors and are written to stderr. This means that if your project misses a description or repository URL, you will receive a 'Failed to deploy' error even if your script technically executes as it should. Note And here's how we use function: execScript scriptPath = ; .log( );
execScript(project, scriptPath);

res.status( ).end(); const `./projects/ .sh` ${project} console `Executing task at: ` ${scriptPath} 200 As for the script itself, it usually boils down to this: cd ~/app/directory/
git pull -q
npm install
pm2 restart app And that's it! Wrap it into express.js boilerplate and you will get the simplest possible CD server! Configuring push Webhooks What's left is to tell GitHub about all the beauty we created. In your project's repo, go to and click . There, you will need to paste the URL of the server we created in the previous step, as well as the secret key. I would also set to , but that's up to you. Settings -> Webhooks Add webhook Content-Type application/json Once you hit , GitHub will send a test request to your server, so you should see that in the app's logs. Also, GitHub will show you a response status code from the CD server, so if you got 200 it means everything should work fine. Add Webhook Wrapping up Here we first set up a simple yet powerful server for continuous deployment. It works awesome for simple workflows ( ), but might as well contain the complex flow, as your Shell scripts can execute arbitrary logic. npm install && pm2 restart app We then use GitHub webhooks to trigger deployments on our server, therefore updating our app on each push.

Flow

Personal website

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

DevOps Shouldn't be Hard: Configurating CD Server

Too Long; Didn't Read

Coins Mentioned

Timur

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

DevOps Shouldn't be Hard: Configurating CD Server

Too Long; Didn't Read

Coins Mentioned

Timur

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES