Not related to Metamon, but in support of it. If you are looking for intros to Vagrant, or Ansible, I have a couple screencasts on them [1, 2]. Both are amazingly awesome tools that I just cannot promote enough. Looks like these Metamon files create a virtual environment using Vagrant, then stand up an application stack, from top to bottom, using Ansible.
> Metamon has hitherto been an internal tool that provides a reusable set of Ansible Playbooks that help us quickly start new projects by skipping environment configuration and automation.
Having built your tool for a specific purpose means it can avoid scope creep.
I built something somewhat similar [0], but use Puppet, added a GUI and keep adding more and more features. Right now you can set up a VM with PHP, HHVM, Ruby, Python, Node.js or a mix of all these. High on my to-do list is to allow setting up Python/Ruby/Node.js apps using Apache/Nginx.
Without a good counterindication, I'll probably end up forking this and adding VirtualEnvWrapper because I like the workflow better than plain VirtualEnv. Is there any particular reason you don't include it? Perhaps the deployment automation mostly moots the VirtualEnvWrapper wins, making it not worth the increased complexity?
P.S. This is a very timely release for me. I've done a few manual deploys of almost this exact stack, and have a major project for my company that I need to port to Django. However, I wanted to learn and use Ansible before attacking the job to lower maintenance costs. This looks like it will be a tremendous leg up on that task.
There isn't really a reason not to use Virtualenv wrapper, but there is also not really a reason to use it. Activating it is rather simple, so I just didn't really want to add something else to the installation (that would make it slightly more complex and slower). However, take a look at the development role[0], it actually activates the Virtualenv on login.
If you're going to be logging into the production machines (where the development role does not make (total) sense to have) you may want to install it, or turn off everything in the development role[1] except virtualenv activation and add it to those machines.
In short, I'm not against it, I just think it's not needed since the development role makes it redundant to have.
That's in the ballpark of the reasoning I expected. Thanks for the reply and the specific pointers. I tend to develop from the command line and have heretofore deployed manually, so I've found the subtle streamlining offered by VirtualEnvWrapper to be worthwhile. However, I think I'll try to go without it initially to reexamine its value under more automated deployment.
Also, this change would mostly serve as an incentive to ssh onto production servers, which is usually not going to be the optimal solution to issues that arise. I hadn't really thought about it this way until your comment.
Very cool, my org uses something similar internally as well. It's been adapted for our own specific purposes but was originally based on https://github.com/jcalazan/ansible-django-stack, a similar project to yours.
Question here.
Assuming I am developing something in pure Python, is there any advantage to using Vagrant if I already have a Virtualenv setup? They are the same principle of isolated environments, but implemented at different levels.
It really depends on what you're doing. If you're working on multiple projects that depend on other services to be running then it probably helps to use Vagrant. If you just need libs virtualenv is enough.
Very nice! I have been using something similar, but mine is only for setting up a dev environment in vagrant, not deployment. I will definitely use this as a reference for when I extend my provisioning to include deployment.
[1] https://sysadmincasts.com/episodes/42-crash-course-on-vagran...
[2] https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl...