"Don't put the app inside Docker", when that's the whole point of Docker. It's one thing to support arbitrary repointing of local vs containerized system components via application configuration. But don't rule out the primary use case for Docker: running application processes.
"Use docker-compose", when minikube is available. Both Docker and minikube prepare an application for production Kubernetes deployment. But docker-compose is wasteful.
> "Don't put the app inside Docker", when that's the whole point of Docker.
I'm afraid you misread the article. The article mentions that the whole point of a Docker image is to deploy the application, but it "shouldn’t include the actual application code itself". The article is focused on local deployments to test and debug code.
The whole point is that the Docker image has everything to run the app, but instead of being forced to rebuild a Docker image every time you touch a source file, you just mount your local workspace and run whatever you wish to run without wasting time rebuilding anything.
I do traffic mostly in compiled languages. But for many dynamic language apps, excluding the source code is not an option.
In terms of skipping image rebuilding for local development, just run the app locally without Docker. That important option should always be available to the developer.
> I do traffic mostly in compiled languages. But for many dynamic language apps, excluding the source code is not an option.
True, it seems the author left that bit implied, given the reference to webpack-dev-server.
> In terms of skipping image rebuilding for local development, just run the app locally without Docker. That important option should always be available to the developer.
That's not really an option. Container orchestration tools like docker-compose are used to quickly launch and setup ephemeral, self-contained development environments, which include not only the services we're developing but also support services such as databases, cache, message brokers, whatever-you-need, etc. If you're working on code that's integrated into a larger system then you need to get all the missing bits up and running to check how your changes work.
"Don't put the app inside Docker", when that's the whole point of Docker. It's one thing to support arbitrary repointing of local vs containerized system components via application configuration. But don't rule out the primary use case for Docker: running application processes.
"Use docker-compose", when minikube is available. Both Docker and minikube prepare an application for production Kubernetes deployment. But docker-compose is wasteful.