This gist quickly explains the scenario demo'd by the Docker to Digital Ocean example project.
The repository contains a single file with Go code called main.go
that contains application logic to host a counter webservice. There is a Dockerfile
that defines how to build the container.
The application that gets deployed is written in Go and is a web service that can count requests. It is hosted at: counter.born2code.net/foo.
Wercker does the following in the build pipeline:
- Setup a Go environment (this step can be removed by adding Go to that box)
- Execute a Go get to get the dependencies of the Go app that we will deploy
- Execute a Go build to build the Go app to a single executable
- Build the docker containers, which takes the base images and adds the just build application
- Export the docker container so it will be stored for deployment
Wercker does the following in the deploy pipeline:
- Copy the container to the remote server
- Import the container into docker
- Stop the running docker containers
- Start the new docker container
The purpose of this demo is to demonstrate the simplest scenario of an fully automated deployment of an containerized Go application to Digital Ocean.
Here is a list of things I would like to improve:
- Add some smoke tests to the deployment pipeline.
- Use the docker register hosted on the target server to so that from wercker I can only push the changes.
- Deploy with zero downtime by switching port mapping between the old and the new containers.
- Persist the state of the application. Currently it holds all the values in memory, that means it is gone after deploying a new version of the software.