Post on 11-Jan-2017
$ whoami
$ who
If you give a mouse a repository...
He’s going to want to fill it with a microservice!
If he’s building a microservice...
He’s going to want to use containers!
If he’s using containers...
He’s going to want to build it in a container!
If he’s doing so much with containers...
He’s going to want to use a container orchestrator!
If he’s using a container orchestrator...
He’s going to want to deploy more containers!
If he’s going to be deploying all these containers...
He’s going to need a few more repositories.
… you’re in for a treat.
What are today’s best practices?
Should Docker be used during the build of an application?
Should the use of Docker for builds be enforced on CI and developer
machines?
Should you use a different Docker image while building vs. the image
you use to distribute your application?
Is bundling Go based applications into Docker containers a good idea?
What base image should you use?
What are today’s best practices?
Who makes these best practices?
Why are the best practices changing nearly every day!?
New tooling changes best practices
CodeUnit Test
Build Package
Deploy(to prod)
Deploy(to dev)
Publish
Test
Deploy(to test/stage)
Code Unit Test
Build Package Run
If he’s building a microservice...
He’s going to want to use containers!
# Ensure go is installed
go build ... go test ...lint ...gox ...
# Ensure Docker is running
docker build ...docker tag ...docker push ...
If he’s using containers...
He’s going to want to build it in a container!
# Ensure Docker is running
docker run ... go build ... docker run ... go test ...docker run ... lint ...docker run ... gox …
# Spit out binaries onto local filesystem
docker build ...docker tag ...docker push ...
$TOOL [build,unit-test,package,deploy <env>,publish,test <env>
]
$TOOL == make
make buildmake testmake docker_build#make docker_push
The Good
● I can make the exact workflow I want
The Bad
● It’s a Makefile.○ Up to date checks are poor / hard to wire up○ Makefile reuse is hard○ Need Makefile ninja skills...
$TOOL == captainhttps://github.com/harbur/captain
captain buildcaptain test#captain push
The Good
● Solves the “How should I version my docker images” in a neat way
The Bad
● But kind of just a wrapper on top of Docker:○ build
○ Push
● Context of build script = outside of container● Still some aspects of building, testing, pushing a project that aren’t wrapped
up in captain’s commands (see call to make in captain.yml)
$TOOL == werckerhttp://devcenter.wercker.com/quickstarts/index.html
#wercker dev...wercker build#wercker deploy
The Good
● Docker centric workflow● Makefiles + code reuse● Context of build script = inside of container
The Bad
● Tied somewhat to their SaaS offering● Can’t add toplevel commands (push AND deploy would be nice)
$TOOL == ?