9 ms·

I understand this can be done. And this post explains how it's done. I still don't get why it should be done? What's the advantage of running your dev environm

• kkapelon 6y ago
  If you have projects with different versions (python2/3, Java5/8, node8/11 etc) you don't need to bother with version managers and package managers anymore. Just launch the respective container and you are good to go.
  • misiti3780 6y ago
    for python, why cant you use use virtualenv with pyenv?
    • miscaccount 6y ago
      because setting and configuring virtualenv is also chore and loads of things that can go wrong. Its different in windows to mac to linux. With docker its a single command run after installing docker.
    • TeMPOraL 6y ago
      You could, but then maybe you have some editor-specific settings you'd also want to tie to particular project. And if you're working with multiple projects in multiple languages, why bother learning each language's equivalent of virtualenv (assuming it has any), when there's an universal method available?
    • kkapelon 6y ago
      Because it is a Python specific thing. Docker works with all programming languages and that's it. If you are full stack or work with multiple programming languages there is no need to learn the "equivalent" of virtualenv everywhere else. Also with docker there is no setup/installation involved. You just pull the image and that is it. Also virtualenv requires that you already have pip/python installed. Docker requires nothing (apart from itself). So you can instantly launch Java/Node/Erlang/Haskell whatever without any SDK/libs installed.
      • collyw 6y ago
        I think every programming language that I have used has had something equivalent.
        • kkapelon 6y ago
          Let's assume that this is true (I don't think that languages like C/C++ have this but I may be wrong). If I use 4 programming languages why learn 4 tools instead of one (Docker)?
      • darkteflon 6y ago
        Second this. Developing in Docker completely liberated me from the caprice of Python packaging and Node dependency management and made doing development work on multiple platforms (MacOS, Ubuntu) frictionless. There’s a “pets vs cattle” angle here, too. Something goes wrong, just pave over it and start again. YMMV, of course, but I can’t imagine going back.
    • nickjj 6y ago
      I wrote this article a while back that compares setting up a Python development environment for web development with and without Docker: https://nickjanetakis.com/blog/setting-up-a-python-development-environment-with-and-without-docker https://nickjanetakis.com/blog/setting-up-a-python-developme... The TL;DR is there's a lot of things to set up yourself without Docker in order to run a typical web application and it's different depending on what OS / version you use. Some of these things are unrelated to Python too, such as running PostgreSQL, Redis, etc. but these are very important to your overall application. Docker unifies that entire set up and the barrier of entry is installing Docker once and then learning a bit about it.
      • potta_coffee 6y ago
        A couple of years ago I got your Docker course and I learned a lot from it, been doing Docker chores for my teams ever since. Anyway, good course!
        • nickjj 6y ago
          Thanks a lot!
    • cashewchoo 6y ago
      Because projects are seldom as simple as that, potentially having lots of other kinds of dependencies (a directory structure, system libraries/command, symlinks, other services running, etc). And let's be honest, virtualenvs and all the various ways they're managed and updated and such aren't really bulletproof either. It's really, really refreshing how much "yeah I managed to break my dev environment" or "I followed the wiki for how to start developing your project but it 'didn't work'" can be avoided if it's just "run docker(-compose)?". And this is especially true for junior developers, who are probably fresh out of college and won't be familiar with lots of the tooling that exists in the world. Not that docker is a simple tool, but it can hide so much complexity that it is easier to just show people how to docker run and docker build and such.
    • pilotneko 6y ago
      So, speaking as a data scientist, the dependencies run deeper than Python kernels and libraries. For something like TensorFlow, you need to account for specific versions of Nvidia drivers and CUDA/CUDnn. Using something like the Nvidia container runtime for model development allows me to essentially version my entire development environment.
      • misiti3780 6y ago
        good point.
• zarkov99 6y ago
  Reproducible build environment.
• tekstar 6y ago
  In big orgs it's a way to manage environment changes for big teams
• lpasselin 6y ago
  Consistency between team members. Super easy for new team members to get started on a project. No need to manually install dependencies. Environment versioning in git and docker. Your local environment gets automatically updated with a git pull.
  • mosselman 6y ago
    > Super easy for new team members to get started on a project. No need to manually install dependencies. I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? Once every 3 years on average or something? Getting your development env setup takes what, a few hours max on 3 years?
    • gokhan 6y ago
      But you can easily switch projects in-company, take a look at the one next cubicle etc. You switch machines. You decide work from home etc.
    • adamkl 6y ago
      It depends on how large your organization is and what specific quirks need to be configured to do your work. Its not unusual for large organizations to have internally hosted registries (Artifactory), source control and network proxies. This usually requires setting up different config files (.npmrc for Node.js/NPM), installation of custom root certificates, ssh keys, etc. None of that includes project/team specific configurations and workflows. Take all that and multiply it by thousands of developers and you have a recipe for an endless stream of Slack chats, email chains, and Teams messages repeating the same config questions and answers. If you can reduce all that down to a single docker pull, while making sure everyone's development environment is consistent, it can be a big win.
    • de_nied 6y ago
      > I see this brought up a lot as an argument. So why do we want this? How often do people switch companies? It's not about you. The people coming in generally need confirmation and help when setting up their environments. Someone there would have to take time out of their day to help you. A few hours, a few days, a few weeks, a few deleted companies (https://news.ycombinator.com/item?id=11496947 https://news.ycombinator.com/item?id=11496947). Here's an even more fun one: https://news.ycombinator.com/item?id=14476421 https://news.ycombinator.com/item?id=14476421
• brundolf 6y ago
  Remote development from different machines/thin client machine
  • kkapelon 6y ago
    You could do that already with VMs and SSH. Sure it is a bit easier with Docker, but that is not the big advantage.
• lenkite 6y ago
  So, you can extend your bio-break waiting for your build to finish as Docker furiously crunches those files, raises your laptop temperature and makes those fans spin mightily.
• coldtea 6y ago
  What exactly is diffucult to understand about the value proposition? Seems pretty obvious to me... If you mean why use dev environments in containers: 1) reproducibility, 2) re-use of container creation scripts for different environments, 3) isolation from your actual OS, 4) ability to run the same OS/libs/etc as the final deployment, 5) tons of base images with different environments already configured - from LAMP to data science, 6) easy sharing with others, team 7) ability to work with 1-2-5 or 100 different environments, with different OSes, versions, libs, python versions, whatever. As for why have your IDE/editor work from inside a container (as described in the article). Well, because you get all the benefits of containers (as above) PLUS get to use the editor as if you were programming directly on the target machine (including having visibility of installed libraries for autocomplete, running code directly there, and so on). It's the same thing people have been doing with running Emacs in "server" mode inside another host, and programming with Emacs client on their machines as if they were locally at the machine.
  • gshulegaard 6y ago
    All of those benefits were solved problems with VM based workflows using something like Vagrant long before Containers started gaining traction (IMO). Don't get me wrong, I am a fan of containers (in particular LXC), but I wouldn't list those benefits as if they are unique or novel to container based workflows. Edit: To be clear, there _are_ benefits to containers over VMs, just not the things you listed above from my perspective.
    • closeparen 6y ago
      Schlepping around and running a whole VBox/Vagrant VM is heavy enough that I will be motivated to see if I can’t get it working under MacOS. Running a container is less offensive.
      • z3t4 6y ago
        Is not docker server running inside a VM though ? You could also run Xserver (available on both Mac and Windows) and ssh -X into a VM to run GUI apps inside the VM.
• Frost1x 6y ago
  Since some of the proported features of containers is portability and consistentency/reproducibility between environments, the idea here is that you want to make sure your develop environment is as close to the deployment environment as possible. In addition, if you want to do prototype development, quickly try and test new ideas, and iterate on that, it's nice to go through that without rebuilding and deploying the container to a test/production environment. Do all of that right where you do your development.
• smt88 6y ago
  It lets you do dev work in an environment that matches prod (and your teammates' environments) as closely as possible. It's frustrating at best and catatrophic at worst when you have code working on your machine, deploy to prod, and then discover incompatibility.
• de_nied 6y ago
  It depends on what the environment is for. Your company work, or individual projects? If you're an individual, then it would benefit someone who has multiple devices and/or multiple operating systems and doesn't want to manage their environment across all those devices and operating systems. For example, I personally have OSX, Windows, and several different Linux distributions on my laptop itself. My desktop also runs several operating systems. Managing software across all of those is a pain. With Docker, I only have to manage the containers, and just have Docker installed on all the operating systems. Instead of managing like 50 different dependencies across 7 systems (think 7x50), I only have to manage Docker inside each system. If you're working for a company, they will have their own dev environment. Instead of setting up and troubleshooting all their dependencies on your computer, you can just use their containers.
  • deleted 6y ago
    [deleted]
• Lendal 6y ago
  If your project is targeting an environment you don't control, and doesn't behave exactly like an environment you have exclusive access to, your code won't run the same way in the production environment as it does on your machine. There are different strategies for dealing with this, but Docker seems to be the sweet spot for making it easier. You use Docker to create a container that mimics the production target, and then use that container to develop in. You could reconfigure your laptop to look exactly like the production target, but then you have to keep doing that every time you change projects. Before Docker, I used VMs for this, but VMs have certain disadvantages that Docker addresses. Like size, and documentability. Every time someone wanted me to look at a project, we had to figure out a way to transfer and store a copy of a 20+ GB VM. And they couldn't tell me everything they did to create that VM from scratch, because VMware doesn't do that and neither does Hyper-V. With Docker it is just a small text file that describes everything it takes to create what was previously a massive, undocumented VM image. It forces you to document how to create the environment, and it saves on the space and time of transferring VMs around.
  • GordonS 6y ago
    I use Windows 10 as my daily driver, and often work on projects using Postgres, RabbitMQ, Redis, nginx and others. Until Docker came along, it was a royal PITA. I always dreaded getting a new laptop or something breaking, as it took forever to set everything back up again, and it was never quite the same. Docker changed all that. It forces you to configure everything in a reproducible way in a Dockerfile - and it's much simpler than trying to come up with scripts to install and configure everything in Windows, and I'd say it's also quicker than trying to come up with scripts for a Linux VM, just because you can spin containers up and down so quickly. Docker has been a game changer for dev/test.
• mediascreen 6y ago
  At the agency where I work we have about 40-50 somewhat active projects at any time. Any given week I work with maybe 3 to 10 of them. It saves so much time to just pull down the repo, run "docker-compose up" and have everything running, almost exactly the way it's running in production. With the right node or php version, databases, Elasticsearch, Redis etc.
  • Silhouette 6y ago
    The problem I usually run into with this sort of arrangement is the database. Every non-newbie developer is very aware of using source control with their code. A lot of developers are careful about managing the dependencies for that code as well. But for the database, you have a second asset that often needs to be synchronised with the code, and that means both schema and possibly records as well. Just deploying changes affecting both assets carefully in production can be quite awkward relative to a code-only deployment. You might need to do this in several stages, updating your code to allow for but not require the DB changes, then updating the DB schema, then maybe updating existing DB records, then at least one more round of code updates so everything is running on the new version of the DB. And you might need to make sure no-one else on your team is doing anything conflicting in between. Doing the same in a staging environment isn't so bad because you're running essentially the same process. However, for a development environment where you want the shortest possible feedback loops for efficiency, you need to be able to spin up a DB with the correct schema, and possibly also with some preloaded data that may be wholly, partially or not at all related to controlled data you use to initialise parts of your database in production or staging environments. It is not always an easy task to keep the code you use to access the database, the current schema in the database, and any pre-configured data to be installed in your database all in sync, and to ensure that your production, staging/testing/CI facilities, and local developer test environment are also synchronised where they should be.
    • mediascreen 6y ago
      I agree that the database (and things like uploaded images) can be a challenge. For WordPress we usually sync down from production, to staging, to testing, to local (while filtering out PII). For other projects is't usually easier using migrations and seeding.
• carlosf 6y ago
  That`s how we do it in my company: - Clone project - Build container - Develop If you're in a polyglot shop there are HUGE productivity gains in not needing to setup your environment manually, or worse, risk that vital information about it is distributed as tribal knowledge. Plus, if your project has external dependencies like DBs, S3, etc... you can use docker-compose with VS Code as well.
  • majodev 6y ago
    Can only second this, we use a VSCode devContainer-based setup in all of our projects and even migrate our legacy projects to it (software agency). Here's our current base go template, you only need Docker+VSCode on your system to get started: https://github.com/allaboutapps/go-starter https://github.com/allaboutapps/go-starter Bonus points: * As all IDE operations solely run within the local Docker container, all developers can expect that their IDE will work the same without manual configuration steps. * We can easily support local development in all three major OSes (MacOS, Windows, Linux) and even support developing directly in your Browser through GitHub Codespaces. * Developing directly inside a Docker container guarantees that you use the very same toolset, which our CI will use to build these images. There are no more excuses why your code builds differently locally versus in our CI. Edit: format/typos
    • harisund 6y ago
      Does that force everyone to use VS Code only? Can non VS Code developers also work efficiently?
      • panzerboy 6y ago
        You could always run something like Vim/Neovim directly in the container. I, personally, hope that JetBrains comes up with something similar which will allow devs to use the same workflow with the JetBrains IDEs.
      • majodev 6y ago
        yep, currently it forces our engineers to use VS Code or a terminal-based setup (or GitHub Codespaces). Hopefully Goland / IntelliJ catches up in this year...