http://www.perlmonks.org?node_id=1074351

Hi all,

this is not really a Perl related question but I would like to address the Perl community with it.

There is rex as a Perl based deployment tool which seems interesting as all is implemented in Perl and someone like me could get the feeling to be able to put hands on when needed. On the other hand there are well known and famous tool sets like Chef and Puppet written in a language not known to me.

So, I would like to hear whether some monks have experience with these distribution tools and whether using them seems worth it (I know, a really vague question).

Thank you in advance.

Best regards
McA

Replies are listed 'Best First'.
Re: Experiences with deployment solutions
by Corion (Patriarch) on Feb 11, 2014 at 07:18 UTC

    I only have direct experience with rex, and it works well enough for my purposes.

    The indirect experience with Chef and Puppet tells me that they don't value backwards compatibility. Every new release of Chef or Puppet means you have to revisit all your existing recipes.

      Hi Corion,

      thank you for your comment. The last sentence sounds weird for Perlianers who are so used to backwards compatibility.

      Best regards
      McA

Re: Experiences with deployment solutions
by stonecolddevin (Parson) on Feb 17, 2014 at 22:13 UTC

    ansible and vagrant are pretty nice.

    Lots of hardcore operations folks will tell you to go with Chef or Puppet because of flexibility/robustness, but it all depends on your infrastructure needs. Chef has A LOT of documentation on deploying things on AWS, and pre-canned recipes for Rails, Scala, etc. type apps, and Puppet has some automation solutions for things like RDP (Windows), though I am not sure if Chef can deal with that, but I digress.

    If you want dead simple setup and just need quick, basic deployment automation, check out ansible. If you are starting from the ground up, check out Chef + Berkshelf. You'll want that kind of control if you're going to scale fast and have many types of machines that need provisioning/nannying, it's just very involved.

    Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

      Thank you for your comment on that. I'll have a look.

Re: Experiences with deployment solutions
by reisinge (Hermit) on Feb 24, 2014 at 19:59 UTC

    I had a similar question about slaughter. I am also considering cfengine.

    Well done is better than well said. -- Benjamin Franklin

Re: Experiences with deployment solutions
by dragonchild (Archbishop) on Feb 25, 2014 at 20:32 UTC
    Deployment is the act of taking a piece of software and installing it onto a server, applying configuration as necessary.

    A deployment tool is a package manager. Various OSes use rpm, deb, msi, dmg, etc. Some languages provide their own methods (CPAN, RubyGems, PyPi, NPM, etc). At its heart, it's a tarball with metadata.

    So, rex is not a deployment tool. It is a provisioning tool. And a poor one, at that.

    Chef, Puppet, Cfengine, Ansible, and Salt are NOT deployment tools. They are provisioning tools. They ensure that certain packages and scripts have been executed on the target server.

    Vagrant is NOT a deployment tool. It is a virtualization manager. (It's actually a sugar layer on top of other virtualization managers.)

    Just because these tools are written in Ruby doesn't make them poor. Ruby is an excellent language to do OS work in, much better than Perl.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      Hi,

      never thought about the subtle differences of terminology. I found this article http://java.dzone.com/articles/deployment-automation-vs-0 which tries to bring light into the differences and seems to be interesting.

      Rex calls itself a tool for "Deployment & Configuration Management".

      On the start page of Chef I found: "...Chef can automate how you configure, deploy and scale your servers and applications...". So, the term "deploy" is there too.

      On the Puppet site I found at http://puppetlabs.com/puppet/puppet-enterprise: "...quickly deploy critical applications...". Also there is the term "deploy" used.

      Ansible says on the homepage (http://www.ansible.com/home): "...Ansible automates app deployment, ..."

      On an introduction page of Salt (http://docs.saltstack.com/topics/) I found: "...Providing versatility between massive scale deployments...". So it seems that Salt is used for deployments too.

      http://cfengine.com/ was dead at the moment when I tried to look at. Probably they tried to provision something.

      But anyways: My total naivety in this domain let me subsume these tools or toolsets as deployment tools. What I meant are tools which help me to automate the installation of software packages and the required prerequisites on servers to run services/applications.

      Thank you for pointing out that there are some important differences in terminology.

      To your other comment: I totally agree with your opinion: "Just because these tools are written in Ruby doesn't make them poor.". But this was also something nobody insisted in.

      Best regards
      McA

      Ruby is an excellent language to do OS work in, much better than Perl.

      Could you please elaborate? And maybe define OS work?

        OS work is work that sysadmins or operations teams tend to do vs development teams. That's probably the best example. As for why Ruby over Perl? I gave a presentation on this at CodeMash 2015

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?