Item — HN Reader

Docker does great marketing but to my knowledge I can't use the toolbox to effortlessly (without Vagrant) set up a non-trivial microservice development flow on my Mac yet.

On the deployment side there are also still lots of inconsistencies between the different tools but I can see it becoming the go-to pragmatic way to bootstrap your private "cloud" very soon.

Again deployment is only part of the solution and I wish Docker would hire more good people to work on different development "best-practices" for Linux as well as OSX.

If Docker eventually wants to become a major service provider they should complement that kind of tooling with the same vigorous level of documentation and blogging as Heroku, Digital Ocean, Codeship and the likes come up with consistently.

2 comments

On my Mac I run docker under CoreOS VM, the same OS I use on production, and use lsyncd to transparently synchronize all the files that I touch in the editor into the VM. Works like charm.

I bet you would help not only me but lots of people if you'd share that workflow.

Which hypervisor are you using?

Is Vagrant still part of that setup (a tool that should become obsolete with a pure docker development approach IMHO)?

I didn't find anything like that on either the Docker nor CoreOS official docs unfortunately. Both of those companies are fighting for territory in this super lucrative space, one of them should provide it without relying on the greater community (like one of you or me doing what's arguably their job for free).

Edit: I'm sorry if this comes off as the typical abrasive comment but I've been working with both those technologies for more than a year now and mind you not alone. A couple of good developers and sysadmins I work with are also still trying to figure out how to go about all of these issues and what I see is a big disconnect between what gets advertised vs. where we are at this point. As somebody who did FreeBSD jails and OpenVZ container system administration as well as general "distributed systems" development myself for many years I also admit to painfully miss the amazing simplicity of creating a monolith and effortlessly deploying it to Heroku. It's something I've become used to over the last couple of years and I miss it, even though I myself find the promise of the current "microservice" trend very interesting as well.

The setup is straightforward.

I use VirtualBox to run CoreOS, but VM can run anything as long as it comes with a recent Docker and does not require a lot of maintenance. Then I run lsyncd to synchronize files from the host transparently into that VM and edit whatever files I need in the Emacs on the host. When I need to run a docker command, I do it either from Emacs by prefixing the command with ssh local-vm-name or from a ssh session in a terminal.

To test the things I use, for example, another VM where /etc/hosts points for my production domains to the VM with Docker. Another useful thing is to expose during development, say, PHP/JS code that I edit directly into container for quick testing feedback. For that I can run the container with an extra host volume mount that override the software tree in the image with one that comes from Docker VM and where lsyncd copies all my changes that I made in Editor.

Thanks for answering, do I understand correctly that you develop directly on CoreOS with Emacs? If so I think your workflow might be more of an outlier as I reckon most people tend to work on OSX (possibly even running some IDE of some sorts).

I think a lot of confusion comes from unclear definitions so I try my best here, it would be great if you could chip in once again...

# Premise

1. our base operating system is Mac OSX which we will simply call osx

2. on top of osx we run a hypervisor (e.g. xhyve, vmware, virtualbox)

3. on top of our hypervisor we are running a virtual machine with CoreOS as our docker_engine (with the help of or without vagrant)

4. on top of our docker_engine we run an arbitrary set of docker_container instances most of which are comprised of a "bespoke" docker_image of our own; a certain "microservice" in development

# Questions

How do we:

a) map a ("microservice") project's source code directory located on our osx file system onto the currently instantiated development docker_image for our current project's development docker_container

osx => hypervisor => docker_engine => docker_container

b) and pass any file changes from osx down to the docker_container level as well (i.e. inotify, lsyncd, etc)

BTW, if we'd wanted to make this an even more helpful effort why not make this a proper gist?

https://gist.github.com/musha68k/399c66374ca54c665fd5

I do not run Emacs in VM, I edit files on the host! lsyncd just transparently copies all my changes into the VM, see the details in the gist. In another setup this also worked with Eclipse when lsyncd synchronized compiled classes into the VM.

So... you ensure that you are using the same OS in dev and production... doesn't this defeat one of the main reasons for using docker in the first place?

It's my understanding that containerization's major benefit is not for development but for system maintenance. It allows sysadmins the luxury to stop spawning VMs left and right, since you can safely avoid all the overhead of keeping full VMs worth of hardware resources for applications that will ultimately only need them in short bursts.

By itself, containerization is great already, without involving the devs at all.

What Docker attempts to provide is a Framework that allows Devs and Sysadmins the use of the same tools. Ideally, if you can get your devs to use this framework, you will unlock the next step: you no longer deliver sources or packages in production, but rather entire Docker Images, ready to use and with clearly identified interfaces with other systems. It's a dream come true for IT sysadmins, who can focus on their own problematics, monitoring, logging, security, resource management, network architecture etc.

And that's what great about the Docker effort: it's the devs trying to be the best wingmen in the world with their sysadmin pals.

Docker have a lot more than just the containers - they acquired Tutum for a cloud based deployment workflow and Universal Control Plane for on prem. The Docker hub and DTR also help with build and deployments of containers.

It's a set of tooling and an ecosystem and not just the container technology.

Thank you, I'm familiar with the various "merges and acquisitions" (fig, tutum cloud etc) but my point was that there are still a lot of unfulfilled promises and that Docker's admittedly great marketing can be misleading.