4
votes

Sorry for the non-explicit title here's what I would like to achieve

  • get my web application running with docker (one container for the database, one for the cache, one for the php-fpm + the code)
  • in production as I don't have vagrant , I would like the standard ansible with the docker module to be able to provision the environment
  • as my developers have linux machines and vagrant support docker as a provider I would like to have these docker containers directly running in our dev machines without a VM (as we have a lot of project, keeping one VM by project soon exhausts the RAM , and we need to halt/up machines often, especially in maintenance phase)
  • we have some developers on Mac/Windows, so we still need vagrant to provide the abstraction layer "vagrant up" to have a brain-dead simple creation of dev environment.

I know how to use Vagrant+Ansible provisionning for one machine and I know how to use ansible with the docker module to create a full environment following the example in

http://docs.ansible.com/docker_module.html

Vagrant.configure(2) do |config|
  config.vm.box = "ubuntu/trusty64"
  config.vm.provision :ansible do |ansible|
      ansible.playbook = 'provisioning/site.yml'
      ansible.extra_vars = app_vars
      ansible.verbose = verbosity_arg
  end
end

but then it will run inside a virtual machine

I know how to use Vagrant to create several machines in one vagrant file

Vagrant.configure(2) do |config|
  config.vm.define :dbmachine do |dbmachine|
    dbmachine.vm.provider = "docker" do |d|
       ...
    end
  end
  config.vm.define :cachemachine do |cachemachine|
    cachemachine.vm.provider = "docker" do |d|
       ...
    end
  end
end

But then in production/staging, as I don't have vagrant, I don't have anymore the things describing the architecture

So is there a way to combine these things together to meet my needs ?

1

1 Answers

5
votes

Few notes:

  1. Not all components need to be dockerized. For example your database is not something that you will release new versions frequently. And its not something that you will add more instances or reduce on the fly. The other components cache/code etc are probably good candidates for dockerizing. Disclaimer: there are few reasons to dockerize db as well, but check if it makes sense for you
  2. Vagrant and docker are alternatives. You should use one or the other - not both. Vagrant builds a full VM (on VMWare/or virtualbox etc) while docker builds a light VM (called container), that is geared towards running ONE process with whole heart. I am going to assume you prefer to use docker over vagrant in the next few points.
  3. Mac/Windows devs are better off using Docker for Mac, and Docker for Windows to setup the apps on their dev machines. It can run the docker containers. I would suggest using a full linux VM in virtualbox that can run ansible and docker on it. (You could use vagrant here to auto install the linux VM with ansible and docker, but then it will be of use only to those mac and windows devs who are working on a VM.)
  4. Use Dockerfile rather than vagrantfile for building/describing your app's environment. Or even better you could use ansible to setup your docker container, if you prefer ansible playbooks as opposed to dockerfile which is basically shell commands. AFAIK they are 2 ways of doing the same thing - but ansible does have much better syntax, and features. Call your ansible playbook for "provisioning tasks" in the Dockerfile. You can also call another ansible playbook AFTER container is built for the "deploy tasks". Chef is also a good alternative to ansible.
  5. For using ansible you will need a control machine and a bunch of target machines in your non-dev (qa/prod) environments. Ansible will be able to SSH into the target machines, and start docker containers. If you write a playbook for stopping container, pulling latest images, and starting it - you have a nice automated deploy process. Locally on devboxes you can test your ansible scripts by start/stopping locally running docker containers.