Monitoring the Deploy Services

Upstart for NodeJS and Python

We don't want to run and monitor the Node and Python scripts by hand. We want the system to start these services for us!

Let's use Upstart to do this on our Ubuntu servers. I'll also show alternative configurations for those using Systemd (For users of newer Ubuntu, Debian, CentOS, RedHat).

Note that my build server in this video has user appuser instead of deployer. Everything is the same otherwise.

Lastly, our NodeJS script is now named builder.js instead of index.js.

These changes are consistent with the included Ansible roles which will build the infrastructure created in this video series.

Node Web Listener:

First, we'll create a service to monitor the NodeJS script. As admin/root, create file /etc/init/deploy-node.conf with the following:

description "NodeJS Web Listener"

start on filesystem or runlevel [2345]
stop on runlevel [!2345]

setuid appuser
setgid appuser

env GITHUB_SECRET=bb4610181a2c95fe695db0a5d29ac3098719d39c
env QUEUE_URL=https://sqs.us-east-1.amazonaws.com/308352032554/serial-deploy

respawn
respawn limit 5 2

chdir /home/appuser/build-server

script
    # Start Listener
    /usr/bin/node builder.js
end script

Then we can start/stop/restart and check the service's status:

# Ensure it's read
sudo service deploy-node status

# Start it and check status, ensure PID doesn't change
# signifying it's failing and getting restarted
sudo service deploy-node start
sudo service deploy-node status

Environment Variables

Lastly, let's change our node script builder.js to use Environmental variables:

/* near top: */
var gitHubHandler = createHandler({ path: '/webhook', secret: process.env.GITHUB_SECRET });

/* and later: */
QueueUrl: process.env.QUEUE_URL

After that is done, (re)start the service:

sudo service deploy-node restart

Python Queue Listener

We'll do the same steps here. Let's make the Upstart configuration. Create file /etc/init/deploy-python.conf with the following:

description "Python Queue Listener"

start on filesystem or runlevel [2345]
stop on runlevel [!2345]

setuid appuser
setgid appuser

respawn
respawn limit 5 2

env QUEUE_NAME=serial-deploy

chdir /home/appuser/build-server

pre-start script
    # Source Python Virtualenv
    . .venv/bin/activate
end script

script
    # Start Python using full or relative
    # path to the python script
    /home/appuser/build-server/.venv/bin/python deploy.py 
end script

Then we can start and check it's status:

# Ensure it's read
sudo service deploy-py status

# Start it and check status, ensure PID doesn't change
# signifying it's failing and getting restarted
sudo service deploy-python start
sudo service deploy-python status

Environment Variables

Let's use the QUEUE_NAME environment variable used in the Upstart configuration:

# add this
import os

# adjust this line
deploy_queue = sqs.get_queue_by_name(QueueName=os.environ['QUEUE_NAME'])

After that is done, (re)start the service:

sudo service deploy-python restart

Error Checking

If you check a services status and see the PID (process ID) change, it's a sign the script is failing and upstart is trying to bring it back online.

It will eventually fail after it hits our respawn limits. You can check for output (stdout and stderr) in /var/log/upstart/*.log, where the * is the name of your service. In this case we have two service logs, deploy-node.log and deploy-py.log.