Docker at YunoJuno
How we (don't) use Docker in our daily workflow
Attribution unknown, source http://www.forwallpaper.com/
I recently saw an article on HN entitled "Docker at Lyst" which contained the following quote re. their use of Docker within the development team, as opposed to production:
It [Development] mostly works but we are considering moving to a Vagrant based host using a commercial VM for better performance.
So I thought I'd add my response on how we use Docker at YunoJuno:
We don't use Docker at YunoJuno, it's just too damn hard.
I've written about this before - here, here, and here, so won't go over old ground, but I can help the Lyst guys out with our approach for development. We have a base VirtualBox VM that runs Ubuntu 14.04 and contains Postgres (9.3), Redis, Memcache, Nginx and ElasticSearch, as well as all the normal Python tools - pip, virtualenv, virtualenvwrapper etc., and some Node.js goodies for the front-enders amongst you.
The Vagrantfile provisioning script automatically mounts a Django app directory into the VM, creates a new virtualenv, installs the app requirements (pip install, npm install, bower install) and sets up various configuration bits and bobs.
New developers can get themselves up and running with a complete replica of the production environment with a simple vagrant up.
It works.
Details available on request (this is the Vagrant repo README)
# Vagrant project and provisioning scripts for YunoJuno
This repo contains the Vagrant provisioning script and configuration
files for the YunoJuno web project.
The base box runs Ubuntu 14.04 (64-bit), and contains the following core
services (version, connection string):
* Nginx - 1.4.6
* Redis - 2.6.7 - redis://localhost:6379
* Memcached 1.4.14 - memcached://127.0.0.1:11211
* ElasticSearch 0.90.7 - http://127.0.0.1:9200
* Postgres - version 9.3 - postgres://127.0.0.1:5432
The `source` repo is shared in (as /app). NB In order for the Vagrantfile
to run, the website repo must be at the same level as the vagrant repo on the
host machine - i.e. it must be accessible as `../website` from the location
at which you run `vagrant up`.
The Vagrantfile has a single provisioning script which activates a python
virtualenv inside the VM, activates virtualenv, installs python dependencies
from `requirements.txt`, Node packages from `package.json` and Bower packages from `bower.json`.
At this point you have a full development environment, but neither data nor
configuration with which to run the application. The dev dataset must be downloaded from Heroku, to which you will need access; the local
configuration comes from a `.env` file at the project root. This is available on demand.
The VM is setup with Nginx serving HTTPS content over 443. It forwards all app
requests (i.e. not static content) to a local server that it expects to be running on port 5000. By default, therefore, if you go to the VM's IP address in your host browser you will get an Nginx error page - which will confirm that:
a.) Nginx **is** running, and
b.) the Django app is **not** yet. To spin it up you will need to run the Django devserver, on port 5000 - e.g. `./manage.py runserver 5000`.
The application runs inside the VM through Foreman, which can run the project
`Procfile` - more details on Foreman, the Procfile, and developing locally are
available on the [Heroku dev site](https://devcenter.heroku.com/articles/procfile#developing-locally-with-foreman).
Final details on configuration available in the output from the Vagrant provisioning process.
Making Freelance Work