[kwlug-disc] Salting pet servers/hosts

peter_melse at gto.net peter_melse at gto.net
Sun Nov 20 12:45:36 EST 2022


I use puppet rather than salt, but the same concepts apply.

This take is for my own personal use rather than anything professional / 
in production, but unless a high quality module exists for the 
application on my pet machines, I don't bother beyond the basics of user 
and group management, firewalls, and hardening, almost a base image if 
you will. It boils down to effort vs reward. When the next version comes 
around, it's often easier (and safer) to backup the offending VM and 
upgrade (or reinstall and migrate the data afterwards) rather than spend 
hours or days tracking down the changes to redefine the state for a 
single host that will never be replicated short of the next upgrade 
cycle.

I'm leaning towards docker now for things like ci and applications where 
docker is the best supported path of least resistance, (the jury is 
still out on k3s / k8s in terms of reward for the additional complexity 
there) but for the legacy monolithic applications, proxmox backup or 
even clonezilla on bare metal still seems to be the best option vs 
taking on additional overhead for me.



On 2022-11-20 11:31, L.D. Paniak wrote:
> Salt for everything!
> 
> I do not define a pet by the number of instance you might be running
> in your environment.
> A pet only exists because its state is difficult to encode in 
> saltstack.
> These important services/servers exist but that should not keep one
> from striving to fully encode its state in a change management system.
> 
> I think an important organizing principle is to analyze a service in
> terms of its components and understand the best way to preserve and
> reproduce its state in case of upgrade, disaster recovery, attack
> recovery...
> The "infrastructure" components noted below are well managed by 
> saltstack.
> The database associated with the service is its own service that has a
> native state backup and preservation system.  We will not use
> saltstack to preserve the state of the database but will safely
> preserve WALs by other means.  Similar for other components.
> 
> There are two difficult parts to encoding the state of a service in 
> saltstack:
> 
> 1) One-time actions at create time.  There are often configurations
> that you only want to have happen when you initially set up a service:
> format drives, load the initial DB schema...  These are downright
> dangerous to manage with saltstack.  The/One philosophy of saltstack
> (and similar change management systems) is to have idempotent actions:
> an admin should be able to apply the same state to a system repeatedly
> without changing the state.  The initialization actions do not
> (easily) fit into this framework and if your saltstack logic fails,
> the results could be disastrous.
> 
> 2) Some states have complex dependencies/assertions.  If you are
> setting up a clustered DB service, you will need to know which system
> is the master before carrying out some application of state. 
> Saltstack does not easily/reliably support complex decision making
> with regards to state.  It can do it, but I would rather take a look
> at the state of a cluster of machines myself instead of depending on a
> blind state.apply to do the right thing.  It might also be that your
> service has its own arcane and ever-changing interface for managing
> state.  If you need to change your salt state on each upgrade to track
> changes to the configuration, you are already doing the state
> management manually (though you will have a good record of how to do
> it again on the current version!)
> 
> On 2022-11-20 10:23, Mikalai Birukou via kwlug-disc wrote:
>> We usually talk about pet and cattle servers/hosts. Cattle should be 
>> handled with some automatic tools like salt. What about those one off 
>> pet hosts?
>> 
>> Let's say there is host with jira. It is obviously a pet, cause only 
>> one is needed for a team. When a host was created salted, then all of 
>> its infrastructure aspects like network, firewall, updates, logging, 
>> so on, are managed by salt. Yes, main pet function is not salted, but 
>> everything else is. And when you ask any other question about pet 
>> host, besides its pet functionality, an answer can be found in a 
>> focused format, written in your salt.
>> 
>> Salt the base of pet hosts.
>> 
>> What's your millage?
>> 
>> 
>> _______________________________________________
>> kwlug-disc mailing list
>> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
>> with the subject "unsubscribe", or email
>> kwlug-disc-owner at kwlug.org to contact a human being.
> 
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.




More information about the kwlug-disc mailing list