Puppet deployment design questions

[Tass Skoudros]

A little history, I work with a small startup and we are looking at
rolling out a automated cloud based provisioning platform. We have a
dilemma and i wanted to ask your communities thoughts.

As far as I am aware there are 3 ways to run puppet, standalone with
puppet, Client/Server and a hybrid of client/server and rsync. The
last of these wouldn't work very well in our case so I am not looking
at it as a potential solution.

We have tried the standalone, its slick. To me the standalone method
is intended to address a need thats something entirely different to
what we require. I moved on.

I then went on to the client/server method. Essentially there are 2
ways this can work, the first is we(startup) control the master and
deploy clients. The second is we deploy master+client on every server,
the configuration would point to our external node web service.

Each has its own advantage and we will be using external nodes to load
the configurations in both cases. The differences are that the first
would quickly become an issue when the version of the puppet client
changes. So we have been exploring the second of these and still have
other encounters that break with our goal of full automation.

So my question, is there a better way? Am I missing something.

[Tass Skoudros]

I have since found out that actually using puppet standalone and node
classifier is possible. In our tests, we added the classifier to the
wrong part of the config file which is probably why we didn't get very
far. Good news is this makes everything simpler. Still very happy to
hear your thoughts and hear any recommendations.

Thanks

[David Schmitt]

On 7/4/2010 11:17 AM, Tass Skoudros wrote:
> Each has its own advantage and we will be using external nodes to load
> the configurations in both cases. The differences are that the first
> would quickly become an issue when the version of the puppet client
> changes. So we have been exploring the second of these and still have
> other encounters that break with our goal of full automation.
>
> So my question, is there a better way? Am I missing something.

If you are using multiple puppetmasters and resource collection (using
@@ and <<||>> syntax) those all need to access the same database and
have to be the same version.

It is expected that a puppetmaster with version N can still serve up
configurations to clients of version N-1. That is, 0.24.x clients can
talk to 0.25.x servers and 0.25.x clients can talk to 2.6.x servers.

If you need longer deployment times of client versions, you're better
off keeping a matching puppetmaster around and looking at a manually
(e.g. cluster ssh) approach to upgrading over multiple versions in one
swoop.

Best Regards, David Schmitt

--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999

FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg

[Harihara Vinayakaram]

Can't you use Puppet to upgrade client versions ? I read about puppet
being used to upgrade and all that . So why can you not upgrade your
client versions using puppet itself ?

Regards
Haro

[TomTom]

Hi Tass,
If I understood your question correctly, you were wondering if you
should deploy puppet as a "standalone" client server model, vs. a
hybrid client+server on each of your hosts. You should shoot for the
standalone option.

Puppet is essentially a webserver. You can scale it with multiple
puppet masters and load balancing. The argument to centralize your
configuration management service is the same for centralization of
any IT service. Easier Manageability, Maintainability, etc.

The need to run puppet in a standalone fashion is an interesting one.
I believe it boils down to not being able to trust the network and the
ssl authentication process built into puppet. Or having a
sophisticated SSH infrastructure already in place and not wanting to
deploy a new protocol. If either of these situations apply to you
shoot for a standalone puppet client and rsync over ssh the /etc/
puppet/modules/ directory. Doing a client+server would be an
additional layer of un-needed complexity.
-Tom