I investigated Docker + Capistrano a couple of months ago.
The implementation gets into the mud around which side should control the
configuration of system vs configuration of app.   In the end, Docker & Cap
both are approaching the same problem (system+app config as "code").

Athough Ionic points out the "long" build-deploy cycle, this depends upon
your hosting I think.  Recent hosting environments for docker images ask
you to point your single image reference (url, github, whatever) into the
host and then tell the host to deploy X instances.  In this case, as a
devop there is virtually _no_ post-deploy code-change ability per-instance
since the host has masked the instance-references, at least behind an API,
if not opaquely.
Ionic did approach the code-change-only mode with the use of a "host
volume" that holds the code.  In this case, Cap could indeed be used to
update the "host volume", with the dependency of a restart.txt or other
file-sys based monitor for server-restart.  This could work depending upon
the availability of such linking of a file-sys volume from one part of the
hosting environment into the hosted Docker instances.  YMMV.

In the end, yes there are multiple ways to skin this cat.   Over 10^x
servers, one specific approach may server better for a specific
app+environment.
I think Docker's approach is that Dockerfile + build is the one-tool
solution that ensures a hosting provider can provision and manage the 10^x
instances without concern for any external forces applying pressure on the
"state" of the image in place.

Thoughts?

Peter Fitzgibbons
(847) 859-9550
G+ : [email protected]

On Tue, Sep 22, 2015 at 9:49 PM, Alex Escalante <[email protected]>
wrote:

> That's a great article, Mazembo. I plan to get into Docker before the year
> ends. My new projects are in DigitalOcean already instead of Heroku. I am
> integrating Capistrano into my workflow right now and it looks promising.
>
> I am thinking about a setup where you launch a container with your
> Bitbucket or Gthub repositories configured and then just "cap production
> deploy".
>
> Now: there are many ways to do things in Docker, from what I've read. You
> could have a docker image per version, for instance, but I think having the
> means to update the version without rebuilding the docker image is faster
> and nicer.
>
> Check, for instance, this post from the guys at Ionic, which is, BTW, a
> very nice framework for doing mobile apps:
>
> One challenge we faced with Docker, though, was that any time we made even
>> the smallest change to our code, we had to go through the process of
>> building a new container, pulling it down to our servers, and replacing the
>> running version.
>>
>> http://blog.ionic.io/docker-hot-code-deploys/
>>
>
> They went for Ansible but, what do you think about Docker + Capistrano?
>
> Alex Escalante
>
> Web & Mobile Development For Hire
> http://audelabs.com
>
>
> Alex Escalante
>
> On Wed, Sep 16, 2015 at 8:58 AM, Mazembo <[email protected]>
> wrote:
>
>> Greetings fellow Rubyists
>>
>> I thought I can share the link to this blog post of mine. It is about my
>> experience of docker as a freelance developer.
>>
>> http://deis.com/blog/2015/why-excited-about-docker
>>
>> Best regards
>>
>> Mazembo Mavungu Eddy, PhD
>>
>> --
>> --
>> SD Ruby mailing list
>> [email protected]
>> http://groups.google.com/group/sdruby
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "SD Ruby" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> --
> SD Ruby mailing list
> [email protected]
> http://groups.google.com/group/sdruby
> ---
> You received this message because you are subscribed to the Google Groups
> "SD Ruby" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
--- 
You received this message because you are subscribed to the Google Groups "SD 
Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to