[TriLUG] Automation from an Existing Server/VM

[Lance A. Brown via TriLUG]

Expanding on Jos' ideas a bit more.

If you can create a VM from the same operating system as a base image, you could find all the 
differences in the "interesting" locations on the filesystem:  /etc, /opt, /usr/local, etc.  Match 
that up with a comparison of installed packages between the base and your active VMs and you'd have 
a starting point for building out playbooks in your preferred configuration management system.

I've done this sort of thing before, bringing existing systems into a configuration management 
system.  At a previous job I automated deployment and management of a fleet of linux desktops using 
bcfg2 by building up a configuration that matched the existing configs.  Later, I migrated to 
puppet, transcribing all the config, and then again to ansible, again transcribing the 
configurations.  (Yes, I'm a masochist.  I was deeply involved in the configuration management 
conversations and work that came out of the LISA conferences).

I expect the effort to create a playbook generator is equal to or greater than creating the 
playbooks yourself.  Then, when you have the playbook for one OS, its much easier to add support for 
additional OSes.

--[Lance]

Jos Purvis via TriLUG wrote on 11/27/2024 12:30 AM:
> THE SHORT ANSWER:
> 
> As others noted, these tools aren't really designed to do that, so you're liable to have to write a lot of glue code and bend a few tools to make that work.
> 
> THE WAY-TOO-LONG ANSWER NO ONE ASKED FOR:
> 
> If the server is a VM and you can run scripts against the hypervisor instead of the VM itself, there are some Ansible modules like vmware_guest_instant_clone that will let you create a copy of a virtual machine by telling the hypervisor to just clone the raw VM image. And I suppose if the server is bare metal, you could use one of the various bare-metal-to-VM tools out there to slurp it into a VM, and then use said Ansible modules to clone the newly-slurped VM into a new one (so you could keep the original copy off to the side without modification). The word "IF" is doing an awful lot of heavy lifting in that paragraph, however. :)
> 
> ### WARNING: Random Midnight-Hour Ramblings Follow ###
> 
> If you have to operate at the OS layer, I suppose it's technically feasible to do something like this, but not terrifically efficient unless you have large numbers of identical or near-identical servers that need cloning[0]. Tools like Ansible or Puppet are really designed to take a server "blueprint" and apply it to a host, which means you have to define the blueprint yourself — they're not really designed to do the "extraction" piece of the equation, so you'd wind up writing a great deal of glue code to do that piece.
> 
> It -would- be an interesting coding project, however, to write up some scripts that would do things like "dump list of packages on source server, use as list to apply to new server" or "collect custom config files from /etc/nginx/conf.d, copy to storage bucket, replicate to new server". I could even imagine turning that into a tool at some point that would at least handle standard applications with standard data locations. Definitely going to involve some coding from scratch, however, which it sounds like maybe you were looking to avoid.
> 
> If I absolutely had to approach this, I think I'd ditch the automation tools and do it the old-fashioned way:
>    - Pull the list of packages from the source host into a file: most package managers will let you source a list of things to install from a flat file, so you could hand that list to dnf/apt/zypper and that gets you going.
>    - Make a list of the data/config directories and files you want to preserve, tar them up, move them to the new box, and extract. This may not be terribly complex depending on what the source server is running: if it's running a handful of bog-ordinary services like NGINX, Postgres, or Wordpress, you'll at least know where the default locations for their custom bits are to pull from. There'll be some cleanup, especially if the new box is a slightly different OS rev than the source[1], but that'll get you fairly close.
>    - From there, I'd finish by rendering the source server's disk into something delve-able, like a disk image or a restic snapshot. That way, when you realize you missed a file, you can just snag it from the image rather than having to flip on the original server to go grab it.
> 
> ### END Ramblings ###
> 
> Probably -WAY- more detail than anyone wanted, but I was sort of intrigued by the idea of building something to do it.
> 
>      -- Jos
> 
> ---
> [0] In which case...they're already...clones?
> [1] Barring "500-mile Email"-type config mismatches[2]
> [2] https://www.ibiblio.org/harris/500milemail.html (q.v.)
> 
> On Tue, Nov 26, 2024, at 18:13, Alan Sterger via TriLUG wrote:
>> Hi Listers,
>>
>> Looking into Linux Automation with Ansible, Chef, Puppet or ... Want to
>> extract a playbook from an existing server/VM to build another with
>> minimal edits.
>>
>> Operation on RHEL or OEL a must; Debian or Ubuntu a plus.
>>
>> Most docs I've reviewed want to start creating the playbook from scratch
>> instead of using an already built server/VM as a template.
>>
>> Any help in creating a playbook from an existing server/VM will be much
>> appreciated.
>>
>> -- Alan
>> -- 
>> This message was sent to: purvis at melete.org <purvis at melete.org>
>> To unsubscribe, send a blank message to trilug-leave at trilug.org from
>> that address.
>> TriLUG mailing list : https://www.trilug.org/mailman/listinfo/trilug
>> Unsubscribe or edit options on the web	:
>> https://www.trilug.org/mailman/options/trilug/purvis%40melete.org
>> Welcome to TriLUG: https://trilug.org/welcome