Web Services in Docker with Golang
By Peter
This post is a walkthrough on my approach to develop and deploy Golang web service in Docker container. There are many reasons for integrating Docker into the daily routine as a developer, one being the simplification of setting up a separated runtime environment. Using containers in production has, even more, advantages from simplified release to better performance. Kubernetes and Docker Swarm is gaining more and more space, which I think is partly because of the simplified management on IBM Cloud and Google Cloud Platform.
The setup discussed in this article can be found at https://github.com/pete314/paste-api-golang. The repository contains a “toy” project, and the only purpose is to be used as an example. The implementation itself is a REST API with OAuth authentication and option to PUT and GET text, stored in Redis. The service is implemented on the top of fasthttp with fasthttprouter.
The project structure
The project is very simple as is the project. The api folder holds the source for the application with a Makefile, to simplify build process. Config holds the configuration for the application. Script folder contains a production build script, working with the docker file in Deploy, which builds on the scratch container. For the production build, Golang should be installed to avoid pulling the dependencies every time but can be run in a container as well. There circle.yml for configuring CI builds, which is still running on version one, without the nice feature of docker support (in 2.0).
The development docker file
The container is based on the official golang base, golang:latest.The only additional packages are for the being able to run the “make”. The entry-point for the container points to the binary to simplify the execution. With the default configuration, the api is looking for an external Redis server, which can be run in another container or on a dedicated host. With this setup Redis can be shared between multiple applications, in production most likely it will have dedicated setup anyway.
The above can be built and executed as
In the development stage, the above setup is enough to test manually or programmatically.
Deploy to production
The development build is light weight without much extra unnecessary OS packages, but it still contains a Debian base image with its default packages installed. Instead of using this the source can be run on the scratch base image. Building this image is only 6MB, plus the binary and dependencies required for running the API, which makes it perfect to move around on the network fast.
The deploy script “deploy-api.sh”, is compiling the source on the host for “Dockerfile.scratch” to build the final image. I found this strategy in this brilliant post about deploying on scratch image
And the Docketfile.scratch