Deploying perl code

[Toby Wintermute]

On 29 July 2014 06:11, Paul Johnson <paul at pjcj.net> wrote:
> On Mon, Jul 28, 2014 at 07:51:12PM +0100, Robert Rothenberg wrote:
>> On Thu, Jul 24, 2014 at 4:25 PM, David Cantrell <david at cantrell.org.uk>
>> wrote:
>>
>> > I'm looking for tools that will make it easy to go from a bunch of code
>> > in a release branch on github to an updated bunch of servers, with
>> > minimal downtime. If it matters we're using Debian.
>>
>> At $previous, we deployed (mainly bespoke) Catalyst apps using the
>> following toolchain at a small shop:
>
> If I were designing an environment from scratch I would take a serious
> look at docker.  I've been using it recently for cpancover.com and,
> whilst it still has some rough edges, I really like the concept of
> compartmentalising functionality.  It's probably not the whole solution
> (and in this case in particular it may not be any part of the solution)
> but I predict a strong future for docker. (Ha! What do I know?)

+1 for docker.

You can host your own "docker registry" which then allows you to
push/pull docker images to it. Images with shared history will only
need to send and store the differences.

So, build a company base image that includes your usual libraries and
configuration.
Then for each app, commit a "Dockerfile" to the repo, which is
instructions on how it builds itself into a docker image, using the
company base image as the starting point.

Then setup your continuous integration server to run "docker build"
and "docker push" for every revision that passes its tests.
Over on your application servers, get them to reboot or restart the
services frequently, pulling updates from the docker registry as they
go. (Perhaps using different tags for staging and production though)

Achievement unlocked: Continuous delivery