Keeping Docker releases up to date with Git releases today is a very manual process.
What it does
Creates an automated pipeline from git through testing to a Docker Registry. The pipeline automates tagging and releasing Docker Images with the appropriate git tag and optionally, automates deployment with optional rollback to previous versions.
How I built it
We wrote integrations with Circle and Docker Hub which talk to our product along the way. Once the entire build process is done, the Image is optionally deployed via direct integration with the Docker Engine Remote API. An agent living on the server of the users choice handles exposing the Docker Remote API.
Challenges I ran into
AWS took out both the Docker Registry and CircleCI while we were developing, forcing us to develop using Docker locally while waiting for the services to come back online.
Accomplishments that I'm proud of
git tag or a GitHub Release is the only action needed to trigger a release to a Docker Registry and a deployment to a node which the user can choose to provide themselves. The user can also redeploy any version at any time using a single http request.
What I learned
- How to expose the docker socket for communication with the outside world.
- How to work with the Docker Remote API (which is much more complex than working with the CLI)
- A great workflow for automating the releases of my open source projects via git
What's next for git2docker
- Slick, React-based UIs for the web and iOS. (We are UI engineers by trade).
- More sophisticated controls for sourcing Dockerfiles and choosing runtime options.