Docker in Production: A retort

Re:Docker in Production: A retort by emeraldd on Saturday November 05, 2016 @04:15PM (#12881654)

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!

[ Parent | on HN ]

Re:Docker in Production: A retort by girvo on Saturday November 05, 2016 @06:52PM (#12882347)

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

[ Parent | on HN ]

Re:Docker in Production: A retort by notliketherest on Sunday November 06, 2016 @01:03AM (#12883619)

Assuming you're also running your db in dockrr, why didn't attaching docker volumes work for you for database persistence ?

[ Parent | on HN ]

Re:Docker in Production: A retort by girvo on Sunday November 06, 2016 @01:41AM (#12883711)

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?

[ Parent | on HN ]

Re:Docker in Production: A retort by roblabla on Saturday November 05, 2016 @08:16PM (#12882674)

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.

[ Parent | on HN ]

Re:Docker in Production: A retort by swsieber on Sunday November 06, 2016 @01:34AM (#12883693)

A slow, blunt, cross-platform tool. So while I agree, I don't think nix makes a good replacement for docker.

[ Parent | on HN ]

Re:Docker in Production: A retort by Drdrdrq on Sunday November 06, 2016 @01:29AM (#12883854)

Cross-distribution, to be precise. You can't run amd64 image on RPi for instance.

[ Parent | on HN ]

Re:Docker in Production: A retort by justincormack on Sunday November 06, 2016 @05:08AM (#12884382)

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.

[ Parent | on HN ]

Re:Docker in Production: A retort by sktrdie on Saturday November 05, 2016 @08:13PM (#12882657)

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_docke...

[ Parent | on HN ]

Re:Docker in Production: A retort by bdcravens on Saturday November 05, 2016 @08:34PM (#12882739)

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)

[ Parent | on HN ]

Re:Docker in Production: A retort by gerdesj on Saturday November 05, 2016 @08:45PM (#12882783)

(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

[ Parent | on HN ]

Re:Docker in Production: A retort by anoctopus on Saturday November 05, 2016 @11:15PM (#12883290)

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.

[ Parent | on HN ]

Re:Docker in Production: A retort by justincormack on Sunday November 06, 2016 @05:13AM (#12884394)

Nor does it have FreeBSD jails.

[ Parent | on HN ]

Re:Docker in Production: A retort by yawz on Saturday November 05, 2016 @07:16PM (#12882442)

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.

[ Parent | on HN ]

Re:Docker in Production: A retort by manojlds on Sunday November 06, 2016 @01:36AM (#12883703)

Also for CI in the same vein.

[ Parent | on HN ]