When puppet, chef or ansible are simpler solutions than package manager?

Question

I'm new to above deployment and configuration tools. I have typical need to install and upgrade on a target machine a customized and configured webserver, maybe reverse proxy, database, required runtime for interpreted languages and such.

My distribution already has a package manager that works. I can create and distribute my own packages containing preconfigured software and install/upgrade them over ssh.

Where should I expect this solution to be insufficient and opt for mentioned tools?

score 3 · Accepted Answer · answered Apr 26 '15 at 17:04

A package manager is in no way a replacement for configuration management. A configuration management system can handle interactions with the native package manager. As far as baking configurations into packages, this would only be sufficient if a) all your servers are intended to have identical configurations and b) No external data is required for their configurations.

Let's look at a basic infrastructure. You have an internal web application but you also use a have a webserver for running ticket tracking software (let's say Redmine). Your internal web application is written in PHP but Redmine is a ruby application. These two different web applications would have different apache configurations. If you are baking configurations into packages, this would require you to build two apache packages that conflict with each other eg apache-internal and apache-redmine. It's easy to see how this can become unmanageable very quickly.

Let's see how this would look in a puppet manifest instead:

# internal PHP application
class { apache: }
# uses your OS package manager to install PHP
class {'::apache::mod::php':
  package_name => "php54-php",
  path         => "${::apache::params::lib_path}/libphp54-php5.so",
}

# redmine
class { apache: }
# uses your OS package manager to install mod_passenger
class { apache::mod::passenger: }
apache::vhost { $::fqdn:
  docroot     => '/path/to/directory',
  directories => [
    { path              => '/path/to/directory',
      passenger_enabled => 'on',
    },
  ],
}

Another basic example is having different environments in your infrastructure. Something that you can't do with static configurations in a package manager is template config files. If you have a development and production environment, templates allow you to write configurations that tell your applications to connect to the correct data source (eg a database) or it's particular environment.

Lastly, who is going to add your custom repos and install the correct packages on each host? This is more unnecessary maintenance that is solved by configuration management.

score 0 · Answer 2 · edited Apr 06 '19 at 00:08

I agree with Jordanm, a practical example of how I use puppet within my company is we have local yum repositories as our whole infrastructure is Centos based. When building new servers from scratch I can choose a manifest I have pre-configured to build the server against e.g. It might be a lamp stack so puppet will install all of the required RPMs to ensure all the correct applications are present. But it will also remove any system services I don't want, change configurations, deploy iptable rules, install administrator user accounts, configure proxy rules and so on. Any system changes I make I do them through puppet so I never forget to make them again.

As you can see puppet is used for more than just package management it can build a whole server without user interaction. Think about if your hardware dies how long and how much effort would it take to build a new replica.

When puppet, chef or ansible are simpler solutions than package manager?

2 Answers2