We run containers locally for components that our code needs, i.e. if the code needs redis, or elasticsearch or whatever it's easier to spin up a local container, keeps the dev system free of clutter, and what you're running can often be the same or very close to what is in prod. For our own code, why should it care whether it is running in a container or not? We develop locally on the host and package into a container at deployment.
Re:Docker Compose Wrapper
by athyuttamre on Saturday March 12, 2016 @11:44AM
(#11273431)
You could host a volume into your container containing the code base. Then use any standard live reloading library to make it work.
If the live reloading library relies on inotifywait, it won't detect changes made on the OSX side across the volume due to issues with Virtual Box. I made a utility that I run in my container while I'm developing to trigger these events: https://github.com/sillypog/inotify-proxy
Does it mean that I need two docker compose, one for development and one for deployment ?
Re:Docker Compose Wrapper
by athyuttamre on Monday March 21, 2016 @07:51PM
(#11333256)
That's correct. I have this setup at http://github.com/athyuttamre/signmeup.
As far as I know the code is uploaded into the container and only gets replaced when the image is re-created. At which point there are issues with private git dependencies because it can't access the SSH_AUTH_SOCK.