File sharing between the Docker machine and containers is extremely fast. But if you want to stay in MacOS and use Docker, I have a few tips to make your life better. Docker-sync and Upcoming Changes. Docker-sync is a very handy Ruby gem that makes it easy to use rsync or unison file sharing with Docker. Rsync and unison allow you to exclude subdirectories, so you can ignore./tmp,./node_modules,./dist, and so on.

We always had our local development environments setup with Docker on top of Vagrant. While this has worked out just fine, the overhead of building and maintaining them started to increase significantly. Then here comes containerization with Docker gaining popularity. So, after a few months of random discussions with colleague (who is by the way a Senior Software Engineer AND a really sly Magician) and with the wide availability of Docker for Mac (they just released it sometime on the last week of July last year), I decided to take it up a notch and see how well it would work. Before we start Here are a couple of requirements we need installed on our host machine: • • by File and Directory Structure Take a look at this overview. FROM node:latest ENV PROJECT_ROOT /opt/app RUN apt-get update && apt-get install -y man postgresql-client-9.4 && rm -rf /var/lib/apt/lists/* && npm install -g pm2 RUN mkdir -p /tmp/app COPY package.json /tmp/app/package.json RUN cd /tmp/app/ && npm install --silent WORKDIR $PROJECT_ROOT COPY bin /opt/bin CMD [ '/opt/bin/start.sh' ] Since this is for a Node.js project, an should do it quite nicely.

Hence, the FROM node:latest line. We then setup an environment variable for our project’s root within the container, that would be ENV PROJECT_ROOT /opt/app. Then we’ll install some dependencies that we need for the project.

In this case, we just want a postgresql-client and a global install for the npm package pm2 to run our Node.js project. RUN apt-get update && apt-get install -y man postgresql-client-9.4 && rm -rf /var/lib/apt/lists/* && npm install -g pm2 We’ll also cleanup our package lists as they take up some space and we don’t need any more to bloat up our soon-to-be-built Docker image. Also did you notice how we string the commands into a single RUN statement instead of declaring one RUN statement for each? Since Docker creates a new layer to the image for every statement, doing this will minimize the amount of layers the image will have and thus speed things up and reduce image size.

The next 3 commands are used as a way for dependency files to be started always on a blank slate on build, forcing Docker to not use the cache when we change our application’s dependencies. Version: '2' syncs: some-random-app-sync: src: './some-random-app-folder/' dest: '/opt/app' sync_host_ip: 'localhost' sync_host_port: 10871 sync_group: root sync_userid: 0 sync_strategy: 'rsync' Some notes to keep in mind: • The sync name must be globally unique just like how container ports are and should NOT match your real application container name. • The sync_host_port should be a unique port. The start.sh shell script What is this start.sh shell script for? Take a look at it’s content. Limited access repair tool for mac doiwnload. #!/usr/bin/env bash if [! -d $PROJECT_ROOT/node_modules ]; then cp -a /tmp/app/node_modules $PROJECT_ROOT fi pm2-dev start '$PROJECT_ROOT/index.js' First, it checks to see if the node_modules dependencies folder exists within the project’s root.

If not, it copies over the dependencies from the /tmp/app folder within the container (remember those 3 commands in the Dockerfile) to the project’s root. This helps us keep the dependencies up-to-date and out of our local host, only existing within the container. Second, we invoked the pm2-dev command to start the app’s index.js file to run in development mode. Don’t forget to set the permissions for start.sh to 0755. Sample index.js and package.json Here is a sample index.js file I picked up from.