We have a nice Docker dev + production automation system that we developed for early Airstack customers. It uses Vagrant to manage VMs for both local dev and remote dev|test|prod. Then Salt to install Docker and Fig on the VM and run Heroku-like commands through salt states.
The fig.yml is controlled by salt to allow jinja scripting of variables like RAILS_ENV, databases, etc.
It works well. Clean separation of concerns between Vagrant (VM mgmt), Salt (provisioning and controller), and Docker (code) goes a long way towards a creating a pleasant DevOps experience.
In dev mode, we share local folders (./app) into the VM (/srv/app) and bind mount the VM folder into containers. In prod, we rsync code to the VM and bind mount into the containers.
For gems and other dependencies, we bundle them in the VM and bind mount them into Docker containers (non-trivial due to path issues) for both dev and prod. This flow makes it a lot more intuitive for devs who are used to running everything on their laptops. Code is still edited locally, but to update gems, a dev just runs `make bundle` instead of `bundle install` to trigger bundling in the VM.
We're planning on open sourcing parts of the system when we have a chance to finish the documentation. In the meantime, feel free to reach out if you want early access. Email on github[1].
The fig.yml is controlled by salt to allow jinja scripting of variables like RAILS_ENV, databases, etc.
It works well. Clean separation of concerns between Vagrant (VM mgmt), Salt (provisioning and controller), and Docker (code) goes a long way towards a creating a pleasant DevOps experience.
In dev mode, we share local folders (./app) into the VM (/srv/app) and bind mount the VM folder into containers. In prod, we rsync code to the VM and bind mount into the containers.
For gems and other dependencies, we bundle them in the VM and bind mount them into Docker containers (non-trivial due to path issues) for both dev and prod. This flow makes it a lot more intuitive for devs who are used to running everything on their laptops. Code is still edited locally, but to update gems, a dev just runs `make bundle` instead of `bundle install` to trigger bundling in the VM.
We're planning on open sourcing parts of the system when we have a chance to finish the documentation. In the meantime, feel free to reach out if you want early access. Email on github[1].
[1] https://github.com/simple10