Has anyone thought about using dotcloud and vagrant together? It would be super sweet to be able to type "vagrant up" into a dotcloud application and have vagrant read from the dotcloud.yml file and create an local environment that would mirror what it would look like if you did a "dotcloud push".
I have a semi-working version, but it isn't automatic. You just create both the dotcloud.yml and Vagrantfile in the same folder and have slightly different setup scripts.
I think the nearest thing you could use would be http://docker.io
Related
I asked for this question on the github repo but no one answered me :/ (see this topic)
Here is my original question :
I would like to customize the hiera.yaml, adding new conf files to the ":hierarchy:" section.
But it seems it doesn't work when I do a "vagrant up" :/
Do I have to destroy and re-up my vagrant box ?
The reason why I want to add custom files to hiera.yaml is that I have multiple boxes and I would like to define my vhosts, sql databases and users, etc... for all of them at once.
Anyone has a solution to my problem ?
Thanks !
If you already built the VM, provisioning is not run on following vagrant up (only the initial one will run the provisioning)
If you need to force a provisioning after you change the hiera.yaml file is to run
$ vagrant provision
or
$ vagrant up --provision
Current Steup
Using a Vagrant/Virtualbox image for development
Vagrant file and php code are both checked into a git repo
When a new user joins the project they pull down the git repo and type vagrant up
When we deploy to our "dev production" server we are on a CentOS 7 machine that has virtual box and vagrant and we just run the vagrant image
Future Setup
We are moving towards an OpenStack "cloud" and are wondering how to best integrate this current setup into the workflow
As I understand it OpenStack allows you to create individual VMs - which sounds cool because on one hand we could then launch our VM's, but the problem is we are taking advantage of Vagrant/Virtual Box's "mapping" functionality so that we are mounting /var/www/html to a /html directory in the folder we run vagrant out of. I assume this is not possible with OpenStack - and was wondering whether there is a specified best practice for how to handle this situation.
Approach
The only approach i can think of is to:
Install a VM on OpenStack that runs Centos7 and then inside that VM run Vagrant/VirtualBox (this seems bonkers)
But then we have VM inside a VM inside a VM and that just doesn't seem efficient.
Is there a tool - or guide - or guidance how to work with both a local vagrant image and the cloud? It seems like there may not be as easy a mapping as I initially though.
Thanks
It sounds like you want to keep using vagrant, presumably using https://github.com/ggiamarchi/vagrant-openstack-provider or similar? With that assumption, the way to do this which is probably the smallest iteration from your current setup is just to use an rsync synced folder - see https://www.vagrantup.com/docs/synced-folders/rsync.html. You should be able to something like this:
config.vm.synced_folder "html/", "/var/www/html", type: 'rsync'
Check the rest of that rsync page though -- depending on your ssh user, you might need to use the --rsync-path option.
NB - you don't mention whether you vagrant host is running windows or linux etc. If you're on windows then I tend to use cygwin, though I expect you can otherwise find some rsync.exe to use.
If you can free yourself from the vagrant pre-requisite then there are many solutions, but the above should be a quick win from where you are now.
If I understood correctly, the intention with using vagrant is to have a workflow in which the developer pulls the project sources along with the Vagrantfile, runs "vagrant up" and that's it right? The developer is not suppose to list and add boxes right, he shouldn't care about devops... that's the intention, to create as little friction as possible before a developer will be up and running, and let him/her focus on the app they're building... so? can I include in the Vagrant file adding boxes? only if they are not available? hey - what about vagrant plugins? can I add those to the Vagrantfile too? Is Vagrant smart enough not to run unnecessary provisioning twice? cheers, Ajar
You can instruct in your Vagrant file which base box should be used as the starting point. If this box is not found on the host, Vagrant will try to download it from Atlas (Vagrant's box repository) or from custom link if provided. Read about config.vm.box and config.vm.box_url config options.
No, Vagrant plugins need to be installed manually from command line. You can add check in Vagrantfile to see if plugin is installed or not. See this answer for more info.
Vagrant will run provision only once when VM is created. You can re-run provision if needed from command line, but Vagrant doesn't know anything about what your provision is doing. It's just executing it. If you use solutions such as Puppet/Chef/Ansible to run provision, they are "smart enough" not to repeat the same provision steps if the desired state was achieved.
I built my config with https://puphpet.com and have successfully deployed my virtual machine using vagrant up. Now I'm trying to customize it a little bit and see in the docs that there are two folders to run scripts in the VM: puphpet/files/exec-always and puphpet/files/exec-once.
I wrote a couple test BASH scripts and dropped them there but the only way I could "apply" these was if I destroy the VM completely and reprovision it from scratch. This takes an enormous amount of time.
What's the proper way to test and debug these scripts?
You should use $ vagrant provision!
I'm looking for some best practices on how to increase my productivity when writing new puppet modules. My workflow looks like this right now:
vagrant up
Make changes/fixes
vagrant provision
Find mistakes/errors, GOTO 2
After I get through all the mistakes/errors I do:
vagrant destroy
vagrant up
Make sure everything is working
commit my changes
This is too slow... how can i make this workflow faster?
I am in denial about writing tests for puppet. What are my other options?
cache your apt/yum repository on your host with the vagrant-cachier plugin
use profile –evaltrace to find where you loose time on full provisioning
use package base distribution :
eg: rvm install ruby-2.0.0 vs a pre-compiled ruby package created with fpm
avoid a "wget the internet and compile" approach
this will probably make your provisioning more reproducible and speedier.
don't code modules
try reusing some from the forge/github/...
note that it can be against my previous advice
if this is an option, upgrade your puppet/ruby version
iterate and prevent full provisioning
vagrant up
vagrant provision
modify manifest/modules
vagrant provision
modify manifest/modules
vagrant provision
vagrant destroy
vagrant up
launch server-spec
minimize typed command
launch command as you modify your files
you can perhaps setup guard to launch lint/test/spec/provision as you save
you can also send notifications from guest to host machine with vagrant-notify
test without actually provisioning in vagrant
rspec puppet (ideal when refactoring modules)
test your provisioning instead of manual checking
stop vagrant ssh-ing checking if service is running or a config has a given value
launch server-spec
take a look at Beaker
delegate running the test to your preferred ci server (jenkins, travis-ci,...)
if you are a bit fustrated by puppet... take a look at ansible
easy to setup (no ruby to install/compile)
you can select portion of stuff you want to run with tags
you can share the playbooks via synched folders and run ansible in the vagrant box locally (no librairian-puppet to launch)
update : after discussion with #garethr, take a look at his last presentation about guard.
I recommand using language-puppet. It comes with a command line tool (puppetresources) that can compute catalogs on your computer and let you examine them. It has a few useful features that can't be found in Puppet :
It is really fast (6 times faster on a single catalog, something like 50 times on many catalogs)
It tracks where each resource was defined, and what was the "class stack" at that point, which is really handy when you have duplicate resources
It automatically checks that the files you refer to exist
It is stricter than Puppet (breaks on undefined variables for example)
It let you print to standard output the content of any file, which is useful for developing complex templates
The only caveat is that it only works with "modern" Puppet practices. For example, require is not implemented. It also only works on Linux.