Looking at how people, with current deployments, can start using docker with out having to replace anything. Also giving a migration path that allows testing the separate pieces and migrating over slowly without painting yourself into a corner. Also covering why you might want to do this and the problems it may help to solve.
Why would you want docker
Can allow simpler scaling
No difference of libraries between dev and live
Simple rollback of libraries programs
Multiple version of programs on the same pc
More lightweight that virtualization
What doesn't it solve
Its a tool that help with speciﬁc problems
Its not a magic bullet
Part of Dev/Ops
Remove the fear of breaking
Simple Roll forward or back
Free you time for more important things
You can't manage what you can't see
The following are tips and methods on how to bring it into your
Not an exact recipe. Take the bits that make sense for you.
Assumes you already have systems that tend to the monolithic
Start with something simple
Don't start with your biggest critical app
You will fail
Take small steps that keep moving you to a better place
Start with a non critical piece of your architecture
Log processing ?
Basically something that if its off while your working things out
will not be a problem
Run your own registry
Docker images are available
Don't forget to add a ssl cert
How to use
Docker Registry URL: https://dr.haak.co
docker login dr.haak.co
Put one person on it
With The Need Skills
Not the new intern/junior developer
Only one person will go through the wrong path pain
Faster iteration while learning
Can back out a wrong path quickly
Rest of the team only see the ﬁnal simpler path
Store conﬁgs externally
While your starting mount the conﬁgs etc via a volume
into the container
You don't have to rebuild the container to update
Other members of your team can just edit the ﬁle
Allows you to use something like Ansible to generate the
Known good state
When restarting the image. DELETE the previous container then restart.
This way your always starting from a know good state.
The only thing that can change is the conﬁg.
Make sure that docker cleans up previous containers and starts new
ones on reboot.
That way rebooting always puts you into a good state
docker rm -f image_name
docker start -d -v /conﬁg/conﬁg -p 321:321 timhaak/awesome1
Before working on your live servers. Start but using docker as
you dev environment.
Don't have to worry about testing
You can make sure you have all the required packages.
Though we all know exactly whats installed on our servers :)
This is actually a good candidate for service bring into docker
Add a docker version into a replica set
Make sure it will only be a slave while testing
If you mess something up your can just remove it as the other
servers will still have a copy of the data.
Don't for get to store the data in a volume
Add DNS Rest Api
Sounds hard but isn't
Allow of adding and removing servers from DNS rotation
You can't get it wrong (Especially when your panicking)
Can eventually be automated
Please secure it
Where we want to get to
HaProxy / Load Balancer
This is actually one of the most important pieces of the system
as it allows you to switch out or test underlying application
You don't have to use HaProxy its just one of the more popular
ones to use and actually gives very nice reporting. Also its
been quiet battle tested.
There are good node and go alternatives.
I would look to setting up an api here to change conﬁg. Fairly
easy agains haproxy.
SSL Off loader / Load balancer
This is a good place to start bringing docker into your live
environment. (Assuming you have a monolithic app)
Fairly simple to test.
Makes your system more resilient.
Allows you to do things like ﬁx cache headers etc.
Once in place can simplify your updates.
Starts you down the path of microservices
Just spin up a temporary server for initial testing.
If you can't do it with your infrastructure look at one of the
cloud servers providers that charge for only the time you use.
Locally you can look at cloudafrica.net (R0.09 per hour.)
Setup server and install docker (I hope your using something
Set up your conﬁg
Run the docker container
If you change your host ﬁle it should all just work
Make it live
With this you'll have to move the port that your application
server listens on.
This is the most dangerous bit.
Especially if you have a single server.
Though once you've got the pieces all working together
switching docker images in and out become quiet simple.
Wrap the code
Ok so how do you now wrap the actual application server into
You don't want to mess up the current server incase you get
Also you want to make sure its using the same ﬁles as the
Well you've got the image that you've been testing on your
local pc while doing dev?
Wrap the code
Start it up on the live server mounting the current server's web
directory as a volume into the docker container running on a
new different port.
Don't you have to stop the old server?
No the only problem you may have is with things like cache
ﬁles or if your using locks.
Wrap the code
Test the server on the new port is it all working. No client will
see it as the load balancer not using it. But its on the same
server should have access to everything it needs.
If everything is working tell your load balancer to switch to the
new server's port.
Check the live site if its all working great. If not switch back.
The only delay will be you as you never stopped the old server.
You can now start moving more services into docker.
As you feel secure in that its work start removing the unused
programs and cruft from the old server.
This will reduce the chance of problems. Also you are now
decreasing the things that need to updated and managed on
the base pc.
Future things to look at
The follow are things you may want to start looking at
Some are available now some are near future.
Though each does increase the complexity which you may not
want to do
Something that seems to be over looked quiet often as people
move to micro service and more servers. Is secure
Main advantage is safe zones so you don't have to wrap
As an example servers talking to a centralised redis cache
Link your servers
docker run -d
jenserat/tinc start -D
Auto Discovery / Conﬁg
Eventually your going to want to have your containers auto
conﬁgure them selves as they start up
There are a couple options here each will depend on your
Tools On Top
SkyDNS2 - DNS Discovery
confd - conﬁg generation/update
$client = new Client($server);
// Set the ttl
$client->set('/foo', 'fooValue', 10);
// get key value
// Update value with key
// Delete key
// Create a directory
// Remove dir
Lots of active work here but no clear winner as yet.
Though most only provide a single network.
Still waiting for one that can give you more SDN functionality.
Basically single network and ability to move containers in and
Though if you know what your doing using Pipework and
openvswitch you could build your own system.
Though very few people would have this requirement.