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

Thu Jun 3 06:10:08 EDT 2021

In Universe everything GO to RUST

On Wed, Jun 2, 2021, 20:38 Jon "maddog" Hall via Ale <ale at ale.org> wrote:

> 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>
> 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, 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
>
> _______________________________________________
> 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/20210603/be0d199a/attachment-0002.htm>