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

Thu Jun 3 08:03:32 EDT 2021

BWAHAHAHAHA! Well said!

On June 3, 2021 6:10:08 AM EDT, Boris Borisov via Ale <ale at ale.org> wrote:
>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
>>

-- 
Computers amplify human error
Super computers are really cool
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210603/326c42d3/attachment-0002.htm>