<p>I think you may be using the wrong tool for the job.  Docker is not designed to be a version control system, it is designed for containerization.  Furthermore, your question makes it sound like the development and support team members are constantly changing the files that are essential to the makeup of the image.  This makes using a volume pointless as the Docker image will always be changing.</p>

<p>If I'm understanding what you are trying to achieve (people should be able to modify the <code>src</code> and <code>eggs</code> folders with whatever editor they want), then you may want to explore adopting a <a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="nofollow noreferrer">CI</a>/<a href="https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment" rel="nofollow noreferrer">CD</a> workflow:</p>

<ol>
<li>Committed changes to the <code>src</code> and <code>egg</code> folders trigger a new image to be built.</li>
<li>The new image is pushed to a <a href="https://docs.docker.com/docker-hub/repos/" rel="nofollow noreferrer">Docker repository</a>.</li>
<li>Team members can then pull the updated image.</li>
</ol>

<p>As for your two specific questions:</p>

<blockquote>
  <p>Do we usually put build stuff that are actually part of the container into volumes? The container has no meaning without these volumes.</p>
</blockquote>

<p>Not usually.  Generally if I have to make changes to a container I would remote into it and then commit the changes.</p>

<blockquote>
  <p>Can end users take a copy of these volumes and just modify it according to their convenience without the master copy of these volumes? (Like Image vs Container concept?)</p>
</blockquote>

<p>This is sounding like a version control system which Docker is not designed for.  You can have a shared <a href="https://docs.docker.com/storage/volumes/" rel="nofollow noreferrer">volume</a> that users have access to, but the use case is for persisting data outside of containers (e.g. SQL database data).</p>

CC BY-SA 4.0
2019-12-04T16:03:49.887Z
Very interesting perspective @Wesley Rolnick. CI/CD gives me an alternative perspective (in a nice way) to go about this problem. Are you saying that docker containers aren't actually meant for code **development** even though it solves a lot of developer problems like setting up an environment for development etc? During development, things will keep changing - but we don't want to create images out of that - it usually goes through a (version control) reviewing system before getting accepted etc. Anyway, food for thought!
Nishant
CC BY-SA 4.0
2019-12-04T16:08:48.000Z
Is there any tool that can be used for the workflow I described?
Nishant
CC BY-SA 4.0
2019-12-04T17:27:56.883Z
@Nishant - Correct, Docker containers are generally used to help deploy or provide developer tools but not provide an Integrated Development Environment (IDE) (e.g., SQL Server image, Dockerized API for app development)
Wesley Rolnick
CC BY-SA 4.0
2019-12-04T15:30:47.520Z
2019-12-04T15:30:47.520Z
Wesley Rolnick
<p>I am trying to setup <strong>plug-and-play</strong> docker images for my development and support team members - however I am running into some problems because I want them to be able to use the editor of their choice!</p>

<p>There are two critical folders that are part of the <strong>build</strong> (<code>eggs</code> and <code>src</code>) that needs to be exposed to the end users so that they can edit it in any editor of their choice.</p>

<p>All the options to edit container files in host machine talks about mounting a fresh folder from the outside; but like I said, my <code>src</code> and <code>egg</code> folders are <strong>part of the build</strong>, so I can't let them mount a fresh folder during <code>docker run</code>.</p>

<p>I thought of about using volumes, but here are the questions I have on this approach:</p>

<p>1) Do we usually put build stuff that are actually part of the container into volumes? The container has no meaning without these volumes.</p>

<p>2) Can end users take a copy of these volumes and just modify it according to their convenience without the master copy of these volumes? (Like Image vs Container concept?)</p>

<p>All my problems will be solved if I can expose folders inside my container to the outside (not the reverse), but that seems really tricky to achieve!</p>

<p>PS: I haven't research enough on volumes but I thought I could ask this question anyway.</p>

<hr>

<p>Just to complete the workflow, our development/support team usually identifies and fixes these problems in their machine, sends a PR to the Git system which then gets merged etc.</p>

<p>I am trying to use Docker to solve the problem of not re-building the entire web-app in each developers machine running multiple OSes etc.</p>

CC BY-SA 4.0
2019-12-04T13:23:20.587Z
Have a look at https://github.com/cweagans/docker-bg-sync.
Hedi Nasr
CC BY-SA 4.0
2019-12-04T13:27:11.273Z
@HediNasr, interesting I will have a work - but I can't believe there are no better options than syncing :-) If it has 2-way syncing it might work, but I am looking for better options.
Nishant
<docker>
How can I access directories inside a docker container from outside (not the reverse!)?
Nishant
# How can I access directories inside a docker container from outside (not the reverse!)?

(Asked by: username_0 on 2019-12-04)

I am trying to setup **plug-and-play** docker images for my development and support team members - however I am running into some problems because I want them to be able to use the editor of their choice!

There are two critical folders that are part of the **build** (`eggs` and `src`) that needs to be exposed to the end users so that they can edit it in any editor of their choice.

All the options to edit container files in host machine talks about mounting a fresh folder from the outside; but like I said, my `src` and `egg` folders are **part of the build**, so I can't let them mount a fresh folder during `docker run`.

I thought of about using volumes, but here are the questions I have on this approach:

1) Do we usually put build stuff that are actually part of the container into volumes? The container has no meaning without these volumes.

2) Can end users take a copy of these volumes and just modify it according to their convenience without the master copy of these volumes? (Like Image vs Container concept?)

All my problems will be solved if I can expose folders inside my container to the outside (not the reverse), but that seems really tricky to achieve!

PS: I haven't research enough on volumes but I thought I could ask this question anyway.

---

Just to complete the workflow, our development/support team usually identifies and fixes these problems in their machine, sends a PR to the Git system which then gets merged etc.

I am trying to use Docker to solve the problem of not re-building the entire web-app in each developers machine running multiple OSes etc.

**Tags:** docker

> **Comments:**
> **username_1**: Have a look at https://github.com/cweagans/docker-bg-sync.  
> **username_0**: @HediNasr, interesting I will have a work - but I can't believe there are no better options than syncing :-) If it has 2-way syncing it might work, but I am looking for better options.  

---

## 1 answers

### Answer by username_2 on 2019-12-04. Score: 1

I think you may be using the wrong tool for the job. Docker is not designed to be a version control system, it is designed for containerization. Furthermore, your question makes it sound like the development and support team members are constantly changing the files that are essential to the makeup of the image. This makes using a volume pointless as the Docker image will always be changing.

If I'm understanding what you are trying to achieve (people should be able to modify the `src` and `eggs` folders with whatever editor they want), then you may want to explore adopting a [CI](https://en.wikipedia.org/wiki/Continuous_integration)/[CD](https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment) workflow:

1. Committed changes to the `src` and `egg` folders trigger a new image to be built.
2. The new image is pushed to a [Docker repository](https://docs.docker.com/docker-hub/repos/).
3. Team members can then pull the updated image.

As for your two specific questions:

> Do we usually put build stuff that are actually part of the container into volumes? The container has no meaning without these volumes.

Not usually. Generally if I have to make changes to a container I would remote into it and then commit the changes.

> Can end users take a copy of these volumes and just modify it according to their convenience without the master copy of these volumes? (Like Image vs Container concept?)

This is sounding like a version control system which Docker is not designed for. You can have a shared [volume](https://docs.docker.com/storage/volumes/) that users have access to, but the use case is for persisting data outside of containers (e.g. SQL database data).

> **Comments:**
> **username_0**: Very interesting perspective @username_2. CI/CD gives me an alternative perspective (in a nice way) to go about this problem. Are you saying that docker containers aren't actually meant for code **development** even though it solves a lot of developer problems like setting up an environment for development etc? During development, things will keep changing - but we don't want to create images out of that - it usually goes through a (version control) reviewing system before getting accepted etc. Anyway, food for thought!  
> **username_0**: Is there any tool that can be used for the workflow I described?  
> **username_2**: @username_0 - Correct, Docker containers are generally used to help deploy or provide developer tools but not provide an Integrated Development Environment (IDE) (e.g., SQL Server image, Dockerized API for app development)  

---

