What is the best practices of using Docker for front end development on OS X and passthrough ENV from host to container

I am looking for best practices about front-end developing on OSX with docker and I have found number of projects on github. Here they are:

The fact is I need two-way syncing files from host system to virtual container and vice versa via mounted (synced) folder and IO performance should be like native one. Therefore I don’t consider shared folders FS like vboxsf and vmhgfs. Also it’s needed to have some build tools (gulp etc) with working wathcer within shared folder.
What do you think about xhyve (with NFS) instead of VirtualBox? Who tried the unison, what the performance docker provides with it?

  • running apache in docker
  • Headless docker host with a headful container
  • Docker OSX disc storage
  • how to clean up docker overlay directory?
  • Boot2Docker Hazelcast and ulimit
  • My boot2docker installation seems to not be working. What am I doing wrong?
  • At last I have a special task I want to run app.js via nodejs through host to container ENV if it is possible. In other words I have to add ENV variable for PATH to nodejs (within virtual container) to my ~/.bash_profile. Is there any chance to do passthrough NODE_PATH from host to container at all?

  • JHipster microservice's sevice restemplate unable to retrieve JWT token_key from UAA server
  • How to expose in a network?
  • vagrant up --provider=docker SSL cert issue
  • How should I create Dockerfile to run multiple services through docker-compose?
  • How to run gerrit cookbook inside docker containers?
  • application performance decrease a lot in docker
  • One Solution collect form web for “What is the best practices of using Docker for front end development on OS X and passthrough ENV from host to container”

    Not sure if “best practice” is asking for opinions (which is against SO policy), note that this also heavily depends on your tools chain.

    I’m not a fan of boot2docker as it works to date (although it may improve and it may be the best approach in the long term as it is the official approach maintained by the docker team).

    EDIT: boot2docker was discontinued and replaced by Docker Machine which does pretty much the same thing but in a more generic way, allowing you to manage Docker daemons locally, in LAN or in the cloud.

    For Me, I’m on Windows, but I face the same (even more) difficulties as OSX devs. As I’m using Hyper-V, boot2docker (VirtualBox) can’t run, so I have to roll my own. Also, last time I tried boot2docker – it ran TinyCoreLinux, which is another Linux distribution I’d have to learn while my focus is CoreOS in the cloud, so I’d rather just focus on CoreOS.

    The target for setting up your dev is as follows:

    • Have ssh access with mounting rights to a docker host (either in VM or on LAN): this is CoreOS on Hyper-V for me.
    • Have a native docker client & export DOCKER_HOST=<ip or hostname here>
    • mount /mnt/from/host working directory into your docker host for live reload: this works through mount.cifs on CoreOS with a systemd unit for me.
    • Make dev.Dockerfile for your dev requirements, if you’re a node developer, start from the node image, npm install gulp/browserify/.. whatever you need as a base image for your projects & docker build -f dev.Dockerfile -t my_dev_container .
    • docker run -it -v /mnt/from/host/:/src/app/ -e my_dev_container

    You are now in a terminal with a fully isolated environment which can be put under source control & replicated between project members and has full live reload abilities.

    Draw backs: if you rely on REPL or intelliSense from your IDE, you’ll have to have an IDE that can use the remote server. Or you have to run your IDE within the dev container (cloud9 or use X server).

    Of course if you live in a terminal and are fluent in vim, you are good to go.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.