3 ms·

Ok, as I said, I may lack perspective. I version control VM configs and script VM deployments, and manage a herd of containers with ansible. We're talking abo

Ok, as I said, I may lack perspective. I version control VM configs and script VM deployments, and manage a herd of containers with ansible. We're talking about simple minded code monkey stuff here: the real work is elsewhere.

dangus 2y ago
For sure, and I think your way is probably superior overall. There are just a lot of people where as soon as you say “code” or “text editor” they are out. My proxmox stack is manually managed in the management GUI, but my Linux VMs within that setup are all managed with a Chef server that runs on one of the VMs. (I would say I only chose Chef because I use it at work and I have recent familiarity and figured I could learn more about it) Basically I do the standard graphical Debian installer and then run a bootstrap script that registers each system as a client. The next thing I’d like to do is figure out cloud-init with Proxmox so that I don’t have to do that manual installation process anymore. This setup works okay for me as-is since I only have about 5 VMs at a time, it’s just a hobbyist setup.
- topspin 2y ago
  > Basically I do the standard graphical Debian installer and then run a bootstrap script that registers each system as a client. Great approach. Might try that. > The next thing I’d like to do is figure out cloud-init with Proxmox so that I don’t have to do that manual installation process anymore. Yeah. cloud-init... The only advice I have there is: use only core cloud-init capabilities -- the stuff that's been around for years, works everywhere and is unlikely to change in subtle ways -- and factor everything else into a shell script that does the rest, which you invoke from cloud-init.
  - dangus 2y ago
    Oh yeah, for cloud init I only need write_files, path, and runcmd. But also it can all just be runcmd. For chef you put a client validator key in a specific location along with a first boot json file that has details about the client’s policy name and group. After that it’s pretty much just installing the chef client and running it.

dangus 2y ago

For sure, and I think your way is probably superior overall. There are just a lot of people where as soon as you say “code” or “text editor” they are out. My proxmox stack is manually managed in the management GUI, but my Linux VMs within that setup are all managed with a Chef server that runs on one of the VMs. (I would say I only chose Chef because I use it at work and I have recent familiarity and figured I could learn more about it) Basically I do the standard graphical Debian installer and then run a bootstrap script that registers each system as a client. The next thing I’d like to do is figure out cloud-init with Proxmox so that I don’t have to do that manual installation process anymore. This setup works okay for me as-is since I only have about 5 VMs at a time, it’s just a hobbyist setup.

topspin 2y ago
> Basically I do the standard graphical Debian installer and then run a bootstrap script that registers each system as a client. Great approach. Might try that. > The next thing I’d like to do is figure out cloud-init with Proxmox so that I don’t have to do that manual installation process anymore. Yeah. cloud-init... The only advice I have there is: use only core cloud-init capabilities -- the stuff that's been around for years, works everywhere and is unlikely to change in subtle ways -- and factor everything else into a shell script that does the rest, which you invoke from cloud-init.
- dangus 2y ago
  Oh yeah, for cloud init I only need write_files, path, and runcmd. But also it can all just be runcmd. For chef you put a client validator key in a specific location along with a first boot json file that has details about the client’s policy name and group. After that it’s pretty much just installing the chef client and running it.