Hi Pete.
I ended up doing just that, class variables for versions of applications
backed by Hiera. I am trying to avoid putting %{environment} in Hiera to
keep different jurisdictions from interfering with each other. I just use
directory environments for both Hiera data and puppet modules.
Now I did end up with the issue I was afraid of: A messy mix of
infrastructure data owned by Ops (IP-addresses, nodes, clustering,
firewall, etc) with all the application data that is owned by delivery
(what things are tested and integrated together).
I'm thinking that my hierarchy is wrong and will try to separate the
application versions from infrastructure data and retrieve them from
separate repos. I'm fairly new to Hiera so I don't know if that will even
work... will have a look into r10k as well.
Something like this:
---
:hierarchy:
- "%{::role}_infrastructure"
- "%{::role}_versions"
- "..."
- "common"
Wish I learned all this "Ops" stuff years ago instead of fumbling in the
dark...
Den fredagen den 1:e augusti 2014 kl. 00:26:29 UTC+2 skrev Pete:
>
> Hi,
>
> I think the best way to achieve this is to use class variables for all
> the versions of packages you want to manage and use hiera as the
> backend.
> You can actually use the $::environment fact in your hiera.yaml file
> when defining the datadir.
>
> I tend to put my hiera tree in a separate repository but you could
> just as easily put it in your environment repository,
>
> I would also recommend using r10k to manage your environment and hiera
> checkouts.
>
> Does that all make sense?
>
> Pete.
>
> On 29 July 2014 09:10, Devminded <[email protected] <javascript:>>
> wrote:
> > Hello everybody.
> >
> > I'm a developer new to puppet and are working with a complex system made
> up
> > of several subsystems. We have regulatory requirements which forces us
> to
> > have several production environments (at-least one per jurisdiction).
> This
> > is causing us some pains.
> >
> > The main problem is that the different jurisdictions "requires"
> different
> > versions (and sometimes content) of the deployed applications. Due to a
> > drawn out certification process some environments lags behind in
> versions by
> > up to six month (that's how long it can take to get changes certified).
> > Given that different environments require different versions of both
> puppet
> > modules and application versions how do we handle this while still
> > guaranteeing system integrity?
> >
> > I'm in the process of trying out some other things, like the roles and
> > profiles pattern. Looking at the 'version' properties in my example
> below;
> > is it a good idea to keep it hardcoded and release a new version of the
> > puppet module for each version of the software (order_service in this
> case)
> > and assign those modules per environment or should I make the
> application
> > versions a hiera variable as well? And if I do decide to keep versions
> in
> > hiera how do I ensure that no-one (in ops) deploys a version that has
> not
> > been integration-tested with the rest of the system?
> >
> > Keeping versions in hiera would make everything much more dynamic but
> also
> > so much more difficult to ensure consistency, especially in a Continuous
> > Delivery workflow...
> >
> > Any takers? What obvious thing did I miss?
> >
> >
> > *Example*
> > class role::app_server {
> > include profile::base
> > include profile::linux
> > include profile::jboss
> > include profile::order_service::webapp
> > }
> >
> > class profile::order_service::webapp {
> > class { 'order_webapp'
> > version => '3.1.2',
> > db_address => hiera('db_address'),
> > etc...
> > }
> > }
> >
> > class profile::jboss {
> > class { 'jbosseap':
> > version => 6.3,
> > port => hiera('port'),
> > broadcast_address => hiera('broadcast_address'),
> > user_roles => hiera('user_roles'),
> > user_groups => hiera('user_groups')
> > }
> > class { 'java'
> > version => '>=1.7.0'
> > }
> > }
> >
> >
> > --
> > 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 [email protected] <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/puppet-users/06c4d567-6785-45ec-ae4a-8a41c236d2fe%40googlegroups.com.
>
>
> > For more options, visit https://groups.google.com/d/optout.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/01e92b60-bb02-4222-9fb3-f864b136c4b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
