RFC Proposal for `deploy.sh` curl bash deployment script (Ubuntu VM Target)

[christopherkeim]

deploy.sh Deployment Script (Ubuntu VM Target)

Purpose

The purpose of this RFC proposal is discussion of requirements and any suggestions that can be made for design and development.

Concept

To build out more scalable DevOps infrastructure for ourselves we'll need a deploy.sh script that can be used to install and deploy our site onto a machine in a fully automated, non-interactive way. The design framework should be idempotent. For the moment we are explicitly targeting a Ubuntu VM as our deploy target.

This script should:

1. Ensure that Node version >= v18.x.x and < v19 is installed

2. Ensure that git is installed

3. Clone the relativepath.tech repository

4. npm install the dependencies for the site

5. npm run build the static assets for the site

6. Ensure that the site works

7. Deploy the site

First iteration minimum viable deploy.sh

The first draft of this deploy.sh script is:

#! /bin/bash

# This script deploys the site onto a Ubuntu machine

# Check if Node.js is in the apt-cache
if (apt-cache show nodejs > /dev/null)
then
  echo "nodejs is already in cache"
else
  sudo apt update
fi

# Install Node.js runtime environment
if [[ $(node --version | cut -d "v" -f2 | cut -d "." -f1) == 18 ]]
then
  echo "Node >= v18.x.x is installed."
else
  echo "Installing Node v18.x.x"
  curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
  sudo apt install -y nodejs
fi

# Check if git is in the apt-cache
if (apt-cache show git > /dev/null)
then
  echo "git is already in cache"
else
  sudo apt update
fi

# Install git
if $(git --version > /dev/null)
then
  echo "git is installed"
else
  echo "Installing git..."
  sudo apt install -y git
fi

# Clone the repository
if [ -d ./relativepath.tech ]
then
  echo "Repository is already cloned."
else
  echo "Cloning relativepath.tech..."
  git clone https://github.com/kensonjohnson/relativepath.tech.git
  cd ./relativepath.tech
fi

# Move into the local repo and install depedencies
if (pwd | grep relativepath.tech > /dev/null)
then
  echo "Already in relativepath.tech"
else
  cd ./relativepath.tech
fi

# npm install will check if requirements have been installed, if so do nothing, 
# and if not install them
npm install

# npm run build will build our the site's static assets
npm run build

# Test that our server is able to run
if [ $(curl -o /dev/null -s -w "%{http_code}" http://localhost:4173/ | grep 200) ]
then
  echo "Looking great! Fire up your browser and head over to http://localhost:4173"
else
  echo "Testing our site." 
  npm run preview & \
    sleep 5 && \
    sh -c "curl -o /dev/null -s -w "%{http_code}" http://localhost:4173/ | grep 200"
fi

# Deploy the server [NODE HTTP SERVER GOES HERE - not implemented yet]
npm run preview

This can also be viewed at https://github.com/kensonjohnson/relativepath.tech/blob/chris/deploy/deploy.sh

Usage

This script could be used to curl bash deploy our site onto a machine:

curl -fsSL https://raw.githubusercontent.com/kensonjohnson/relativepath.tech/chris/deploy/deploy.sh | bash -

In Progress

1. node command for direct HTTP server invocation for production
2. Implementation of absolute paths using pushd and popd
3. Any other suggestions

[kensonjohnson]

1. Ensure that Node version >= v18.x.x and < v19 is installed

We can simply target Node v18+, there is no need to clamp the upper value.

[kensonjohnson]

1. node command for direct HTTP server invocation for production

This isn't actually necessary, since the React project compiles everything to static assets, it isn't specific to any one webserver technology. This would run on nginx just as well as it would run using Node's built in http server function. Moreover, the idea for deployment is to setup a destination for these static assets to be served as opposed to thinking about "running" them.

All of that is to say, 99% chance you won't be using Node to run this in production.

[christopherkeim]

1. Ensure that Node version >= v18.x.x and < v19 is installed

We can simply target Node v18+, there is no need to clamp the upper value.

In the context of a deployment I would very much like to clamp our version of Node between v18 and v19 - because it is the current "LTS" (long term support) version.

You did mention that Node releases are backwards compatible, mostly involving optimizations, but it adds a huge amount of uncertainty at the level of testing and stability when we implicitly give our runtime the ability to vary between v18 - v20. You are the SME in Node here though.

The way I was thinking about this in terms of design is that we establish a minimum necessary version (v.18.x.x >= Node < 19) - at the level of design if we determine that it's viable to upgrade, and it's sensible, we can do so. But I don't see a reason to have our runtime environment vary at all between versions in terms of infrastructure - it seems like more of a consideration if we were concerned about optimizations down the road.

[stephenlauck]

Since we are targeting Ubuntu for production (and anything past local) I would like to see a a service file for systemd that enables and starts our node app. This would be orchestrated by our deploy-ubuntu.sh or something named reasonably.

https://nodesource.com/blog/running-your-node-js-app-with-systemd-part-1/

[stephenlauck]

In the context of a deployment I would very much like to clamp our version of Node between v18 and v19 - because it is the current "LTS" (long term support) version.

This idea of "clamping" or "pinning" the node version is actually more complex. The idea is we want to run in dev or locally using the latest ALWAYS and then test that along the way to deploy. If we are building the WHOLE system from scratch on deploy, then it's not an issue keeping things in line. Pinning is the "road to hell" where you are diverging the system from the SBOM in a way where the deploy is not paired with the infra.

tl;dr: Build artifacts are your clamping, don't pin anything before build/release.

[kensonjohnson]

Since we are targeting Ubuntu for production (and anything past local) I would like to see a a service file for systemd that enables and starts our node app. This would be orchestrated by our deploy-ubuntu.sh or something named reasonably.

To reiterate what I mentioned above: our artifact is not a Node app and I want to make that clear. We are delivering static files via any webserver of our choosing. There is no Node command to run.

With that in mind, our systemd script should start and stop a configured webserver (nginx or otherwise) and have some type of state management to restart the server on failure.

Once again, I say this for clarity for the developers involved with creating the systemd file: Don't go looking for a Node command to run, there isn't one.

[stephenlauck]

Since we are targeting Ubuntu for production (and anything past local) I would like to see a a service file for systemd that enables and starts our node app. This would be orchestrated by our deploy-ubuntu.sh or something named reasonably.

To reiterate what I mentioned above: our artifact is not a Node app and I want to make that clear. We are delivering static files via any webserver of our choosing. There is no Node command to run.

With that in mind, our systemd script should start and stop a configured webserver (nginx or otherwise) and have some type of state management to restart the server on failure.

Once again, I say this for clarity for the developers involved with creating the systemd file: Don't go looking for a Node command to run, there isn't one.

In this case I would agree then and also suggest using NGINX as your "static webs server" and the deploy is literally just the static files put in the right directory and reload of nginx (also accounting for install of nginx). Simple deploy is 👍

[mflorida]

In the context of a deployment I would very much like to clamp our version of Node between v18 and v19 - because it is the current "LTS" (long term support) version.

This idea of "clamping" or "pinning" the node version is actually more complex. The idea is we want to run in dev or locally using the latest ALWAYS and then test that along the way to deploy. If we are building the WHOLE system from scratch on deploy, then it's not an issue keeping things in line. Pinning is the "road to hell" where you are diverging the system from the SBOM in a way where the deploy is not paired with the infra.

tl;dr: Build artifacts are your clamping, don't pin anything before build/release.

@stephenlauck Most current LTS version could be considered "latest", no?

[mflorida]

If the end goal is to automate deployment, can't we use a special 'deploy' branch (Github pages uses pages) that's watched and deployed automatically? What's involved in something like this?

[kensonjohnson]

If the end goal is to automate deployment, can't we use a special 'deploy' branch (Github pages uses pages) that's watched and deployed automatically? What's involved in something like this?

This is actually the current setup! It works well as long as we continue using static files, but we will need more granular control once we implement either the blog or site rotator feature.

[christopherkeim]

If the end goal is to automate deployment, can't we use a special 'deploy' branch (Github pages uses pages) that's watched and deployed automatically? What's involved in something like this?

You can add a Webhook to a repository:

"Webhooks allow external services to be notified when certain events happen. When the specified events happen, we’ll send a POST request to each of the URLs you provide. Learn more in our Webhooks Guide."

To hook it into an external service or endpoint. Interesting to be aware of.