Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VSCode, Dev Containers and Docker

blog.feabhas.com

Post reply on HN
Print view View original

111–120 of 234 posts

Re: VSCode, Dev Containers and Docker

#111

Post by mediascreen »

Silhouette wrote: post #105
mediascreen wrote: post #89

Earlier quoted context omitted.

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 chan…

I agree that the database (and things like uploaded images) can be a challenge. For WordPress we usually sync down from production, to staging, to testing, to local (while filtering out PII). For other projects is't usually easier using migrations and seeding.

Re: VSCode, Dev Containers and Docker

#112

Post by 0x008 »

lpasselin wrote: post #42

One slight problem I had with .devcontainer in VS Code was running the devcontainer on a remote ssh server. Remote SSH works. Local devcontainer works. But mixing the two requires configuring the docker engine settings to point to the remote. This forces other projects to also run on the remote machine. This was a problem as of 2 months ago.

Does this help?

https://code.visualstudio.com/docs/remote/containers-advance...

Re: VSCode, Dev Containers and Docker

#113

Post by hctaw »

nly wrote: post #106
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…

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

I don't appreciate the condescension, is it not fairly well known that shared libraries aren't typically shared at all? You can distribute software that is reusable and packaged for many machines (the ultimate sense of "shared" in my opinion) but that's difficult when it relies on distribution-specific nuances and packages.

Do you really enjoy having separate packages for the same software for each flavor of package manager that does the same thing? Wouldn't it be nice if we didn't have to use containerization to distribute the same software to machines running a kernel with a stable ABI?

Re: VSCode, Dev Containers and Docker

#114

Post by OnlyOneCannolo »

UweSchmidt wrote: post #67

As amazing and convenient as Docker is in practice, containers hide the inherent mess that is modern computing, and the more they are used, the less chance is that this mess is getting cleaned up... ever. Ultimately this is another dependency, complexity hidden by another layer...

I agree. While I understand the practicality of Docker and facilitating development using it, I wouldn't call it "forward" progress.

The fundamental problem, as you say, is that our dependency ecosystems don't meet our requirements. Docker is one way to avoid the problem without fixing it since it's easier. Forward progress would be to fix the problem.

On one hand, Docker removes some pressure to fix the problem and encourages perpetuating it. On the other hand, maybe it gets people to think about the problem more. I don't know which influence is stronger.

Re: VSCode, Dev Containers and Docker

#115

Post by Silhouette »

gameswithgo wrote: post #70
UweSchmidt wrote: post #67

As amazing and convenient as Docker is in practice, containers hide the inherent mess that is modern computing, and the more they are used, the less chance is that this mess is getting cleaned up... ever. Ultimately this is another dependency, complexity hidden by another layer...

agreed. that docker is needed represents a failure of our industry

I'm not sure I quite agree with that. Having a controlled environment in a sandbox of its own clearly has benefits, both for consistency of what you're running and for safety if it doesn't work as you expected. It doesn't need to be Docker specifically that we use to create such an environment, but if not Docker then we'd surely have looked for some other way to achieve the same result.

Re: VSCode, Dev Containers and Docker

#116

Post by nly »

treis wrote: post #91
IggleSniggle wrote: post #61

Earlier quoted context omitted.

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

Since they're lighter weight it's easier to run more of them. Think of a place with 7-8 different applications, a few different DBs to support them, redis, elastic search, etc. You can spin up a mirror of your production environment with one command. Theoretically you can do the same with VMs but it will consume a lot more resources.

This is only true of Docker on Linux hosts.

Re: VSCode, Dev Containers and Docker

#117

Post by 0x008 »

While I love that VSCode can do this and I would like to appreciate a post about the topic, I wonder if I should upvote a blog post that adds almost no value over the existing VSCode documentation which is basically excellent already and covers every use case I ever stumbled upon.

Re: VSCode, Dev Containers and Docker

#118

Post by ywei3410 »

Silhouette wrote: post #105
mediascreen wrote: post #89

Earlier quoted context omitted.

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 chan…

There's also mutual deployments which suck really bad i.e. deployment A needs to go out with deployment B; but if you haven't set up your CI with that facility (and, let's face it, the easiest way to set up a CI with multi-repos is on a per-repo basis), it can get really hairy.

Re: VSCode, Dev Containers and Docker

#119

Post by chrisjc »

ducktective wrote: post #5

Does this deprecate my vim/gcc/gdb/make (in general "CLI driven workflow") which I have assigned so much time to, to have a nice vender/IDE-independent solution for development? I'm curious to know the answer in an honest/practically-speaking sense not ideologically. IMO, the downside of this container/web-app solution is the memory size that all the SDKs would need and this would add up eventually. But I'm not sure…

I don't think so. If fact you could just package your "CLI driven workflow" up into a docker image and now you can instantly move it between machines, peers, etc...

Furthermore you could version and manage the evolution/drift of your workflow as underlying components change/get updated.

Post reply on HN