Has Anyone Used Dev Containers for Elixir Development?

Questions / Help
1

Recently, I’ve heard people using dev containers for development. I want to give it a try—has anyone here developed an Elixir app with them? Any tips or experiences would be appreciated.

I’m working on an Elixir cluster (Phoenix + Postgres) on macOS, with Kubernetes as the deployment environment.

1 Like
2

I know that my co-worker is using containers for development, though I don’t know if he does it the dev-containers way.

Also I don’t know if he is active on this forum or whether he has an account.

1 Like
3

Personally I’d advise using something like devenv.sh instead of a dev container. Most of the advantages without the disadvantages of Docker.

Been using that for two years, a dev can switch between any project and have the exact same setup as any other dev in a matter of moments

4 Likes
4

They are nice for a uniform and reproducible development environment.

They are NOT great when used in github’s browser based devcontainer environment ( extremely slow, laggy ).

I see it as trading in one set of problems for another. ( easily reproducible dev envs, for docker debugging issues )

In the same sense that having a web app inside the container network is a pain, because you’ll have a layer of problems arise from the internal DNS, networking layer, volume mount issues, files missing, etc, meaning there’s more stuff to go wrong in comparison to just having the standard stuff go wrong ( service ports not open, dependencies missing )

just my opinion, nice for initial start, less nice for long term debugging, but still okay

It’s a layer of abstraction, so it doesn’t help developers with learning how to do things manually when stuff goes wrong.

It might just be how i like things, but it really bugs me when tools get in the way, and its especially true for visual studio code and dev containers, its just a layer ( hey its great if its working, but at the same time, I don’t want to spend a few hours debugging/configuring/diagnosing the tool, the plugin, the whatever, just so i can get to the work )

3 Likes
5

Hi! I just created a template for a Phoenix 1.8.3 project using Docker and Docker Compose, both for production deployment and for running Docker Compose in development mode.

Feel free to download it and adapt it to your needs. If you have any questions, you can send me a message — I’d be happy to help you with whatever you need :slight_smile:

2 Likes
6

I’m wondering if the question was originally about this?

See:

I only did a quick skim of the repo you shared ( which looked promising for sure ), or maybe I misunderstood the original question.

I thought the original question was about devcontainer.json setup?

I think it’d be straight forward to vibe into your template_docker_dev repo?

7

Thank for your suggestion!

Actually, I thought about dev container because it have same env for dev & deployment environment. We have some issues in early day when we run project on multi environment (macOS, Windows).

8

Thanks for sharing! It sounds like we might be creating more trouble instead of making things simpler. I’ve spent a lot of time bringing the local/dev cluster to Kubernetes, and that’s also why I started thinking about dev containers.

Currently, I use the Zed editor for development (VS Code is too slow for me). I develop with multiple nodes, so that might be an issue if I use dev containers.

9

Thank you so much!

10

Do you mean Create a Dev Container? I’m a bit confused about the original question.

Or just like containers in general? like docker containers, kubernetes pods with helm charts?

Cause then what rocket4ce posted is totally relevant.

But my recommendation would be to make it easy to run the web app locally outside of the container network, as many things can break down in the container for webapps, debugging, stdout, stderr, tty for breakpoint debugging, gdb, valgrind, delv, etc

As far as just general k8s related container tooling there’s tons of it, but several come to mind for general pod development classically I have used minikube, more recently i’ve looked at k3s, and tilt i really like the spirit of what tilt has going on, especially for any sprawling microservice architecture ( 7+ services ) ( but again a level abstraction, and yet another tool, and I haven’t used it enough to find out how much it complicates things )

But this doesn’t solve the issue of installing the dev dependencies themselves, which is why I thought you were asking about devcontainers.json, which i’d second a vote with DGollings suggestion using the nix based devenv.sh

11

" Do you mean Create a Dev Container? I’m a bit confused about the original question."

Sorry for not clear question, I want to ask about experience & pros/cons when work with dev container. Your answer in last post is good info for me.

1 Like
12

I am currently using dev containers for development of all my Elixir projects. I created it using a template in the initial setup of the dev container but I don’t find the template anymore, it seems it is not maintained anymore.

Recently I noticed more and more problems with using dev containers as the ssh-agent starts to break down and I cannot use them to interact with Github in the container anymore, I have to use the terminal outside the container. Now the performance of the language server is also getting worse and worse and I am thinking about switching to a different environment.

1 Like
13

We are using Dev Containers at work. I think of them as a local minima in the current dev tooling landscape. They come with some downsides, sure. But the friction from not using them on a multi-disciplinary team is worse.

Pros:

  • Gets everything else working too: Your app probably has a collection of non-Elixir software that also must be in place to work. For us that includes multiple DBs and an emulator for testing. Using a Dev Container means all of the software needed for development is covered.
  • Uniform experience across languages: We use multiple languages. If you want to check on something from another team’s repo, you don’t want to have to get a separate dev environment up and running too. This also applies if you’re using something like Rustler in your Elixir app.
  • Works for multiple experience levels: Many devs you work with won’t be experienced Elixir devs. A Dev Container ensures that they can do their work too without having to pair with a senior Elixir dev every time something in the configuration changes.
  • Good VSCode experience: The VSCode integrated Dev Container workflow is quite nice.

Cons:

  • Slow on MacOS: Using a Dev Container in VSCode on a Mac is slower. Though this is no where near as bad as it was years ago. So if your impression of container speed was set a long time ago, you should reassess.
  • Poor support for non-integrated editors: E.g. I’ve been watching this Zed issue tracking integrated Dev Containers for some time. (Side note: there appears to be a PR now! I’ll be checking that out after I write this comment.)
  • New concepts: You have to now learn a new tech stack that is not really required to run your production app (though there will be overlapping concepts if you deploy with K8s). This held me off for a while and I’m still not an expert.
  • General docker pain points: E.g. mounting and networking are a pain. IME that doesn’t go away.

Despite the cons, the uniformity and consistency of the Dev Container experience are worth their weight in gold. If you’re a solo dev this won’t be as big of a deal (though even then it makes managing e.g. multiple Postgres versions on your machine, say one per project, much easier.) But if you’re on a team I recommend taking on the complexity.

2 Likes
14

What is the advantage of dev containers versus a docker-compose.yml file + an .env file that gets auto-loaded when entering the directory via f.ex. the direnv program?

15

Thank for sharing, I need a dev environment that can run on multi platform (macOS, Windows & Linux) and new member doesn’t need to setup & config a ton of repos.

Almost dev can understand docker then I think it isn’t a cons for now.

For me, not support for Zed editor is a pain point, I usually work with 4-6 repos VS Code is too slow :face_exhaling:

1 Like
16

dev-containers.yml gets into the business of configuring the editor, plugins, shell environment, etc and running that inside of a container. The editor GUI becomes a client to LSP etc running elsewhere. This allows you to replicate the experience on desktop or Web (some companies offering remote development environments).

docker-compose.yml is limited to services that make up your project. Editor, plugins, LSPs, shell, is up to the developer.

Which one you choose depends on what you want to standardize/make readily replicable vs the imposed limitations.

5 Likes
17

@manhvu pretty much nailed it.

I’ll also add that a few members of the team (myself included) worked through this book while deciding how to improve the DX at CargoSense:

It explicitly eschews Dev Containers, instead recommending a combination of Docker and Bash for dev environments like you’re suggesting. One annoying thing with this approach is that you can’t “develop normally”. All commands like mix test need to be mediated by Docker, so you need to prefix every command with the correct docker incantation to get it to run in the container.

The book solves this problem with a collection of well designed bash scripts (some of which we adopted anyway despite using Dev Containers). But that solution is incompatible with editor features such as integrated testing/debugging which would otherwise be available. So you’re still blunting your tools if you go this route.

For the time being, we’ve settled on Dev Containers because using them is as close to developing without Docker as possible, albeit with the caveats listed above. But if you’re not sold on Dev Containers but are still interested in Docker, that book is worth looking into.

1 Like
18

Thank you, will do!

So far I never worked on a project where a combination of a Justfile and docker-compose.yml has not gotten the job done but admittedly I steered away from too much infra / dev complexity for a while. I know many don’t have that luxury.

2 Likes
19

Hey sorry, I accidentally credited the wrong person and now I can’t edit my post. It was @rhcarvalho who correctly outlined the benefits of Dev Containers over docker-compose.yml alone.

2 Likes