Answers: <p>Hi and welcome to DevOps SE and Docker!</p>
  
  <p>Now the concept of Docker is to create isolated virtual  environments, actually it's just a process or more but wrapped in its own environment.</p>
  
  <p>So at first hand you could take any Docker image and the scripts inside would be there where the creators of the image placed them.</p>
  
  <p>If you decide to create your own Docker images, and I believe you will sooner or later, then it is up to you how layout the system.</p>
  
  <p>Additionally, you could link - proper term is here <em>mount</em> - your system's folders with those of the container but still the execution will take place inside the container.</p>
  
  <p>For example to install the RStudio package in an Anaconda3 environment, I have tried the following.</p>
  
  <pre><code>$ docker run -it continuumio/anaconda3 bash
  (base) root@7162c3acc9e3:/# conda install -y -c r rstudio
  (base) root@7162c3acc9e3:/# which rstudio
  (base) root@7162c3acc9e3:/# /opt/conda/bin/rstudio
  </code></pre>
  
  <p>As you can see, if installed as root user which is default, the path is <code>/opt/conda/bin/rstudio</code>. Most packages not using special system capabilities would considerably not "know" whether they are in a Docker environment or not, so in many cases you could consider a Docker container to be just a (fluid) environment you have the root access too.</p>
  
  <p>Additional note on the terms:</p>
  
  <ul>
  <li><em>image</em> is a blueprint for a container defined by a Dockerfile. "Installing" something in an image means you add instructions to its Dockerfile. Own images can be derived from others by the statment FROM.</li>
  <li><em>container</em> is basically process isolation in its own OS environment. If you install something in the container during its uptime, this change will be gone with the container.</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-13T15:45:05.683Z
Answers: Thanks. So if I use the anaconda3 image and then within that container install say the RStudio package, where would I find the sh file for RStudio that I would normally fin in ~/anaconda3/bin/rstudio?
Answers: user2757598
Answers: CC BY-SA 4.0
Answers: 2018-12-13T15:45:06.717Z
Answers: Thanks. So if I use the anaconda3 image and then within that container install say the RStudio package, where would I find the sh file for RStudio that I would normally fin in ~/anaconda3/bin/rstudio?
Answers: user2757598
Answers: CC BY-SA 4.0
Answers: 2018-12-14T07:13:37.153Z
Answers: @user2757598 look for it by `docket run` of the image and running basic Linux commands like `find / -name blah` every image is likely unique and if the image author hasn't clearly documented it's usage you simply have to hunt around. you can do wild card match with `find / -name prefix.\*` where it's a regex and the backslash is to stop bash from evaluating it so that it's passed properly to find
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2018-12-14T07:16:54.610Z
Answers: Also check `env` in the image as authors often define key locations and folders they way. This sometimes works well as containers can be a minimal environment without huge amounts of unused software. It depends on the containers though and the effort the author has made to create a clean environment that is easy to use. You might want to shop around to find the most ergonomic containers for the ecosystems you use.
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2018-12-13T15:14:23.017Z
Answers: 2018-12-14T08:55:16.103Z
Answers: 2018-12-14T08:55:16.103Z
Answers: Ta Mu
Answers: <blockquote>
    <p>How/where are programs installed in Docker containers?</p>
  </blockquote>
  
  <p>They are stored inside an image.</p>
  
  <p>In a nutshell, what Docker does for you is this:</p>
  
  <ul>
  <li>It takes a prepared "image" (which you name on the command line <code>docker run ...</code>).</li>
  <li>For all intents and purposes, you can consider this image as simply a volume stored somewhere in <code>/var/lib/docker</code>, temporarily mounted somewhere on the host temporarily for you.</li>
  <li>Docker then executes an executable within that image as usual, but fakes its environment such that the new process thinks that the volume mounted in the previous step is its <code>/</code> directory. Also, the new process is pretty much encapsulated from the host, i.e., it shares nothing (other processes, files, networking etc.) unless specifically opened up by Docker for you.</li>
  </ul>
  
  <p>Apart from that, everything is as usual. There is a lot of fakery going on, but technically, at the end of the day, it's just a normal Linux process. The magic happens due to <a href="http://man7.org/linux/man-pages/man7/namespaces.7.html" rel="nofollow noreferrer">namespacing</a>, but it is mostly Linux magic, which is simply used by the Docker demon for you. Docker is like <code>chroot</code> on steroids.</p>
  
  <p>What Docker does is manage all the tiny bits and pieces for you - i.e., the image management (creating, deleting, listing etc.), the container management (running, stopping, inspecting etc.), virtual networking, the "onion" filesystems which you probably heard about and all such.</p>
  
  <blockquote>
    <p>If I'm using a Docker container for my project and install anaconda and the other packages I use, is there a folder within the container containing the bash scripts </p>
  </blockquote>
  
  <p>Yes, exactly. You acquire an image with anaconda, prepared by someone or yourself. The image is like a <code>.tar</code> archive (in a different format), and mounted during runtime. Everything lives in there. (Nomenclature: the folder is within the image, which is mounted. The "container" is just the ephemeral runtime - the process, networking etc.).</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-12-14T07:25:24.147Z
Answers: 2018-12-14T07:48:07.987Z
Answers: 2018-12-14T07:48:07.987Z
Answers: AnoE
Body: <p>Apologies for being such a basic question but all the resources I've found seem to take this knowledge for granted. </p>
  
  <p>I'm brand new to docker and containerization in general.</p>
  
  <p>Today when opening a program for a project i.e. RStudio, Jupyter, Notebook, Spyder or an IPython Console I would run a bash script in anaconda3/bin, either from a custom menu item or Anaconda Navigator or just the terminal.</p>
  
  <p>How does this work with Docker? If I'm using a Docker container for my project and I install Anaconda and the other packages I use, is there a folder within the container containing the bash scripts or does it link to bash scripts installed on my system or something else?</p>
  
Tags: <docker>
Title: How/where are programs installed in Docker containers?
UserDisplayName: user2757598
ThreadText: # How/where are programs installed in Docker containers?
  
  (Asked by: username_0 on 2018-12-13)
  
  Apologies for being such a basic question but all the resources I've found seem to take this knowledge for granted.
  
  I'm brand new to docker and containerization in general.
  
  Today when opening a program for a project i.e. RStudio, Jupyter, Notebook, Spyder or an IPython Console I would run a bash script in anaconda3/bin, either from a custom menu item or Anaconda Navigator or just the terminal.
  
  How does this work with Docker? If I'm using a Docker container for my project and I install Anaconda and the other packages I use, is there a folder within the container containing the bash scripts or does it link to bash scripts installed on my system or something else?
  
  **Tags:** docker
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-12-13. Score: 4
  
  Hi and welcome to DevOps SE and Docker!
  
  Now the concept of Docker is to create isolated virtual environments, actually it's just a process or more but wrapped in its own environment.
  
  So at first hand you could take any Docker image and the scripts inside would be there where the creators of the image placed them.
  
  If you decide to create your own Docker images, and I believe you will sooner or later, then it is up to you how layout the system.
  
  Additionally, you could link - proper term is here *mount* - your system's folders with those of the container but still the execution will take place inside the container.
  
  For example to install the RStudio package in an Anaconda3 environment, I have tried the following.
  
  ```
  $ docker run -it continuumio/anaconda3 bash
  (base) root@7162c3acc9e3:/# conda install -y -c r rstudio
  (base) root@7162c3acc9e3:/# which rstudio
  (base) root@7162c3acc9e3:/# /opt/conda/bin/rstudio
  
  ```
  
  As you can see, if installed as root user which is default, the path is `/opt/conda/bin/rstudio`. Most packages not using special system capabilities would considerably not "know" whether they are in a Docker environment or not, so in many cases you could consider a Docker container to be just a (fluid) environment you have the root access too.
  
  Additional note on the terms:
  
  * *image* is a blueprint for a container defined by a Dockerfile. "Installing" something in an image means you add instructions to its Dockerfile. Own images can be derived from others by the statment FROM.
  * *container* is basically process isolation in its own OS environment. If you install something in the container during its uptime, this change will be gone with the container.
  
  > **Comments:**
  > **username_0**: Thanks. So if I use the anaconda3 image and then within that container install say the RStudio package, where would I find the sh file for RStudio that I would normally fin in ~/anaconda3/bin/rstudio?  
  > **username_0**: Thanks. So if I use the anaconda3 image and then within that container install say the RStudio package, where would I find the sh file for RStudio that I would normally fin in ~/anaconda3/bin/rstudio?  
  > **username_2**: @username_0 look for it by `docket run` of the image and running basic Linux commands like `find / -name blah` every image is likely unique and if the image author hasn't clearly documented it's usage you simply have to hunt around. you can do wild card match with `find / -name prefix.\*` where it's a regex and the backslash is to stop bash from evaluating it so that it's passed properly to find  
  > **username_2**: Also check `env` in the image as authors often define key locations and folders they way. This sometimes works well as containers can be a minimal environment without huge amounts of unused software. It depends on the containers though and the effort the author has made to create a clean environment that is easy to use. You might want to shop around to find the most ergonomic containers for the ecosystems you use.  
  
  ---
  
  ### Answer by username_3 on 2018-12-14. Score: 3
  
  > How/where are programs installed in Docker containers?
  
  They are stored inside an image.
  
  In a nutshell, what Docker does for you is this:
  
  * It takes a prepared "image" (which you name on the command line `docker run ...`).
  * For all intents and purposes, you can consider this image as simply a volume stored somewhere in `/var/lib/docker`, temporarily mounted somewhere on the host temporarily for you.
  * Docker then executes an executable within that image as usual, but fakes its environment such that the new process thinks that the volume mounted in the previous step is its `/` directory. Also, the new process is pretty much encapsulated from the host, i.e., it shares nothing (other processes, files, networking etc.) unless specifically opened up by Docker for you.
  
  Apart from that, everything is as usual. There is a lot of fakery going on, but technically, at the end of the day, it's just a normal Linux process. The magic happens due to [namespacing](http://man7.org/linux/man-pages/man7/namespaces.7.html), but it is mostly Linux magic, which is simply used by the Docker demon for you. Docker is like `chroot` on steroids.
  
  What Docker does is manage all the tiny bits and pieces for you - i.e., the image management (creating, deleting, listing etc.), the container management (running, stopping, inspecting etc.), virtual networking, the "onion" filesystems which you probably heard about and all such.
  
  > If I'm using a Docker container for my project and install anaconda and the other packages I use, is there a folder within the container containing the bash scripts
  
  Yes, exactly. You acquire an image with anaconda, prepared by someone or yourself. The image is like a `.tar` archive (in a different format), and mounted during runtime. Everything lives in there. (Nomenclature: the folder is within the image, which is mounted. The "container" is just the ephemeral runtime - the process, networking etc.).
  
  
  ---
  
  