4 ms·
To make it workable I had to just give up on the local host file integration. I basically used the container like a VM. Configured it with all the tools I norm
by adamkl 6y ago
To make it workable I had to just give up on the local host file integration.
I basically used the container like a VM. Configured it with all the tools I normally use (e.g. OhMyZsh, etc) and had it constantly running in the background. I would use VS Code as a front end and work directly inside the container (cloning repos and pushing commits).
It had its quirks but the main benefit was that my local machine was no longer a snowflake. I could easily move to any machine, pull my "development" image, spin up the container and everything was exactly as I liked it.
- IggleSniggle 6y agoWhat would be the advantage of this setup over a traditional VM where you presumably have more portability of the stateful image?
- ItalyPaleAle 6y agoSpeaking for myself, containers are started and destroyed faster. When using VMs, the tendency is to keep updating the software within the VM, making changes to their state, etc: this eventually leads to drifts. When using containers, if you need to make a change, you destroy the container and re-build it, and the state is always consistent with what you (and possibly your teammates) use
- Shicholas 6y agoas an addition to do this, we've found it easier to spin up the same exact environment for CI/CD.
- adamkl 6y agoTo be perfectly honest, in this scenario, there isn't much of an advantage. The container approach is lighter weight, and I found it easier to manage the configuration via Dockerfiles. Managing a full VM with the OS install is a bit of a pain. That being said, I worked at an organization that did the VM approach using Vagrant. It wasn't as nice as the VS Code/Docker approach, but the results were similar.
- treis 6y agoSince they're lighter weight it's easier to run more of them. Think of a place with 7-8 different applications, a few different DBs to support them, redis, elastic search, etc. You can spin up a mirror of your production environment with one command. Theoretically you can do the same with VMs but it will consume a lot more resources.
- nly 6y agoThis is only true of Docker on Linux hosts.
- treis 6y agoEven on Windows/Mac you're probably better off running 1 VM and then docker inside of it.
- scoopertrooper 6y agoIsn't that essentially what mac Docker Desktop does?
- IggleSniggle 6y agoCorrect.