Discussion:
[ale] Puppet vs chef vs ansible vs ???
Edward O. Holcroft via Ale
2017-11-17 14:22:59 UTC
Permalink
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.

"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.

I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?

ed
--
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
leam hall
2017-11-18 21:40:42 UTC
Permalink
Ansible is one rpm, some reading, and ssh keys everywhere. I've done Chef,
Puppet, and Ansible and find the latter the simplest. Skip "Ansible Tower"
until you find a need for it.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Derek Carter
2017-11-18 21:41:48 UTC
Permalink
Ansible if you want easy.
Puppet if you have compliance needs.
Chef if you bleed Ruby.
Salt if you didn't try Ansible first.
And CFEngine if you like pain.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
leam hall
2017-11-18 21:43:55 UTC
Permalink
I find Ansible more compliance oriented. Puppet the company didn't seem to
understand why config directories and files shouldn't be 0777.
Post by Derek Carter
Ansible if you want easy.
Puppet if you have compliance needs.
Chef if you bleed Ruby.
Salt if you didn't try Ansible first.
And CFEngine if you like pain.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Derek Carter
2017-11-18 22:31:09 UTC
Permalink
When I speak to compliance I mean the large industry that has sprung up
around puppet. Your audit capability goes up if there is tooling around
your tool.
Post by leam hall
I find Ansible more compliance oriented. Puppet the company didn't seem to
understand why config directories and files shouldn't be 0777.
Post by Derek Carter
Ansible if you want easy.
Puppet if you have compliance needs.
Chef if you bleed Ruby.
Salt if you didn't try Ansible first.
And CFEngine if you like pain.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet
thing ... been putting off learning about ti for way too long. So where's
the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets
2017-11-20 13:13:08 UTC
Permalink
+1 here. PuppetConf (just a month ago) covered a LOT of compliance topics. Add to that the introduction of new tools like Chef’s knife (Bolt) and hierarchical lookup with Hiera (not available in Data Bags or in Ansible’s offerings) and it’s hard to compare.

-j
When I speak to compliance I mean the large industry that has sprung up around puppet. Your audit capability goes up if there is tooling around your tool.
I find Ansible more compliance oriented. Puppet the company didn't seem to understand why config directories and files shouldn't be 0777.
Ansible if you want easy.
Puppet if you have compliance needs.
Chef if you bleed Ruby.
Salt if you didn't try Ansible first.
And CFEngine if you like pain.
I have just started looking into automation with Puppet. Before I go too far down the rabbit I was hoping to get the opinions on this list about the best tool to use. I have a basic puppet server running, but am still not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with automation". I don't need the most powerful or most awesome tool, my environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing ... been putting off learning about ti for way too long. So where's the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This message may be confidential and/or privileged. If you are not the intended recipient, please notify the sender immediately then delete it - you should not copy or use it for any purpose or disclose its content to any other person. Internet communications are not secure. You should scan this message and any attachments for viruses. Any unauthorized use or interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale <http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo <http://mail.ale.org/mailman/listinfo>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale <http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo <http://mail.ale.org/mailman/listinfo>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale <http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo <http://mail.ale.org/mailman/listinfo>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets
2017-11-20 13:09:26 UTC
Permalink
I find Ansible more compliance oriented. Puppet the company didn't seem to understand why config directories and files shouldn't be 0777.
Leam, this is incorrect. There is no directive in PE or P FOSS that requires 0777 anywhere. Further, enforcement standards meet C2. You and I have had this very discussion. Even further, DoD has selected Puppet for ops, mil, and several agency components (DHS, FDA, etc.)

Could you give examples?


—j
leam hall
2017-11-20 13:25:15 UTC
Permalink
Hey Jerald, it is correct. Or was as of a couple years ago when we opened a
ticket with PuppetLabs. Can't recall the exact directory but it had to be
world readable. Maybe that's changed.

What I have found is that Ansible as a community is more aware of STIG type
needs than PuppetLabs was. Red Hat recommende the Mind Point Group's STIG
playbook; it takes a vanilla RHEL box with the right filesystem layout from
mid-60's to just over 90% measured by SCC 5.0. That said, the Ansible
community isn't as talkative either.

Having done both I would choose Ansible for my needs. Everyone's needs may
differ.
Post by leam hall
I find Ansible more compliance oriented. Puppet the company didn't seem
to understand why config directories and files shouldn't be 0777.
Leam, this is incorrect. There is no directive in PE or P FOSS that
requires 0777 anywhere. Further, enforcement standards meet C2. You and I
have had this very discussion. Even further, DoD has selected Puppet for
ops, mil, and several agency components (DHS, FDA, etc.)
Could you give examples?
—j
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets
2017-11-20 13:47:02 UTC
Permalink
Hey Jerald, it is correct. Or was as of a couple years ago when we opened a ticket with PuppetLabs. Can't recall the exact directory but it had to be world readable. Maybe that's changed.
There was a bug filed a couple years ago that after resolution changed the directory perms for a single directory
 location escapes me now
 but that’s long since been resolved.
What I have found is that Ansible as a community is more aware of STIG type needs than PuppetLabs was. Red Hat recommende the Mind Point Group's STIG playbook; it takes a vanilla RHEL box with the right filesystem layout from mid-60's to just over 90% measured by SCC 5.0. That said, the Ansible community isn't as talkative either.
The NSA has selected Puppet for their needs recently, and has written a HOST of code around STIG compliance. They’re also aggressively contributing to the community now.

https://puppet.com/resources/whitepaper/continuous-stig-enforcement-puppet-enterprise-and-nsa-modules <https://puppet.com/resources/whitepaper/continuous-stig-enforcement-puppet-enterprise-and-nsa-modules>

I’m happy to have them, but keep one eye peeled in their direction
 LOL.
Having done both I would choose Ansible for my needs. Everyone's needs may differ.
Why not both?

:D



—j
Ryan Spencer
2017-11-21 01:50:02 UTC
Permalink
I've used Chef for configuration management and recently started using
Ansible for some task automation/orchestration. Since then, I've been
pretty impressed with Ansible.

Pros for Ansible:
- Really easy to get started with.
- No agent to install on nodes. It works over SSH or WinRM on Windows.
- Great documentation.
- Ansible playbooks (scripts) are written in YAML, which is simple to learn
and very readable.
- RedHat recently published the open-source version of Ansible Tower,
called AWX. I've been using Jenkins as a web front-end for Ansible so I
haven't tried this yet.

-Ryan Spencer
Post by leam hall
Hey Jerald, it is correct. Or was as of a couple years ago when we opened
a ticket with PuppetLabs. Can't recall the exact directory but it had to be
world readable. Maybe that's changed.
There was a bug filed a couple years ago that after resolution changed the
directory perms for a single directory
 location escapes me now
 but that’s
long since been resolved.
What I have found is that Ansible as a community is more aware of STIG
type needs than PuppetLabs was. Red Hat recommende the Mind Point Group's
STIG playbook; it takes a vanilla RHEL box with the right filesystem layout
from mid-60's to just over 90% measured by SCC 5.0. That said, the Ansible
community isn't as talkative either.
The NSA has selected Puppet for their needs recently, and has written a
HOST of code around STIG compliance. They’re also aggressively
contributing to the community now.
https://puppet.com/resources/whitepaper/continuous-stig-
enforcement-puppet-enterprise-and-nsa-modules
I’m happy to have them, but keep one eye peeled in their direction
 LOL.
Having done both I would choose Ansible for my needs. Everyone's needs may differ.
Why not both?
:D
—j
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
James Sumners
2017-11-18 21:59:45 UTC
Permalink
Ansible. What takes three weeks to do in Puppet takes 30 minutes with
Ansible. I manage >=150 systems with Ansible no problem.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
Edward O. Holcroft via Ale
2017-11-19 01:22:57 UTC
Permalink
​Thanks for all the comments. In playing around with Puppet and Ansible
over the last few days I certainly found Ansible to be more agreeable​ to
just getting running and basic tests working.

So based on the general feeling here, I'm jumping into Ansible and will see
where the rabbit hole leads. I was able to get AWX "almost" working with a
Docker container that somebody has built. But I think for now I will take
Leam's advice and skip Tower/AWX and focus on getting Ansible working.

cheers
ed



_________________________________________

*Edward O. Holcroft*
IT Operations Manager

*Madsen, Kneppers & Associates, Inc.*
Construction Consultants & Engineers
11695 Johns Creek Parkway, Suite 250
Johns Creek, GA 30097

*O* 770.446.9606 | *F* 770.446.9612 | *C* 770.630.0949 |
***@mkainc.com

www.mkainc.com
Post by James Sumners
Ansible. What takes three weeks to do in Puppet takes 30 minutes with
Ansible. I manage >=150 systems with Ansible no problem.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.______________________
_________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
--
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
Jerald Sheets
2017-11-20 13:10:33 UTC
Permalink
Ansible. What takes three weeks to do in Puppet takes 30 minutes with Ansible. I manage >=150 systems with Ansible no problem.
I manage over a quarter million nodes in Puppet, and while your experience may differ, this is misinformation. We use both. Ansible for orchestration, Puppet for configuration.

—j
James Sumners
2017-11-20 13:24:34 UTC
Permalink
No, it isn't misinformation. It is a very literal representation of my
experience with both. After three frustrating weeks of attempting to figure
out the Puppet garbage, and getting absolutely nowhere, I read the Ansible
introduction and had the exact same test done in less than an hour.
Post by James Sumners
Post by James Sumners
Ansible. What takes three weeks to do in Puppet takes 30 minutes with
Ansible. I manage >=150 systems with Ansible no problem.
I manage over a quarter million nodes in Puppet, and while your experience
may differ, this is misinformation. We use both. Ansible for
orchestration, Puppet for configuration.
—j
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
DJ-Pfulio
2017-11-21 12:32:13 UTC
Permalink
Puppet was the early winner. Now it feels like picking MSFT solutions.
Nobody gets fired for going with the most popular solution. You'll
always be employed, but might hate it.

Ansible is like Unix. The simplest solution that solves the problem.
It builds on things you already know. No "magic" directories to
memorize (cough Chef). Things work off relative paths, which any admin
would already understand. Since the beginning, the order of
instructions/tasks was never a question (cough puppet).

I attended 4 hrs of Chef training at SELF a few years ago. When they
started talking about "magic locations", I left.

I attended a Puppet Labs day at GA-Tech a few years ago. About 250
others were there too. During the keynote, the speaker asked how many
people were using Puppet to manage their environment 100% - 4 people in
the far left raised their hands. Nobody else.

My personal experience with small scale stuff is that puppet is worse
than my carefully crafted ssh scripts to manage systems. Chef seems to
be similarly complex. At the time, both puppet and Chef required me to
install ruby on every node. That was a non-starter. I like ruby (the
language), but putting ruby on an email gateway seems foolish. Actually,
I don't want python or perl on that machine either, but the small OS
installs use those for scripting, so there isn't a choice.

Ansible didn't require that I learn/solved 20 new problems to work. I
was managing systems, building them out just post-install, quickly. I
started by managing /etc/hosts files as my first learning exercise.
Took about 30 minutes to get that done from knowing ZERO about ansible
except that it worked over ssh.

I can see where experts in each of these tools would be very efficient.
But for a small shop with zero budget for outside experts, Ansible wins
immediately. For puppet consultants, of course you want puppet
everywhere. I want Linux everywhere too, but most of us here have the
Linux expertise already so it isn't a huge unknown.

This can easily be a religious war. Use what works for your needs. If
you are a chef consultant, push chef. Same for puppet. I'm certain both
those tools have addressed the issues that were common when I looked at
them 4+ yrs ago - too late. Found ansible. Happy.

I found Ansible to be the simplest solution for my needs, like many
others here.
Post by James Sumners
No, it isn't misinformation. It is a very literal representation of my
experience with both. After three frustrating weeks of attempting to
figure out the Puppet garbage, and getting absolutely nowhere, I read
the Ansible introduction and had the exact same test done in less than
an hour.
Ansible. What takes three weeks to do in Puppet takes 30 minutes with Ansible. I manage >=150 systems with Ansible no problem.
I manage over a quarter million nodes in Puppet, and while your
experience may differ, this is misinformation.  We use both. 
Ansible for orchestration, Puppet for configuration.
—j
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
<http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
<http://mail.ale.org/mailman/listinfo>
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Got Linux? Used on smartphones, tablets, desktop computers, media
centers, and servers by kids, Moms, Dads, grandparents and IT
professionals.
Jim Kinney
2017-11-21 13:15:44 UTC
Permalink
Bash scripts over ssh. Nothing says "my network and server farm" like customs solutions for specific problems. Add a custom pack of cool tools on a server build out.
Post by DJ-Pfulio
Puppet was the early winner. Now it feels like picking MSFT solutions.
Nobody gets fired for going with the most popular solution. You'll
always be employed, but might hate it.
Ansible is like Unix. The simplest solution that solves the problem.
It builds on things you already know. No "magic" directories to
memorize (cough Chef). Things work off relative paths, which any admin
would already understand. Since the beginning, the order of
instructions/tasks was never a question (cough puppet).
I attended 4 hrs of Chef training at SELF a few years ago. When they
started talking about "magic locations", I left.
I attended a Puppet Labs day at GA-Tech a few years ago. About 250
others were there too. During the keynote, the speaker asked how many
people were using Puppet to manage their environment 100% - 4 people in
the far left raised their hands. Nobody else.
My personal experience with small scale stuff is that puppet is worse
than my carefully crafted ssh scripts to manage systems. Chef seems to
be similarly complex. At the time, both puppet and Chef required me to
install ruby on every node. That was a non-starter. I like ruby (the
language), but putting ruby on an email gateway seems foolish.
Actually,
I don't want python or perl on that machine either, but the small OS
installs use those for scripting, so there isn't a choice.
Ansible didn't require that I learn/solved 20 new problems to work. I
was managing systems, building them out just post-install, quickly. I
started by managing /etc/hosts files as my first learning exercise.
Took about 30 minutes to get that done from knowing ZERO about ansible
except that it worked over ssh.
I can see where experts in each of these tools would be very efficient.
But for a small shop with zero budget for outside experts, Ansible wins
immediately. For puppet consultants, of course you want puppet
everywhere. I want Linux everywhere too, but most of us here have the
Linux expertise already so it isn't a huge unknown.
This can easily be a religious war. Use what works for your needs. If
you are a chef consultant, push chef. Same for puppet. I'm certain both
those tools have addressed the issues that were common when I looked at
them 4+ yrs ago - too late. Found ansible. Happy.
I found Ansible to be the simplest solution for my needs, like many
others here.
Post by James Sumners
No, it isn't misinformation. It is a very literal representation of
my
Post by James Sumners
experience with both. After three frustrating weeks of attempting to
figure out the Puppet garbage, and getting absolutely nowhere, I read
the Ansible introduction and had the exact same test done in less
than
Post by James Sumners
an hour.
On Nov 18, 2017, at 4:59 PM, James Sumners
Ansible. What takes three weeks to do in Puppet takes 30
minutes with Ansible. I manage >=150 systems with Ansible no problem.
Post by James Sumners
I manage over a quarter million nodes in Puppet, and while your
experience may differ, this is misinformation.  We use both. 
Ansible for orchestration, Puppet for configuration.
—j
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
<http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
<http://mail.ale.org/mailman/listinfo>
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Got Linux? Used on smartphones, tablets, desktop computers, media
centers, and servers by kids, Moms, Dads, grandparents and IT
professionals.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
DJ-Pfulio
2017-11-21 13:30:11 UTC
Permalink
The problem with this is shared work. Only you and your small team know
your scripts. When you leave, I bet the next guy will re-work everything
- perhaps using a DevOPS tool.

With those tools, there are multiple repos with pre-existing solutions.
Need WP, apache, and mariaDB ... pull the playbooks from github. They
might not be perfect for your environment, but they will work. On
Cent/RHEL, they install, enable, setup the services and open the
firewall port(s) where needed. Fewer chances to forget those tiny
config settings.

It also means that the next guy will hit the ground running, effectively
zero spin-up time to start working with the devops tool. THAT is the
real power. When I see an ansible setup, since most are following the
same "best practices", there is a huge, existing, understanding, for
where and how things work. Your scripts that call scripts and call
scripts - not so much.
Bash scripts over ssh. Nothing says "my network and server farm" like
customs solutions for specific problems. Add a custom pack of cool tools
on a server build out.
Puppet was the early winner. Now it feels like picking MSFT solutions.
Nobody gets fired for going with the most popular solution. You'll
always be employed, but might hate it.
Ansible is like Unix. The simplest solution that solves the problem.
It builds on things you already know. No "magic" directories to
memorize (cough Chef). Things work off relative paths, which any admin
would already understand. Since the beginning, the order of
instructions/tasks was never a question (cough puppet).
I attended 4 hrs of Chef training at SELF a few years ago. When they
started talking about "magic locations", I left.
I attended a Puppet Labs day at GA-Tech a few years ago. About 250
others were there too. During the keynote, the speaker asked how many
people were using Puppet to manage their environment 100% - 4 people in
the far left raised their hands. Nobody else.
My personal experience with small scale stuff is that puppet is worse
than my carefully crafted ssh scripts to manage systems. Chef seems to
be similarly complex. At the time, both puppet and Chef required me to
install ruby on every node. That was a non-starter. I like ruby (the
language), but putting ruby on an email gateway seems foolish. Actually,
I don't want python or perl on that machine either, but the small OS
installs use those for scripting, so there isn't a choice.
Ansible didn't require that I learn/solved 20 new problems to work. I
was managing systems, building them out just post-install, quickly. I
started by managing /etc/hosts files as my first learning exercise.
Took about 30 minutes to get that done from knowing ZERO about ansible
except that it worked over ssh.
I can see where experts in each of these tools would be very efficient.
But for a small shop with zero budget for outside experts, Ansible wins
immediately. For puppet consultants, of course you want puppet
everywhere. I want Linux everywhere too, but most of us here have the
Linux expertise already so it isn't a huge unknown.
This can easily be a religious war. Use what works for your needs. If
you are a chef consultant, push chef. Same for puppet. I'm certain both
those tools have addressed the issues that were common when I looked at
them 4+ yrs ago - too late. Found ansible. Happy.
I found Ansible to be the simplest solution for my needs, like many
others here.
No, it isn't misinformation. It is a very literal representation of my
experience with both. After three frustrating weeks of attempting to
figure out the Puppet garbage, and getting absolutely nowhere, I read
the Ansible introduction and had the exact same test done in less than
an hour.
On Nov 18, 2017, at 4:59 PM, James Sumners
Ansible. What takes three weeks to do in Puppet takes 30
minutes with Ansible. I manage >=150 systems with Ansible no
problem.
I manage over a quarter million nodes in Puppet, and while your
experience may differ, this is misinformation.  We use both. 
Ansible for orchestration, Puppet for configuration.
—j
------------------------------------------------------------------------
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
<http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
<http://mail.ale.org/mailman/listinfo>
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
------------------------------------------------------------------------
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Sent from my Android device with K-9 Mail. All tyopes are thumb related
and reflect authenticity.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Got Linux? Used on smartphones, tablets, desktop computers, media
centers, and servers by kids, Moms, Dads, grandparents and IT
professionals.
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/li
Jim Kinney
2017-11-21 14:28:13 UTC
Permalink
We have things that are often highly customised. The broad-scale roll out is already simple enough. I have a few custom tools for "splat an new package across the computation cluster" and "give me a quick health report". Other tools are "security update across all outward facing systems for ssh/ssl" and "run all security updates now and restart everything that uses the updated packages".

Yes. Could use chef, puppet, spacewalk, ansible, "next cool tool here", but I prefer to build my own toolchain tailored specifically for the environment I have. The beginning and end points are the same, only the middle is different. I've tinkered with several and found they were all designed with a philosophy that didn't mesh with my processes well enough. It's all just automation of repetitive tasks and as such its pretty language agnostic.

In other words: "It works for me!" :-)
Post by DJ-Pfulio
The problem with this is shared work. Only you and your small team know
your scripts. When you leave, I bet the next guy will re-work
everything
- perhaps using a DevOPS tool.
With those tools, there are multiple repos with pre-existing solutions.
Need WP, apache, and mariaDB ... pull the playbooks from github. They
might not be perfect for your environment, but they will work. On
Cent/RHEL, they install, enable, setup the services and open the
firewall port(s) where needed. Fewer chances to forget those tiny
config settings.
It also means that the next guy will hit the ground running,
effectively
zero spin-up time to start working with the devops tool. THAT is the
real power. When I see an ansible setup, since most are following the
same "best practices", there is a huge, existing, understanding, for
where and how things work. Your scripts that call scripts and call
scripts - not so much.
Bash scripts over ssh. Nothing says "my network and server farm" like
customs solutions for specific problems. Add a custom pack of cool
tools
on a server build out.
Puppet was the early winner. Now it feels like picking MSFT
solutions.
Nobody gets fired for going with the most popular solution.
You'll
always be employed, but might hate it.
Ansible is like Unix. The simplest solution that solves the
problem.
It builds on things you already know. No "magic" directories to
memorize (cough Chef). Things work off relative paths, which any
admin
would already understand. Since the beginning, the order of
instructions/tasks was never a question (cough puppet).
I attended 4 hrs of Chef training at SELF a few years ago. When
they
started talking about "magic locations", I left.
I attended a Puppet Labs day at GA-Tech a few years ago. About
250
others were there too. During the keynote, the speaker asked how
many
people were using Puppet to manage their environment 100% - 4
people in
the far left raised their hands. Nobody else.
My personal experience with small scale stuff is that puppet is
worse
than my carefully crafted ssh scripts to manage systems. Chef
seems to
be similarly complex. At the time, both puppet and Chef required
me to
install ruby on every node. That was a non-starter. I like ruby
(the
language), but putting ruby on an email gateway seems foolish.
Actually,
I don't want python or perl on that machine either, but the small
OS
installs use those for scripting, so there isn't a choice.
Ansible didn't require that I learn/solved 20 new problems to
work. I
was managing systems, building them out just post-install,
quickly. I
started by managing /etc/hosts files as my first learning
exercise.
Took about 30 minutes to get that done from knowing ZERO about
ansible
except that it worked over ssh.
I can see where experts in each of these tools would be very
efficient.
But for a small shop with zero budget for outside experts,
Ansible wins
immediately. For puppet consultants, of course you want puppet
everywhere. I want Linux everywhere too, but most of us here
have the
Linux expertise already so it isn't a huge unknown.
This can easily be a religious war. Use what works for your
needs. If
you are a chef consultant, push chef. Same for puppet. I'm
certain both
those tools have addressed the issues that were common when I
looked at
them 4+ yrs ago - too late. Found ansible. Happy.
I found Ansible to be the simplest solution for my needs, like
many
others here.
No, it isn't misinformation. It is a very literal
representation
of my
experience with both. After three frustrating weeks of
attempting to
figure out the Puppet garbage, and getting absolutely
nowhere, I
read
the Ansible introduction and had the exact same test done in less than
an hour.
On Mon, Nov 20, 2017 at 8:10 AM, Jerald Sheets
On Nov 18, 2017, at 4:59 PM, James Sumners
Ansible. What takes three weeks to do in Puppet takes 30
minutes with Ansible. I manage >=150 systems with Ansible
no
problem.
I manage over a quarter million nodes in Puppet, and while
your
experience may differ, this is misinformation.  We use both. 
Ansible for orchestration, Puppet for configuration.
—j
------------------------------------------------------------------------
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
<http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
<http://mail.ale.org/mailman/listinfo>
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
------------------------------------------------------------------------
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Sent from my Android device with K-9 Mail. All tyopes are thumb
related
and reflect authenticity.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Got Linux? Used on smartphones, tablets, desktop computers, media
centers, and servers by kids, Moms, Dads, grandparents and IT
professionals.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
James Sumners
2017-11-21 14:34:55 UTC
Permalink
Every single one of those examples is exactly what Ansible is for, and far
easier to maintain.

Deploy package to all hosts:
```
- hosts: all

tasks:
- name: deploy foo package
yum:
name: http://www.example.com/my-awesome-local.rpm
state: present
```

Really, it's that simple.

Run all security updates? No problem:

```
- hosts: all

tasks:
- name: install security updates
yum:
name: *
security: yes
state: latest
```

Boom! Done, moving on to other things worth expending thought on.

Ansible just makes your life easier.
We have things that are often highly customised. The broad-scale roll out
is already simple enough. I have a few custom tools for "splat an new
package across the computation cluster" and "give me a quick health
report". Other tools are "security update across all outward facing systems
for ssh/ssl" and "run all security updates now and restart everything that
uses the updated packages".
Yes. Could use chef, puppet, spacewalk, ansible, "next cool tool here",
but I prefer to build my own toolchain tailored specifically for the
environment I have. The beginning and end points are the same, only the
middle is different. I've tinkered with several and found they were all
designed with a philosophy that didn't mesh with my processes well enough.
It's all just automation of repetitive tasks and as such its pretty
language agnostic.
In other words: "It works for me!" :-)
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
Jerald Sheets
2017-11-21 13:57:38 UTC
Permalink
Bash scripts over ssh. Nothing says "my network and server farm" like customs solutions for specific problems. Add a custom pack of cool tools on a server build out.
Puppet was the early winner. Now it feels like picking MSFT solutions.
Nobody gets fired for going with the most popular solution. You'll
always be employed, but might hate it.
TL;DR: Everything’s in a bubble right now, all the tools are about to change, and the methods typically assigned to the sysadmin will need to look fundamentally different while the sensibilities need to remain the same and a new culture needs to be apprehended and embraced.


And these are the conversations we’re having in the DevSecOps world and in the Sysadmin’s groups (USENIX, LOPSA, et. al.)

We have a ton of “cool tools” we’ve either assimilated or built ourselves over our collective careers, and we have our own denomination in the systems world. Thing is, the job hunts any more are requiring skillsets that have Config Management right square in the middle of them, and Chef/Puppet are the clear winners there.

A lot of recruiters are lumping Ansible in with those two, but there is a difference between a DSC paradigm and a “push what I need out there
everywhere” paradigm. I’ve always separated Ansible into its own world of which it is the master of that domain, and that is one of orchestration. Puppet and Chef are nowhere near as good at orchestration as Ansible, and is why we have it paired with Puppet for the workload we have. Neither is up to the task in and of itself, but needs the capabilities of the other to be a powerful, wholistic toolset.

Anywho
 I talk to recruiters all the time who can’t define “DevOps”. The toolset that could constitute a DevOps is so vast and arrayed, finding people who’ve taken the time to start digging into all of it is very difficult. That’s why the more capable of the DevOps-ians are making 160-200k in Atlanta. The problem is that “DevOps Engineer” in Atlanta also makes 80k. Just search the boards
 it’s confusing and can be maddening.

Now what do we do? How do you define these things such that it makes the hiring process easier? This is becoming a problem because DevOps (and by implication, Configuration Management) has such a WIDE description and salary range that the exact same term at two different companies can mean the difference between feast or famine, entry/mid level or senior architect, and unfortunately means two entirely different toolsets and two entirely different skillsets.

I’ve always been one to try and stay one step ahead of the “coming wave” and be tooled to be marketable for “what’s next”. Ask Joey Kelly right here on this board
 he’s been the same way since the early 90’s when I first met him. I remember when no one else was talking about it, he was a firm proponent that biblical translation work should happen on CD technology (this was before CDs were released as data storage mechanisms, btw) when translators were in the field to avoid loss of translation work and resiliency against the elements. Wycliffe translators (largest translation group in the world) started using that as the standard toolset 5 years later (an eternity in computer-speak), and have now moved to removable media of the USB drive ilk. In Baton Rouge, I was Linux before Linux was a thing. I installed the first Slackware at LSU from floppies mere months after Linus had announced the kernel and slack had produced a distribution. I like to stay ahead. :)

The issue isn’t Puppet or Chef, Ansible or SALT, and it isn’t whether you’re Linux/UNIX or Win, small environment or large.

The issue is CULTURE. 20 years ago, the very idea of a tool that could manage the configuration of “all the things” was anathema to a Systems person. We had our scripts, our Perl, our host files, and our provisioning nexxi, and we would be damned if we were going to change. Fast forward, and we still have our tools and our methods, and its “good enough for what I’m doing and I’ll be damned if I’m going to change” is still our story, but I fear not for what’s adequate for today, but what’s necessary for tomorrow.

I submit to you that the current trend is that you MUST have a config management background to be employable any more, and the better you grasp the dev methods out today, apply them to infrastructure ,and become portable in that knowledge, the further up the salary chain you will find yourself. “Linux Admin” as a discipline is seeing its salaries normalize and in some cases go down. Way down. If you want sooth elder years, you might want to rethink strategy, as the old methods and tools might find you unemployed in 5-10 years.

Problem is, as you all know, this is a bubble (the config management one, anyhow) and it’s coming to an end! IAC (Infrastructure as Code) is sticking around, but new tools and methods are emerging that are better at “even bigger” where tools like Puppet and Chef (and to some degree Ansible, but not as much because it’s not like those other kids) are starting to fail. And that is massive scale. Tools like Terraform, Consul, Vault, and Nomad are designed for massive scale and were essentially built in the cloud. Both Chef and Puppet are being bolted onto the cloud and cloud methods.

Before you cry “foul”, both Adam Jacobs and Luke Kanies (creator of Chef and Puppet respectively) feel this way, and they’ve said as much to my face, that they wish their tools were more cloud friendly, and the biggest challenge they will need to solve is to become more “cloud friendly” as the months go on.

So then, why this missive in the middle of such a conversation?

Administration is changing, we have to as well.
Scale is going to be king and while you may not need scale now, you will.
Our discipline is morphing, and the “cool tool” of now will debut and wane, but DevOps culture and IAC sensibilities will never die.
I’m not worried about what you need today, but what you WILL need tomorrow next time you heat up your resume at Dice, Indeed, or whatever the new tool will be in the future.

The conversation is bigger than the tools.
Jim Kinney
2017-11-21 15:50:36 UTC
Permalink
Another aspect of "the change" is the proliferation of "cloud
services". If you are on the consumer end, the tools are of one type
while the providers use a totally different type.
Picture my scenario: computational jobs that can NOT exceed 8 hours of
wall clock time that have to scale across multiple (dozens to thousands
of) nodes of a donated platform with limited storage and bandwidth. The
nodes are not joined by by interconnect processes like MPI. Jobs must
launch and complete within a strict timeframe and must be reconfigured
after each run to get as much done as possible. I don't have root
access on any of these systems :-) and all the code used is scp'ed over
and run from static linked binaries with data (about 800GB chunks)
streams into RAM from networked sources.
Yep. Different kind of problem yet still very similar - automate a
complicated task at scale with essentially minimal tools at hand.
Don't get me wrong: this is a fantastic opportunity to do some really
cool stuff and I am NOT complaining at all. Unlimited resources
decreases the challenge and thus the fun.
Post by Jerald Sheets
Bash scripts over ssh. Nothing says "my network and server farm"
like customs solutions for specific problems. Add a custom pack of
cool tools on a server build out.
Post by DJ-Pfulio
Puppet was the early winner. Now it feels like picking MSFT solutions.
Nobody gets fired for going with the most popular
solution. You'll
always be employed, but might hate it.
TL;DR: Everything’s in a bubble right now, all the tools are about to
change, and the methods typically assigned to the sysadmin will need
to look fundamentally different while the sensibilities need to
remain the same and a new culture needs to be apprehended and
embraced.
And these are the conversations we’re having in the DevSecOps world
and in the Sysadmin’s groups (USENIX, LOPSA, et. al.)
We have a ton of “cool tools” we’ve either assimilated or built
ourselves over our collective careers, and we have our own
denomination in the systems world. Thing is, the job hunts any more
are requiring skillsets that have Config Management right square in
the middle of them, and Chef/Puppet are the clear winners there.
A lot of recruiters are lumping Ansible in with those two, but there
is a difference between a DSC paradigm and a “push what I need out
there
everywhere” paradigm. I’ve always separated Ansible into its
own world of which it is the master of that domain, and that is one
of orchestration. Puppet and Chef are nowhere near as good at
orchestration as Ansible, and is why we have it paired with Puppet
for the workload we have. Neither is up to the task in and of
itself, but needs the capabilities of the other to be a powerful,
wholistic toolset.
Anywho
 I talk to recruiters all the time who can’t define “DevOps”.
The toolset that could constitute a DevOps is so vast and arrayed,
finding people who’ve taken the time to start digging into all of it
is very difficult. That’s why the more capable of the DevOps-ians
are making 160-200k in Atlanta. The problem is that “DevOps
Engineer” in Atlanta also makes 80k. Just search the boards
 it’s
confusing and can be maddening.
Now what do we do? How do you define these things such that it makes
the hiring process easier? This is becoming a problem because DevOps
(and by implication, Configuration Management) has such a WIDE
description and salary range that the exact same term at two
different companies can mean the difference between feast or famine,
entry/mid level or senior architect, and unfortunately means two
entirely different toolsets and two entirely different skillsets.
I’ve always been one to try and stay one step ahead of the “coming
wave” and be tooled to be marketable for “what’s next”. Ask Joey
Kelly right here on this board
 he’s been the same way since the
early 90’s when I first met him. I remember when no one else was
talking about it, he was a firm proponent that biblical translation
work should happen on CD technology (this was before CDs were
released as data storage mechanisms, btw) when translators were in
the field to avoid loss of translation work and resiliency against
the elements. Wycliffe translators (largest translation group in the
world) started using that as the standard toolset 5 years later (an
eternity in computer-speak), and have now moved to removable media of
the USB drive ilk. In Baton Rouge, I was Linux before Linux was a
thing. I installed the first Slackware at LSU from floppies mere
months after Linus had announced the kernel and slack had produced a
distribution. I like to stay ahead. :)
The issue isn’t Puppet or Chef, Ansible or SALT, and it isn’t whether
you’re Linux/UNIX or Win, small environment or large.
The issue is CULTURE. 20 years ago, the very idea of a tool that
could manage the configuration of “all the things” was anathema to a
Systems person. We had our scripts, our Perl, our host files, and
our provisioning nexxi, and we would be damned if we were going to
change. Fast forward, and we still have our tools and our methods,
and its “good enough for what I’m doing and I’ll be damned if I’m
going to change” is still our story, but I fear not for what’s
adequate for today, but what’s necessary for tomorrow.
I submit to you that the current trend is that you MUST have a config
management background to be employable any more, and the better you
grasp the dev methods out today, apply them to infrastructure ,and
become portable in that knowledge, the further up the salary chain
you will find yourself. “Linux Admin” as a discipline is seeing its
salaries normalize and in some cases go down. Way down. If you want
sooth elder years, you might want to rethink strategy, as the old
methods and tools might find you unemployed in 5-10 years.
Problem is, as you all know, this is a bubble (the config management
one, anyhow) and it’s coming to an end! IAC (Infrastructure as Code)
is sticking around, but new tools and methods are emerging that are
better at “even bigger” where tools like Puppet and Chef (and to some
degree Ansible, but not as much because it’s not like those other
kids) are starting to fail. And that is massive scale. Tools like
Terraform, Consul, Vault, and Nomad are designed for massive scale
and were essentially built in the cloud. Both Chef and Puppet are
being bolted onto the cloud and cloud methods.
Before you cry “foul”, both Adam Jacobs and Luke Kanies (creator of
Chef and Puppet respectively) feel this way, and they’ve said as much
to my face, that they wish their tools were more cloud friendly, and
the biggest challenge they will need to solve is to become more
“cloud friendly” as the months go on.
So then, why this missive in the middle of such a conversation?
Administration is changing, we have to as well.
Scale is going to be king and while you may not need scale now, you will.
Our discipline is morphing, and the “cool tool” of now will debut and
wane, but DevOps culture and IAC sensibilities will never die.
I’m not worried about what you need today, but what you WILL need
tomorrow next time you heat up your resume at Dice, Indeed, or
whatever the new tool will be in the future.
The conversation is bigger than the tools.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Antony Natale
2017-11-18 22:09:38 UTC
Permalink
Don't know if there are anymore open spots but a few coworkers and I are going to a free Ansible workshop in December from Red Hat. I've only played with a little of each and Ansible seems to be the simplest and quickest to get going and powerful too. Here's a link to that workshop. As they said to me when I got the email "it fills up quickly so book asap"

https://ansibleworkshop.com/workshops/Atlanta

⁣Sent from BlueMail ​
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
--
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
------------------------------------------------------------------------
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jeremy T. Bouse
2017-11-19 06:27:57 UTC
Permalink
For me personaly... currently the first choice would be SaltStack
followed by Puppet... That said I'm in the committers for both for bug
fixes and I'm a SaltStack Certified Engineer. My work with Ansible was
limited to converting what someone else wrote for a company ours
absorbed but no one left at that company actually understood what it
did. I did work with Chef but it was basically a limited POC when
evaluating options.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go
too far down the rabbit I was hoping to get the opinions on this list
about the best tool to use. I have a basic puppet server running, but
am still not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet
thing ... been putting off learning about ti for way too long. So
where's the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the
intended recipient, please notify the sender immediately then delete
it - you should not copy or use it for any purpose or disclose its
content to any other person. Internet communications are not secure.
You should scan this message and any attachments for viruses. Any
unauthorized use or interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets
2017-11-20 13:14:26 UTC
Permalink
For me personaly... currently the first choice would be SaltStack followed by Puppet... That said I'm in the committers for both for bug fixes and I'm a SaltStack Certified Engineer. My work with Ansible was limited to converting what someone else wrote for a company ours absorbed but no one left at that company actually understood what it did. I did work with Chef but it was basically a limited POC when evaluating options.
Hehe
 you came to one of our Puppet groups quite awhile ago. Moved on to other pastures, eh?

Hope you’re well.

—j
Beddingfield, Allen
2017-11-19 19:56:42 UTC
Permalink
If you are managing CentOS, I would also consider Spacewalk.
I use SUSE Manager, which is SUSE's commercial product. It is Spacewalk
with Salt support recently added. I'm still managing my systems the
"Spacewalk way", because I just can't see a lot of benefit to moving
from that to Salt.
Pros of Spacewalk:
1. It also has integrated patch management. You can click on the
system and see outstanding patches to apply, or click the patch, and see
which systems need it.
2. Minimal hand editing of config files. Most is done through a web
based console.
3. With a little work, you can use it to manage other distributions.

Cons:
1. Not as powerful
2. It is a resource hog. I'm managing around 500 systems, and I have
it on a VM with 8 vCPUs and 32GB of memory.


Allen B.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about
the best tool to use. I have a basic puppet server running, but am still
not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet
thing ... been putting off learning about ti for way too long. So
where's the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the
intended recipient, please notify the sender immediately then delete it
- you should not copy or use it for any purpose or disclose its content
to any other person. Internet communications are not secure. You should
scan this message and any attachments for viruses. Any unauthorized use
or interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
***@ua.edu
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
leam hall
2017-11-19 20:10:48 UTC
Permalink
We used Satellite at another place; the commercial version of Spacewalk.
Unless things have changed. Couldn't stand it.

https://github.com/LeamHall/Ansible_Test/blob/master/playbooks/patch.yml

Here's an Ansible playbook to patch your RHEL/CentOS systems. If I had
Debian based systems I could add to it, not a lot of difference. This
assumes:

1. You have ssh keys on all nodes.
2. The account you use can sudo.
3. The nodes are in the Ansible inventory file
https://github.com/LeamHall/Ansible_Test/blob/master/inventory/b2532
4. The nodes can talk to a patch repository.

That's pretty much it. To patch my vms I run:

ansible-playbook playbooks/patch.yml -K b2532_vms

And we're good to go.
Post by Beddingfield, Allen
If you are managing CentOS, I would also consider Spacewalk.
I use SUSE Manager, which is SUSE's commercial product. It is Spacewalk
with Salt support recently added. I'm still managing my systems the
"Spacewalk way", because I just can't see a lot of benefit to moving from
that to Salt.
1. It also has integrated patch management. You can click on the system
and see outstanding patches to apply, or click the patch, and see which
systems need it.
2. Minimal hand editing of config files. Most is done through a web
based console.
3. With a little work, you can use it to manage other distributions.
1. Not as powerful
2. It is a resource hog. I'm managing around 500 systems, and I have it
on a VM with 8 vCPUs and 32GB of memory.
Allen B.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Joey Kelly
2017-11-19 20:15:17 UTC
Permalink
Post by leam hall
We used Satellite at another place; the commercial version of Spacewalk.
Unless things have changed. Couldn't stand it.
To enterprisy and too much for Windows lusers.

Satellite 5 was open-sourced and christened Spacewalk, and SuSE snatched it up
and repackaged it... their version is worse than anything. 5 is based on RH 6
distros and does old-school automation. Sat. 6 is for RH 7 distros, uses
Puppet, REST and other cool stuff (but it's still for brane-dead Windows-
trained enterprise lusers).

...but then RH bought Ansible, a Puppet competitor. Interesting.

--Joey
--
Joey Kelly
Minister of the Gospel and Linux Consultant
http://joeykelly.net
504-239-6550
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets
2017-11-20 13:30:16 UTC
Permalink
Post by Joey Kelly
Sat. 6 is for RH 7 distros, uses
Puppet, REST and other cool stuff (but it's still for brane-dead Windows-
trained enterprise lusers).
RedHat originally released Sat 6 right around RHEL6.2, IIRC. I had to get Katello running so I could go do a Sat 6 engagement because RH couldn’t get their collective butts out their rears long enough to send me a beta to support a mutual customer. :-|

Puppet done right makes a lot of this stuff easy. Chef done right makes a lot of this stuff easy. I personally class Ansible in a different classification of tool (orchestration over config management). Note that I am aware I have folks that would disagree with me there.


IMO, the problem is all these vendors turn training into a profit center. They have NO motivation to help you learn their products. The single largest beef I continually have with Puppet is their documentation SUCKS. Let me clarify that: it is THE most complete and nearly encyclopedic documentation out there, but as a result is opaque and becomes nearly unusable at times because it’s written for engineers by engineers, and has no thought of new adopters.

I went through the Chef training and afterward had lunch with Adam Jacobs. I’ve sat with Luke Kanies and discussed the problems with Puppet documentation with him, and after discussing these things with them both, that’s MY assessment. They didn’t say as much, but it’s important to keep both education revenue and professional services revenue up for BOTH companies. As a result, we all suffer.
Post by Joey Kelly
...but then RH bought Ansible, a Puppet competitor. Interesting.
I REALLY like Ansible, but there are things it’s not tooled to do. It works wonderfully hand in hand with either Puppet or Chef, and I’ve worked on both environments. However, now that Bolt is out there, I foresee another “shaking” going on in the product sets out there. We’ll all likely need to retool, especially if you consult on and train on any of the above mentioned tools.

It’s both a good time to be in config management and a confusing time to be in config management because everything is shifting right now, and everyone is more interested in money now than in making the tools the best they can be.


—j
Beddingfield, Allen
2017-11-19 20:21:44 UTC
Permalink
I prefer to have an administration console, where I can log in...take a
quick glance at the state of things (or create a "pretty report" for
management), check some boxes, and be done.
It just seems like Ansible and Salt are a step backward. We just spent
the last two decades pushing administration into consoles and guis, and
now it seems like everyone, even Microsoft is pushing it all back to
hand editing config files and console commands again.

Allen B.
Post by leam hall
We used Satellite at another place; the commercial version of Spacewalk.
Unless things have changed. Couldn't stand it.
https://github.com/LeamHall/Ansible_Test/blob/master/playbooks/patch.yml
Here's an Ansible playbook to patch your RHEL/CentOS systems. If I had
Debian based systems I could add to it, not a lot of difference. This
1. You have ssh keys on all nodes.
2. The account you use can sudo.
3. The nodes are in the Ansible inventory file
https://github.com/LeamHall/Ansible_Test/blob/master/inventory/b2532
4. The nodes can talk to a patch repository.
ansible-playbook playbooks/patch.yml -K b2532_vms
And we're good to go.
If you are managing CentOS, I would also consider Spacewalk.
I use SUSE Manager, which is SUSE's commercial product.  It is
Spacewalk with Salt support recently added.  I'm still managing my
systems the "Spacewalk way", because I just can't see a lot of
benefit to moving from that to Salt.
1.  It also has integrated patch management.  You can click on the
system and see outstanding patches to apply, or click the patch, and
see which systems need it.
2.  Minimal hand editing of config files.  Most is done through a
web based console.
3.  With a little work, you can use it to manage other distributions.
1.  Not as powerful
2.  It is a resource hog.  I'm managing around 500 systems, and I
have it on a VM with 8 vCPUs and 32GB of memory.
Allen B.
I have just started looking into automation with Puppet. Before
I go too far down the rabbit I was hoping to get the opinions on
this list about the best tool to use. I have a basic puppet
server running, but am still not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running
with automation". I don't need the most powerful or most awesome
tool, my environment is small, about 70 servers, a mix of CentOS
and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this
Puppet thing ... been putting off learning about ti for way too
long. So where's the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY
NOTICE: This message may be confidential and/or privileged. If
you are not the intended recipient, please notify the sender
immediately then delete it - you should not copy or use it for
any purpose or disclose its content to any other person.
Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
<http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
<http://mail.ale.org/mailman/listinfo>
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251 <tel:205-348-2251>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
<http://mail.ale.org/mailman/listinfo/ale>
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
<http://mail.ale.org/mailman/listinfo>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
***@ua.edu
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/lis
leam hall
2017-11-19 20:25:55 UTC
Permalink
The "Readily Visible" thing is a forte of Puppet Enterprise, Ansible
Tower/AWX, Satellite, etc. From a "huge deployment" perspective it is nice
to have a way for junior admins to watch things. If I was back at the bank
watching 3,000+ servers I might think differently.
Post by Beddingfield, Allen
I prefer to have an administration console, where I can log in...take a
quick glance at the state of things (or create a "pretty report" for
management), check some boxes, and be done.
It just seems like Ansible and Salt are a step backward. We just spent
the last two decades pushing administration into consoles and guis, and now
it seems like everyone, even Microsoft is pushing it all back to hand
editing config files and console commands again.
Allen B.
Jerald Sheets
2017-11-20 13:38:03 UTC
Permalink
The "Readily Visible" thing is a forte of Puppet Enterprise, Ansible Tower/AWX, Satellite, etc. From a "huge deployment" perspective it is nice to have a way for junior admins to watch things. If I was back at the bank watching 3,000+ servers I might think differently.
Try a quarter million rapidly heading toward half a million. We have a single integrated view, but not without a lot of extra work on our developers’ part.

The underlying architecture is what I have written about here:

http://questy.org/blog/2017/04/17/scaling-puppet-enterprise/ <http://questy.org/blog/2017/04/17/scaling-puppet-enterprise/>
http://questy.org/blog/2017/04/18/scaling-puppet-enterprise-part-ii-installation/ <http://questy.org/blog/2017/04/18/scaling-puppet-enterprise-part-ii-installation/>
http://questy.org/blog/2017/04/21/scaling-puppet-enterprise-part-iiia-additional-compilers/ <http://questy.org/blog/2017/04/21/scaling-puppet-enterprise-part-iiia-additional-compilers/>
http://questy.org/blog/2017/04/23/scaling-puppet-enterprise-part-iiib-additional-compilers/ <http://questy.org/blog/2017/04/23/scaling-puppet-enterprise-part-iiib-additional-compilers/>
http://questy.org/blog/2017/04/24/scaling-puppet-enterprise-part-iv-activemq-hub-and-spokes/ <http://questy.org/blog/2017/04/24/scaling-puppet-enterprise-part-iv-activemq-hub-and-spokes/>
http://questy.org/blog/2017/04/24/scaling-puppet-enterprise-part-v-gitlab/ <http://questy.org/blog/2017/04/24/scaling-puppet-enterprise-part-v-gitlab/>
http://questy.org/blog/2017/04/28/scaling-puppet-enterprise-part-vi-code-manager/ <http://questy.org/blog/2017/04/28/scaling-puppet-enterprise-part-vi-code-manager/>


You can infinitely scale with a single pane under Puppet Enterprise, but then that’s $130/node “out there”
. (I’ve seen discounts to as low as $89/node, but that’s still “spending money”).

The combo of PE and Ansible works well, but we’re getting a lot of really cool features with recent releases from Puppet. Truth is, they DO cater to Enterprise users because that’s their bread and butter. There WAS a community console for awhile, but it got abandoned. I thought I’d try to take that over and keep it up, but my Ruby just isn’t “there” to manage such a project.


—j
Jerald Sheets
2017-11-20 13:32:28 UTC
Permalink
There’s a point of diminishing return here, no?

I don’t know that I’d trust Microsoft tools to correctly write out configurations.. :-D

I’m being facetious here
 I haven’t so much as touched a Microsoft Operating System in over 12 years, so I wouldn’t know the state of things today.

Even the Windows folks are loving both Powershell and Bash. In that regard, I think that it’s a positive move that they’re looking for the power we’ve had for decades, and are recognizing that sometimes you just have to open a shell.

—j
I prefer to have an administration console, where I can log in...take a quick glance at the state of things (or create a "pretty report" for management), check some boxes, and be done.
It just seems like Ansible and Salt are a step backward. We just spent the last two decades pushing administration into consoles and guis, and now it seems like everyone, even Microsoft is pushing it all back to hand editing config files and console commands again.
Allen B.
Jerald Sheets
2017-11-20 13:20:46 UTC
Permalink
We used Satellite at another place; the commercial version of Spacewalk. Unless things have changed. Couldn't stand it.
Satellite (Sat6, anyhow) has Puppet+Foreman running internally.

The problem with Satellite is the problem with anything at all that RedHat tries to touch. They did VERY strange things with both Puppet and Foreman “the RedHat way” and made things more difficult to apprehend. I’m Puppet AND RedHat certified, and finding all the components from Puppet in the Satellite stack was difficult (being nice). Pieces were distributed ALL OVER and I kept having to run locates just to find all the componenetry of a system that is intended to live in just TWO places: /opt/puppetlabs and /etc/puppetlabs. Not as familiar with Foreman, but my guess is going to be the “LFHS-ization” of Foreman likely made it crazy to even have to deal with as well.

These tools (Puppet, Chef, Ansible) are easy enough to figure out without interference from others. RedHat has done the largest disservice to both Puppet and Ansible, IMO.


—j
James Sumners
2017-11-19 21:33:15 UTC
Permalink
The only thing I use Satellite for is managing licenses. I really don't
even use it for provisioning because iPXE does it a helluva lot better.
Post by Beddingfield, Allen
If you are managing CentOS, I would also consider Spacewalk.
I use SUSE Manager, which is SUSE's commercial product. It is Spacewalk
with Salt support recently added. I'm still managing my systems the
"Spacewalk way", because I just can't see a lot of benefit to moving
from that to Salt.
1. It also has integrated patch management. You can click on the
system and see outstanding patches to apply, or click the patch, and see
which systems need it.
2. Minimal hand editing of config files. Most is done through a web
based console.
3. With a little work, you can use it to manage other distributions.
1. Not as powerful
2. It is a resource hog. I'm managing around 500 systems, and I have
it on a VM with 8 vCPUs and 32GB of memory.
Allen B.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about
the best tool to use. I have a basic puppet server running, but am still
not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet
thing ... been putting off learning about ti for way too long. So
where's the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the
intended recipient, please notify the sender immediately then delete it
- you should not copy or use it for any purpose or disclose its content
to any other person. Internet communications are not secure. You should
scan this message and any attachments for viruses. Any unauthorized use
or interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
Michael Potter
2017-11-19 22:13:39 UTC
Permalink
I think we have the makings of a great meeting topic...

Automation Wars.
Post by James Sumners
The only thing I use Satellite for is managing licenses. I really don't
even use it for provisioning because iPXE does it a helluva lot better.
Post by Beddingfield, Allen
If you are managing CentOS, I would also consider Spacewalk.
I use SUSE Manager, which is SUSE's commercial product. It is Spacewalk
with Salt support recently added. I'm still managing my systems the
"Spacewalk way", because I just can't see a lot of benefit to moving
from that to Salt.
1. It also has integrated patch management. You can click on the
system and see outstanding patches to apply, or click the patch, and see
which systems need it.
2. Minimal hand editing of config files. Most is done through a web
based console.
3. With a little work, you can use it to manage other distributions.
1. Not as powerful
2. It is a resource hog. I'm managing around 500 systems, and I have
it on a VM with 8 vCPUs and 32GB of memory.
Allen B.
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about
the best tool to use. I have a basic puppet server running, but am still
not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet
thing ... been putting off learning about ti for way too long. So
where's the best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the
intended recipient, please notify the sender immediately then delete it
- you should not copy or use it for any purpose or disclose its content
to any other person. Internet communications are not secure. You should
scan this message and any attachments for viruses. Any unauthorized use
or interception of this e-mail is illegal.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251 <(205)%20348-2251>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (music)
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Michael Potter
Tapp Solutions, LLC
www.tappsolutions.com
+1 770 815 6142 ** Atlanta ** ***@potter.name **
www.linkedin.com/in/michaelpotter
Schedule a meeting with me: https://calendly.com/michael-potter
Phil Turmel
2017-11-20 02:00:16 UTC
Permalink
Indeed. January, perhaps?

Steven Blevins is on my list for this week, and it's been proposed that
December be a joint mtg with DC404 for a keysigning party.
Post by Michael Potter
I think we have the makings of a great meeting topic...
Automation Wars.
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Jerald Sheets
2017-11-20 13:39:47 UTC
Permalink
The only thing I use Satellite for is managing licenses. I really don't even use it for provisioning because iPXE does it a helluva lot better.
You’d be surprised just how many customers say the same thing. It’s a shame, really. The tool is quite good at all the domains it tries to serve. The combination of poor docs, expensive training, and no motivation in the community to help you through working with it engenders just such a situation.

—j
Scott Plante via Ale
2017-12-06 22:12:07 UTC
Permalink
I went today to the workshop you mentioned below, Antony, and thought it was worthwhile and informative for someone like me who hadn't done anything with Ansible before.


Thanks for the link because I wouldn't have known about the workshop otherwise!
--
Scott Plante



----- Original Message -----

From: "Antony Natale" <***@gmail.com>
To: "Edward O. Holcroft" <***@mkainc.com>, "Atlanta Linux Enthusiasts - Yes! We run Linux!" <***@ale.org>
Sent: Saturday, November 18, 2017 5:09:38 PM
Subject: Re: [ale] Puppet vs chef vs ansible vs ???


Don't know if there are anymore open spots but a few coworkers and I are going to a free Ansible workshop in December from Red Hat. I've only played with a little of each and Ansible seems to be the simplest and quickest to get going and powerful too. Here's a link to that workshop. As they said to me when I got the email "it fills up quickly so book asap"


https://ansibleworkshop.com/workshops/Atlanta


Sent from BlueMail
On Nov 18, 2017, at 4:37 PM, "Edward O. Holcroft via Ale" < ***@ale.org > wrote:



I have just started looking into automation with Puppet. Before I go too far down the rabbit I was hoping to get the opinions on this list about the best tool to use. I have a basic puppet server running, but am still not sure it's the best road to be on.


"Best" in my case typically means "easiest to get up and running with automation". I don't need the most powerful or most awesome tool, my environment is small, about 70 servers, a mix of CentOS and Ubuntu.


I'm somewhat experienced with Linux but a total noob on this Puppet thing ... been putting off learning about ti for way too long. So where's the best place to start?


ed











MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This message may be confidential and/or privileged. If you are not the intended recipient, please notify the sender immediately then delete it - you should not copy or use it for any purpose or disclose its content to any other person. Internet communications are not secure. You should scan this message and any attachments for viruses. Any unauthorized use or interception of this e-mail is illegal.

Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo



_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
Edward O. Holcroft via Ale
2017-12-06 22:29:52 UTC
Permalink
#metoo

Thanks Antony for the heads up.


_________________________________________

*Edward O. Holcroft*
IT Operations Manager

*Madsen, Kneppers & Associates, Inc.*
Construction Consultants & Engineers
11695 Johns Creek Parkway, Suite 250
Johns Creek, GA 30097

*O* 770.446.9606 | *F* 770.446.9612 | *C* 770.630.0949 |
***@mkainc.com

www.mkainc.com
Post by Scott Plante via Ale
I went today to the workshop you mentioned below, Antony, and thought it
was worthwhile and informative for someone like me who hadn't done anything
with Ansible before.
Thanks for the link because I wouldn't have known about the workshop otherwise!
--
Scott Plante
------------------------------
*Sent: *Saturday, November 18, 2017 5:09:38 PM
*Subject: *Re: [ale] Puppet vs chef vs ansible vs ???
Don't know if there are anymore open spots but a few coworkers and I are
going to a free Ansible workshop in December from Red Hat. I've only played
with a little of each and Ansible seems to be the simplest and quickest to
get going and powerful too. Here's a link to that workshop. As they said to
me when I got the email "it fills up quickly so book asap"
https://ansibleworkshop.com/workshops/Atlanta
Sent from BlueMail <http://www.bluemail.me/r?b=11061>
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I go too
far down the rabbit I was hoping to get the opinions on this list about the
best tool to use. I have a basic puppet server running, but am still not
sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running with
automation". I don't need the most powerful or most awesome tool, my
environment is small, about 70 servers, a mix of CentOS and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet thing
... been putting off learning about ti for way too long. So where's the
best place to start?
ed
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
------------------------------
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
MADSEN, KNEPPERS & ASSOCIATES USA WARNING/CONFIDENTIALITY NOTICE: This
message may be confidential and/or privileged. If you are not the intended
recipient, please notify the sender immediately then delete it - you should
not copy or use it for any purpose or disclose its content to any other
person. Internet communications are not secure. You should scan this
message and any attachments for viruses. Any unauthorized use or
interception of this e-mail is illegal.
Tony via Ale
2017-12-06 22:34:24 UTC
Permalink
My pleasure guys, glad you found it useful! I thought it was pretty
good myself. Not to mention free breakfast, lunch and swag is always a
bonus!

Tony


On Wed, Dec 6, 2017 at 5:29 PM, Edward O. Holcroft via Ale
Post by Edward O. Holcroft via Ale
#metoo
Thanks Antony for the heads up.
_________________________________________
Edward O. Holcroft
IT Operations Manager
Madsen, Kneppers & Associates, Inc.
Construction Consultants & Engineers
11695 Johns Creek Parkway, Suite 250
Johns Creek, GA 30097
O 770.446.9606 | F 770.446.9612 | C 770.630.0949 |
www.mkainc.com
Post by Scott Plante via Ale
I went today to the workshop you mentioned below, Antony, and
thought it was worthwhile and informative for someone like me who
hadn't done anything with Ansible before.
Thanks for the link because I wouldn't have known about the workshop otherwise!
--
Scott Plante
Sent: Saturday, November 18, 2017 5:09:38 PM
Subject: Re: [ale] Puppet vs chef vs ansible vs ???
Don't know if there are anymore open spots but a few coworkers and I
are going to a free Ansible workshop in December from Red Hat. I've
only played with a little of each and Ansible seems to be the
simplest and quickest to get going and powerful too. Here's a link
to that workshop. As they said to me when I got the email "it fills
up quickly so book asap"
https://ansibleworkshop.com/workshops/Atlanta
Sent from BlueMail
On Nov 18, 2017, at 4:37 PM, "Edward O. Holcroft via Ale"
Post by Edward O. Holcroft via Ale
I have just started looking into automation with Puppet. Before I
go too far down the rabbit I was hoping to get the opinions on this
list about the best tool to use. I have a basic puppet server
running, but am still not sure it's the best road to be on.
"Best" in my case typically means "easiest to get up and running
with automation". I don't need the most powerful or most awesome
tool, my environment is small, about 70 servers, a mix of CentOS
and Ubuntu.
I'm somewhat experienced with Linux but a total noob on this Puppet
thing ... been putting off learning about ti for way too long. So
where's the best place to start?
ed
This message may be confidential and/or privileged. If you are not
the intended recipient, please notify the sender immediately then
delete it - you should not copy or use it for any purpose or
disclose its content to any other person. Internet communications
are not secure. You should scan this message and any attachments
for viruses. Any unauthorized use or interception of this e-mail is
illegal.
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
This message may be confidential and/or privileged. If you are not
the intended recipient, please notify the sender immediately then
delete it - you should not copy or use it for any purpose or disclose
its content to any other person. Internet communications are not
secure. You should scan this message and any attachments for viruses.
Any unauthorized use or interception of this e-mail is illegal.
Loading...