3 ms·

Agreed, it's a nice intro. I still think the hardest part is understanding how docker fits into the bigger picture. I think I've more or less figured it out on

• icebraining 11y ago
  If you're loading the source from outside, aren't you losing the advantages of immutability of the Docker container? Suddenly the same image may have different behaviours depending on the state of the code outside.
  • xchaotic 11y ago
    That's why you want to use volumes for mutable data such as your source code repo - you isolate the changing parts and keep the containers static.
    • icebraining 11y ago
      But if the source is mutable data, what isn't? Everything eventually mutates - dependencies have updates, configurations change, etc. Isn't the point of images that you "freeze" a static release that can be deployed everywhere? It seems that by that point you've lost the advantage of using images; if parts of the system must be loaded outside of the container, it seems you might as well simply use a configuration manager to install the stuff and then run LXC/LXD containers instead of using images at all.
      • tvmalsv 11y ago
        I know, I'm a little late to this party, but just in case anyone is still around... :) For me, mounting my local app files as a volume is useful during development since it keeps the workflow fast. I don't have to rebuild the image every time I want to try the app out, I get to use the new code without delay. If I were deploying as a container, I presume my build process would check the app out of git and build the image based on that fresh checkout. I'm just using Docker as a convenient way of simulating my production environment (dev'ing on Ubuntu 15.04, but deploying to Debian 7), and still be able to iterate rapidly.
        • icebraining 11y ago
          Ah, fair enough, I was really thinking about shared, deployable images. I suppose this use case makes sense.