On Mon, 2014-08-11 at 10:43 -0500, Eric Johnson wrote:
> Have you looked at Rex? They have pretty good docs: http://rexify.org
Thanks Eric (and Pierre) - no, I hadn't come across that. I'll have a
play with it and see how it is - looks very promising though.
> Its a deployment type tool vaguely
Have you looked at Rex? They have pretty good docs: http://rexify.org
Its a deployment type tool vaguely like ansible/puppet/chef/salt/whatever
and its written in Perl and it looks pretty nice. I've personally never
used Rex for real anywhere though.
I wrote up a little intro to using rex (the
> does [a Perl equivalent to Ansible] already exist?
I think Rex fits the bill:http://blog.kablamo.org/2013/11/22/rex/
-- Pierre Masci
On Fri, 2014-07-25 at 12:08 +0200, James Laver wrote:
> On 25 Jul 2014, at 11:54, Andrew Beverley wrote:
>
> > The main problem is that it seems to be a victim of its own success:
> > there is a huge backlog of merge requests. I'd like to provide some
> > simple patches to a couple of modules to
On 29 July 2014 06:11, Paul Johnson 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
>> 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 upd
On Mon, Jul 28, 2014 at 07:51:12PM +0100, Robert Rothenberg wrote:
> On Thu, Jul 24, 2014 at 4:25 PM, David Cantrell
> 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.
On Thu, Jul 24, 2014 at 4:25 PM, David Cantrell
wrote:
> Our "deployment process" at work isn't so much a well-documented
> dependable repeatable process as a modern dance interpretation of
> lemonparty. It needs taking out and shooting.
>
> ...
>
> I'm looking for tools that will make it easy t
On Fri, 2014-07-25 at 12:08 +0200, James Laver wrote:
> On 25 Jul 2014, at 11:54, Andrew Beverley wrote:
>
> > The main problem is that it seems to be a victim of its own success:
> > there is a huge backlog of merge requests. I'd like to provide some
> > simple patches to a couple of modules to
On 25 Jul 2014, at 11:54, Andrew Beverley wrote:
> The main problem is that it seems to be a victim of its own success:
> there is a huge backlog of merge requests. I'd like to provide some
> simple patches to a couple of modules to make them work better for me,
> but have little hope that they'
On Fri, 2014-07-25 at 10:11 +0200, James Laver wrote:
> Ansible I do like for the most part
I'm a fan of Ansible, and am in the process of using it to deploy code
(although more by accident than design).
The main problem is that it seems to be a victim of its own success:
there is a huge backlog
Hey,
We're in a similar boat to Leo for our use of Puppet - used to manage stuff
in /etc/ and the general Debian packages we have installed - but mostly we
build our own. We have an /opt/lokku/pkgs which contains our own Perl,
Apache, Percona DB, node.js, etc. We manage /opt/lokku/bin with swpkg -
On 25 Jul 2014, at 09:40, mascip wrote:
> and the idempotence: you can run a playbook as many times as you like, it
> should
> have just the same effect as running it once (true for most Ansible things).
That’s in stark contrast to my experiences. I found ansible requires you to
think about t
On 25 Jul 2014, at 08:52, Ben Tisdall wrote:
> However, I would urge you to spend a day each investigating Ansible &
> SaltStack, the latter in salt-ssh mode if you want to make a direct
> comparison. Both of the aforementioned tools do ad-hoc remote
> execution, task orchestration and configura
I've loved using Ansible on a personal project recently. Almost zero set up
and learning.
Compared to bash scripts, I love the reuse with Roles, the fact that many
tasks and roles exist (Ansible Galaxy is Ansible's CPAN), and the
idempotence: you can run a playbook as many times as you like, it sho
>> On 24 July 2014 22:31, Paul Makepeace wrote:
>>>
>>> capistrano is a (the?) winner for sure.
>>
I've used Capistrano a bit - it's ok but too much magic for my liking
(and in general I'm a big fan of the Ruby ecosystem). Fabric is a more
sensible alternative IMO (you might find
http://www.slide
On 24 Jul 2014, at 23:47, Schmoo wrote:
> On 24 July 2014 22:31, Paul Makepeace wrote:
>>
>> capistrano is a (the?) winner for sure.
>
> Why do these new fangled things all have such off-putting names?
Just wait til you find out that someone built a web frontend for it called
‘webistrano’.
On Thu, Jul 24, 2014 at 2:47 PM, Schmoo wrote:
> On 24 July 2014 22:31, Paul Makepeace wrote:
>> On Thu, Jul 24, 2014 at 2:06 PM, James Laver wrote:
>>>
>>> Then I’ll double down on my capistrano/tak recommendation.
>>
>> capistrano is a (the?) winner for sure.
>
> Why do these new fangled thing
On 24 July 2014 22:31, Paul Makepeace wrote:
> On Thu, Jul 24, 2014 at 2:06 PM, James Laver wrote:
>>
>> Then I’ll double down on my capistrano/tak recommendation.
>
> capistrano is a (the?) winner for sure.
Why do these new fangled things all have such off-putting names?
On Thu, Jul 24, 2014 at 2:06 PM, James Laver wrote:
>
> Then I’ll double down on my capistrano/tak recommendation.
capistrano is a (the?) winner for sure.
Paul
On 24 Jul 2014, at 18:59, David Cantrell wrote:
> On Thu, Jul 24, 2014 at 06:34:08PM +0200, James Laver wrote:
>
>> And if your jenkins isn?t already singing the single-button deployment song,
>> make it do so*.
>
> That does, of course, depend on our code being easily deployable. We're
> a lo
On Thu, Jul 24, 2014 at 06:34:08PM +0200, James Laver wrote:
> And if your jenkins isn?t already singing the single-button deployment song,
> make it do so*.
That does, of course, depend on our code being easily deployable. We're
a long way from that at the moment. It's something to consider
On 24 Jul 2014, at 17:25, David Cantrell 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.
>
> Is this the sort of thing that puppet and chef
On 24 July 2014 16:25, David Cantrell wrote:
> What tools do you use for:
>
> * deploying code to multiple servers;
> * and multiple environments - eg live, staging, ...
> so eg we have api1.live..., api2.live..., ...
>
We use a combination of:
minicpan + CPAN::Mini::Inject
All under ver
Our "deployment process" at work isn't so much a well-documented
dependable repeatable process as a modern dance interpretation of
lemonparty. It needs taking out and shooting.
What tools do you use for:
* deploying code to multiple servers;
* and multiple environments - eg live, staging, ...
24 matches
Mail list logo
