Developers having access to deploy

[Thomas Rasmussen]

Hi

I'm in the process of looking for a way to have developers deploying
on their test systems without intervention of sysadmins, to solve this
i'd like to use Puppet (either the OSS version or Enterprise,
whichever solves the problem).

I can manage to only grant access to certain systems and limit the
ability to execute puppetd --test, however, the developers would like
to create a new version of the application and then this should be put
into place instead of the old version, but I can't seem to find a
solution to this.

I was thinking somewhat on the option to issue a command like this:
puppetd --test --my-app-version 3.2.1

And then the puppet manifests will use the my-app-version variable to
fetch and deploy this specific version. I know that the manifests
should be developed with care, which is also the idea.

Or what solutions do people use in case where developers should have
access to deploy, but not have access to the puppetmaster server?

hope that this can be done.

Regards
Thomas

[Jos Houtman]

Hi,

For deployment we do not usually use puppet. The deployment we do with are puppet are for stable in house packages.

This is then done by releasing a new version in our package environment and utilizing  ensure => latest for the package type.

But for frequent deployment methods I would personally look towards other means of deployment.

We are currently utilizing the python fabric library for deployments.

Jos

[JasonAntman]

We haven't actually done this in production yet, but we've discussed
it quite a bit. Our current theory for things like this is:

1) MySQL-based External Node Classifier. Developers get
(authenticated, ACL'ed) access to a simple PHP script with two
options: a dropdown list of modules for their app (i.e. myapp_v1,
myapp_v2, etc.), and a link that triggers a puppet run on the client
(via the API call used by "puppet kick").

The lab42 examples make use of their "puppi" tool, but our theory was
based on us having to approve modules (or at least review them), and
explicitly add them to the list of options for a given app.

Another, simpler option would be to store your manifests/modules in
SVN, and grant developers read/write access to certain paths. If you
don't want to mess with an authenticated interface to trigger client
runs, you could just grant them sudo access to a script that triggers
the run.

Of course, all of this is making two pretty large assumptions: 1) that
you're using a puppet master, and it's also used for stuff more
critical than this, and 2) you're using Puppet to manage the entire
systems (or at least stuff other than the app deployment)

I know many here may disagree with me, but I'd say that if you're
intending to use Puppet to manage just the app deployment (not the
whole system build/provisioning, or at least other components), you
can probably find a better/easier solution.

-Jason

On Mar 2, 4:42 am, Thomas Rasmussen <rasmussen.tho...@gmail.com>
wrote:

[Adam Heinz]

We do something similar to what you describe with foreman (which can
be used as an ENC). The user sets the my-app-version parameter on the
node, then runs puppet on that node. The main drawback is that
foreman does not currently have a permission for puppetrun, so the
users have to be admins, so I have a test puppet master for this
purpose.

[Brian Gallew]

I did up a nifty deployment engine using Jenkins.  Give the devs/CM a form (e.g. "silo", application versions, etc).  It would figure out what it needed to deploy and then do so, complete with telling the Nagios system to disable checks while everything was going on.  Foreman/Puppet could be the right tool for a *production* environment, particularly if your applications can be deployed piecemeal, but doing it for dev seems like it would add increased overhead without any real benefit.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Thomas Rasmussen]

Thanks for the replies, I can see that there is no "easy" setup to allow what I'm looking for :-( I will be looking a bit more on the External Node Classifier to see if this will solve my problem.

We will be using puppet to fully automate everything that has to be performed on servers, so I will not be interested in using a different system to do the app-deployment than to do the OS deployment. 

I was hoping that maybe it was possible to do this task through the Dashboard, but I discovered that it was only a standard htpassword setup without any group knowledge or ACLs on nodes.

Thomas

On Friday, March 2, 2012 10:42:28 AM UTC+1, Thomas Rasmussen wrote:

[Chuck Anderson]

Check out InstantLinux as a front-end to puppet:

http://www.instantlinux.net/

[Craig White]

On Mar 5, 2012, at 11:51 PM, Thomas Rasmussen wrote:

> Thanks for the replies, I can see that there is no "easy" setup to allow what I'm looking for :-( I will be looking a bit more on the External Node Classifier to see if this will solve my problem.
>
> We will be using puppet to fully automate everything that has to be performed on servers, so I will not be interested in using a different system to do the app-deployment than to do the OS deployment.
>
> I was hoping that maybe it was possible to do this task through the Dashboard, but I discovered that it was only a standard htpassword setup without any group knowledge or ACLs on nodes.

----
theforeman has a fairly sophisticated users/groups/roles and also servers can 'belong' to individual users and would probably give you everything you want including a very useful ENC

Craig

[Thomas Rasmussen]

Seems as though instantlinux is deploy'ing a customized OS, however we are dealing with mix of different OS'es (This has to work at least on Linux and Solaris), so doesn't seem like an option

Thomas