Satellite version 6 with Puppet, git, Foreman, Katello, Pulp and Candlepin included - questions on using Puppet
Minor update 2/5/2015 - note the pdf files at the bottom of this original post, and included in the links here... Many folks added some good/relevant discussions as well.
UPDATED: More slides from the 2014 Red Hat Summit, Todd Warner/Thomas Cameron
I first heard of the use of deploying Puppet Manifests through one of the other people in the discussions here who goes by PixelDrift.NET. Then I came across this at this link that tacitly describes this.... Puppet is apparently very powerful and has a lot of merit, so in my reading I found this further descriptions of Puppet integration with Red Hat Satellite v6; Puppet Installation of Master and Client Components PDF FORMAT
Updated, this link is from the 2014 Red Hat Summit, Red Hat Satellite 6 Overview, Demo and Roadmap regarding these products being included with Red Hat Satellite 6.
This link is from the 2011 RH Summit, yet it contains some relevant info regarding the addition of:
- Puppet for Configuration
- Foreman for Provisioning
- Katello for Content/Life Cycle Management
- Pulp for Repo Management
- Candlepin for Subscription Management.
Puppet will likely be a welcome addition for PixelD (and others), and those of us not yet acquainted with it's use will get the opportunity to do so...
So I'm now interested in instantiating this, and perhaps a proper Puppet server in my test environment to learn it as well.
Does anyone have any idea on building custom manifests, perhaps not only for a more secure build addressing CVEs and other needed security issues, but also configuring server and workstation roles, or a good guide to build a Puppet server?
The discussion here can be wider than what I've introduced here...
Thanks,
Remmele
Aug 21st, 2014 - added the puppet guide for satellite 5/6 provided by Xixi D. mentioned in the comments below and also at https://access.redhat.com/articles/1138393
Attachments
Responses
Hi Remmele,
Before heading down the road of setting up a full Puppet environment (ie. server etc.), I would recommend getting the Puppet rpm's from the puppetlabs site (http://yum.puppetlabs.com/el/) and then creating a few manifests locally.
You can then apply them to the local server with
puppet apply manifest.file.pp
The contents of the manifest file is no different to those deployed from a central location and it is an easy way to get to know the structure of the files and what they are capable of. You can also run with:
puppet apply --noop manifest.file.pp
Which will show you what Puppet plans/intends to do without actually making any changes to the system (dry run).
If you want a starting point, here is an extremely basic manifest that will work locally:
package { "httpd":
ensure => installed
}
service { "httpd":
ensure => running,
enable => true,
require => [ Package["httpd"] ]
}
If you save this as httpd.pp and then run "puppet apply httpd.pp" it will install the httpd package for you, configure it to start on boot and ensure that it is running.
Output will look like:
Notice: Compiled catalog for build14.pixeldrift.net in environment production in 0.28 seconds
Notice: /Stage[main]/Main/Package[httpd]/ensure: created
Notice: /Stage[main]/Main/Service[httpd]/ensure: ensure changed 'stopped' to 'running'
Notice: Finished catalog run in 17.98 seconds
The documentation on the puppetlabs.com site is extensive. I think a good place to start getting an idea of capabilities is here: http://docs.puppetlabs.com/references/latest/type.html
The power of Puppet really gets unleashed when you integrate it with a revision control system (Puppetlabs uses git in their classroom sessions - sadly, it's not yet pre-integrated in Puppet Enterprise - maybe RH can do an uber-stack of Satellite+Puppet+Git?).
As far as evaluating Puppet goes, PuppetLabs uses a soft licensing model. While they typically want people using Puppet to manage more than 10 end-points to buy licensing, it's not actually enforced. The difference between the free and "Enterprise" version is the management interface under PE is much more refined and feature-complete (and "just works" right out of the box). If you grab PE, you'll get contacted by their sales team, but it's not high-pressure and stops quickly after you indicate you're using it for eval purposes.
I don't think Katello uses git for Puppet version control. Pulp has been extended recently to manage Puppet manifests.
Mightly impressive project so far. Liking the move to Foreman and Katello as an engine. Still many questions about how certain things are going to work, but development moves at a good pace.
For your security lockdown manifests, have a look at https://fedorahosted.org/aqueduct/
Not been there for a while, but there were a bunch of lockdown scripts and there was discussion about translating them to Puppet manifests.
There's also https://github.com/major/securekickstarts for performing much of the CIS lockdown during the kickstart phase rather than waiting until a machine is up and potentially vulnerable before you link it to Puppet and get the first puppet run completed successfully.
Cheers
D
Are you going to be at Summit? We have several demos and labs around Satellite 6. You will see hands on how Content Views can combine rpms and puppet modules into complete application stacks which you can manage. @Duncan Innes is correct, it is Pulp behind hte scenes. But, we have tools which will yank puppet modules out of git and push them into Satellite.
PuppetLabs offers a set of courses on basic administration and deployment of Puppet. Each course-installment is a week long. Each gives you a feel for different aspects of Puppet.
It's a very powerful and very flexible tool. However, like any enterprise-grade CM system and any tool that has the powerful/flexible characteristics, it's a non-trivial endeavor to get really solidly deployed. While it's quick to stand up and quick to get pieces talking to each other (gathering "facts", etc.), beginning to meaningfully realize its potential is a months-long project.
I was surprised to see that Puppet hasn't been included with RHEL 7, is Puppet going to be a Satellite specific inclusion? or is there a vision to include it in future RHEL 7 releases?
I was looking forward to having a Red Hat supported source for Puppet!
Is there any word on the version of Puppet that will be released with Satellite 6?
Not sure what you mean by "included in RHEL 7". Puppet is only semi opensource. While the dox indicate the Satellite uses Puppet, I didn't see it detailed whether they were including a version of PE or including a Red Hat packaged version of the open platform. If the former, then part of what you're paying Red Hat for is the licensing costs for PE.
I'd have to assume that you get the Puppet client components if you buy Satellite 6, regardless of version. Support of the agents would come through the support of Satellite 6. Just throwing Puppet agent RPMs out there doesn't really make sense to do, from a vendor standpoint, if they're not part of the larger paid solution (i.e., why assume the liability of supporting Puppet client software if you're not getting paid for the Puppet master software).
Puppet is opensouce (originally GPL, now Apache 2.0), the Puppet Enterprise product built on Puppet is not.
What I mean by 'included' is included in the base packages or in the extras repository (both puppet and puppet-server components, not just the 'agent').
As I have mentioned in this thread you can use Puppet in standalone (masterless) mode or directed by a Puppet Master (which is also opensource/free). I personally think there would be benefit in providing the Puppet packages for the RHEL 7 platform so RHEL users can run them in masterless mode or setup their own master/client configuration completely aside from integration in Satellite.
As for the Summit.. I saw the slide deck you have posted, and I also saw the Satellite 6 video presentation, the question of version + inclusion in RHEL 7 isn't really answered. Version is important for manifest compatibility, but based on the release date I am going to assume 3.x.
Currently, I have environments consuming PE for the support aspect (as well as the PE product), I was hoping (fingers crossed) to have support of the Puppet base components (without PE) provided by Red Hat (ie. errata/patch releases, distribution) as they had Puppet on their wider product roadmap.
Cheers.
Instructions for setting up basic Puppet / Puppet Master here (no PE or closed licensed component required):
http://projects.puppetlabs.com/projects/1/wiki/simplest_puppet_install_pattern
Description of opensource offering here:
http://puppetlabs.com/puppet/puppet-open-source
Yes, I'm aware that Puppet is OSS. It's more a question of what overriding interest does RedHat have in making it a supported component of RHEL outside of the context of customers that are paying for Satellite 6? If anything, doing so has a negative incentive for them as they're enabling potential Satellite customers to have a supported CM solution without buying Satellite to run it. Further, if Satellite 6 packages PE, maintaining supported RPMs for both the open and PE versions has an even more spurious business-case.
Your previous comment included "Puppet is only semi opensource." which is what I was responding to.
Red Hat's model/approach may have been to provide Puppet for CM, and then Satellite as the 'value add' for managing the complete lifecycle/version control/subscription management in the same way that Puppet Labs provide Puppet open source for CM and PE for lifecycle/reporting etc.
Following the same logic, what is their interest in including/supporting Docker in RHEL if they are going to sell the Atomic host product? Why do they include/support KVM in RHEL if they sell RHEV?
I was of the understanding that their interest was in providing flexibility and features to paying enterprise customers.
If you want specific details of Puppet versions etc in Katello/Satellite 6, they're best asked on the Google Groups for Foreman. Just put a "[katello]" at the front of the subject.
https://groups.google.com/forum/#!forum/foreman-users
and
https://groups.google.com/forum/#!forum/foreman-dev
We're already using Puppet 3.6.1 on our estate and are certainly hoping that there's no backwards step when Satellite 6 rolls out. Foreman is at 1.5.0 and just keeps getting better. Will know much more about Satellite 6 when the next drop of Katello comes out (perhaps the next phase of the MDP).
Cheers
Duncan
Cheers Duncan.
I have been following Foreman fairly closely (Katello not so much) and am really impressed with the product maturity with Foreman 1.5. I am interested to know if Satellite 6 forked from Katello/Foreman/Puppet at specific versions (to sure up stability) or if they are rolling with the latest versions until formal release... I guess that's a wait and see!
I find it interesting that both Katello and Foreman offer Puppet installation methods, which re-iterates my point about the usefulness of including Puppet packages in the base RHEL.
Will add Katello to my reading list.. really wish they had a more descriptive rundown of capabilities and implementation on their website... keen to see the ENC for Puppet up and running.. are you using this?
I notice you are quite active in the group and have mentioned an active deployment... are you running that in parallel to Satellite? or to replace/phase Satellite out?
Great!.. and Puppet will be...
Thanks Bryan.
The Roadmap http://rhsummit.files.wordpress.com/2014/04/caplan_t_0330_red_hat_satellite_6_overview_roadmap__demo.pdf says that MCollective is planned to be added in Satellite 6.1, early 2015 as of that slideset.
I think it's an unfortunate choice to restrict the Beta program to subscribers of the Satellite product, but understandable.
I look forward to hearing what others have to say, and what improvements / benefits there are over an opensource install over TheForeman + Katello.
Has anyone deployed Sat 6 beta yet?
More efficient and flexible tables would be a help.
1920x1200 24" monitor - tables have a large blank space on the left and right. They are also pretty wasteful of space, with only around a dozen lines visible on a maximised browser window. Can the padding be reduced to allow more on the screen?
Variable width columns, show/hide different columns etc. would be great too.
Functionally though, looking great for a Beta.
D
Nothing is what I'd call offensive - it's just I can end up with very little information on my 24" screen compared to the similar screen from Satellite 5.6.
Example: using the Hosts page, I can get as few as 12 rows on the screen because the right most column gets wrapped to 2 lines (I forget numbers now, but I think Satellite 5.6 shows around 30 lines in the System view page). The table also only occupies the central 2/3 of the page, leaving large white space at the left & right.
The filters on the host screen are certainly going to be a huge help, but it's also really useful to see loads of hosts & data on a single page so the user can scan down columns to see differences. Being able to choose which columns are visible and re-order them would also be a great help.
All tables seem to suffer from the width issue. The top and bottom padding for each cell tends to make each row twice the height of the data contained within it.
They're all pretty minor niggles, but I just feel that the screen real estate isn't being used to best effect at this point. The engine underneath is way better than Satellite 5.x, but I'm seeing less on my screen (sometimes that's not bad admittedly!).
Pages
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
