Why use Docker to program?

Asked

Viewed 87 times

1

Using a Docker container for a database is easy to understand the need, because I don’t need to install anything on my machine, everything is in the container. But what I don’t understand is the advantage of using a Docker container to program?

For example: If creating an app on Node I would have to install all packages locally (if not VS Code will not recognize the Imports) and then create a volume to play everything in the container.

Now, if I have to have everything local, why have a container? It will not increase the processing of my machine?

It would not be lighter for my machine to run the app directly on it and the container only for database?

Thank you!

  • 3

    For those who do simple things do not need. And by simple I am not talking about silly things. a full ERP can be simple in this concept I’m doing. Docker is used more where one adds complexity, almost always unnecessary, which by itself is unnecessary complexity. I’m not saying it’s not useful, but it’s a lot less than people think. Not that it’s always wrong, but I’d say the same for DB.

  • In the case of the database, sometimes I do not want to keep installing, even more if you want to have Mysql, Mongo, Postgree, I think it is even justifiable. But to program with Node I don’t see how to escape from installing it. So I don’t really understand the need.

  • 3

    @Webdevbrazil has no need anyway. Even in production many people use pq saw the favorite blogger say it was good. Container is more efficient than multiple Vms on the same machine, but most applications don’t need separation, for starters. The guy makes shop site and thinks that with container prepared to become "Amazon", instead of focusing on learning to program, and understand a little bit of infra before picking up the first service. In your example, you don’t need a database container or anything. Even if you’re running 10 separate DB instances, you don’t need that.

  • 3

    One of the "alleged" reason is that many devs who do things without knowing what they are doing (believe it is possible and common) had as excuse: "on my computer worked", so with Docker is "taken" the environment to other places, that is, one of the ideas was not suffer with complexity of publishing an environment, only that in practice it is not so simple, it would more compensate the person to learn better to do things and prepare a pre-environment isolated on the server to climb the system (with alternative database)But that’s another story. Like I said, it’s one of the supposed motives.

  • 3

    Still, a Mysql in development environment for example: you with a single installation (or mere executable copy, without installing) can run a lot of instance (and only run each when using, via shortcut) straight from the desktop, just creating different shortcuts for each application (changing the IP, for ex 127.0.0.1, 127.0.0.2, etc., and storage folder), and having full separation of the bases for development. And the best, it only runs when it’s developing. Day-to-day things that make work much easier by using the basics of what comes "factory" in OS and engine.

  • Personal thanks! Your answers together took away my question! Do not even need.

Show 1 more comment

1 answer

1


One of the reasons to use container, you already gave. Additional resources.

To develop you gain by being in the environment closest to productive. Where you can handle the same settings and mainly, the same dependencies.

Whenever your application depends on something that is not just a package (NPM, nuget, Maven), that is, it depends on some installation in the development environment, whether with apt or apk or otherwise, you will have difficulties dealing with large teams, with various projects and different types of dependencies.

An example of this is the use of DB2 with . NET Core on Linux. Windows and Linux packages are different, depend on specific java version, environment variables compatible with the setup, influence the build profile.

Or when you need something like Tesseract, ffmpeg and the like.

If you have something more complex, like several projects that need to talk there are also facilities.

If you have a vanilla Node api, these difficulties do not exist, but if you are in an ecosystem that takes Ocker seriously, it makes sense to standardize, even if you make little use of these benefits. But stay tuned, often monitoring depends on machine setup and this is also a typical case where even without the application directly depending on anything involving Docker. Something important depends.

The dependencies of your vscode only concern it. This does not enter the subject Docker.

  • I like your answer. I only talked about Vscode, because I see them talking about Docker not to install dependencies on the machine, and then they only install Node in the container, which implies that the dependency is Node and npm packages. And if that were it, it has no advantage because we have to install all this locally on the machine. But after your explanation, it became clearer things.

  • @The point is not to not install on the machine, it’s not to depend on something that only exists on it. That’s the point. If you inadvertently install something for project A, you ensure that a project B does not carry code that depends on something that does not exist in the context of it, but on your machine there is.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.