[kwlug-disc] Salting pet servers/hosts

[L.D. Paniak]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xC9C450AD41E27BAA.asc
Type: application/pgp-keys
Size: 1696 bytes
Desc: OpenPGP public key
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20221120/599b839b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20221120/599b839b/attachment.sig>