On 06/05/16 15:46, christg76 wrote:
Hi, I'm fairly new to Puppet and have been given the project of
upgrading an existing Puppet 2.7 site (Puppetmaster with
Apache/Passenger, and MySQL for exported resources, with hundreds of
clients), possibly to Puppet 4.
Just wanted to ask around if anybody has got experience with such an
upgrade. Reading the docs it says that skipping major versions isn't
recommended, so I guess I'd have to first upgrade to 3.x? Are there
anymore upgrade docs for 2.7 to 3.x available?
You have already received great advice on two strategies:
* Ramin K - points out the good versions to move to before jumping to
the next level. Each step requires addressing something fairly major
changing.
* Andrew Grimberg - greenfield approach on a 4.x to also do major
refactoring / cleanup.
I would just like to add a couple of considerations. With newer puppet
versions you also get the opportunity to use newer versions of modules
from the forge + better tooling. Your code base may contain solutions /
work-arounds that are now no longer needed (fixed in modules, better /
cleaner ways of doing things). Thus if you follow the longer path of
upgrading several times; you may need to learn / and re-learn how to do
things.
The chain of good versions (as pointed out by Ramin K) can also be made
shorter depending on how your operation is set up, how much the
operation depends on things like dynamic environments, how much custom
code you have to migrate, custom facts, types and providers that you
have implemented in house. Is your code in git or not? What are the
processes around your installation, what is it integrated with?
Also, worth considering is how different your nodes are and who controls
their configuration. Worst case it is like migrating multiple puppet
installations (different groups having written different things
different ways).
If things are really messy, what Andrew Grimberg suggests sounds best.
As you are learning (and do what Martin Alfke said; attend training),
set up a canary and use 4.x and apply best practices. Then you know what
the target is. Then "slice the elephant" and migrate nodes over
gradually. Now you "only" have to figure out what "old messy things"
intended and express then once in 4.x rather than risking changing a lot
of code several times and learning best practices as they were 3 years
ago and then what they were 2 years ago...
A very concrete example - if your in-house code base is fairly clean /
small someone else has already done the heavy lifting to get to 4.x as
most popular modules supports it.
Best of luck,
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/66a76695-7733-5658-a884-ab7e1f0f0c14%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
