5 ms·

Vagrant / Packer?

by ThreatSystems 2y ago

Vagrant / Packer?

gavindean90 2y ago
With all the mind share that terraform gets you would thing vagrant would at least be known but alas
- tptacek 2y ago
  Somebody educate me about the problem Packer would solve for you in 2024?
  - kasey_junk 2y ago
    I think the thread is more about how docker was a reaction to the vagrant/packer ecosystem that was deemed overweight but was in many ways was a “docker like thing” but VMs.
    - tptacek 2y ago
      Oh, yeah, I'm not trying to prosecute, I've just always been Packer-curious.
  - yjftsjthsd-h 2y ago
    What's a better way to make VM images?
    - DaanDeMeyer 2y ago
      There's lots of tools in this space. I work on https://github.com/systemd/mkosi https://github.com/systemd/mkosi for example.
  - sgarland 2y ago
    Making machine images. AWS calls them AMIs. Whatever your platform, that's what it's there for. It's often combined with Ansible, and basically runs like this: 1. Start a base image of Debian / Ubuntu / whatever – this is often done with Terraform. 2. Packer types a boot command after power-on to configure whatever you'd like 3. Packer manages the installation; with Debian and its derivatives, this is done mostly through the arcane language of preseed [0] 4. As a last step, a pre-configured SSH password is set, then the new base VM reboots 5. Ansible detects SSH becoming available, and takes over to do whatever you'd like. 6. Shut down the VM, and create clones as desired. Manage ongoing config in a variety of ways – rolling out a new VM for any change, continuing with Ansible, shifting to Puppet, etc. [0]: https://wiki.debian.org/DebianInstaller/Preseed https://wiki.debian.org/DebianInstaller/Preseed
    - pxc 2y ago
      This is nice in its uniformity (same tool works for any distro that has an existing AMI to work with), but it's insanely slow compared to just putting a rootfs together and uploading it as an image. I think I'd usually rather just use whatever distro-specific tools for putting together a li'l chroot (e.g., debootstrap, pacstrap, whatever) and building a suitable rootfs in there, then finish it up with amazon-ec2-ami-tools or euca2ools or whatever and upload directly. The pace of iteration with Packer is just really painful for me.
      - sgarland 2y ago
        I haven’t played with chroot since Gentoo (which for me, was quite a while ago), so I may be incorrect, but isn’t that approach more limited in its customization? As in, you can install some packages, but if you wanted to add other repos, configure 3rd party software, etc. you’re out of luck.
        pxc 2y ago
        Nah you can add other repos in a chroot! The only thing you can't really do afaik is test running a different kernel; for that you've got to actually boot into the system. If you dual-boot multiple Linux systems you can still administer any of the ones you're not currently running via chroot at any time, and that works fine whether you've got third-party repositories or not. A chroot is also what you'd use to reinstall the bootloader on a system where Windows has nuked the MBR or the EFI vars or whatever. There might be some edge cases like software that requires a physical hardware token to be installed for licensing purposes is very aggressive, so it might also try to check if it's running in a chroot, container, or VM and refuse to play nice or something like that. But generally you can do basically anything in a chroot that you might do in a local container, and 99% of what you might do in a local VM.
    - stargrazer 2y ago
      I miss saltstack. I did that whole litany of steps with one tool plus preseed.
stackskipton 2y ago
Wouldn't work here, they have software on each VM that cannot be reimaged. To use Packer properly, you should treat like you do stateless pod, just start a new one and take down the old one.
- ThreatSystems 2y ago
  Sure then throw Ansible over the top for configuration/change management. Packer gives you a solid base for repeatable deployments. Their model was to ensure that data stays within the VM which a deployed AMI made from Packer would suit the bill quite nicely. If they need to do per client configuration then ansible or even AWS SSM could fit the bill there once EC2 instance is deployed. For data sustainment if they need to upgrade / replace VMs, have a secondary EBS (volume) mounted which solely stores persistent data for the account.
  - stackskipton 2y ago
    That might work as well. I've found Packer + Ansible to be juice not really worth the squeeze vs base Ubuntu/Debian/Rocky + bigger Ansible playbook.

Vagrant / Packer?

gavindean90 2y ago

With all the mind share that terraform gets you would thing vagrant would at least be known but alas

tptacek 2y ago
Somebody educate me about the problem Packer would solve for you in 2024?
- kasey_junk 2y ago
  I think the thread is more about how docker was a reaction to the vagrant/packer ecosystem that was deemed overweight but was in many ways was a “docker like thing” but VMs.
  - tptacek 2y ago
    Oh, yeah, I'm not trying to prosecute, I've just always been Packer-curious.
- yjftsjthsd-h 2y ago
  What's a better way to make VM images?
  - DaanDeMeyer 2y ago
    There's lots of tools in this space. I work on https://github.com/systemd/mkosi https://github.com/systemd/mkosi for example.
- sgarland 2y ago
  Making machine images. AWS calls them AMIs. Whatever your platform, that's what it's there for. It's often combined with Ansible, and basically runs like this: 1. Start a base image of Debian / Ubuntu / whatever – this is often done with Terraform. 2. Packer types a boot command after power-on to configure whatever you'd like 3. Packer manages the installation; with Debian and its derivatives, this is done mostly through the arcane language of preseed [0] 4. As a last step, a pre-configured SSH password is set, then the new base VM reboots 5. Ansible detects SSH becoming available, and takes over to do whatever you'd like. 6. Shut down the VM, and create clones as desired. Manage ongoing config in a variety of ways – rolling out a new VM for any change, continuing with Ansible, shifting to Puppet, etc. [0]: https://wiki.debian.org/DebianInstaller/Preseed https://wiki.debian.org/DebianInstaller/Preseed
  - pxc 2y ago
    This is nice in its uniformity (same tool works for any distro that has an existing AMI to work with), but it's insanely slow compared to just putting a rootfs together and uploading it as an image. I think I'd usually rather just use whatever distro-specific tools for putting together a li'l chroot (e.g., debootstrap, pacstrap, whatever) and building a suitable rootfs in there, then finish it up with amazon-ec2-ami-tools or euca2ools or whatever and upload directly. The pace of iteration with Packer is just really painful for me.
    - sgarland 2y ago
      I haven’t played with chroot since Gentoo (which for me, was quite a while ago), so I may be incorrect, but isn’t that approach more limited in its customization? As in, you can install some packages, but if you wanted to add other repos, configure 3rd party software, etc. you’re out of luck.
      - pxc 2y ago
        Nah you can add other repos in a chroot! The only thing you can't really do afaik is test running a different kernel; for that you've got to actually boot into the system. If you dual-boot multiple Linux systems you can still administer any of the ones you're not currently running via chroot at any time, and that works fine whether you've got third-party repositories or not. A chroot is also what you'd use to reinstall the bootloader on a system where Windows has nuked the MBR or the EFI vars or whatever. There might be some edge cases like software that requires a physical hardware token to be installed for licensing purposes is very aggressive, so it might also try to check if it's running in a chroot, container, or VM and refuse to play nice or something like that. But generally you can do basically anything in a chroot that you might do in a local container, and 99% of what you might do in a local VM.
  - stargrazer 2y ago
    I miss saltstack. I did that whole litany of steps with one tool plus preseed.

stackskipton 2y ago

Wouldn't work here, they have software on each VM that cannot be reimaged. To use Packer properly, you should treat like you do stateless pod, just start a new one and take down the old one.

ThreatSystems 2y ago
Sure then throw Ansible over the top for configuration/change management. Packer gives you a solid base for repeatable deployments. Their model was to ensure that data stays within the VM which a deployed AMI made from Packer would suit the bill quite nicely. If they need to do per client configuration then ansible or even AWS SSM could fit the bill there once EC2 instance is deployed. For data sustainment if they need to upgrade / replace VMs, have a secondary EBS (volume) mounted which solely stores persistent data for the account.
- stackskipton 2y ago
  That might work as well. I've found Packer + Ansible to be juice not really worth the squeeze vs base Ubuntu/Debian/Rocky + bigger Ansible playbook.