3 ms·

Is there a specific reason you haven't replaced the Vagrant stuff with a container-based approach? You can also do stuff like using the lxc backend[0] for Vagra

Is there a specific reason you haven't replaced the Vagrant stuff with a container-based approach? You can also do stuff like using the lxc backend[0] for Vagrant if that's more your speed. While containers aren't strictly better, they are certainly lighter weight and quicker to spin up/tear down, though performance characteristics and OS settings/etc can definitely differ. I've found linux containers to be fantastic for both replicating pieces of the environment and making your e2e tests a little more offical. Running postgres itself (migrating it like you would your real app, inserting data like the app would, then tearing it all down in seconds), apps like mailcatcher[1][2] and actually letting your app send mail (this way you don't even need a local/log-only implementation), running redis locally, and replicating S3 with a project like minio[3] is very easy and fast. You can take this even further also by building a way to completely spin up your production environment to a certain point in time locally -- though all the resources for the ecosystem of apps may not be on the same VM image (otherwise you could just snapshot and technically go to the point in time), if you can assemble the state and the backups, you can hook them all up to the containers running locally (or in a VM running locally to be fair) and get an approximation of your entire system. Of course, it is somewhat less true-to-production (given that production is you running a VM), but you can remove that barrier with things like linuxkit[4]. [0]: https://github.com/fgrehm/vagrant-lxc https://github.com/fgrehm/vagrant-lxc [1]: https://mailcatcher.me https://mailcatcher.me [2]: https://github.com/sj26/mailcatcher https://github.com/sj26/mailcatcher [3]: https://www.minio.io/ https://www.minio.io/ [4]: https://github.com/linuxkit https://github.com/linuxkit

fpereiro 7y ago
You raise interesting points! In general, I don't use Vagrant. I simply use my host OS (Ubuntu) and my local node & redis. There's usually no further moving parts than these, so it is easy to achieve development in an environment that is practically equivalent to the Ubuntu servers/instances in the cloud, the main difference being a different folder path, different files stored and different info on the DB. When running the app locally, I still use services like S3 and SES - although I might not send emails, to keep things as "real" as possible. I do use Vagrant when the project requires installation of other tools beyond my basic toolkit (like MongoDB or Elasticsearch) - in this case, I want that software to stay within the VM. In general, I'd rather avoid virtualization because it represents an extra layer, but if it is necessary for idempotence or having a dev environment that mimics the prod environment, I'd definitely embrace it.
- hardwaresofton 7y ago
  I'd really recommend getting more intuition/familiar with containerization and introducing it -- it is an essential part of the modern toolkit and really isn't very hard to use these days. It will absolutely introduce/encourage idempotence and bring your dev environment just a little closer to your prod environment. Modern container runtimes can even run rootless containers, swap out the "virtualization" engine underneath (as in you can even run your container in QEMU without changing it for more isolation), so it can be a net positive for security too. There's also no need to swap out folder paths and file locations -- just moving around and disconnecting/reconnecting your data. Containerization is actually not virualization (which is why it was in quotes ealrier), they're basically better-sandboxed local processes (just like your local redis instance), and the better sandboxing has benefits for both development and production. So if you squint, it's actually very similar to just running redis yourself on a similar OS -- just now when you shut it down you don't have to manage any folders. Of course, use what works -- there's no need to fix things that aren't broken, but there is a reason that the defacto deployment artifact of the modern application is very quickly becoming a container (if it isn't already) -- in relatively trusted environments they give just the right amount of isolation and reproducibility, and centralized management (systemd even has space for containers via systemd-nspawn[0]). [EDIT] - somewhat unrelated but if you haven't I'd really suggest you give GitLab a try for your source code management -- not only does it come with a free to use docker image registry, it comes with a fantastically easy CI platform which can make automated testing easier. You get 2000 free minutes a month, and actually if you bring your own hardware (which is as easy as running a container on your local machine and pointing it at gitlab.com to run your jobs for you) it's all free. There are lots of other integrations and benefits (kanban style issue boards, gitlab pages, wiki, etc), but it's one of my gotos for small projects and I introduce it to corporate clients every chance I get. Microsoft-owned Github is doing it's best to compete now that it has endless pockets, but GitLab has been offering an amazing amount of value for free for a long time now. [0]: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...
allan_s 7y ago
note that vagrant support containers :)

fpereiro 7y ago

You raise interesting points! In general, I don't use Vagrant. I simply use my host OS (Ubuntu) and my local node & redis. There's usually no further moving parts than these, so it is easy to achieve development in an environment that is practically equivalent to the Ubuntu servers/instances in the cloud, the main difference being a different folder path, different files stored and different info on the DB. When running the app locally, I still use services like S3 and SES - although I might not send emails, to keep things as "real" as possible. I do use Vagrant when the project requires installation of other tools beyond my basic toolkit (like MongoDB or Elasticsearch) - in this case, I want that software to stay within the VM. In general, I'd rather avoid virtualization because it represents an extra layer, but if it is necessary for idempotence or having a dev environment that mimics the prod environment, I'd definitely embrace it.

hardwaresofton 7y ago
I'd really recommend getting more intuition/familiar with containerization and introducing it -- it is an essential part of the modern toolkit and really isn't very hard to use these days. It will absolutely introduce/encourage idempotence and bring your dev environment just a little closer to your prod environment. Modern container runtimes can even run rootless containers, swap out the "virtualization" engine underneath (as in you can even run your container in QEMU without changing it for more isolation), so it can be a net positive for security too. There's also no need to swap out folder paths and file locations -- just moving around and disconnecting/reconnecting your data. Containerization is actually not virualization (which is why it was in quotes ealrier), they're basically better-sandboxed local processes (just like your local redis instance), and the better sandboxing has benefits for both development and production. So if you squint, it's actually very similar to just running redis yourself on a similar OS -- just now when you shut it down you don't have to manage any folders. Of course, use what works -- there's no need to fix things that aren't broken, but there is a reason that the defacto deployment artifact of the modern application is very quickly becoming a container (if it isn't already) -- in relatively trusted environments they give just the right amount of isolation and reproducibility, and centralized management (systemd even has space for containers via systemd-nspawn[0]). [EDIT] - somewhat unrelated but if you haven't I'd really suggest you give GitLab a try for your source code management -- not only does it come with a free to use docker image registry, it comes with a fantastically easy CI platform which can make automated testing easier. You get 2000 free minutes a month, and actually if you bring your own hardware (which is as easy as running a container on your local machine and pointing it at gitlab.com to run your jobs for you) it's all free. There are lots of other integrations and benefits (kanban style issue boards, gitlab pages, wiki, etc), but it's one of my gotos for small projects and I introduce it to corporate clients every chance I get. Microsoft-owned Github is doing it's best to compete now that it has endless pockets, but GitLab has been offering an amazing amount of value for free for a long time now. [0]: https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html https://www.freedesktop.org/software/systemd/man/systemd-nsp...

allan_s 7y ago

note that vagrant support containers :)