I've seen various reports of people using tools like puppet and chef for deploying systems. I'm looking at setting up some scripts to create test images for Debian. The main use will be for testing SE Linux so I can test all the combinations of daemons that the policy should support. But I also plan to publish them for the benefit of other people. What system do you recommend for creating such images? Puppet? Chef? Something else? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
At work I use puppet master/agent to manage the configuration of our machines, at home I use master-less "puppet apply". I've never had any problems with either. Alternatively, have you looked at packer.io and/or vagrant if all you are after is configured image generation? Ashley On 3 August 2016 at 13:10, Russell Coker via luv-main <luv-main@luv.asn.au> wrote:
I've seen various reports of people using tools like puppet and chef for deploying systems.
I'm looking at setting up some scripts to create test images for Debian. The main use will be for testing SE Linux so I can test all the combinations of daemons that the policy should support. But I also plan to publish them for the benefit of other people.
What system do you recommend for creating such images? Puppet? Chef? Something else?
-- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
On 3 August 2016 1:10:05 PM AEST, Russell Coker via luv-main <luv-main@luv.asn.au> wrote:
I've seen various reports of people using tools like puppet and chef for deploying systems.
I'm looking at setting up some scripts to create test images for Debian. The main use will be for testing SE Linux so I can test all the combinations of daemons that the policy should support. But I also plan to publish them for the benefit of other people.
What system do you recommend for creating such images? Puppet? Chef?
I've used puppet a fair bit for systems and VMs... But it does require puppet installed in the system in question, and possibly a puppet master et Al. I've heard that ansible does similar things but is agentless, it just uses ssh to run commands.
On Wednesday, 3 August 2016 1:10:05 PM AEST Russell Coker via luv-main wrote:
What system do you recommend for creating such images? Puppet? Chef?
We've been using Puppet for infrastructure VMs but now migrating to using Salt instead. https://saltstack.com/ Our clusters continue to use xCAT, but they're all RHEL based. http:// xcat.org/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Wed, 3 Aug 2016, Chris Samuel wrote:
On Wednesday, 3 August 2016 1:10:05 PM AEST Russell Coker via luv-main wrote:
What system do you recommend for creating such images? Puppet? Chef?
We've been using Puppet for infrastructure VMs but now migrating to using Salt instead. https://saltstack.com/
Salt eh? I'm reminded of this -- p6 on: http://sysadmin.miniconf.org/2016/lca2016-martin_krafft-ssh_botnet.pdf
Our clusters continue to use xCAT, but they're all RHEL based. http:// xcat.org/
Just don't use Bright Cluster Manager. Don't ask me how I know to give you this anti-recommendation. But stay away from golden image based deployments anyway. Start of with a kickstart, FAI etc based deployment, followed by configuration managing an installation of a known set of packages with a known set of configuration changes. Anything else will result in you asking WTF you installed 5 years ago that you now can't repeat because dozens of people have come in in the meantime and made random changes in random places (including the image that started getting deployed 3 years and 2 months ago, but only when deployed from datacentre C) without documenting anything (and that includes all of your own personalities and drunken states). -- Tim Connors
On Wed, Aug 03, 2016 at 06:42:59PM +1000, Tim Connors via luv-main wrote:
result in you asking WTF you installed 5 years ago that you now can't repeat because dozens of people have come in in the meantime and made random changes in random places (including the image that started getting
been there :-/ not sure that's unique to golden image deployments. pretty sure any system can end up like that... we put oneSIS master OS images into git, so changes are obvious. if folks write good commit messages then even 'why' can be clear. cheers, robin
Robin Humble via luv-main <luv-main@luv.asn.au> wrote:
been there :-/ not sure that's unique to golden image deployments. pretty sure any system can end up like that...
I use etckeeper to track configuration changes under the /etc hierarchy in a Git repository. If that's valuable in your usage scenario, you can obviously install etckeeper and Git in the image that you plan to deploy (perhaps even with the deployed configuration already committed).
On Fri, Aug 05, 2016 at 03:58:37PM -0400, Jason White via luv-main wrote:
Robin Humble via luv-main <luv-main@luv.asn.au> wrote:
been there :-/ not sure that's unique to golden image deployments. pretty sure any system can end up like that... I use etckeeper to track configuration changes under the /etc hierarchy in a Git repository.
I've tried just keeping /etc in git, but I found it's helpful to track package changes as well as /var, /root, kernel and... at that point I figured I may as well just track everything. there's always a lot of spam and churn from eg. /var/cache and /var/lib/rpm but it's pretty easy to just git commit that as "cruft" or "yum updates" :)
If that's valuable in your usage scenario, you can obviously install etckeeper and Git in the image that you plan to deploy (perhaps even with the deployed configuration already committed).
there is only one image in the oneSIS system and the whole of the single image is in git, so everything is already tracked. oneSIS 101 is that all nodes run an idential image. so there's not really a separate deployed image or deployed config. all nodes boot to one read-only (usually NFS or Lustre) root image and then small oneSIS tools set up all the differences between nodes as they boot or after you change the live image. oneSIS isn't for everyone - it's mainly for "100's of similar nodes". so the one problem I've had with "everything in git" is the particular set of git hooks to store permissions and ownerships that come with oneSIS can screw up if you ever try to revert or checkout an old revision of the OS. I haven't ever bothered to try and fix it. I just go linearly forward and treat git like a logging system and something that I can use to do 'git log' and 'git diff' against. so it's far from using the full power of git, but it's still great. cheers, robin
On Wed, Aug 3, 2016 at 6:42 PM, Tim Connors via luv-main
But stay away from golden image based deployments anyway. Start of with a kickstart, FAI etc based deployment, followed by configuration managing an installation of a known set of packages with a known set of configuration changes. Anything else will result in you asking WTF you installed 5 years ago that you now can't repeat because dozens of people have come in in the meantime and made random changes in random places
Agreed. The only problem I see: This is not widely excepted and you end up with a lot of frustration if you try. Automation has to be understood from management so considered if it comes to decision making and establishing processes. It also has to be understood by your colleagues. I failed miserably in "Germanizing" systems when I was explicitly hired by a former co-worker to do so (his terminology;-). I was unable to achieve much because it was like cleaning a shared house where only one person does the dishes. These environments are best off with backing up and copying images because there is no way to explain how to install it from scratch (without having nasty surprises). They still end up with scaling problems because even minor changes can have weird side-effects. (E.g. because there are IP addresses buried in /where/this/app/lives/config/system.xml) Regards Peter
On 3 August 2016 at 13:10, Russell Coker via luv-main <luv-main@luv.asn.au> wrote:
I've seen various reports of people using tools like puppet and chef for deploying systems.
I'm looking at setting up some scripts to create test images for Debian. The main use will be for testing SE Linux so I can test all the combinations of daemons that the policy should support. But I also plan to publish them for the benefit of other people.
What system do you recommend for creating such images? Puppet? Chef? Something else?
I've seen the current competing configuration management tools referred to as CAPS. The CAPS are Chef, Ansible, Puppet and SaltStack. CFEngine is apparently still a contender too, but I haven't seen it used much, and haven't touched it in over ten years. I assume it's become more user-friendly in the meantime.. If you want to compare the different syntaxes, I have a repo with some configs for each of the CAPS running in standalone mode (i.e. no master). https://github.com/furlongm/standalone-configuration-management To answer your original question though, I would probably also use packer to create the images. Packer has provisioners for local shell scripts, and also all four of the configuration management tools mentioned above: https://www.packer.io/docs/provisioners/shell-local.html https://www.packer.io/docs/provisioners/chef-solo.html https://www.packer.io/docs/provisioners/ansible-local.html https://www.packer.io/docs/provisioners/puppet-masterless.html https://www.packer.io/docs/provisioners/salt-masterless.html Cheers, Marcus.
participants (10)
-
Andrew Pam -
Ashley Baumann -
Chris Samuel -
Jason White -
Marcus Furlong -
Peter Ross -
Robin Humble -
Russell Coker -
Stewart Smith -
Tim Connors