As a short follow-up on my tweet for those interested in how we deploy rancher.
The setup includes git, Jenkins, Welder (homegrown tool, will hopefully be able to release this as open-source), RabbitMQ, Puppet (with a custom built ENC).
In git, I have a spec-file defining which versions of rancher/server, rancher/agent and rancher/agent-instance to pull down. There’s also a Welderfile (more on welder below) that describes which images to pull, which tags to apply to them and where to push them (to our private registry). I tweak the tags a bit, and add an additional tag on the agent images, so it’s easy to pick the correct versions, based on the server version alone (that is, they get a :server-0.42.0 tag on them as well, for instance).
The Welderfile is not strictly needed here, a few lines of shell script would do just fine for this simple case.
Then there is a webhook from the git server to Jenkins, triggering a build running the welder, which picks up the Welderfile to find out what to do. In this case, pull a few images, re-tag them and push them internally. Then a message is posted to our Continuous Deployment bus with information about a new release.
Our ENC picks up the new release from the CD bus, finds all deployments for rancher/server and finds that one is configured as “BleedingEdge”, which results in a kick to run the puppet agent for the nodes that should install the new version.
I realize that this is a non-trivial setup. But given that all the pieces already were in place, the “only” thing I had to do specifically for this setup with rancher was the git repo with two files in it, and a few puppet manifests to install the rancher server and supporting manifests for adding hosts to the environments on that server.
It’s really nice to be able to just bump a version in a text file, git push it, and watch our rancher/server be upgraded within minutes… 
Now, a few words about welder.
It’s a tool we built to be able to build any kind of project, where the build configuration specific to the project is kept along with the code in git. All the common functionality is re-used and kept in what we call tigs, or build tools, that are built separately and with a dedicated purpose. One tig may be to have a java build environment, another for C projects, etc. And yet other tigs are for publishing information, or packaging rpm’s and publishing those, and on and on. Having all this infrastructure functionality isolated, in one common place, makes it much easier to work with and develop.
This was in no way a complete nor thorough walk-through of welder, what it does or the motivation for it, but should give you an idea as to what it’s used for.