VSCode, Dev Containers and Docker • Hacker News Board

Re: VSCode, Dev Containers and Docker

#101

Post by mbreese » Thu, Jan 21, 2021, 4:49 PM UTC

coldtea wrote: post #23

marcus_holmes wrote: post #10

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?

What exactly is diffucult to understand about the value proposition? Seems pretty obvious to me... If you mean why use dev environments in containers: 1) reproducibility, 2) re-use of container creation scripts for different environments, 3) isolation from your actual OS, 4) ability to run the same OS/libs/etc as the final deployment, 5) tons of base images with different environments already configured - from LAMP t…

> 3) isolation from your actual OS

For me, this is the major benefit. I don't have to worry about installing new tools or libraries and how they interact with my primary OS. While this isn't a huge issue for many, I don't want to have to worry about how Go, Python, Java, etc... are installed on my Mac. I like being able to pull in a Docker container with everything already setup (or a customized one). Then when I throw away a project, I don't have orphaned installations on my Mac.

Re: VSCode, Dev Containers and Docker

#102

Post by jayd16 » Thu, Jan 21, 2021, 4:52 PM UTC

gshulegaard wrote: post #41

coldtea wrote: post #23

Earlier quoted context omitted.

What exactly is diffucult to understand about the value proposition? Seems pretty obvious to me... If you mean why use dev environments in containers: 1) reproducibility, 2) re-use of container creation scripts for different environments, 3) isolation from your actual OS, 4) ability to run the same OS/libs/etc as the final deployment, 5) tons of base images with different environments already configured - from LAMP t…

All of those benefits were solved problems with VM based workflows using something like Vagrant long before Containers started gaining traction (IMO). Don't get me wrong, I am a fan of containers (in particular LXC), but I wouldn't list those benefits as if they are unique or novel to container based workflows. Edit: To be clear, there _are_ benefits to containers over VMs, just not the things you listed above from m…

Vagrant could have made it but it didn't. Seems like the cloud providers leaned into docker much more heavily.

Re: VSCode, Dev Containers and Docker

#103

Post by AnIdiotOnTheNet » Thu, Jan 21, 2021, 4:52 PM UTC

moistbar wrote: post #97

hctaw wrote: post #50

Earlier quoted context omitted.

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…

Both apt and yum support installing to whatever directory you like as long as you have write permissions there.

Not really. They support dumping the package contents to an arbitrary directory, but you can't actually run the software from there without either the software having been written to support arbitrary paths (almost none is) or using namespacing and chroot to build it a sandbox wherein its baked-in paths actually work.

Contrast that with something like RiscOS AppDirs, classic Mac applications, or Next/Mac Application Bundles.

Re: VSCode, Dev Containers and Docker

#104

Post by mbreese » Thu, Jan 21, 2021, 4:54 PM UTC

gshulegaard wrote: post #41

coldtea wrote: post #23

Earlier quoted context omitted.

What exactly is diffucult to understand about the value proposition? Seems pretty obvious to me... If you mean why use dev environments in containers: 1) reproducibility, 2) re-use of container creation scripts for different environments, 3) isolation from your actual OS, 4) ability to run the same OS/libs/etc as the final deployment, 5) tons of base images with different environments already configured - from LAMP t…

All of those benefits were solved problems with VM based workflows using something like Vagrant long before Containers started gaining traction (IMO). Don't get me wrong, I am a fan of containers (in particular LXC), but I wouldn't list those benefits as if they are unique or novel to container based workflows. Edit: To be clear, there _are_ benefits to containers over VMs, just not the things you listed above from m…

Overhead... it's all overhead. Starting and connecting to a VM isn't nearly as streamlined as connecting to a Docker container (even if it is also running in a VM).

Even the hurdle of SSH'ing to a VM is more cumbersome than `docker run`.

Certainly this could be automated and scripted, but the Docker solution is so... streamlined.

And I say this as someone that used to use Vagrant. With smaller installs available (such as Alpine), maybe more modern VMs would be just as easy as containers...

Also -- for me, VirtualBox was just "meh". It worked, but really wasn't that great. It always seemed like it took too many resources to run. That was another issue with Vagrant. (And yes, I did also use Vagrant with VMWare, but again -- that's a lot of overhead).

Re: VSCode, Dev Containers and Docker

#105

Post by Silhouette » Thu, Jan 21, 2021, 4:57 PM UTC

mediascreen wrote: post #89

marcus_holmes wrote: post #10

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?

At the agency where I work we have about 40-50 somewhat active projects at any time. Any given week I work with maybe 3 to 10 of them. It saves so much time to just pull down the repo, run "docker-compose up" and have everything running, almost exactly the way it's running in production. With the right node or php version, databases, Elasticsearch, Redis etc.

The problem I usually run into with this sort of arrangement is the database. Every non-newbie developer is very aware of using source control with their code. A lot of developers are careful about managing the dependencies for that code as well. But for the database, you have a second asset that often needs to be synchronised with the code, and that means both schema and possibly records as well.

Just deploying changes affecting both assets carefully in production can be quite awkward relative to a code-only deployment. You might need to do this in several stages, updating your code to allow for but not require the DB changes, then updating the DB schema, then maybe updating existing DB records, then at least one more round of code updates so everything is running on the new version of the DB. And you might need to make sure no-one else on your team is doing anything conflicting in between.

Doing the same in a staging environment isn't so bad because you're running essentially the same process. However, for a development environment where you want the shortest possible feedback loops for efficiency, you need to be able to spin up a DB with the correct schema, and possibly also with some preloaded data that may be wholly, partially or not at all related to controlled data you use to initialise parts of your database in production or staging environments.

It is not always an easy task to keep the code you use to access the database, the current schema in the database, and any pre-configured data to be installed in your database all in sync, and to ensure that your production, staging/testing/CI facilities, and local developer test environment are also synchronised where they should be.

Re: VSCode, Dev Containers and Docker

#106

Post by nly » Thu, Jan 21, 2021, 4:59 PM UTC

hctaw wrote: post #50

dhruvrrp wrote: post #22

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…

You seem to be missing the point of what we call a "Linux distribution". Shared libraries are fantastic and everything in /usr/lib should be shared

Re: VSCode, Dev Containers and Docker

#107

Post by physicsguy » Thu, Jan 21, 2021, 5:00 PM UTC

umvi wrote: post #94

dhruvrrp wrote: post #22

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!

We don't rebuild image every time. We store images in GitLab registry. Also, just because we use apt-get to install python3 doesn't mean build isn't reproducible. The actual toolchain and sysroot are highly version controlled and python is just used to kick off the build script so it almost doesn't really matter which version python is as long as it's backwards compatible with the build script.

We tried this in our research group, and found that issues come in when it gets to things like...

Oh no! CMake is too old a version to support a dependency we have to build in the image construction. So we better pull in a version of CMake from a PPA which is community maintained, and build it from source/etc.

Re: VSCode, Dev Containers and Docker

#108

Post by chrisjc » Thu, Jan 21, 2021, 5:00 PM UTC

dhruvrrp wrote: post #22

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!

Depends on how you do it, right?

For instance, we create base images configured with SDKs, libraries, frameworks, configurations, binaries, etc...

Those base images are then built, versioned, tagged and then pushed to our container repos ready to be used by developers, CI/CD, etc...

Images based on these base images never need an apt-get, pip install, etc... If there is a dependency missing, updated needed, etc... we'll create a new base image with it, following the steps above.

I would love some constructive feedback.

Re: VSCode, Dev Containers and Docker

#109

Post by IggleSniggle » Thu, Jan 21, 2021, 5:01 PM UTC

gspr wrote: post #34

A little bit off-topic, but I hope it's relevant enough: can someone who's well-versed in Docker give me some pointers as to how I can use it in a better way? Let me elaborate. I'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 dependenc…

Try thinking of it as `git` but for an entire OS instead of merely a filesystem, and that you have multiple branches of your git tree opened simultaneously in different locations.

Or think of it as a set of databases that include the combination of the current state and the code ("migrations") to achieve that state, while allowing those databases to share the same history.

In other words, containers are a solution to state problems, not only "works on my machine" problems. The benefits are reproducibility and shared resources. It is "functional OS" as in "functional programming," a pipe of common operations to apply to inputs to generate a consistent output, and which can be forked anywhere in the history/pipeline long as the pipeline does not hide held state.

Coming back to the `git` analogy, a traditional VM with Snapshots is like saving ProjectV1, ProjectV2, ProjectV3, ProjectV2_fixed, ProjectV2_fixed_final, while a container solution is saving only the history and places where histories diverge.

To answer your alternative question, nix package manager (which can also be run as a standalone OS, NixOS) is an interesting alternative solution from Docker. Reading its documentation may also help in appreciating the alternative set of perspectives.

Re: VSCode, Dev Containers and Docker

#110

Post by moistbar » Thu, Jan 21, 2021, 5:01 PM UTC

AnIdiotOnTheNet wrote: post #103

moistbar wrote: post #97

Earlier quoted context omitted.

Both apt and yum support installing to whatever directory you like as long as you have write permissions there.

Not really. They support dumping the package contents to an arbitrary directory, but you can't actually run the software from there without either the software having been written to support arbitrary paths (almost none is) or using namespacing and chroot to build it a sandbox wherein its baked-in paths actually work. Contrast that with something like RiscOS AppDirs, classic Mac applications, or Next/Mac Application…

You very much can run the software from those directories, what are you talking about? Those paths are handled by the OS itself as well through LD_PRELOAD and PATH.

If what you're saying were true, unmodified software wouldn't work in a Docker container, either.

EDIT: Here's the exact command to do what you're saying isn't possible: apt-get download package; dpkg -i --force-not-root --root=$HOME package.deb