7 ms·

Reusable development containers with Docker Compose and Dip

51 points by progapandist 6y ago

hugodutka 6y ago
I haven't heard about Dip before, but it's really cool to see. It seems to solve a bunch of my pain points with bare Docker Compose, so I'm eager to try it out. It does not address my biggest issue though - setting up a Docker development environment is a considerable upfront investment that slows me down. When I start a new project, I want to jump into writing code in a complete Docker environment right away, and not spend hours or days setting up Dockerfiles, docker-composes, remote image builds, etc. Recently I have been trying to solve that with hocus [0], which is a very early stage framework for creating and managing Docker development environments. [0] https://hocus.dev/ https://hocus.dev/
ghostwriter 6y ago
> So you need environment managers: rvm, nvm, rbenv, pipenv, virtualenv, asdf, gvm… The list of acronyms just gets longer and longer. That's where Nix[1] shines, as most of the times you no longer need these separate tools for creating individual isolated environments for specific languages/frameworks. It also can help in partially replacing the local docker daemon for regular development tasks with images[2], with a help from Hocker[3] [1] https://nix.dev/tutorials/ad-hoc-developer-environments.html https://nix.dev/tutorials/ad-hoc-developer-environments.html [2] https://nix.dev/tutorials/building-and-running-docker-images.html https://nix.dev/tutorials/building-and-running-docker-images... [3] https://awakesecurity.com/blog/hocker/ https://awakesecurity.com/blog/hocker/
- Shoue 6y ago
  I know it's mentioned in that tutorial under the next developer environment section but it's worth mentioning that direnv also makes it pretty much seamless because you can hook it into your shell of choice (I use Fish). It just drops the environment on you, that nix-shell would set up, the moment you step into that project's directory (after you've consented to it of course).
- aclatuts 6y ago
  asdf literally is designed to replace some of the stuff on that list and then some. And it negates the need for docker in some examples.
daitangio 6y ago
A similar project (I am the author) https://github.com/daitangio/misterio/ https://github.com/daitangio/misterio/ Docker-compose based Ansible/SaltStack minimalistic alternative. Feel free to add your feedback on opening issues
- eeZah7Ux 6y ago
  Ansible/SaltStack are far from minimalistic
pydry 6y ago
Does anybody know of a good docker compose alternative? I absolutely loathe using it for development environment or testing because of awful design decisions like this wait-for-it hack https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/
- oogetyboogety 6y ago
  If you're using K8s professionally, using it at home just becomes easier. If you're not, maybe try k0s + helm charts or operators for local dev
- nickjj 6y ago
  > I absolutely loathe using it for development environment or testing because of awful design decisions like this wait-for-it hack https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/ I'd be curious to know which tech stack you're using where you even need to use wait for it. I've built and worked with various Flask, Django, Rails and Phoenix apps and none of them needed wait-for-it. Most of those ran a web server + background worker + redis + postgres. Everything starts up no problem in development without any extra tooling when using Docker Compose. Tests in CI are a different story, but I find wait-for-it to not be the tool to fix that problem. Instead I ended up writing this tiny shell script[0] to wait for a process to be ready between running a docker-compose up -d and running my test suite in CI. You'd run into this issue with or without Docker Compose too. You could use it to wait until you can do a SELECT 1 on your database (the docs cover multiple database examples). The docs also cover why wait-for-it doesn't work to fix waiting for a database and other common use cases. [0]: https://github.com/nickjj/wait-until https://github.com/nickjj/wait-until
  - pydry 6y ago
    Tests are what I'm concerned about. I tend to do TDD when I develop code and run test suites in CI. I'd rather like something that can orchestrate in a development environment half way competently. I find it hard to believe that docker-compose thinks that "start database, wait for port to be available and then start web server, then wait for port 8080 to be available and then kick off tests" is a workflow that ought to require a hacky bash script and a lecture about the importance of resilience. It's a pretty straightforward feature to implement. I haven't used swarm but I can only imagine how bad that is.

51 points by progapandist 6y ago

I haven't heard about Dip before, but it's really cool to see. It seems to solve a bunch of my pain points with bare Docker Compose, so I'm eager to try it out. It does not address my biggest issue though - setting up a Docker development environment is a considerable upfront investment that slows me down. When I start a new project, I want to jump into writing code in a complete Docker environment right away, and not spend hours or days setting up Dockerfiles, docker-composes, remote image builds, etc. Recently I have been trying to solve that with hocus [0], which is a very early stage framework for creating and managing Docker development environments. [0] https://hocus.dev/ https://hocus.dev/

ghostwriter 6y ago

> So you need environment managers: rvm, nvm, rbenv, pipenv, virtualenv, asdf, gvm… The list of acronyms just gets longer and longer. That's where Nix[1] shines, as most of the times you no longer need these separate tools for creating individual isolated environments for specific languages/frameworks. It also can help in partially replacing the local docker daemon for regular development tasks with images[2], with a help from Hocker[3] [1] https://nix.dev/tutorials/ad-hoc-developer-environments.html https://nix.dev/tutorials/ad-hoc-developer-environments.html [2] https://nix.dev/tutorials/building-and-running-docker-images.html https://nix.dev/tutorials/building-and-running-docker-images... [3] https://awakesecurity.com/blog/hocker/ https://awakesecurity.com/blog/hocker/

Shoue 6y ago
I know it's mentioned in that tutorial under the next developer environment section but it's worth mentioning that direnv also makes it pretty much seamless because you can hook it into your shell of choice (I use Fish). It just drops the environment on you, that nix-shell would set up, the moment you step into that project's directory (after you've consented to it of course).
aclatuts 6y ago
asdf literally is designed to replace some of the stuff on that list and then some. And it negates the need for docker in some examples.

daitangio 6y ago

A similar project (I am the author) https://github.com/daitangio/misterio/ https://github.com/daitangio/misterio/ Docker-compose based Ansible/SaltStack minimalistic alternative. Feel free to add your feedback on opening issues

eeZah7Ux 6y ago
Ansible/SaltStack are far from minimalistic

pydry 6y ago

Does anybody know of a good docker compose alternative? I absolutely loathe using it for development environment or testing because of awful design decisions like this wait-for-it hack https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/

oogetyboogety 6y ago
If you're using K8s professionally, using it at home just becomes easier. If you're not, maybe try k0s + helm charts or operators for local dev
nickjj 6y ago
> I absolutely loathe using it for development environment or testing because of awful design decisions like this wait-for-it hack https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/ I'd be curious to know which tech stack you're using where you even need to use wait for it. I've built and worked with various Flask, Django, Rails and Phoenix apps and none of them needed wait-for-it. Most of those ran a web server + background worker + redis + postgres. Everything starts up no problem in development without any extra tooling when using Docker Compose. Tests in CI are a different story, but I find wait-for-it to not be the tool to fix that problem. Instead I ended up writing this tiny shell script[0] to wait for a process to be ready between running a docker-compose up -d and running my test suite in CI. You'd run into this issue with or without Docker Compose too. You could use it to wait until you can do a SELECT 1 on your database (the docs cover multiple database examples). The docs also cover why wait-for-it doesn't work to fix waiting for a database and other common use cases. [0]: https://github.com/nickjj/wait-until https://github.com/nickjj/wait-until
- pydry 6y ago
  Tests are what I'm concerned about. I tend to do TDD when I develop code and run test suites in CI. I'd rather like something that can orchestrate in a development environment half way competently. I find it hard to believe that docker-compose thinks that "start database, wait for port to be available and then start web server, then wait for port 8080 to be available and then kick off tests" is a workflow that ought to require a hacky bash script and a lecture about the importance of resilience. It's a pretty straightforward feature to implement. I haven't used swarm but I can only imagine how bad that is.