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.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: Experiences with deployment solutions
by reisinge (Hermit) on Feb 24, 2014 at 19:59 UTC
|
| [reply] [Watch: Dir/Any] |
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:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] [Watch: Dir/Any] |