Hacker News Reader

Comment by scruple | Hacker News Reader

I'm not quite sure that I understand the advantages of doing development work inside of the container. What am I missing?

View on HN

Working with a team on a project with a moderately complex build process (say python and node), it soon becomes a painful to onboard new team members and get their dev environments set up.

Even assuming they have the same version of macOS, homebrew constantly evolves so getting everyone developing with the same version of dependencies as you use in prod is super painful. If they’re on Linux they likely don’t run the exact same distribution as prod.

Even if all that is the same, maybe they have to work on multiple projects simultaneously with different dependencies.

Python and node are probably the easiest to get setup. With Python you have venvs which do a lot of the heavy lifting required.

The issue becomes when you are on a non Linux environment for development and deploy to Linux in containers. If you build your code locally then you are debugging $DESKTOP issues which might not be the same as Linux.

Also languange environments with poor dependency management (e.g. C, C++) benefit from having an installable system.

> Even assuming they have the same version of macOS, homebrew constantly evolves so getting everyone developing with the same version of dependencies as you use in prod is super painful.

If someone is using homebrew for their development dependencies, unless they are targeting a release to homebrew, kindly ask them to stop doing this.

for me the best advantage of working with containers is the initial setup for new colleagues, especially junior devs...,

setting up pyenv, correct version of python manually, nvm, postgres, etc.. takes time and our setup guides grown a lot in the past 5 years...,

with containers all those long setup guides can boil down to `docker-compose up -d`

On-boarding really does seem to be the major pull. I've been developing along side docker containers for years now and I just don't see that changing.

I do see value in it, though, after the comments and after doing some additional reading. I could see myself pushing this direction if the teams I worked on had higher churn rates or more frequent new hires. Also, I think that it lends itself well to certain tech stacks / languages / ecosystems than others.

There are many advantages of containerized development. One example would be the protection of root environment from version pollution. My team uses and supports 3 versions of a framework, how do I test and develop in all of them without one environment affecting the other?

Of course, you could use a version management tool like nvm/rvm/asdf etc, but I think containerisation is also a neat alternative, as you would be able to use multiple versions for languages/tools and libraries within those languages for which a version management tool doesn't exist.

"3 versions of a framework" is quite vague. Are those versions Linux/Windows/Mac? Because then Docker is not very useful.

Docker is not a general solution to this problem because it ties you intimately to Linux, whether directly, or through VMs, or compat layers.

Let's say you maintain or occasionally code several big webapps in Ruby. One uses Ruby 2.4 and Ruby-on-Rails 3.2, another uses Ruby 2.6 and Ruby-on-Rails 5.2, and the last one is bleeding edge using Ruby 3.0 and Rails 6.1

Having all versions of you language and framework installed top level is a huge pain in the ass, since they inevitably will interfere with each other. Having separate containers with all necessary dependencies in it for each app is a lot more manageable.

rbenv actually solves this quite well. You can set a project-level version in a .ruby-version file, and each lang version has its own gem cache

Yeah. I have over a dozen Ruby on Rails apps on my development machine, targeting a variety of Ruby and RoR (and other common gem) versions. I'm not aware of any problems anyone has experienced in recent years, since everyone has moved to rbenv. We used to see issues with rvm.

I don't use docker with any of these projects. They're mostly legacy for us at this point and are shipping to EC2 instances directly.

Our more current projects do use Docker, however, and we're doing development along side of Docker in those instances and that seems to be working fine for us.

I do appreciate that a dev container would / may be a better approach to this for other reasons and especially, potentially, other languages and ecosystems, though.

I used to work at a company where I'd write and maintain multiple microservices, so I was dealing with dozens of small and big ruby applications across different language versions and different frameworks and dependencies. It was two years ago, but I did experience a ton of issues between different versions of Bundler and rake and rubygems. I'd absolutely go full docker if I was still working there.

I work with several programming languages, its easier to make the problem language agnostic.

Why would you be doing development as root?

Personally I would use virtualenvs with Python to solve that problem you described.

I think root refers to the main system environment, not the privileged user.

there's still system level packages that you might need, which may come into version conflicts among each other.

note: me too I default to virtualenv for local development, however there are usecases where this becomes insufficient.

My team uses macOS, windows and Linux. Dev Containers not only allow us to have our dev envs and prod environment as close as possible, as well as making all our dev envs identical, it makes working cross platform really straightforward.

If you work in enterprise 80% of developers have to rock windows laptops for compliance reasons but develop applications that will run on redhat/centos in the end.

It's not so much that it's a container, but rather it's Linux. The host OS isn't Linux.

Reply on news.ycombinator.com