getting-started/docs/tutorial/using-bind-mounts/index.md

In the previous chapter, we talked about and used a named volume to persist the data in our database. Named volumes are great if we simply want to store data, as we don't have to worry about where the data is stored.

With bind mounts, we control the exact mountpoint on the host. We can use this to persist data, but is often used to provide additional data into containers. When working on an application, we can use a bind mount to mount our source code into the container to let it see code changes, respond, and let us see the changes right away.

For Node-based applications, nodemon is a great tool to watch for file changes and then restart the application. There are equivalent tools in most other languages and frameworks.

Quick Volume Type Comparisons

Bind mounts and named volumes are the two main types of volumes that come with the Docker engine. However, additional volume drivers are available to support other uses cases (SFTP, Ceph, NetApp, S3, and more).

	Named Volumes	Bind Mounts
Host Location	Docker chooses	You control
Mount Example (using -v)	my-volume:/usr/local/data	/path/to/data:/usr/local/data
Populates new volume with container contents	Yes	No
Supports Volume Drivers	Yes	No

Starting a Dev-Mode Container

To run our container to support a development workflow, we will do the following:

• Mount our source code into the container
• Install all dependencies, including the "dev" dependencies
• Start nodemon to watch for filesystem changes

So, let's do it!

1. Make sure you don't have any previous getting-started containers running.

2. Run the following command. We'll explain what's going on afterwards:

   docker run -dp 3000:3000 \
       -w /app -v "$(pwd):/app" \
       node:12-alpine \
       sh -c "yarn install && yarn run dev"
   

   If you are using PowerShell then use this command.

   docker run -dp 3000:3000 `
       -w /app -v "$(pwd):/app" `
       node:12-alpine `
       sh -c "yarn install && yarn run dev"
   

   • -dp 3000:3000 - same as before. Run in detached (background) mode and create a port mapping
   • -w /app - sets the "working directory" or the current directory that the command will run from
   • -v "$(pwd):/app" - bind mount the current directory from the host in the container into the /app directory
   • node:12-alpine - the image to use. Note that this is the base image for our app from the Dockerfile
   • sh -c "yarn install && yarn run dev" - the command. We're starting a shell using sh (alpine doesn't have bash) and running yarn install to install all dependencies and then running yarn run dev. If we look in the package.json, we'll see that the dev script is starting nodemon.

3. You can watch the logs using docker logs -f <container-id>. You'll know you're ready to go when you see this...

   docker logs -f <container-id>
   $ nodemon src/index.js
   [nodemon] 1.19.2
   [nodemon] to restart at any time, enter `rs`
   [nodemon] watching dir(s): *.*
   [nodemon] starting `node src/index.js`
   Using sqlite database at /etc/todos/todo.db
   Listening on port 3000
   

   When you're done watching the logs, exit out by hitting Ctrl+C.

4. Now, let's make a change to the app. In the src/static/js/app.js file, let's change the "Add Item" button to simply say "Add". This change will be on line 109.

   -                         {submitting ? 'Adding...' : 'Add Item'}
   +                         {submitting ? 'Adding...' : 'Add'}
   

5. Simply refresh the page (or open it) and you should see the change reflected in the browser almost immediately. It might take a few seconds for the Node server to restart, so if you get an error, just try refreshing after a few seconds.

   {: style="width:75%;"} {: .text-center }

6. Feel free to make any other changes you'd like to make. When you're done, stop the container and build your new image using docker build -t getting-started ..

Using bind mounts is very common for local development setups. The advantage is that the dev machine doesn't need to have all of the build tools and environments installed. With a single docker run command, the dev environment is pulled and ready to go. We'll talk about Docker Compose in a future step, as this will help simplify our commands (we're already getting a lot of flags).

Optionals steps for "resource sharing" may be required

If the docker run... command above fails with an error message, stating docker: Error response form daemon: status code not OK but 500:..., it's likely caused by the fact, that resource sharing is disabled (e.g. default in "Docker Desktop for Windows").

To make it work, you need to add a path to the "Docker Desktop" configuration, to define it as a shared ressource between the host and docker containers.

1. Click the "gear" symbol inside the docker dashboard, to open the "Settings" panel.
2. Click "Resources"
3. Click "FILE SHARING"
4. Click on blue "plus" symbol
5. Enter the path to the shared folder
6. Click on "Apply & Restart"

Please note: If the path name is automatically shortened, you need to make sure it's still valid. In most cases you'll need to manually reduce the path name to the directory on the higher level.

Recap

At this point, we can persist our database and respond rapidly to the needs and demands of our investors and founders. Hooray! But, guess what? We received great news!

Your project has been selected for future development!

In order to prepare for production, we need to migrate our database from working in SQLite to something that can scale a little better. For simplicity, we'll keep with a relational database and switch our application to use MySQL. But, how should we run MySQL? How do we allow the containers to talk to each other? We'll talk about that next!