Ask Your Question
0

Infrastructure and Application environments : looking for a solution

asked 2017-05-31 10:40:13 -0600

craymore gravatar image

Hello my dear puppeteers,

I am currently looking forward to have a solution which would allow me to manage hundreds of machines with different needs.

Brief explanation about the setup I currently have :

  • there is one puppetmaster per technical environment ( i.e : dev, uat, prod ... )
  • each puppetmaster handles several application-based environments

example

machine devpuppetmaster has the following items in /etc/puppetlabs/code/environments/

  • application1
  • application2
  • application3

This setup is a bit different from the expected standards as the 'environments' processed are not technical environments but application-based ones

While it works well for the current deployment needs, I am willing to extend the scope of puppet machines' management to entire park ... and this is where it gets complicated :(

I could have a 'default' environment defined, that all the infrastructure machines would use in order to get a generic configuration ( system utilities, middlewares etc. ) .... but then how would I also get the application definitions deployed on the machines which require it ? ( AFAIK, a puppet agent can only be configured to use one environement )

Thanks beforehand for any answers !

edit retag flag offensive close merge delete

Comments

I'll try to come up with a more through writeup later, but a quick question first... Is the intent that the individual tenants can manage their own configurations, or are you still centrally managing them for each tenant?

DarylW gravatar imageDarylW ( 2017-05-31 11:11:19 -0600 )edit

One approach would be to have your own internal modules (Forge/Git) where all of the common modules are pieces that could be brought in as dependences per application environment. That way you could have a collection of modules (including profile modules), and each env can control when to upgrade

DarylW gravatar imageDarylW ( 2017-05-31 11:14:47 -0600 )edit

Another approach is to manage them all as a single environment, with hiera managing the different sets of configurations. There are several ways to do this, but it is more of a 'centrally managed' example

DarylW gravatar imageDarylW ( 2017-05-31 11:15:23 -0600 )edit

( I answered these points below )

craymore gravatar imagecraymore ( 2017-06-01 07:40:06 -0600 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2017-05-31 11:37:42 -0600

craymore gravatar image

Hi DarylW,

Thanks for your answer(s)

Regarding the configuration, here's what's currently in use in all environments ( application-based ) :

application1
    ├── hiera
          ├── common.yaml
          ├── env.yaml
          └── crossroles -> /etc/puppetlabs/puppet/hiera/crossroles

Basically, we have the configuration dedicated to the environment itself ( common.yaml, env.yaml ) and then what we call the crossroles configuration which contains every pieces of configuration which is shared by all the environments

  • the dedicated environment's configuration changes frequently ( depending on the application needs )
  • the crossroles ( aka common configuration ) changes less frequently ( e.g : middleware version upgrade )

To manage everything trough a single environment and use hiera to distinguish the needs would be too much work ( to rework the existing controlrepos ) I am afraid

Your modules proposition looks interesting, I'll analyze it

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

1 follower

Stats

Asked: 2017-05-31 10:40:13 -0600

Seen: 20 times

Last updated: May 31