Day 4 - Running the backend

Published by Michael Banzon on Thu Feb 16, 2017

In this part we are going to get our software running! The code we wrote in the previous part needs a server to run on and for that we also needs an operating system - we need to pick the architecture + OS part of the stack and get our software installed. Check out the introduction to this series to get up to speed with what we are building and why.

Choosing the platform

There are so many options when selecting a platform. Usually external factors are most important when choosing. Some of the parameters that matter are:

  • Team experience
  • Vendor offering
  • Programming language etc.

It is up to you to choose your platform - but considering these factors we’re going to select a amd64 server running Ubuntu flavor linux - this is based on experience and the offering of Digital Ocean. This backend - written in Go - will run on plenty of platforms.

Setup + build the backend

Setting up a new server on Digital Ocean is easy enough that it doesn’t need to be explained here.

There is a previous post about setting a new server and another about selecting a cloud provider - both these should give you an idea on how to get started if you have no idea where to go with deployment etc..

Building the backend is pretty easy with Go - we just run the go build command in the folder with the code:

$ go build

That’s it! It leaves a binary in the folder, and that is the server.

But wait! I’m running this on my MacBook and the go build command will spit out a binary targeted the platform it is running on - unless we do something different.

In the previous section we defined the architecture - I made sure to use the precise wording that would tie this together - and we can use that with the go build command:

$ GOARCH=amd64 GOOS=linux go build

And there you have it - now we have a binary that has been compiled to run on the right target architecthire and operating system. We are now ready to move it to the server!

Deploying to the server

After setting up the new Ubuntu machine we have a user account that will allow us to acces it via SSH.

The binary is copied to the server using the scp command:

$ scp currencyconverter user@server.ip.address:.

Running it

After uploading to the server we need to login and just run the server as we would run any other command line program on linux:

$ ssh user@server.ip.address
server$ ./currencyconverter

And that’s it - the server is now running - but it is bound to the default address and port, which is easy to change. The code uses default values or values form environment variables - which means we can use environment variables to configure the server. Let’s start by making the server bind to all addresses on port 80 - as a normal webserver (this needs to be run as root - so we’ll use sudo):

server$ sudo GFS_CURRENCY_HOST= GFS_CURRENCY_PORT=80 ./currencyconverter

Now we can fire up our browser and go to http://localhost/currencies and you’ll see the JSON output from the server containing the currency rates (relative to EUR) for all the known currencies.

Starting it on boot

Now that the server is running on our machine we want it to start when we reboot the server.

For a quick and easy solution we’ll leave this task to cron. Let’s assume that the binary is located /home/user - using the crontab edit command as root (sudo crontab -e, as the server needs to be run as root, and using sudo in crontab is not an option) the following line can be added:

@reboot GFS_CURRENCY_HOST= GFS_CURRENCY_PORT=80 nohup /home/user/currencyconverter &

… and there it is! Now the server will run on reboot and you’ll have a running webservice waiting to convert currencies etc.

Please notice two small changes - the nohup (see more about it here) in front of the command and the & behind - this will detach the process from the cron process and run it in the background and it will keep running until it decide should decide to stop on its own.

What’s next?

Next we are going to set up continious integration and continious deployment for our server to make it possible to iterate quickly without having to go through the process described in this post every time we need to deploy a change.

Continue to day five…