Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How do you handle tooling? Install it in the parent or in the container? I quite like the idea of VS Code dev containers since it does a lot of the bootstrapping work to make the container be more like a full system, and I wish this “remote environment” idea was more widely supported amongst editors.


Hmm. By tooling are you referring to things like jq and other "uncommon" cli/tui apps I use to work against a code base locally? I think that's what you mean.

One of the best practices when using docker-compose to develop is actually to mount your code base as a volume. This lets you modify the code locally without requiring a complete rebuild of the container each time code is modified.

You might have to no-hup a service or run it not as pid1 (init container or supervisord) so it can restart without killing the container but that depends on the work being done.

I'm trying to find a good example to show you but I'm not finding much. If you have a medium account this might be decent, I don't have one but it starts off going through the process https://medium.com/swlh/tutorial-how-to-use-docker-volumes-t...

With that said I use literally the exact same containers that are pushed to production.


Mostly tools that you are going to run during the development process that aren’t going to be run in CI/at “build time”. So sure, possibly jq, but especially language server and editor integrations. Do you run the editor in the container? Do not use these tools?


Devcontainers are indeed the answer if you’re using VSC. I use the docker-outside-docker feature (there’s a few flavors of these) so my app can be defined with docker-compose. The experience is nice once you’ve taken the time to customize your image, settings, and extensions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: