[TriLUG] Automation from an Existing Server/VM

[William Sutton via TriLUG]

Riffing off of this ... I recommend standing up a bare VM, then see what 
a dry run of rsync from the live machine to the bare VM suggests, and 
using that as a starting point for your puppet/ansible/whatever template. 
(e.g., what packages and config files need to be installed on the bare VM 
to match the existing machine).  Then do a deep dive on the config files. 
vimdiff can be your friend for that.

William Sutton

On Wed, 27 Nov 2024, Lance A. Brown via TriLUG wrote:

> 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
>
> -- 
> This message was sent to: William <william at trilug.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/william%40trilug.org
> Welcome to TriLUG: https://trilug.org/welcome