Developing with Docker

That's why there is the meme. Docker doesn't always solve this, or even often on its own. You can't just "build image to docker" and expect things to go okay and pretend you can be agnostic about its prod environment (you kind of can, but usually requires an ops team supporting whatever assumptions your image made).

It's been addressed in other comments but you have:

- differences in architectures, CPU, memory

- if the docker image has a volume attached, unless local perfectly represents prod, you're going to have issues

- networking and firewall rules can be drastically different than a production environment and the assumptions made there

- differences in RBAC/IAM/etc. between local and prod could go on and on.

In reality, this is a nice idea, in practicality, it almost never works 1:1. The common refrain is "well just make the local/dev/sandbox exactly match prod" and my point is this is often unrealistic to the point it cannot/won't happen. If you can do it, good for you, I just personally have never seen this work as simply the author describes it in a system of any kind of complexity.

> What if running the linters was as easy as:

> $ docker compose exec web /scripts/run-linters

What do people do for making these kinds of commands less verbose and easy to remember?

We've done things like use Makefile with the above behind `make lint`. However, chaining together shortcuts like "make format lint test" gets slow because "docker compose" for each one takes time to start up.

If you instead run the Makefile while you have a terminal open inside one of the Docker containers, that can be faster as you can skip the "docker compose" step, but then not every Makefile target will be runnable inside a Docker container (like a target to rebuild the Docker image), so you have to awkwardly jump between terminals that are inside/outside the Docker container for different tasks? Any tricks here?

I was hoping the article was about using a Docker container *as* your development environment. Talk about easily compartmentalizing and standardizing your projects across machines.

Imagine if you got to a new job and your setup instructions were literally `docker pull mycorp:development.mobile && docker run mycorp:development.mobile`.

- Oh, your machine was lost? Take your new machine and docker pull docker run.

- Someone migrated project A to python 3.8 but project B still requires python 3.6? docker pull docker run.

- You have to work on some backend code? docker pull docker run.

- But the backend code uses an IDE that I don't have installed. Docker Pull! Docker Run!

Every job I've ever started has come with a sheet explaining how to set your machine up to work on the codebase. Install this, upgrade that, change this environment variable, and for the love of god don't install a newer version than this. I mean, I know I've been lucky to get a sheet, but this is usually the first full day of work.

I've never really tried to get this going. I assume that it'd be possible to get an OS instance up in docker that you just VNC into. Load up that image with the tools you need (IDE, git, etc.), wire up some stuff for security (GitHub keys, probably other stuff), and clone the initial commit of your repo so that people can just `git pull` the rest.

Maybe this is a thing. I haven't looked in a few years.