Ask Your Question
0

How do you manage your different configurations in environments?

asked 2018-10-12 10:08:53 -0500

Alexis Lessard gravatar image

Hello!

We are currently in the process of implementing the role-profile-module method in our organization (about time, you might say, but better late than never!). Everything will be managed in a git repository, meaning that our environment is completely inside git: The node manifests and the modules, as well as, eventually, our hiera data (still working on that one...) Logically, we want a branch to represent an environment. In almost all our solutions, we have already different environments. We have development, approbation, production, sometimes test, etc... But sometimes, between those environments, the configuration of the different tools we use isn't the same. For instance, we want to enable alerts in a monitoring system when it's in production, but we don't want to enable them in approbation. But if we have different code in our different environments, we fear that we may have a lot of merge conflicts. If we implement a change in approbation, and then merge it in production, all the modifications of approbation will be included, which could be bad...ish?

This is also apparent when managing our agents. If we define a node in our experimentation branch, it'll be included in out approbation and production branch as well. We can't ignore those files because they have to be sent to the puppet server in order to be included in our environment.

I feel like this should require a totally different way of developping our puppet code, forcing us to be more flexible in our code. How would you abord this problem? Should we put as much configuration in templates as we can, and write a lot of case statements? Or use booleans to insert or not data in those files, and assign values in hiera? And when it comes to profile, wich wouldn't be the same between those environments, could we put if statements in the profiles based on the environment? What would you suggest?

I'm looking for real life experiences and work methods, so feel free to say anything related to the subject which might help us figure out our way of handling the situation. Thank you!

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted
1

answered 2018-10-15 09:05:11 -0500

DarylW gravatar image

updated 2018-10-15 09:09:58 -0500

The answer is to have as close to a single environment (all of the 'code' is in every environment), you just have all of your data for every environment stored in hiera, and an 'environment' fact that you use to pick which set of data gets pulled in - that will make the code merge problems a lot more manageable.

If you have any information that can't be shared across the environments (sometimes prod credentials aren't allowed to be accessed by developers, etc), you would need a different Hiera backend for the credential portion of your data, but all of the 'configuration' portion of your data should be in that common hiera hierachy.

As you mentioned above, you 'could' put if statements inside of your profiles, or you would just have different roles you would assign to instances - perhaps a myserver_dev role that doesn't include the same alerting profile, or just an 'if' statement around the alerting portion that disables it in dev (or not prod/qa).

edit flag offensive delete link more

Comments

1

For information that couldn't be shared, I would use eyaml I believe. Thank you for the advice!

Alexis Lessard gravatar imageAlexis Lessard ( 2018-10-15 09:45:35 -0500 )edit

In that case, you need to use different keys for different eyaml files within the same set of hiera data - and you need to make sure that the nodes don't have a problem with seeing a file that they can't parse (dev not parsing prod, vice versa)

DarylW gravatar imageDarylW ( 2018-10-16 08:26:08 -0500 )edit
1

answered 2018-10-15 16:03:12 -0500

luksi1 gravatar image

I'll add my own answer to this thread as I think the most important thing we've found is testing, testing, and more testing! As both commentors mentioned, you'll need environments and certainly some conditional logic. This allows you to merge between branches, but you certainly have some expectations between dev, test, qa, and prod. This means you'll need to be using rspec-puppet for unit testing and beaker for your acceptance testing, so that you get it right. Nothing throws a wrench into a large configuration management refactoring like merging dev data into prod! I know it's a standard answer to test, test, test, but it's true, and more true when refactoring!

One last thing... in our experience you can hold off on the unit testing in your roll/profile manifests and focus on robust acceptance testing. The reason for this is that it's mostly simple conditional logic and application of a hodge-podge of modules. What you really want to be testing is that these modules are producing what you want on bare-metal and playing well together.

Good luck!!

edit flag offensive delete link more
0

answered 2018-10-15 08:41:58 -0500

Speaking from my own experience, we do use the branch as environment approach. Because there are currently only two people managing the Puppet enterprise (which we'll be expanding in the future) it's fairly easy to manage.

Currently we keep track of changes in each environment with a home grown tracker and we selectively checkout individual files into other branches when it is time to promote code from one environment to the next (test -> dev -> prod). Additionally we try to use as many "defaults" as possible in the code and use hiera to override the "snowflakes".

Because you mentioned doing node definitions on a node by node basis, I'm assuming you are using Puppet OSS. We are using PE and we have the nodes automatically classify based upon trusted facts created at the time the node is deployed. Because the nodes are automatically classified by the master, we keep the same hiera files, including node files, in all branches.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-10-12 10:08:53 -0500

Seen: 84 times

Last updated: Oct 15