[ale] [EXTERNAL] Re: Re: Time for this Grey Beard to stir up some stuff

[Jerald Sheets]

> On Jun 1, 2021, at 9:34 AM, Allen Beddingfield via Ale <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 hostname wwwdevhr3129.foo.com <http://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 <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












-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210601/42b41369/attachment-0002.htm>