7 ms·

I can tell you one place I've found them very valuable: development systems. The longer I've been in the field, the more I've learned that polluting my dev box

I can tell you one place I've found them very valuable: development systems. The longer I've been in the field, the more I've learned that polluting my dev box with globally installed tools makes life painful down the road. Docker provides a nice way (especially now that they have docker exec) to spin up environments, or set's of environments with tools/stacks and not touch the host. It's lighter than a bunch of vm instances and easier to orchestrate on a small scale than most tools I've found. Docker for Mac makes that even nicer!

girvo 10y ago
Completely agreed. My workplace adopted Docker for local development first, before using it anywhere else. Aside from the "volume mount wiping the `node_modules` folder that was installed in the image but doesn't exist in the host on first boot" problem, it's been an absolute dream. We had some issues with docker-compose for our use-cases, such as persistent database even when recreating every container from scratch, so I hacked on some stuff that become "dup" [0] (nee. docker-up) Ps. it's written in Nim, which was a lot of fun! [0] https://github.com/girvo/dup https://github.com/girvo/dup
- notliketherest 10y ago
  Assuming you're also running your db in dockrr, why didn't attaching docker volumes work for you for database persistence ?
  - girvo 10y ago
    Because docker-compose had a very bad habit of destroying and rebuilding the volume-only container, unfortunately! This was of course back when running Docker on macOS was somewhat painful, so mounting the DB data directory directly as a volume into your host would nearly always fail to work successfully due to screwy permissions errors (it's quite a bit better now with Docker for Mac) So, some dodgy code and a JSON file later, and our team uses the `dup` CLI to run everything with exactly zero hitches thus-far, and we've been using (across it's two incarnations) for... 18 months now?
deleted 10y ago
[deleted]
yawz 10y ago
Agreed! So far I've used Docker only on Dev systems. I'm still waiting to be convinced that there's sufficiently higher productivity and value to be had by introducing it to Prod.
deleted 10y ago
[deleted]
sktrdie 10y ago
It's great for development if it wasn't 4 to 5 times slower on Mac: https://www.reddit.com/r/docker/comments/59u1b8/why_is_docker_so_slow_on_mac/ https://www.reddit.com/r/docker/comments/59u1b8/why_is_docke...
- bdcravens 10y ago
  Still feels several times faster than using an option like Vagrant. (haven't found a container that didn't cold start in less than 5 seconds; 3+ minutes for common Vagrant setup is pretty common)
- gerdesj 10y ago
  (Having read the Reddit thread for a while) Macs don't appear to have support for containers which is what Docker is. Well that is probably bollocks because they are *BSD based and I know that FreeBSD at least has a form of containerization and I seem to recall that the whole container thing was invented on a BSD - "jails". So Docker can't run native on iStuff. You have to run it within a Linux VM. I gave up on Googling for "apple mac jail" 8) The reason why Docker runs slowly on Macs is because it is running under emulation within a VM. Unfortunately, Macs are not cool enough to run Docker, so there 8) Cheers Jon
  - anoctopus 10y ago
    XNU (the macOS kernel) may have BSD origins, but it doesn't have features like cgroups and process namespacing that the Linux kernel provides and the Docker runtime relies on.
    - justincormack 10y ago
      Nor does it have FreeBSD jails.
roblabla 10y ago
I find using nix as a package manager to be a better solution. Write a nixfile that have all the tools you need for a script, and you're fixed. Docker is a slow, blunt tool for just containerizing dependencies IMO.
- swsieber 10y ago
  A slow, blunt, cross-platform tool. So while I agree, I don't think nix makes a good replacement for docker.
  - Drdrdrq 10y ago
    Cross-distribution, to be precise. You can't run amd64 image on RPi for instance.
    - justincormack 10y ago
      Cross platform. Runs on Linux, Windows, and the Solaris port is being merged. There was a FreeBSD port but it was alas not upstreamed and needs some work. No it does not change processor architectures for you.
manojlds 10y ago
Also for CI in the same vein.

girvo 10y ago

Completely agreed. My workplace adopted Docker for local development first, before using it anywhere else. Aside from the "volume mount wiping the `node_modules` folder that was installed in the image but doesn't exist in the host on first boot" problem, it's been an absolute dream. We had some issues with docker-compose for our use-cases, such as persistent database even when recreating every container from scratch, so I hacked on some stuff that become "dup" [0] (nee. docker-up) Ps. it's written in Nim, which was a lot of fun! [0] https://github.com/girvo/dup https://github.com/girvo/dup

notliketherest 10y ago
Assuming you're also running your db in dockrr, why didn't attaching docker volumes work for you for database persistence ?
- girvo 10y ago
  Because docker-compose had a very bad habit of destroying and rebuilding the volume-only container, unfortunately! This was of course back when running Docker on macOS was somewhat painful, so mounting the DB data directory directly as a volume into your host would nearly always fail to work successfully due to screwy permissions errors (it's quite a bit better now with Docker for Mac) So, some dodgy code and a JSON file later, and our team uses the `dup` CLI to run everything with exactly zero hitches thus-far, and we've been using (across it's two incarnations) for... 18 months now?

deleted 10y ago

[deleted]

yawz 10y ago

Agreed! So far I've used Docker only on Dev systems. I'm still waiting to be convinced that there's sufficiently higher productivity and value to be had by introducing it to Prod.

deleted 10y ago

[deleted]

sktrdie 10y ago

It's great for development if it wasn't 4 to 5 times slower on Mac: https://www.reddit.com/r/docker/comments/59u1b8/why_is_docker_so_slow_on_mac/ https://www.reddit.com/r/docker/comments/59u1b8/why_is_docke...

bdcravens 10y ago
Still feels several times faster than using an option like Vagrant. (haven't found a container that didn't cold start in less than 5 seconds; 3+ minutes for common Vagrant setup is pretty common)
gerdesj 10y ago
(Having read the Reddit thread for a while) Macs don't appear to have support for containers which is what Docker is. Well that is probably bollocks because they are *BSD based and I know that FreeBSD at least has a form of containerization and I seem to recall that the whole container thing was invented on a BSD - "jails". So Docker can't run native on iStuff. You have to run it within a Linux VM. I gave up on Googling for "apple mac jail" 8) The reason why Docker runs slowly on Macs is because it is running under emulation within a VM. Unfortunately, Macs are not cool enough to run Docker, so there 8) Cheers Jon
- anoctopus 10y ago
  XNU (the macOS kernel) may have BSD origins, but it doesn't have features like cgroups and process namespacing that the Linux kernel provides and the Docker runtime relies on.
  - justincormack 10y ago
    Nor does it have FreeBSD jails.

roblabla 10y ago

I find using nix as a package manager to be a better solution. Write a nixfile that have all the tools you need for a script, and you're fixed. Docker is a slow, blunt tool for just containerizing dependencies IMO.

swsieber 10y ago
A slow, blunt, cross-platform tool. So while I agree, I don't think nix makes a good replacement for docker.
- Drdrdrq 10y ago
  Cross-distribution, to be precise. You can't run amd64 image on RPi for instance.
  - justincormack 10y ago
    Cross platform. Runs on Linux, Windows, and the Solaris port is being merged. There was a FreeBSD port but it was alas not upstreamed and needs some work. No it does not change processor architectures for you.

manojlds 10y ago

Also for CI in the same vein.