> docker cp ~/.gitconfig project_dev_1:/home/dev I also like to have my normal Git configuration available as well: > docker-compose exec -u root app chown dev:dev /home/dev/.ssh/id_rsa > docker cp ~/.ssh/id_rsa project_dev_1:/home/dev/.ssh These examples assume the container will be run as a user called “dev.” I needed to do the latter because my ~/.ssh/config has some things that aren’t compatible with the Ubuntu version running in the container. If you rely on your SSH keys to authenticate with your Git server, then you’ll want to either mount your ~/.ssh directory in the container or copy your private key into the container manually. You can’t do this as part of the Dockerfile because we want the repository to live in the mounted volume. Once you have your container up and running ( docker-compose up), you’ll need to check out your source code inside the container. But you’ll still need a little customization of the container once it’s been built. The idea is that any developer could check out the repository on their laptop, run docker-compose up, and have a working development environment. I’m using this for an old Ruby on Rails project, hence the old version of MySQL. Here’s an example docker-compose.yml file that has a couple of named volumes, one for the source code directory and the other for the contents of the database. With Docker Compose, you just need to set the tty option to true in your docker-compose.yml. Similar to a database container, your “dev” container should stay running when you do a docker-compose up so you can attach to it from VS Code. But if the source code is checked out into a named volume, the container can be re-built over and over again, with your source code being mounted exactly as it was before. If you just checked out a repository into a normal directory inside the container, you’d have to be careful not to lose any changes that had not been committed and pushed whenever making changes to container (updating something in the Dockerfile, etc.).
#DOCKER ON MAC SOUND HOW TO#
There’s plenty of existing documentation on how to use Docker Compose, but I want to point out a couple of things that I’ve done because I’m using a container to host the source code I’m editing. I’m using Docker Compose to manage the containers that make up my development environment.
#DOCKER ON MAC SOUND UPDATE#
However, earlier this summer, a Visual Studio Code update introduced the ability to “attach to a running container.” Once attached, the experience when editing files that reside on a container using VS Code is nearly indistinguishable from that of editing files on the local filesystem with VS Code! 1. But I’ve still found it to be unacceptably slow to have the source code mounted from the host machine, at least for something like a Ruby on Rails application. In the time since that post was written, those improvements have been released.
#DOCKER ON MAC SOUND MAC OS#
He talked about some of the filesystem performance problems that can arise when using a shared volume from the host machine on Mac OS X, along with some potential workarounds and word of some upcoming performance improvements. A couple of years ago, Will Pleasant-Ryan wrote Docker for Mac: Overcoming Slow Mounted Volumes, describing his desire to use Docker for local development.