Open lcreid opened 4 years ago
It looks like AWS is relatively agnostic about how you build an image. At least, the easiest thing to find in Google is how to take an existing VM image or instance, and turn it into an AWS AMI to run on EC2.
One trick I see is that our traditional model has been a development VM that has everything included, but a production VM that talks to a remote database.
We could investigate how you would run a DB VM locally and have all local development instances talk to it. You'd want to be able to start the DB VM automatically if it wasn't running when you start a development instance, not fail if it was already running, and turn it off if you turn off the last development VM. This option would have to take into account that you might need multiple instances of the DB VM running, when you have version upgrades happening. But it would also facilitate version upgrades
Another option is how to factor the build process similar to how the scripts work today, so we could reliably build a local development image with a DB, but also build a production image that is only missing the database. This would solve the start and stop issues. It makes DB version changes a little more of a pain because you have to deal with each box separately
It looks like cloud-init
YAML files are the standard way to set up a Multipass image. There are a bunch of examples here: https://cloudinit.readthedocs.io/en/latest/topics/examples.html.
Does this also drive me to look into using Chef or Puppet?
What's the story of shared directories (host/guest)? What about copying files from the build machine into the image?
As of Ubuntu 20.04, Multipass is standard. It's also supported on Mac and Windows. It looks like a lot smoother way to manage multiple local dev instances.
Big question: If we're going to move away from the Vagrant platform, is Multipass the right way to do it? What about Docker? (I don't like what I'm hearing about Docker, but Mulitpass is new so it's likely to have its haters in a few years, too.)