Now that you know the basics of what makes a
Vagrantfile work, it's time to build ourselves a reusable Symfony 2 box.
After watching this video, you will have learned how to:
Let's break down each step.
We've covered the
Vagrantfile already, but in this video we are going to make some tweaks that you would likely need to make if you want to use this in a real project.
Firstly, we bump up the RAM from 1024 to 2048.
v.memory = 2048
Next, we cover how to change the box name. To do this, you will need to edit three files:
Make sure you change the machine name in any place where you find the word
lemp. Replace it with whatever you see fit.
Whatever you change this too will become the name of your webserver - so by default, you are going to end up with a Symfony 2 site running at
http://lemp, which you may not like.
Don't forget to update your local host file.
With the given
Vagrantfile you will get a machine running on
192.168.33.33, so be sure to edit your hosts file to add in e.g. :
# /etc/hosts 192.168.33.33 lemp
Be sure to update inline with your own settings / chosen name.
You likely need some persistence. MySQL is as good a choice as any (DB holy wars notwithstanding), so let's make use of Jeff Gerling's Ansible MySQL Role.
I'm making this as generic as possible so you can use it on any project, or customise it to make it more specific as you see fit.
provisioning/playbook.yml file we want to add in the following to our
vars: # * snip * mysql_databases: - name: devdb mysql_users: - name: dbuser password: dbpass host: "%" priv: "*.*:ALL"
Of course, feel free to change this as you see fit.
These settings will give you the ability to connect from your local / development machine to your Vagrant MySQL instance using the client you are used to - Sequelpro, SQLYog, or what have you.
I want to stress that this is a Development config.
root user is insecure by default. There is no password on the root account.
Also, this setup is wide open - allowing anyone to connect from anywhere. This isn't an issue for development as we are using a private network - your Vagrant box is only accessible by your local machine.
Use a proper set up in production please!!! If in doubt, ask your host.
Next, we want to configure our
Vagrantfile so that it synchronises the local development folder containing our Symfony folders and files, with the directory nginx is serving from on the server.
This is clever, but also a little confusing.
We are going to synchronise a folder, relative to the location of our
Vagrantfile, and this is going to replace the contents of the
/var/www/lemp directory which our Ansible provisioning script will have created for us already.
What happens to the existing contents of the
Well, they get hidden. Not removed. If you had data in there that you wanted, be sure to comment out the
synced_folder line we are about to configure, and then do a
vagrant reload to get access to that data.
The idea is, we have a directory structure like this:
# our-development-project . |-- our-symfony-folder |-- our-vagrant-folder |-- provisioning |-- Vagrantfile |-- README.md
We want to go one directory 'up' from
our-vagrant-folder and access / share / sync the
We could do this by specifying the absolute path to the folder on our system (e.g.
/home/codereview/development/our-development-project). However, this would severally hamper the ability to easily share the
Vagrantfile with colleagues / others.
Instead, we use a relative path:
config.vm.synced_folder "../our-symfony-folder", "/var/www/lemp", :nfs => true
Let's break this down further.
"../our-symfony-folder" - this is the relative path from our
Vagrantfile to the folder we want to share. Up one directory essentially.
"/var/www/lemp" - this is the folder we want our shared folder to be available from on the vagrant box itself. When the box is booted, we want
/var/www/lemp to contain everything / anything that lives inside our local
This is a two way read / write.
:nfs => true - more on this below in the Speeding Up Symfony and Vagrant section.
As we have changed our
Vagrantfile, be sure to run
vagrant reload to apply these changes. If you have mucked up your relative path, you may find a nasty red error telling you the folder you reference does not exist.
The inclusion of
:nfs => true is what makes this whole setup actually usable.
Without this setting you can expect response times somewhere in the 2 second+ range. This is fine, if you have the patience of a saint.
Personally, I like to smush the reload key in anger. Smush, smush, smush! We all know that reloading four or five times is an essential step in the debugging process ;) What did Einstein say about doing the same thing over and over and expecting a different outcome?
Anyway, by simply enabling NFS, you should be able to smash your response times down into the 300ms area.
Not bad for a one line change.
Now, you may need to install some additional requirements to get NFS to work.
The latest version of OSX seems to play nicely with no extras needed.
Ubuntu, I found, generally needs
sudo apt-get install nfs-kernel-server.
Windows... not entirely sure.
There is a really helpful post called Speedup Symfony2 on Vagrant boxes by Benjamin Eberlei with loads of great advice, and the comments as much as the post itself are gold on this subject.
If you have found this video helpful, please consider sharing. I really appreciate it.
|1||Beginners Guide to Vagrant||07:58|
|2||Vagrant Ansible Provisioning||14:35|
|4||Vagrant and Symfony2||13:50|