[ale] [EXTERNAL] Re: Re: Time for this Grey Beard to stir up some stuff
jonhall80 at comcast.net
jonhall80 at comcast.net
Wed Jun 2 20:38:01 EDT 2021
Wow, I turn my back for a few minutes and the conversation goes from "vim is the greatest text editor" to "Rust, Go and the Universe"...
md
> On 06/01/2021 3:32 PM Jerald Sheets via Ale <ale at ale.org> wrote:
>
>
>
>
>
> > > On Jun 1, 2021, at 9:34 AM, Allen Beddingfield via Ale < ale at ale.org mailto:ale at ale.org > wrote:
> > So, how do you get from one type of operation to another? For example, I have 500-600 SLES servers. 99% of them were loaded by booting the ISO image, stepping through the installer, bootstrapping against config management, and pushing a base configuration to them.
> > That is where the "cookie cutter" setup stops. Various firewall ports have been configured, directories have been made, "stuff" installed, disks added and mounted, virtual hosts configured, nfs shares configured, local users and groups added, etc . . .
> > Some of these started on SLES 11, were upgraded to 12, then 15. Our idea of config management is pushing patches, deploying rpm-based applications, pushing config files, and remote execution operations.
> > I don't see a path to get from what I have to what you have, without just blowing everything away and starting with a clean slate - which will never be an option.
> > Allen B.
> >
> > >
>
>
> This is worlds difficult without a whiteboard with which to kibbutz this around.
>
>
> We tend to see systems as objects with many things needing configuration. The secret sauce is not in whether we automate, but in how we apply the configurations we need in that automation.
>
>
> Let me do a hyper-simplistic example consisting of a web app server, a php server, and a bare apache server and I’ll have a “base” configuration consisting of NTP, DNS, and perhaps sudo.
>
> My presupposed framework is Puppet, but this methodology works on pretty much any config platform.
>
>
>
> First, let’s look at the app side. For simplicity, let’s say we use Apache everywhere. Secondarily, let’s say we use mod_proxy and let’s say we use Tomcat/Java.
>
>
>
> Base_config
> NTP settings
> DNS Settings
> sudoers settings
>
> Webapp_server_config
> apache settings
> mod_proxy config
> java_config
> tomcat_config
> php_config
>
>
>
> In most older design patterns, we would create a scenario where we’d create a new configuration fro every type of machine we have. This becomes unruly quickly and the larger the fleet, the more unruly and unmanageable it becomes.
>
>
> Now, in a Puppet paradigm, there is a datasource tool (Hiera) which provides not only data lookups, but hierarchical conditionals wherein you can choose complex context per machine, class of machines, or even large abstractions (like “east coast” or “Australia”)
>
>
>
> So, for a fleet of web servers, I may have the following:
>
>
> **BASE CONFIGS*
> Apache_Config
> - install and options
> Apache_Settings
> - configuration
> Java_Config
> - install and options
> Java_settings
> - configuration
> PHP_Config
> - install and options
> PHP_Settings
> - configuration
> MySQL_Config
> - install and options
> MySQL_Settings
> - configuration
> Mod_proxy_config
> - Instalation AND configuration
> OS_Base_Config
> - customizations looked up and specific to distro, etc.
>
> **ABSTRACTIONS**
> Apache_php_stack
> - Apache_config
> - Apache_Settings (Values for settings looked up from datastore)
> - PHP_Config
> - PHP_Settings (Values looked up from datastore)
> - MySQL_Config
> - MySQL_Settings (Values looked up)
>
> HR PHP Server
> OS_Base_config
> Apache_PHP_Stack
> HR codebase
> HR configuration (SIDs, DB names, tables, authentication, etc. all looked up)
>
>
> Static Webserver
> OS_Base_config
> Apache_Config
> Apache_Settings (Looked up)
>
> Java Web Server
> OS_Base_Config
> Apache_Config
> Apache_Settings
> Java_Config
> Java_Settings
> Mod_proxy config
>
>
> As you can see, the more “building blocks” you create, the more things you can build. You can mix & match all the various configurations and installations to put together highly customized configurations depending on what you’ve chosen to identify a system to the “collective”.
>
> For instance, if you have a hostnamehttp://wwwdevhr3129.foo.com , that is one highly information packed name you can parse to tell the system just what it’s dealing with. So, to not go into stupid details, imagine just a dev/testprod scenario. If your data lookup engine has values for things differing between each environment and then can structurally decide whether to apply a value and which one to apply based on the context of the machine itself, you’ve started to institutionalize how you deal with servers with “special needs” and have now created a way to manage all this in ways that the team works all the while storing it in code, moving the config out of the realm of “cowboy sysadmins” and into the realm of managed configs (no matter how gnarly they may be.
>
>
> As I said, this is a terrible way to explain it, and white boarding is much better. I have one puppet-centric video tha;t describes this design pattern in a Puppet context, but does a considerably better job than I because 1) I’m trying to type it all out and 2) I’m trying to remain config platform agnostic. The principle carries, and it’s an entertaining video. I’d recommend watching the entire thing to get the full gist:
>
> https://www.youtube.com/watch?v=v9LB-NX4_KQ
>
> I’ve done this for several companies as a Puppet consultant and as a Puppet partner as well as in my own DevOps consulting company. Last count, I think I’ve helped along or completed DevOps journeys for over 100 companies now. The stuff works. You just have to be able to get the concepts across better which I still feel as though I’m failing at through email.
>
> Happy to meetup for pizza and beer and a whiteboard if anyone has interest, I just don’t know when everyone will feel comfy getting together in public again.
>
>
> Let me know. Happy to help.
>
> —jms
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210602/7a5edaf9/attachment-0002.htm>
More information about the Ale
mailing list