3 ms·

To give a counter-point to all the praise here, Docker for Mac has been one of the most frustrating pieces of software I've had to use for work. It has improved

To give a counter-point to all the praise here, Docker for Mac has been one of the most frustrating pieces of software I've had to use for work. It has improved significantly over the first time I used it (almost immediately after public beta), but I still occasionally run into various bugs, such as inotify events ceasing to work arbitrarily. Any kind of networking that makes your containers visible to the host/on the local network is also a PITA to set up through the VM that Docker for Mac uses. It's also supposed to abstract away the fact that it's actually running in a VM, but I have had to tweak the VM's CPU/memory settings multiple times, and it's not obvious when you have to do this. On top of that, last I checked, Docker for Windows is still missing some features like inotify events, and requires you to enable Hyper-V, which of course removes your ability to have other VMs running simultaneously. The other side of it is that Vagrant is just easier. Docker requires everything to fit into a "one container per service, one process per container" model, which is a really good idea in production, but makes setting up background services (such as the Flow server) in development way harder than it needs to be. I'm not a devops person, so the extra overhead of trying to figure this all out is significant. Vagrant isn't without its own technical problems, but it mostly Just Works™, and I can do anything to the VM that I'd do on a regular Linux machine. As someone who really doesn't care how these things work under the hood, Vagrant has been a significantly smaller source of friction for me.

mschuster91 9y ago
> Docker requires everything to fit into a "one container per service, one process per container" model, which is a really good idea in production, but makes setting up background services (such as the Flow server) in development way harder than it needs to be. No, it does not. I use Docker as vagrant replacement too, and use a self-written bash script as "init script" that: 1) launches all services required (e.g. apache, mysql, sshd, elasticsearch) by running "service XYZ start" 2) records the pidfiles of each service (/var/run/xyz.pid) 3) sleeps 10 seconds, waits for all the pids having exited - if yes, exit the initscripts, if not, go back to #3 4) on SIGTERM/SIGINT, gracefully shut down the services in the correct order (e.g. apache/php first, then elasticsearch, then mysql); the watcher loop of #3 will detect all services having shut down and exit cleanly This way I have exact reproduction of a real target server and don't have to deal with the myriad of issues that arise with docker-compose and "custom networks". Also, the documentation on how to set up a production server, especially the required OS packages, is embedded right in the Dockerfile (or, as I put the setup script in its own file, in this one). Build time for an image with identical functionality is approximately equal to what it was with Vagrant. In contrast to vagrant, once you build that image initially it starts up way faster (10s for a LAMP+es stack), and provisioning it is a breeze compared to puphpet or whatever is the trend now. And you don't have to update your setup script unless the base OS changes, as compared to puphpet+vagrant - in fact I can use nearly the same setup and init script across stuff as old as Debian 6 (some ancient proprietary software I had to dockerize) over Ubuntu 16.04 and as brand new as Debian nightly.
- anaganisk 9y ago
  can i see the init script seems useful
  - mschuster91 9y ago
    Unfortunately it's corp stuff and needs a bit of cleanup. But I'll try to get it open sourced - can you send me a reminder email? My email's in my profile.
- RussianCow 9y ago
  I used the wrong wording: I should have said that Docker encourages one process per container, not that it requires it. It's possible to do most of the same things with Docker as you can do with a VM, including implementing a full-blown init system, it's just a matter of effort. Having said that, what you did is definitely non-trivial (at least it would be for me), and you've basically re-implemented all of the stuff Vagrant gives you for free, for a pretty marginal benefit (IMO). Maybe that setup works better for you, but I don't understand why I should go through all that effort when Vagrant Just Works™ most of the time, and Docker for Mac runs everything through a VM anyway.
  - mschuster91 9y ago
    > but I don't understand why I should go through all that effort when Vagrant Just Works™ most of the time Problem with Vagrant is you can't take the VM you created and deploy it on any random Linux server (or random Docker-hosting cloud provider) - while a pure Docker solution can be deployed literally anywhere with Docker support, as long as you give it a way to persist the data directories of the services. docker-compose is a hit-and-miss across hosters, and you can't use it on DC/OS or Kubernetes environments. I use my script collection mainly for dev environments, but it's useful when you want to spin up QA/dev instances without having to provision real servers.

mschuster91 9y ago

> Docker requires everything to fit into a "one container per service, one process per container" model, which is a really good idea in production, but makes setting up background services (such as the Flow server) in development way harder than it needs to be. No, it does not. I use Docker as vagrant replacement too, and use a self-written bash script as "init script" that: 1) launches all services required (e.g. apache, mysql, sshd, elasticsearch) by running "service XYZ start" 2) records the pidfiles of each service (/var/run/xyz.pid) 3) sleeps 10 seconds, waits for all the pids having exited - if yes, exit the initscripts, if not, go back to #3 4) on SIGTERM/SIGINT, gracefully shut down the services in the correct order (e.g. apache/php first, then elasticsearch, then mysql); the watcher loop of #3 will detect all services having shut down and exit cleanly This way I have exact reproduction of a real target server and don't have to deal with the myriad of issues that arise with docker-compose and "custom networks". Also, the documentation on how to set up a production server, especially the required OS packages, is embedded right in the Dockerfile (or, as I put the setup script in its own file, in this one). Build time for an image with identical functionality is approximately equal to what it was with Vagrant. In contrast to vagrant, once you build that image initially it starts up way faster (10s for a LAMP+es stack), and provisioning it is a breeze compared to puphpet or whatever is the trend now. And you don't have to update your setup script unless the base OS changes, as compared to puphpet+vagrant - in fact I can use nearly the same setup and init script across stuff as old as Debian 6 (some ancient proprietary software I had to dockerize) over Ubuntu 16.04 and as brand new as Debian nightly.

anaganisk 9y ago
can i see the init script seems useful
- mschuster91 9y ago
  Unfortunately it's corp stuff and needs a bit of cleanup. But I'll try to get it open sourced - can you send me a reminder email? My email's in my profile.
RussianCow 9y ago
I used the wrong wording: I should have said that Docker encourages one process per container, not that it requires it. It's possible to do most of the same things with Docker as you can do with a VM, including implementing a full-blown init system, it's just a matter of effort. Having said that, what you did is definitely non-trivial (at least it would be for me), and you've basically re-implemented all of the stuff Vagrant gives you for free, for a pretty marginal benefit (IMO). Maybe that setup works better for you, but I don't understand why I should go through all that effort when Vagrant Just Works™ most of the time, and Docker for Mac runs everything through a VM anyway.
- mschuster91 9y ago
  > but I don't understand why I should go through all that effort when Vagrant Just Works™ most of the time Problem with Vagrant is you can't take the VM you created and deploy it on any random Linux server (or random Docker-hosting cloud provider) - while a pure Docker solution can be deployed literally anywhere with Docker support, as long as you give it a way to persist the data directories of the services. docker-compose is a hit-and-miss across hosters, and you can't use it on DC/OS or Kubernetes environments. I use my script collection mainly for dev environments, but it's useful when you want to spin up QA/dev instances without having to provision real servers.