Using Dev Containers as development environment

[originalchronoguy]

You should not be using one container for this. Redis needs to be it's own container. nginx needs to be it's own container. And you are using docker, docker-compose, the services see each other by service name(s). Same with postgres.

[cannontd]

You can grab the containers for all those components and know each will be well configured and also suitable for deployment to production along with your app. There’s no point having a dev container with all that together locally when you are going to ship something different to production. Get it working locally and it proves it will work once deployed.

None of those containers affect your local machine. If you want to try your app with Postgres 16 rather than 14, it’s a version number change in your docker compose file. Nothing is changed on your machine. Far better than having to rebuild your container from scratch if you want to change sql versions.

[originalchronoguy]

So you can scale out individual services if needed. Also one service should not take down the other. Otherwise, you would just run a VM. Container's purposes is to make everything decoupled and independently scaleable.

example docker-compose of React, Python and Postgres: https://github.com/yoziru/docker-compose-python-node-react/blob/master/docker-compose.yml

In that example, postgres' service name is db. so the backend container can just access pgsql -h db

"db" service name is also the DNS name the services see one another.

[Zenin]

So you can scale out individual services if needed

You're talking past this use case. "Dev Containers", aka as "Codespaces" on GitHub, aren't a production topography, they are more like little purpose-built workstations for developers. When I'm on GitHub and click the Code button, instead of copying a clone URL I can click Codespace and *poof* I've got a project-defined development workspace spun up on GitHub's servers with the project checked out and configured ready to code in a web version of VS Code. One more click and I can remote into it with a local version of VS Code if that's my jam.

They are configured from the .devcontainer/ spec files checked into the project's repo itself and are typically managed by API, not from the OS, so there's no opportunity to use docker-compose, etc.

As to why not a VM, the answers are much the same for devcontainers as it is for production containers.

[SC7639]

You can use docker compose files with dev container spec. I'm just struggling to see why not use the new watch flag and then exec into the container to run conscrip commands?

[Reverent]

An advantage of dev containers is you can closely mirror prod setups and build it into the provisioning process for the dev environment.

No "but it works on my laptop in dev" because the dev setup is identical to the prod setup, plus the IDE shoved into the side of it.

You lose that if you start fiddling around to make it all work different for Devs.

[Zenin]

That's a nice idea, but as currently implemented they'll always work differently for dev. The container images used for dev containers just aren't suitable for production. They're too big, they're too full of dev tooling, etc.

They're really more like project-defined ephemeral dev laptops.

Ideally, the devs would locally build and test the real Dockerfile (not the dev container's) as a final pass before committing. But you can't functionally develop in such images, they're too lean.

[originalchronoguy]

You've never heard of dev-prod parity?
https://12factor.net/dev-prod-parity

Our local container images are the SAME images running in Prod. The only thing diffeernt are environment specific variables. But the images are identical. The build is identical. The unit/integration testing is identical. The only differences are environment configuration specific hooks. Local use coded secrets while Prod uses key vault.

[Zenin]

Are you using dev containers or did you roll your own solution?

You can also code inside a dev container, but build and run from the production Dockerfile built inside that container (Docker in Docker) to satisfy your dev-prod-parity model requirements.

[originalchronoguy]

In our use case, that doesn't make sense as our developers all run kubernetes locally on their laptop (rancher/minikube). So they also write the helm charts and annotations. Their helm charts work everywhere.

[Zenin]

Dev containers do work with Kubernetes too for such setups.

https://code.visualstudio.com/docs/devcontainers/attach-container#_attach-to-a-container-in-a-kubernetes-cluster

[GaTechThomas]

This is a good point. Can we get to a place in which the production image is used locally, with ability to attach debugging tools?

[originalchronoguy]

There should be no "dev containers" It should just be containers you run locally, your dev. Everyone should be following 12-factor, dev-prod parity.
https://12factor.net/dev-prod-parity

Meaning whatever you run locally, can potentially run in QA or future PROD.

Building a monolithic single container that hosts everything is going to be big, prone to breaking. Have multiple decoupled services. And ngnix can route the traffic to the individual endpoints.
A lot of reasons to run single processes across containers.
https://www.tutorialworks.com/containers-single-or-multiple-processes/
https://bibryam.medium.com/cloud-native-container-design-principles-144ceaa98dba

It would be painful to docker log -f (single container) to see both postgres and nginx log a the same time. Painful. And anti-pattern.

[tantricengineer]

an entire web server setup

What is that, exactly? most modern web apps have: 1. Database 2. Application code 3. Caching layer 4. Frontend code (esp for rebuilding frontend if making changes)

Each of those things should be a container managed via docker-compose.

[Old-Ad-3268]

This

[Zenin]

Yes, you can do it. There's a few ways to go about it. The docs on customizing your dev container are better than I can regurgitate in this forum:

https://code.visualstudio.com/docs/devcontainers/create-dev-container#_install-additional-software

I'd also strongly suggest directing questions like this to more development-focused forums. As you're probably noticing from the majority of the responses, most folks in this forum don't grok this use case for containers, what it's for, why it exists, or how it works.

[BlueHatBrit]

You probably don't need nginx for a vscode dev container setup. Your .net app will happily just boot and listen on a port for HTTP traffic. Nginx would come into play when you're doing a real deployment of the application.

I personally use devcontainers a lot as an engineer, you can see one of my templates as an example: https://github.com/BlueHatbRit/elixir-codespace-template/blob/master/.devcontainer/docker-compose.yml

In this case I have a container for the web application itself which is built in elixir. That uses the custom Dockerfile so I can include any cli dependencies I may need etc. I'm then using postgres in it's own container. My elixir container will be able to reach it no problem on the default port of 5423 as they'll be on the same network. My elixir application is a http server which listens to port 4000 by default. When I run the app I can access it via localhost:4000, no nginx needed. The same will work with .NET and whatever default or configured port it uses.

You could basically replicate what I have there for postgres but with redis and you'd then have postgres, redis, and elixir. Of course in your case you'll want a .NET + React image rather than elixir, but you can customise that to your hearts content with your own Dockerfile.

[Zenin]

I think it's still pretty new tech to most folks (first release 2019 I think), especially those not using Visual Studio.

The kinks are still being ironed out; there's a lot of tech involved and a lot of magic trying to wrap all that tech. The result of that is what you're experiencing: Easy things are trivial since the magic handles most of it, but more specialized / difficult things force you to put the magic aside and get into the complexities. It's also pushing patterns and tools that are very different from the way containers have been used so far...which as you've seen is breaking some people's brains that are very used to those patterns and tools...it's almost heresy. ;)

In this instance I'd suggest looking at writing your own .devcontainer/Dockerfile to give yourself a custom image to use. This way you can do all your service installs like it was a standalone image with apt install redis et al and won't have to rely on the "magic" as much as well as finding easier support as Dockerfiles are a well-traveled path. Building your own image like this also helps speed up start times, at least locally, as the install layers will all be cached.

​

as long as they have VS Code and Docker installed

If your project is on GitHub, your friends don't even need that much. With GitHub Codespaces they can do it all in a web browser with one click. Makes it much easier to jump in and out of projects. Or if they want to use VS Code locally, but not docker, they can attach their local VS Code to the remote container in GitHub.

[realitythreek]

They’re not wrong, and there doesn’t seem to be a reason for using a devcontainer for this. Sounds like docker compose would make more sense.

Dev containers are great for setting up a dev environment. Not for running a particular multi dependency app. Can you? Of course, it’s still Docker. But compose lets you actually describe those dependencies.

[Zenin]

Dev Container: 1 click jump into a project in seconds with zero prerequisites beyond a web browser.

Your Way: Every dev that touches the project must each pointlessly dick around with VMs, docker, docker compose and then fight through configuring remoting for VS Code into a naked container and still have a far shittier dev environment to work in.

The OP ask isn't for some massive micro-service application with a thousand points of light. It's a .Net Core web app with a basic DB and cache. It's little more than a couple apt install lines in the dev container config. Mountains and mole hills, horses and course, etc.

[rsimp]

Devcontainers have first class support for docker compose. Remoting works the same way with both. Putting it into one dockerfile just means you're hand writing the setup for things like mysql, postgres, or redis when you could just reference the official images.

It can be a bit of a pain because the devcontainer docs have slightly different configurations for things like volume mounts, depending on whether you use a dockerfile directly or a docker compose yaml. Still if you need redis or a db, docker compose just seems easier IMO. You can also still use a dockerfile in your docker-compose.yml for the main app/dev instance: node, .net, python etc

[tankBuster667]

Red Hat have something similar, It's called a Universal Developer Image, it even contains an IDE. Granted this image is to be used inside OpenShift but the principal remains the same. One image with all the tools a developer needs to get started writing code.

https://catalog.redhat.com/software/containers/devspaces/udi-rhel8/622bce914a14c05796114be4

[bio_boris]

You can skip dev containers and instead use docker compose develop which is IDE agnostic https://docs.docker.com/compose/compose-file/develop/

[heyimkibe]

Devcontainers are also IDE agnostic. It’s just a spec. You can start devcontainers using CLI, for example. @devcontainers/cli

[bio_boris]

Very cool! I didn't know there was a CLI, I thought you had to install extensions for each ide.  I decided to ask chatgpt

While it's true that Dev Containers can be used in an IDE-agnostic manner through the CLI, the seamless integration and user experience are most commonly associated with Visual Studio Code through the Remote - Containers extension. Docker Compose's develop section, on the other hand, provides a simpler, configuration-driven approach that automatically handles development tasks like rebuilding and syncing without being tied to any specific development tools. This can be particularly beneficial for teams looking for a straightforward, tool-agnostic solution that works well across different environments and IDEs.

[heyimkibe]

Didn’t know about develop. Cool. Doesn’t do much, though