[mattlondon]

I would also be interested to know what the typical dev workflow is like these days when working with containers.

Like do you just run e.g. nodejs or javac locally and then "deploy" to a container, or do you have a development container where you code "in it", or is a new container built on every file change and redeployed?

At my current place of work, all of this is totally abstracted away so no idea how real world people do it!

[dude187]

Typically I use a multi stage build so I build the app in one container, and copy the result to a final output container. That keeps the final container clean and lightweight. Pure local development I prefer to do locally outside of any container.

There's certainly patterns you can use to run things like auto compiling code (think angular app in dev server mode) as you save in a container to ensure a consistent dev environment. However, I usually find that you're fighting the operating system and dev tooling on things like volume syncing that makes it not actually a net benefit. Though if I were to tackle getting my 100 devs consistent and I know they all have the same OS layout it probably would be worth it.

The only time I tend to code "in" a container is when it's a very large code base with complicated dev tooling, or tooling I need to containerize to avoid clashing with my OS. In that case I build a "build container" and run it with a volume mount pointing to my working directory, rather than do a docker build. For a large code base, the purist "build with docker" approach requires copying that whole build context each time. Causing the build to take forever and thrash disk space

[NumberWangMan]

I'm not sure if my workplace is "typical", but what we do for local development is only to use containers for dependencies, such as the database, or localstack (an AWS emulator). We have bash scripts that can set up and tear them down, using docker compose. Typically, we create a database container and then use it until we need to restart it for some reason, such as if the schema has changed.

There's a shared repository we use that hosts all our migrations and has a script to refresh a set of schema files that define our current schema by running the migrations against a fresh, empty database container; this repository is referenced by our code repositories as a git submodule.

We have one shared database that multiple apps use, and the above setup has worked out reasonably well for us. It's not terribly fancy, and I'm sure there are better ways out there we haven't discovered, but we have a good amount of flexibility.

Also, that's all just for local manual testing/exploration -- we also use Java's "testcontainers", which spins up its own containers (though basically the same idea) for automated tests to run against. Testcontainers lets you specify how it restarts the containers -- after each test class, after each test run, or not at all. Restarting the container is pretty slow, so we have it set up to just drop and recreate the relevant databases within the container.

For deployment, we've used different platforms that deploy apps in containers, but we don't manage the containers directly.

Also, I've tried the "develop in a container" thing but only on rare occasions, such as to work around a MacOS bug that makes CIFS file sharing horribly slow. Technically that was a Vagrant VM, not a container. Haven't had much luck with it otherwise -- it seemed like more trouble than it was worth (it's the awkward file syncing that's the barrier for me).