3 ms·

At my company we just finished setting up a brand new docker dev container that we work out of, and it's awesome. However, it was absolute pain to get it to the

At my company we just finished setting up a brand new docker dev container that we work out of, and it's awesome. However, it was absolute pain to get it to the point where it's awesome, and the only way it worked at all was because of the fantastic new "Remote: Docker" docker extension that has been released with vscode. Our dev environment is intimately tied to vscode and its ability to interpret a special .devcontainer folder to automagically add in special additional dev layers with project-specific vscode extensions, run all relevant language tools as remote servers inside the container, and provide full intellisense over your project. My questions is, how the hell is anybody getting anything done _without_ all the features I just mentioned? I've found initial, paltry support for particular languages in JetBrains, etc. IDEs, and that's about it. None of the other IDEs have any real solution go getting multi-language intellisense from inside the container. Are people just like... exec'ing into the container and then dicking around in Vim? Or are people mapping all of the source in as a volume, running the IDE outside the container, and just forcing the user to have all the relevant dependencies installed on their host system if they want to see auto-completions, go-to-definition, etc. (thus completely defeating the purpose of containerizing your environment)? In my eyes, the only reason Docker as a dev environment makes any sense at all is because of the uniquely good support vscode offers, but I see it mentioned all over the docker website that it can help you make your development environment repeatable and exactly like your production environment. But... that doesn't actually work, like, at all... Can somebody help me understand what I'm missing?

dmead 7y ago
the second thing. we do this heavily. you map the source directory as a volume and then run the editor outside the container.
- sebastos 7y ago
  Do you mind if I ask whether you're using some kind of stack where auto-completion, intellisense, etc. is not dependent on any system libraries or dependencies? Or do you just require the developer to install all of those libraries and dependencies on bare metal as well? If it's the latter, isn't that defeating half the purpose of containerizing it? My prediction is that you might be using a stack where it's not a big deal to isolate project-specific dependencies, npm or virtual-env style. And so in that context, it's not a big deal to ask developers to do a pip install -r requirements.txt or whatever, and then the docker container's job is just to emulate the runtime environment. It has just always made sense to me that the win of dockerizing your dev environment would be that you could reproduce it on another machine with a docker pull, so those sort of "half-way" workflows were unsatisfying to me. I'm always curious to hear how other people are doing it though - thanks for responding.
  - jzoch 7y ago
    I think the idea others are getting at is using docker as a means of setting up a testing environment in your dev env, not using it as a dev env. I tend to do this (though the way you describe would be great too!). I develop locally with intellij but run my integration tests in a docker container (or a few) by packaging up my app in a container. I just make that container look like whats running in prod. Thats the magic. dev looks like prod.
  - dmead 7y ago
    I'm not using intellisense or anything. the editor is left to the developer whos workstation the environment is running on. The docker approach for this is just to manage the build in a way that is like the CI pipeline. we have a shell script that adds some syntactic sugar around running docker in a consistent way, but other than that it's left to the dev how they want to manage the editor process.
goblin89 7y ago
Having the environment containerized, you can run the software on your hardware in conditions equivalent to production. That’s it; whether or not your IDE also uses the environment inside the container doesn’t detract from that. Personally, I don’t care for auto-completion or go-to-definition, but I want to be as sure as possible that if my software doesn’t break in development then it won’t break in staging and production.
- sebastos 7y ago
  Interesting. >Personally, I don’t care for auto-completion or go-to-definition What about just plain old syntax highlighting to make sure your imports are resolving? Do you just run vim from inside the container or something, and then find out whether it builds / works by running the container? Like, say you had a Python project that you were going to containerize. Do you perhaps do the actual editing of the source on your dev machine, with all of the relevant libraries installed into a virtualenv or something? If that's the case, then it's basically a guess-and-check workflow, right? There's nothing strongly enforcing your virtualenv to match what's in the container. And there's nothing about having the container that saves you from having to setup your local environment in a way that's suitable for that particular project. That just doesn't seem like "developing out of a container" to me. More like... using containers as a local test environment, or something like that. Maybe you're just explaining why the Docker folk feel it's reasonable to say that Docker improves the development experience, putting aside whether they imagine you literally sync'ing up your IDE up with a container as I was describing.

dmead 7y ago

the second thing. we do this heavily. you map the source directory as a volume and then run the editor outside the container.

sebastos 7y ago
Do you mind if I ask whether you're using some kind of stack where auto-completion, intellisense, etc. is not dependent on any system libraries or dependencies? Or do you just require the developer to install all of those libraries and dependencies on bare metal as well? If it's the latter, isn't that defeating half the purpose of containerizing it? My prediction is that you might be using a stack where it's not a big deal to isolate project-specific dependencies, npm or virtual-env style. And so in that context, it's not a big deal to ask developers to do a pip install -r requirements.txt or whatever, and then the docker container's job is just to emulate the runtime environment. It has just always made sense to me that the win of dockerizing your dev environment would be that you could reproduce it on another machine with a docker pull, so those sort of "half-way" workflows were unsatisfying to me. I'm always curious to hear how other people are doing it though - thanks for responding.
- jzoch 7y ago
  I think the idea others are getting at is using docker as a means of setting up a testing environment in your dev env, not using it as a dev env. I tend to do this (though the way you describe would be great too!). I develop locally with intellij but run my integration tests in a docker container (or a few) by packaging up my app in a container. I just make that container look like whats running in prod. Thats the magic. dev looks like prod.
- dmead 7y ago
  I'm not using intellisense or anything. the editor is left to the developer whos workstation the environment is running on. The docker approach for this is just to manage the build in a way that is like the CI pipeline. we have a shell script that adds some syntactic sugar around running docker in a consistent way, but other than that it's left to the dev how they want to manage the editor process.

goblin89 7y ago

Having the environment containerized, you can run the software on your hardware in conditions equivalent to production. That’s it; whether or not your IDE also uses the environment inside the container doesn’t detract from that. Personally, I don’t care for auto-completion or go-to-definition, but I want to be as sure as possible that if my software doesn’t break in development then it won’t break in staging and production.

sebastos 7y ago
Interesting. >Personally, I don’t care for auto-completion or go-to-definition What about just plain old syntax highlighting to make sure your imports are resolving? Do you just run vim from inside the container or something, and then find out whether it builds / works by running the container? Like, say you had a Python project that you were going to containerize. Do you perhaps do the actual editing of the source on your dev machine, with all of the relevant libraries installed into a virtualenv or something? If that's the case, then it's basically a guess-and-check workflow, right? There's nothing strongly enforcing your virtualenv to match what's in the container. And there's nothing about having the container that saves you from having to setup your local environment in a way that's suitable for that particular project. That just doesn't seem like "developing out of a container" to me. More like... using containers as a local test environment, or something like that. Maybe you're just explaining why the Docker folk feel it's reasonable to say that Docker improves the development experience, putting aside whether they imagine you literally sync'ing up your IDE up with a container as I was describing.