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

Thu Jun 3 07:41:46 EDT 2021

I am not sure if you can download RHEL 6, but  can sign up for a free
developer account. Then you might be able to download it

Pup.

On Thu, Jun 3, 2021 at 6:10 AM 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
>>
> _______________________________________________
> 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
>

-- 
Terror PUP a.k.a
Chuck "PUP" Payne
-----------------------------------------
Discover it! Enjoy it! Share it! openSUSE Linux.
-----------------------------------------
openSUSE -- Terrorpup
openSUSE Ambassador/openSUSE Member
skype,twiiter,identica,friendfeed -- terrorpup
freenode(irc) --terrorpup/lupinstein
Register Linux Userid: 155363

openSUSE Community Member since 2008.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20210603/d957ae49/attachment-0002.htm>