Slightly off-topic, it really irks me when people take about reproducible builds/environments while using docker, while having something along the lines of apt-get update/pip install in their dockerfile. Like that completely destroys the reproducibility of your container!
VSCode, Dev Containers and Docker
31–40 of 234 posts
Re: VSCode, Dev Containers and Docker
#32I understand this can be done. And this post explains how it's done. I still don't get why it should be done? What's the advantage of running your dev environment in a container?
It's frustrating at best and catatrophic at worst when you have code working on your machine, deploy to prod, and then discover incompatibility.
Re: VSCode, Dev Containers and Docker
#33I understand this can be done. And this post explains how it's done. I still don't get why it should be done? What's the advantage of running your dev environment in a container?
Remote development from different machines/thin client machine
Re: VSCode, Dev Containers and Docker
#34I'm a bit of an old fart when it comes to software development. I prefer stable, slowly evolving solutions. I am a fan of the role of classical distributions. I abhor bundling every piece of software with all its particular versioned dependencies until everything works. I'm not gonna change. And that means I'm probably not the type to use Docker to deploy anything. That being said, I do see great value in it as a way for sysadmins to let semi-trusted people run their own OS on shared hardware without stepping on each other's feet. I love that it lets all of us run each our OS of choice on our compute machines at work. But that's just it: when I use Docker, I pretend it's a VM. I really would like to learn to use it in a better and more appropriate way, but whenever I try to seek out information, quality search results are absolutely covered in garbage 10-second-attention span "just type this until it works" blogposts.
Any pointers?
(Alternative question: are there some cleaner solutions than Docker out there for the workflow I describe above?)
Re: VSCode, Dev Containers and Docker
#35Earlier quoted context omitted.
If you have projects with different versions (python2/3, Java5/8, node8/11 etc) you don't need to bother with version managers and package managers anymore. Just launch the respective container and you are good to go.
for python, why cant you use use virtualenv with pyenv?
And let's be honest, virtualenvs and all the various ways they're managed and updated and such aren't really bulletproof either.
It's really, really refreshing how much "yeah I managed to break my dev environment" or "I followed the wiki for how to start developing your project but it 'didn't work'" can be avoided if it's just "run docker(-compose)?".
And this is especially true for junior developers, who are probably fresh out of college and won't be familiar with lots of the tooling that exists in the world. Not that docker is a simple tool, but it can hide so much complexity that it is easier to just show people how to docker run and docker build and such.
Re: VSCode, Dev Containers and Docker
#36Re: VSCode, Dev Containers and Docker
#37Slightly off-topic, it really irks me when people take about reproducible builds/environments while using docker, while having something along the lines of apt-get update/pip install in their dockerfile. Like that completely destroys the reproducibility of your container!
Reproducibility is a continuum, not a binary. We've chosen a point on that continuum that we believe gives us the best trade-off between reliability and maintenance effort. 100% from-the-ground-up reproducibility would be ideal, of course, but there's a cost-benefit tradeoff, and we're not being paid to be perfectionists.
Re: VSCode, Dev Containers and Docker
#38Doing any sort of development with Docker on OSX can be painfully slow if you have a lot of files that change frequently. There are a few projects to improve it but they quite aren't there yet. It's my least favourite aspect of modern web work.
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.
Re: VSCode, Dev Containers and Docker
#39I understand this can be done. And this post explains how it's done. I still don't get why it should be done? What's the advantage of running your dev environment in a container?
Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.
I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?
Re: VSCode, Dev Containers and Docker
#40Doing any sort of development with Docker on OSX can be painfully slow if you have a lot of files that change frequently. There are a few projects to improve it but they quite aren't there yet. It's my least favourite aspect of modern web work.
Agreed, try running webpack in debug mode with watch it's basically not-usable, as is git and install npm packages.