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

121–130 of 234 posts

Re: VSCode, Dev Containers and Docker

#121

Post by brianm »

gingerlime wrote: post #99
cpuguy83 wrote: post #44

Earlier quoted context omitted.

I use vscode to connect to a a cloud vm. VSCode is surprisingly good at this. Client is local and connects to an vscode server over ssh. Granted I work on Azure and the cost of the vm is not something I have to worry about.

We also use remote dev boxes, but can VSCode connect to a remote server and connect to remote docker containers? For example, I don't have ruby installed on the remote dev box, but it is installed inside docker on the remote host. I also don't have ruby or docker running locally. I think all the linting plugins either expect ruby to be available on the remote host, or inside docker, but not this combo... Is there som…

> can VSCode connect to a remote server and connect to remote docker containers?

Yes, it can. https://code.visualstudio.com/docs/remote/containers-advance... talks about setting it up.

Re: VSCode, Dev Containers and Docker

#123

Post by Silhouette »

mediascreen wrote: post #111
Silhouette wrote: post #105

Earlier quoted context omitted.

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.

The challenge is how you keep your migrations, source code and any seed data synchronised, but only where they should be. There is often a need for any separate migration process/scripts to be synchronised with corresponding changes to the DB access code in the main application, so the models in the application code always match the actual schema in the database. For seed data, there may be some "real" data that should always be present but also some "example" data you want to include (and reset to a known state) for each test in an integration test suite. Etc.

It kind of amazes me that there doesn't yet seem to be a way of handling this in the web development community that has become a de facto standard in the way most of us look at tools like Docker or Git these days.

Re: VSCode, Dev Containers and Docker

#124

Post by AnIdiotOnTheNet »

moistbar wrote: post #110
AnIdiotOnTheNet wrote: post #103

Earlier quoted context omitted.

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

I was going to give you the benefit of the doubt and actually try this so I could show you that you are wrong, but I couldn't even get that far because dpkg always complains it is unable to access the dpkg status area. So clearly this is not as trivial as you make it out to be. I suspect because it expects a full filesystem in $HOME with its status file in the appropriate place. In other words, it is expecting a whole separate installation to be under $HOME.

Regardless, lets assume it did work. Here's what it would do: unpack the package replacing '/' with '$HOME' in the destination paths. That's it. That software will not magically be able to find its associated libraries and configurations without the user mucking with environment variables at best, or chrooting or sandboxing such that $HOME appears to it to be a wholly separate installation.

That's not how sane systems do this sort of thing. I have been trying to do this sort of thing in Linux for pretty much as long as I have been using Linux because I loathe the way Linux installs software, and in 20 years it has never been straight forward. AppImage is a close as we get and software needs to be carefully built and packaged for that.

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

> [...] or using namespacing and chroot to build it a sandbox wherein its baked-in paths actually work.

Re: VSCode, Dev Containers and Docker

#125

Post by lpasselin »

mosselman wrote: post #39
lpasselin wrote: post #16

Earlier quoted context omitted.

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.

> Super easy for new team members to get started on a project. No need to manually install dependencies. 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?

Not how often people switch companies but how often people work on different projects. Someone working on multiple projects can waste a lot of time keeping up with the environment of each project.

Re: VSCode, Dev Containers and Docker

#126

Post by lpasselin »

0x008 wrote: post #112
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...

This is what I used (combined with stackoverflow posts) to try it.

Re: VSCode, Dev Containers and Docker

#127

Post by carlosf »

onion2k wrote: 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.

Not sure about OSX, but in Windows 10 + WSL 2 Docker development can be made faster by cloning code directly to a volume.

Re: VSCode, Dev Containers and Docker

#128

Post by carlosf »

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?

That`s how we do it in my company:

- Clone project

- Build container

- Develop

If you're in a polyglot shop there are HUGE productivity gains in not needing to setup your environment manually, or worse, risk that vital information about it is distributed as tribal knowledge.

Plus, if your project has external dependencies like DBs, S3, etc... you can use docker-compose with VS Code as well.

Re: VSCode, Dev Containers and Docker

#129

Post by carlosf »

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…

It actually makes your workflow more powerful as you can package it in a container and other devs can start using it in no time.

Re: VSCode, Dev Containers and Docker

#130

Post by AnIdiotOnTheNet »

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

The majority of "shared" libraries are used by exactly one application: https://drewdevault.com/dynlib

It makes absolutely no sense to pollute a global namespace with these.

Post reply on HN