I just started working on a cli tool to easily create, manage, and spin up dev environments in docker containers. The
initial impetus for starting the project was to try out Doom Emacs without messing with my current Emacs setup, so an
example session could be:
dv new emacs dev-img-emacs:latest
dv start emacs
dv conn emacs
The first line creates a new "development environment" named emacs, based on the docker image dev-img-emacs:latest.
The second line starts up a docker container based on the saved image. The third line connects to the running image
via mosh (or ssh).
Mostly I just meant to use it as a learning experience, but it's actually been really convenient in a lot of ways, so
I think I might develop it further.
LXD container instances are much better suited for portable dev environments. They are persistent by default and are intended to run multiple processes within a container instance. They can also be copied/migrated between lxd agents.
In contrast, docker was created to run a single ephemeral process per container. It's nice in production environments, but its also a huge pain for some tasks. That's why were seeing folks create things like docker s6-overlay.
Thanks for the suggestion, this looks great! At a glance LXD seems to be a much more robust version of what I've built. Time to learn something new I guess lol.
Yeah there’s the downside. The interface is a bit unwieldy. Documentation for lxd is far lower quality compared to the massive and mature docker ecosystem.
However if you know a lot about what docker does at a lower level, that knowledge is transferable to something like lxd. Most of these containerization tools are all using the same Linux kernel features under the hood!
Nice! It's cool to see that other people had the same issues I did, and solved them the same way (though you're much further along than I am). How are you hooking into the environment container? Are you running an editor in the terminal, or maybe something like tramp or vs code dev containers?
Have you considered adding an option to "virtualize" the container's home directory? It's probably pretty niche but I've found it to be useful when I'm doing something more exploratory, like testing out a new editor config, where I don't want to commit to anything.
Great idea to expose the host docker instance to the container btw (if I'm understanding this correctly). I didn't think to do that but it seems like it could be really useful.
Did you end up incorporating dew into your workflow? Sorry for the jumbled response btw, this is mostly stream-of-consciousness as I read through the repo.
dv new emacs dev-img-emacs:latest
dv start emacs
dv conn emacs
The first line creates a new "development environment" named emacs, based on the docker image dev-img-emacs:latest. The second line starts up a docker container based on the saved image. The third line connects to the running image via mosh (or ssh).
Mostly I just meant to use it as a learning experience, but it's actually been really convenient in a lot of ways, so I think I might develop it further.