Hacker News Reader

Comment by AlexanderDhoore | Hacker News Reader

I just now (past few days) started learning about this stuff. I've been doing the "Learning Puppet" tutorials [1].

The most important thing about it is that you describe the state of the server. And puppet applies it for you. It's idempotent (you might know this term from REST). You can run puppet multiple times and the end result would be the same.

Normally (without config management) you would write scripts that do the configuration. If you ran them twice, things could go wrong, or they would overwrite the stuff from last time. Scripts are descriptions of what steps to take. Puppet manifests are descriptions of what state you want the server to be in.

[1] http://docs.puppetlabs.com/learning/index.html

View on HN

Ok, the declarative and idempotency sounds great. But consider this one use case. I want to stop a service, upgrade it to a new version, restart that service. The service is an application which I wrote that runs in apache tomcat.

    1: Stop Service
    2: Upgrade
    3: Start Service

Right now I have just made three non-declarative statements about my tomcat server. I am describing a process that runs through a series of steps to reach a new conclusion.

So puppet has these beautiful (sounding) properties. But declaratively describing the state of my servers isn't a real problem I have.

I need to deal with the way that my servers change. I need to upgrade services, including starting and stopping. Puppet absolutely fails at this. Any attempt to describe a process is antagonistic to puppet at a fundamental level.

Whenever people seek a solution to these problems they always get fed that line. That puppet is declarative and idempotent, which is fine. But we should be _very_ clear that puppet does a spectacularly bad job of solving a very ordinary problem that I have, and which I would expect almost everyone else working with large numbers of servers to have too.

Your actual objective seems to be: 1. The current version of MyApplication must be deployed and running.

If you're interested in trying out Chef - which seems like a good fit from your comment - read on.

For tomcat you could take a look at this community-provided cookbook, which contains resources that make it simple:

https://github.com/opscode-cookbooks/application_java

If you explicitly need to stop/start tomcat beforehand (I believe this resource does a restart after deploying your app) you can do that with the "service" resource built into Chef - though doing so may mean that you're restarting every time you converge the node, which is probably not what you're looking for.

> I want to stop a service

You WANT to stop the service? Really? Stopping the service is an actual headline-level goal, and not a behind-the-scenes detail?

Personally I tell puppet "make sure that the latest version of X is running", because that's what I actually want, and I don't care how it does it...

Maybe you want to tell the load balancer before stopping a service, and actually wait for it to drain before going ahead. Or you want to disable alerts for services while they're being restarted.

Maybe puppet has hooks to integrate with the rest of your setup, I don't know - either way, caring about how things are restarted isn't that crazy imo.

Your ultimate goal is to ensure that the service is at the latest version.

There are numerous dependencies to that task - one of which may be stopping the service before upgrading. There are dependencies to stopping the service - maybe telling the load-balancers or your monitoring system. When the service has been upgraded, you can trigger notifications that other items within your config can depend upon (for example, when an upgrade is complete, restart the service, when the service restarts, add it back to the monitoring system etc).

All of these can be modelled in these config-management tools, as explicit dependencies within your manifest file - as opposed to implicit and ad-hoc dependencies within your script.

But consider this one use case. I want to stop a service, upgrade it to a new version, restart that service. The service is an application which I wrote that runs in apache tomcat.

Perhaps I'm missing some obvious detail but I would think you would just update your repository with the new version of your application and/or Tomcat package and that would cause the service to restart on the next Puppet run, after the new version has been installed.

The last web company I worked for had an app that required a little extra care and feeding to deploy, and we just didn't use configuration management for that. There were plenty of other uses for config management (changes to rewrites in httpd.conf, for example). We used bash scripts for handling deployments, which primarily relied on distributed ssh and rsync to perform upgrades. (I believe this is the fabric use case, though it didn't exist at the time and I've never used it)

The app was already documented, source-controlled, version-controlled, and tested by developers and QA. There wasn't much benefit to adding anything to the configuration management repository unless there were platform/infrastructure changes.

This is a very ordinary problem, and it's usually solved like this with Puppet:

Specify the service declaratively, and subscribe it to the package that provides the payload.

  service { 'myservice':
     ensure    => running,
     enable    => true,
     subscribe => Package['myservice'],
  }

Then when you upgrade the package on that node, either by using ensure => latest, or by manually specifying the new version, Puppet will automatically restart the service.

Reply on news.ycombinator.com