Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

71–80 of 234 posts

Re: VSCode, Dev Containers and Docker

#71
post #38

Earlier quoted context omitted.

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…

What would be the advantage of this setup over a traditional VM where you presumably have more portability of the stateful image?

Speaking 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

Re: VSCode, Dev Containers and Docker

#72

Earlier quoted context omitted.

Agreed, try running webpack in debug mode with watch it's basically not-usable, as is git and install npm packages.

npm / webpack: That's not Docker's fault - that's node/JS's fault. Having to touch thousands and thousands of files is expensive. This is why I've come to loath web frontend development.

It's definitely Docker that's the problem. It's a well known problem, and people are working on solutions. It affects far more than NPM and Webpack.

Re: VSCode, Dev Containers and Docker

#73

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!

And by that you mean that the version of those deps aren't pinned?

At least for python, just pinning the top level dependencies are not enough. if you pin tensorflow==2.4.0, it doesn’t pin its required packages, rather it just defines a range. An example would be tf will try to get wheel>=0.26 (which was released in 2015 and is currently on release 0.36.2)

Re: VSCode, Dev Containers and Docker

#74
post #47

I 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 depends on what the environment is for. Your company work, or individual projects? If you're an individual, then it would benefit someone who has multiple devices and/or multiple operating systems and doesn't want to manage their environment across all those devices and operating systems. For example, I personally have OSX, Windows, and several different Linux distributions on my laptop itself. My desktop also run…

[deleted]

Re: VSCode, Dev Containers and Docker

#75
post #8

Doing 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.

There's a volume feature that sped up disk access to mounted volumes quite a bit. You add ":cached" to any volume. This changes some of the guarantees around consistency, but I haven't had any issues. See https://www.docker.com/blog/user-guided-caching-in-docker-fo...

Re: VSCode, Dev Containers and Docker

#77

Earlier quoted context omitted.

Agreed, try running webpack in debug mode with watch it's basically not-usable, as is git and install npm packages.

npm / webpack: That's not Docker's fault - that's node/JS's fault. Having to touch thousands and thousands of files is expensive. This is why I've come to loath web frontend development.

Same problem with PHP development, anyone trying to develop on windows for any real world framework will have epic IO lags, sometimes crashes with composer (equivalent to npm) and ALSO during execution time. Is this composer/PHP/Symfony-Laravel-whatever's fault ? Is it the caching lib fault ?

I work on linux, but try to onboard windows dev frequently ("windows dev", ikr ;) . The experience is always painful, and despite many efforts from the WSL team to move forward, docker for development on Windows is still barely usable right now ...

Re: VSCode, Dev Containers and Docker

#78
post #50

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!

I mean in a sense, the fucked up behavior of system package managers relative to the actual concerns of building and distributing software to the masses is the reason we need Docker to sandbox environments in the first place. It's 2021, there is next to no reason why the default behavior is installation to /usr/lib with shared objects that are rarely shared, with global access when installed for one application used…

[deleted]

Re: VSCode, Dev Containers and Docker

#79

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!

I never understood why commands like apt-get don't take a version with the dependency name.

They do. You can do `apt-get install package=version`

Re: VSCode, Dev Containers and Docker

#80
post #63

Earlier quoted context omitted.

You are confusing two different things. One is using Docker as a deployment packaging method. The other is using Docker only for development and still deploying traditionally. Sure you can do both, but it doesn't have to be this way. >when I use Docker, I pretend it's a VM Also check anti-patterns 1 and 4 here https://codefresh.io/containers/docker-anti-patterns/

Anti-pattern 1 perfectly describes how I am (hamfistedly) using Docker. Thanks! However, it doesn't really explain how to fix my mindset. It just says that I should ;-) Could you give me some hints?

"There is no easy fix for this anti-pattern other than reading about the nature of containers, their building blocks, and their history (going all the way back to the venerable chroot)."

Basically learn the basics (cgroups, namespaces)

You should also study this https://github.com/p8952/bocker

Post reply on HN