4 ms·

I have done this but if possible I just run my code locally and reserve docker for infra (e.g. DB). Java, nodejs, go are all very easily run locally. Maintaini

I have done this but if possible I just run my code locally and reserve docker for infra (e.g. DB). Java, nodejs, go are all very easily run locally. Maintaining a complex Dockerfile is just more crap that makes programming tedious.

Fredej 5y ago
Honestly my experience is basically the opposite: Maintaining a coherent development environment is what makes programming tedious. I'd much prefer to just specify in a dockerfile that I need this compiler, these tools and these env-variables, and then I never have to worry about that stuff again.
- tlarkworthy 5y ago
  It's hotcode reload and debugging where I find docker starts to annoy me. (Also resource consumption and performance to an extent)
- deleted 5y ago
  [deleted]
nucleardog 5y ago
Sure, nodejs is easy to run locally. nodejs+npm of the exact version that a specific project needs, which is different and incompatible with the version some other project needs starts to get more annoying. Basically all of our projects have some level of external dependencies in the form of libraries or binary tools. Some projects overlap dependencies, but on incompatible versions. This gets really hairy. Trying to do this without containers (from experience, this is what the devs were doing before) turns into a massive documentation project and a nightmare of trying to get all these incompatible things to exist on a single system where we don't even have a consistent target because everyone's local dev environment is different enough to make it a nightmare. And then continually hounding the devs to keep the documentation up-to-date. But even that doesn't solve the problem because "apt-get install nodejs" today is not necessarily the same as "apt-get install nodejs" in six months or a year and nobody's thinking about this so it's just "worked for me last time!". Onboarding people at one point was a _days_ long process and a group effort. Instead we just re-use the same 30-odd line Dockerfile we use for deploying out to the infra for local dev. Instead of pages upon pages of out-of-date documentation. a bunch of tribal knowledge, and continually running into new and interesting bugs, we now have a short and simple source of truth which _has_ to be up-to-date because otherwise the environment the project is deployed to is broken. Onboarding people takes 5 minutes. If you're a single person working on a single project, yeah, containerizing stuff is maybe some annoying overhead. Even then I still use it because once you've gotten past the learning curve, it's actually a really effective way to document and define your project's environment and ensure it stays consistent.
- forty 5y ago
  My own fix for the node version issue is that we use a single version of nodejs (currently latest v12), and when we update, we update everything (which happens every two years, and is generally not too painful in my experience), so we just have to have this version locally.
  - tqkxzugoaupvwqr 5y ago
    nvm (node version manager) is your friend. Allows you to use different node versions for different projects.
    - scns 5y ago
      https://volta.sh https://volta.sh too
    - forty 5y ago
      I used to use nvm, nave, n and similar things, but I think having a single version of node for all projects is easier and better. I just have unattended upgrade setup everywhere, so I have always the latest v12 without having to think about it.
  - nucleardog 5y ago
    Yes, it's do-able. As others have pointed out, nvm also works. 1. There isn't nvm for things that aren't node. Some things have an equivalent (e.g., pyenv). Many external dependencies do not. 2. I've inherited a spiderweb of like two dozen different major projects that are all interconnected. Doing an upgrade across everything at once means a stop-work for months while all the developers update tooling, then fix all their issues so everything works, then we try and coordinate testing and deploys of everything without breaking anything. Or, alternatively: 1. We don't need extra tooling that doesn't exist. 2. We can update projects one at a time instead of mass-migrating several million lines of code across half a dozen different frameworks.
- majkinetor 5y ago
  If only life was such a beauty. Now you have bunch of new and interesting problems with docker ecosystem. Newer tools are much much better in this cross-dependency problem as they evolved too, not only docker. I don't remember dependency hell nowdays while it was more or less common 15 years ago. I had the same project with and without docker and I totally prefer without docker. There are few quirks here and there but problems are mostly solvable within minutes unlike basically anything you can get with docker.
jansommer 5y ago
I have the same experience. If cross platform loading of environment variables and shell scripting is needed one can use Powershell. Together with Windows Terminal and tmux for Linux and Mac, you can start every microservice in different panes and tabs. You won't get the full Docker experience where you know for a certainty that your code will run the same way in production, but leave that to ci/cd, perhaps a local kubernetes cluster you can use for production-like testing.
brundolf 5y ago
It's my impression that there are lots of platforms that ask very little of their environment, and therefore don't benefit much from Docker, and therefore can be developed with minimal friction in a local environment without using it. Node, Java, often Python, even Rust because of its static dependencies, etc often fall into this category. And of course front-ends, especially. In practice you'll still use Docker to deploy because it's a nearly-unavoidable deployment protocol at this point. But I see very little reason to have it house your in-progress code in these cases.

Fredej 5y ago

Honestly my experience is basically the opposite: Maintaining a coherent development environment is what makes programming tedious. I'd much prefer to just specify in a dockerfile that I need this compiler, these tools and these env-variables, and then I never have to worry about that stuff again.

tlarkworthy 5y ago
It's hotcode reload and debugging where I find docker starts to annoy me. (Also resource consumption and performance to an extent)
deleted 5y ago
[deleted]

nucleardog 5y ago

Sure, nodejs is easy to run locally. nodejs+npm of the exact version that a specific project needs, which is different and incompatible with the version some other project needs starts to get more annoying. Basically all of our projects have some level of external dependencies in the form of libraries or binary tools. Some projects overlap dependencies, but on incompatible versions. This gets really hairy. Trying to do this without containers (from experience, this is what the devs were doing before) turns into a massive documentation project and a nightmare of trying to get all these incompatible things to exist on a single system where we don't even have a consistent target because everyone's local dev environment is different enough to make it a nightmare. And then continually hounding the devs to keep the documentation up-to-date. But even that doesn't solve the problem because "apt-get install nodejs" today is not necessarily the same as "apt-get install nodejs" in six months or a year and nobody's thinking about this so it's just "worked for me last time!". Onboarding people at one point was a _days_ long process and a group effort. Instead we just re-use the same 30-odd line Dockerfile we use for deploying out to the infra for local dev. Instead of pages upon pages of out-of-date documentation. a bunch of tribal knowledge, and continually running into new and interesting bugs, we now have a short and simple source of truth which _has_ to be up-to-date because otherwise the environment the project is deployed to is broken. Onboarding people takes 5 minutes. If you're a single person working on a single project, yeah, containerizing stuff is maybe some annoying overhead. Even then I still use it because once you've gotten past the learning curve, it's actually a really effective way to document and define your project's environment and ensure it stays consistent.

forty 5y ago
My own fix for the node version issue is that we use a single version of nodejs (currently latest v12), and when we update, we update everything (which happens every two years, and is generally not too painful in my experience), so we just have to have this version locally.
- tqkxzugoaupvwqr 5y ago
  nvm (node version manager) is your friend. Allows you to use different node versions for different projects.
  - scns 5y ago
    https://volta.sh https://volta.sh too
  - forty 5y ago
    I used to use nvm, nave, n and similar things, but I think having a single version of node for all projects is easier and better. I just have unattended upgrade setup everywhere, so I have always the latest v12 without having to think about it.
- nucleardog 5y ago
  Yes, it's do-able. As others have pointed out, nvm also works. 1. There isn't nvm for things that aren't node. Some things have an equivalent (e.g., pyenv). Many external dependencies do not. 2. I've inherited a spiderweb of like two dozen different major projects that are all interconnected. Doing an upgrade across everything at once means a stop-work for months while all the developers update tooling, then fix all their issues so everything works, then we try and coordinate testing and deploys of everything without breaking anything. Or, alternatively: 1. We don't need extra tooling that doesn't exist. 2. We can update projects one at a time instead of mass-migrating several million lines of code across half a dozen different frameworks.
majkinetor 5y ago
If only life was such a beauty. Now you have bunch of new and interesting problems with docker ecosystem. Newer tools are much much better in this cross-dependency problem as they evolved too, not only docker. I don't remember dependency hell nowdays while it was more or less common 15 years ago. I had the same project with and without docker and I totally prefer without docker. There are few quirks here and there but problems are mostly solvable within minutes unlike basically anything you can get with docker.

jansommer 5y ago

I have the same experience. If cross platform loading of environment variables and shell scripting is needed one can use Powershell. Together with Windows Terminal and tmux for Linux and Mac, you can start every microservice in different panes and tabs. You won't get the full Docker experience where you know for a certainty that your code will run the same way in production, but leave that to ci/cd, perhaps a local kubernetes cluster you can use for production-like testing.

brundolf 5y ago

It's my impression that there are lots of platforms that ask very little of their environment, and therefore don't benefit much from Docker, and therefore can be developed with minimal friction in a local environment without using it. Node, Java, often Python, even Rust because of its static dependencies, etc often fall into this category. And of course front-ends, especially. In practice you'll still use Docker to deploy because it's a nearly-unavoidable deployment protocol at this point. But I see very little reason to have it house your in-progress code in these cases.