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
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 currencyconverter email@example.com:.
After uploading to the server we need to login and just run the server as we would run any other command line program on
$ ssh firstname.lastname@example.org 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
server$ sudo GFS_CURRENCY_HOST=0.0.0.0 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
sudo crontab -e, as the server needs to be run as
root, and using
crontab is not an option) the following line can be added:
@reboot GFS_CURRENCY_HOST=0.0.0.0 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.
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.