I''ven been learning puppet over the last 2 weeks and the one thing I''ve come to realize is there is a completely different way of thinking that I''ve normally been accustomed to. I''ve been trying to absorb as much knowledge as possible on how I should think about organizing our infrastructure. One of the resources I''ve come across was this article http://www.craigdunn.org/2012/05/239/ talking about roles and profiles. I definitely like this way of thinking so I''ve been trying to massage it into our specific needs. I have a few questions regarding this "pattern". Now I understand the smaller, simpler aspects of setting up roles and profiles for our system.. ie, nagios, ntp, networking etc, but it starts to break down when I try to model our application needs. Our application is a Ruby on Rails application that runs within a Unicorn server with ngninx sitting in front of it. Our application also requires the correct mounting of a NFS filer before its able to start. We also have custom nagios checks for this application as well as checking that our mounts are correctly configured. Using the above pattern of roles and profiles how could I model this? This is what I have so far: https://gist.github.com/4192914. Now I''m kind of lost and I have a bunch of questions: - Should I move the RVM logic out of webapp profile, push it down further into the company_application module, or leave it where it is? - What profile and/or module should be responsible for checking out the code from git? The webapp profile, company_application::install.pp or somewhere else? - Who should be responsible for the mounting? Module, push it down into company_application or leave it at the profile level? - Who should be responsible for the custom nagios checks? Module, push it down into company_application or leave it at the profile level? Anything else you can recommend? Any input is greatly appreciated. Thanks! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
2012-Dec-03 15:20 UTC
[Puppet Users] Re: Roles, Profiles and Application Specific Needs
On Sunday, December 2, 2012 11:32:29 PM UTC-6, Smashed wrote:> > I''ven been learning puppet over the last 2 weeks and the one thing I''ve > come to realize is there is a completely different way of thinking that > I''ve normally been accustomed to. I''ve been trying to absorb as much > knowledge as possible on how I should think about organizing our > infrastructure. One of the resources I''ve come across was this article > http://www.craigdunn.org/2012/05/239/ talking about roles and profiles. >That''s a cool post, with some very useful thoughts. As simple as it may seem, though, it''s not beginner-level stuff. It''s likely to leave a newbie with a lot of questions about how to actually apply that pattern. Just as it has done for you.> I definitely like this way of thinking so I''ve been trying to massage it > into our specific needs. I have a few questions regarding this "pattern". > Now I understand the smaller, simpler aspects of setting up roles and > profiles for our system.. ie, nagios, ntp, networking etc, but it starts to > break down when I try to model our application needs. > > Our application is a Ruby on Rails application that runs within a Unicorn > server with ngninx sitting in front of it. Our application also requires > the correct mounting of a NFS filer before its able to start. We also have > custom nagios checks for this application as well as checking that our > mounts are correctly configured. Using the above pattern of roles and > profiles how could I model this? This is what I have so far: > https://gist.github.com/4192914. Now I''m kind of lost and I have a bunch > of questions: >One of the reasons you are having trouble is that you are only trying to configure one type of machine. Roles and profiles are way overkill for you at this point. They are mainly an approach to handling situations where you have a medium to large number of different types of machines, with varying amounts of shared configuration in different areas. I''d suggest that you cut out the middle layer (profiles). It will make your problem clearer without really costing you anything, because adding more machine types later on would very likely require you to refactor anyway. For the same reason, dump "base" roles (and profiles) for now. No modules/profiles are more basic than any others when there is only one role defined.> > - Should I move the RVM logic out of webapp profile, push it down further > into the company_application module, or leave it where it is? >You should avoid RVM at all costs. Just install the needed Ruby version on the machine, and use it. If there is some reason why you think you need RVM, however, then surely that reason bears on the question of how RVM should be managed.> - What profile and/or module should be responsible for checking out the > code from git? The webapp profile, company_application::install.pp or > somewhere else? >There should be no company_application::install.pp, as judged by the fact that "install" is a verb. Puppet DSL is all about describing the desired state of your machine, strongly de-emphasizing the actions required to achieve that state. Therefore modules, classes, and resources (including definitions) should generally represent things, therefore their names should be nouns. In some cases, it may be appropriate for classes to represent variations on a thing defined separately; in those cases it may be appropriate for class names to be adjectives. (So perhaps there is a company_application::installed.) That may seem like a nit-pick, but it''s all about thinking in the Puppet model. As for the main thrust of your question, how is anyone here supposed to advise you about details of your configuration when you only present a very sketchy outline? We don''t know what the classes you name are supposed to represent, or what else they manage, or why. My advice to dump profiles might give you a nudge in the right direction, though.> - Who should be responsible for the mounting? Module, push it down > into company_application or leave it at the profile level? >Given that the only thing being configured is a machine to run your specific application, I''m not sure it even makes sense to have a "company_application" module. Everything you are declaring is part of the configuration for your application, one way or the other, so it is natural that you are confused about what layer of abstraction you should work at. For much the same reason I recommended you dump profiles, I also recommend that you pull up your "company_application" module to merge it into your role::webapp role. It probably makes more sense for the role to be more specifically-named, too, maybe "role::company_app_server".> - Who should be responsible for the custom nagios checks? Module, push it > down into company_application or leave it at the profile level? > >Again, you are struggling with multiple levels of abstraction that all represent essentially the same thing. Simplify. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/43b61QTGk20J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Mark
2012-Dec-03 16:26 UTC
Re: [Puppet Users] Roles, Profiles and Application Specific Needs
John, thanks for your input. I should note however that this application is just one of several types of machines that we will set up. It''s just that this our primary type of machine that needs to be configured so I listed it as an example. We have other such as, memache, redid, solr, hadoop, etc. I''m trying to start off on the right foot by learning "best practices". Having said that could you lend some guidance on my original questions? - M On Dec 3, 2012, at 7:20 AM, jcbollinger <John.Bollinger@stJude.org> wrote:> > > On Sunday, December 2, 2012 11:32:29 PM UTC-6, Smashed wrote: > I''ven been learning puppet over the last 2 weeks and the one thing I''ve come to realize is there is a completely different way of thinking that I''ve normally been accustomed to. I''ve been trying to absorb as much knowledge as possible on how I should think about organizing our infrastructure. One of the resources I''ve come across was this article http://www.craigdunn.org/2012/05/239/ talking about roles and profiles. > > > That''s a cool post, with some very useful thoughts. As simple as it may seem, though, it''s not beginner-level stuff. It''s likely to leave a newbie with a lot of questions about how to actually apply that pattern. Just as it has done for you. > > > I definitely like this way of thinking so I''ve been trying to massage it into our specific needs. I have a few questions regarding this "pattern". Now I understand the smaller, simpler aspects of setting up roles and profiles for our system.. ie, nagios, ntp, networking etc, but it starts to break down when I try to model our application needs. > > Our application is a Ruby on Rails application that runs within a Unicorn server with ngninx sitting in front of it. Our application also requires the correct mounting of a NFS filer before its able to start. We also have custom nagios checks for this application as well as checking that our mounts are correctly configured. Using the above pattern of roles and profiles how could I model this? This is what I have so far: https://gist.github.com/4192914. Now I''m kind of lost and I have a bunch of questions: > > > One of the reasons you are having trouble is that you are only trying to configure one type of machine. Roles and profiles are way overkill for you at this point. They are mainly an approach to handling situations where you have a medium to large number of different types of machines, with varying amounts of shared configuration in different areas. > > I''d suggest that you cut out the middle layer (profiles). It will make your problem clearer without really costing you anything, because adding more machine types later on would very likely require you to refactor anyway. For the same reason, dump "base" roles (and profiles) for now. No modules/profiles are more basic than any others when there is only one role defined. > > > - Should I move the RVM logic out of webapp profile, push it down further into the company_application module, or leave it where it is? > > > You should avoid RVM at all costs. Just install the needed Ruby version on the machine, and use it. If there is some reason why you think you need RVM, however, then surely that reason bears on the question of how RVM should be managed. > > > - What profile and/or module should be responsible for checking out the code from git? The webapp profile, company_application::install.pp or somewhere else? > > > There should be no company_application::install.pp, as judged by the fact that "install" is a verb. Puppet DSL is all about describing the desired state of your machine, strongly de-emphasizing the actions required to achieve that state. Therefore modules, classes, and resources (including definitions) should generally represent things, therefore their names should be nouns. In some cases, it may be appropriate for classes to represent variations on a thing defined separately; in those cases it may be appropriate for class names to be adjectives. (So perhaps there is a company_application::installed.) That may seem like a nit-pick, but it''s all about thinking in the Puppet model. > > As for the main thrust of your question, how is anyone here supposed to advise you about details of your configuration when you only present a very sketchy outline? We don''t know what the classes you name are supposed to represent, or what else they manage, or why. My advice to dump profiles might give you a nudge in the right direction, though. > > > - Who should be responsible for the mounting? Module, push it down into company_application or leave it at the profile level? > > > Given that the only thing being configured is a machine to run your specific application, I''m not sure it even makes sense to have a "company_application" module. > > Everything you are declaring is part of the configuration for your application, one way or the other, so it is natural that you are confused about what layer of abstraction you should work at. For much the same reason I recommended you dump profiles, I also recommend that you pull up your "company_application" module to merge it into your role::webapp role. It probably makes more sense for the role to be more specifically-named, too, maybe "role::company_app_server". > > > - Who should be responsible for the custom nagios checks? Module, push it down into company_application or leave it at the profile level? > > > > Again, you are struggling with multiple levels of abstraction that all represent essentially the same thing. Simplify. > > > John > > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/43b61QTGk20J. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
jcbollinger
2012-Dec-04 14:32 UTC
Re: [Puppet Users] Roles, Profiles and Application Specific Needs
On Monday, December 3, 2012 10:26:33 AM UTC-6, Smashed wrote:> > John, thanks for your input. I should note however that this application > is just one of several types of machines that we will set up. It''s just > that this our primary type of machine that needs to be configured so I > listed it as an example. We have other such as, memache, redid, solr, > hadoop, etc. I''m trying to start off on the right foot by learning "best > practices". Having said that could you lend some guidance on my original > questions? >No, I can''t, not any more so than I already have done. Most of your questions bear on issues that are specific to your site or are highly interrelated. I do not have the local knowledge I would need to make good recommendations on specifics, and sorting out the interrelations among pieces of your configuration is a major set of design tasks (not something I can do for you). I will re-emphasize, however, that I think you are going about this the wrong way. Nobody learns Puppet by doing a *de novo* top-down design of an entire site configuration. The best way to learn Puppet is bottom-up. Moreover, that allows you to integrate Puppet gradually into your infrastructure, which tends to go much more smoothly than trying to change over all at once. Do start with some simple modules (both senses of the term). Ignore profiles for now, as I already suggested, but by all means use role classes if that design style is your goal. Keep your modules small and tightly focused. Profiles will emerge as you configure additional roles -- look for recurring, natural aggregates of your modules. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ZueYPfumVVUJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.