So I have read about Docker, and I've understood most of it. Nonetheless, I have a question: why are most of the tutorials still developing the whole application within their local environment and installing tools like Node, Python or Ruby if you can just create a bind mount and develop all inside the container? Did I misunderstood anything or is this approach wrong? Below is some simple dockerfile I used to develop a test app:
FROM node
WORKDIR /home/app
VOLUME . .
And from here I would go into the terminal of the container, run npm init and start developing my application.
Now, my goal is to have my machine as clean as possible, without having to install Java, Node, Ruby, etc. Which would be the best approach for this? And also how does this approach work in a windows machine? I'm currently using Ubuntu.
I don't want to dockerize an app. I want to build the whole application by composing containers. For example, I want to have a clean manjaro installation, then install docker, next get a spacevim image, then start a new app in java for example in some local directory being able to link my local directory with the java container so it can run the compiler. Then if i want to, start a new app in node, and do the same. In all cases i will be using a local directory with the source code, edited with my vim container and run from the language container. is that possible? so i don't have to instal nvm or nodenv or any version managers and so on.
I can manually run this code for example:
docker container run --rm -it -v /home/alex/Documents/REPOs/testing:/home/app -p 3000:3000 --name node node:latest bash
And it lets me work in /home/app/ directory as 2 way bind, but how could i achieve the same through a dockerfile or docker-compose file so that i can share my configuration and stop using version managers for each language.
Let's say I'm developing a Node application. I need one language runtime, but then the way the Node ecosystem works, all of a package's build-time and compile-time dependencies are declared in the package.json file, and isolated in the node_modules directory. There's not really any overhead involved in doing this; I need one apt-get install or brew install command, and I'm ready to go.
Once I've done this, I have a whole suite of tools available that work really well if I'm working locally. My editor can talk to a static type checker and highlight errors for me, but only if the node_modules directory is in my local environment. My editor can run my test suite and jump to failures, but only if the language runtime is local. My editor can access my code if it's running on a remote system, or in a container, but none of this extra tool suite is available to me.
In turn, there's a lot of complexities in using Docker. You still have to install something (Docker itself) to use Docker. Running any Docker command involves root-equivalent privileges, so either you're using sudo a lot or you're trusting that nothing will "accidentally" docker run -v /:/host ... and muck around underneath you. You need to get your code into the container. You need to tell the container to make your server's ports accessible to you. You'll routinely need to delete the container to change settings. There are recurring permission-mapping issues, and if file I/O is a major part of the program, you need to get those files in and out too. And Docker is complex, and like every complex thing it occasionally just outright fails.
I think Docker is awesome – as a deployment system. If you have a well-packaged and self-contained Python, Ruby, JavaScript, or Go program, it's very easy to build a container around it, and run that as a prepackaged solution, or deploy it to a Kubernetes cluster. The two major arguments in favor of Docker for development I've seen are filesystem isolation per project (which you get without Docker via node_modules, Python virtual environments, Ruby rvm gemsets, $GOPATH, ...) and wanting exact versions of language runtimes (in my experience not a big deal). It's outweighed by the hassle of managing the Docker environment and the difficulties of doing development "remotely"...just to avoid installing a language runtime on the host.