# Anyone know of a pre-built PHP7 vagrant box?

I don’t suppose anyone knows of a pre-built PHP7 vagrant box out there in the wilds yet? Preferably debian based and for virtualbox.

I was going to make my own but thought I’d check first to see if anyone knows of such a beast.

Actually, scratch that. Found one here

2 Likes

https://github.com/rlerdorf/php7dev

1 Like

Rasmus’ image is great, really works out of the box, tested it just yesterday. Also delightfully easy to just switch out PHP versions with the newphp command.

1 Like

Aye, I noticed. Nothing short of awesome. The ability to switch PHP versions so easily is just a miracle to behold. The collective number of hours that that alone is going to save… boggles

Maybe you should whip up an article on how to do vagrant+rasmus’ image+version switching.

Oh I think its docs are already excellently written. I do, however, have some articles about PHP7 planned and this will be a godsend to test on.

That would be great and if you can some how incorporate how to effectively include this vagrant box into a new project that’d really make me happy. That is probably the one thing I continuously struggle with as I don’t have the need to use vagrant very often so it is a major chore for me when I need it for a random project. I just can’t seem to find an effective way to manage it from a new project standpoint.

What kind of problems are you running into? It should be literally as simple as git clone ... and vagrant up, as described here. If I can improve that tip somehow, please let me know - I want to make it as approachable as possible to everyone.

It is more tying it with a new project. What is the best way to do that? As a git module? It may be more of a generic Vagrant question than about php 7 vagrant box but it is something I continue to struggle with when I need to start a new project

Ah, no. vagrant is all about creating an environment to work in.

Forget about writing any code for a new project for the moment. Lots of developers like to have a web server running on their local machines to make it easier to test whether something works or not.

Prior to vagrant, or rather prior to VirtualBox or VMWare, this would generally be achieved by installing WAMP, MAMP or XAMP (or similar), which would put things like apache, mysql and php directly onto your machine.

The key problem here is that you have only one web server environment to run all your projects in, so if you need to install a php extension, it’s installed for all projects.

Enter VirtualBox.

What this does is make it possible to run, say, a linux based web server (much like most hosting companies) as a virtual machine inside your OS. So, even if your desktop of choice is Windows 8, you can still run a linux web server and access it as “http://localhost” in your browser. You can stop and start the virtual machines at will, which means you could have different machines for different setups.

Enter Vagrant

At its core, vagrant makes managing virtual machines super easy. I mean, really super easy.

Start a web server?
cd C:\path\to\your\project
vagrant up

Stop the server?
vagrant halt

A typical (read ‘default’) vagrant setup also shares the folder that you’re in on your host machine with the guest’s operating system, so the web server running in the guest’s virtual machine can access the files in this folder.

This means that the webserver inside the virtual machine can read your php files as if they were local to it but you can still use your coding environment/preferred IDE on your host machine.

Result: You can begin to code up a new project inside the folder that the virtual machine can ‘see’ (because it’s mounted in the guest as a share) and check the results in your browser.

Hopefully that makes a bit of sense? The git clone…vagrant up process that @swader is referring to is merely (in essence) a mechanism for downloading and then launching the virtual machine part.

Check out that article - once you try it, you’ll never go back to ?AMP

Forgot one small but absolutely crucial point.

If you develop in one of the ?AMP variants (say XAMPP on windows) but your host is using Debian Wheezy, you can’t be 100% certain that the code that you develop locally is going to work fully when you deploy.

vagrant+virtualbox gives you the ability to develop inside a perfect copy of your live server environment, eliminating this concern.

(plus if you’re a linux guy like I am, you can also spark up a windows machine for whenever HR sends you one of their annoying Microsoft Word forms to fill in )

I didn’t explain myself well enough. I understand what vagrant is, I use it for Discourse development and for other established projects (but they already had a Vagrant file). What I’m trying to figure out is how best to include Vagrant in a new project or to take an existing vagrant project (such as php7dev) and incorporate it into a new project I’m ready to create (and it can be assumed I’m using GitHub – if that helps any).

I’ve just never had to do it from beginning to end and I find most of the articles I’ve read to not be very helpful.

And yes, I’m a 100% linux user who is desperately trying to not have to install PHP locally this time around. So I’m trying to figure out how to get Vagrant to be easy enough to be part of each project I spin up.

Ah, ok. Got it now then. In which case, it should just a matter of picking a directory on your local machine to start a project in and then following @swader 's article to spin up a virtual web server for that project.

The first time you do this, it will take a bit of time to download and install the vagrant box image but that’s a stage you only need do once.

Once you’ve got that VPS up and running, the only thing to add to your github repo will be the files that you can see in that project directory that you chose. That means both your own php code (which you would do normally) and the vagrant scripts such as Vagrantfile (and any other ancillary scripts you have in there - I don’t have the homestead_improved checked out on this machine atm).

This would then mean you can replicate that dev environment on any machine that can clone your own github repo.

I’ll have to try that later. But to make matters hopefully run smoother, I have an existing git repo (let’s call it sitepoint-demos)

Its directory structure:

./sitepoint-demos/

• demo1
• demo2

So when I pull down homestead, I’d pull it into the sitepoint-demos folder, alter the yaml and add it to my repo?
Maybe even move the demo1 and demo2 into another folder called sites or something so I can easily separate the vagrant/project level data from the sites?

Sounds logical enough.

You could do this to get the result that you’re after.

cd to an appropriate working directory of your choice

Then you would have two folders in your working directory

/
demo1/


Move all of the visible files (and none of the hidden git files) from the homestead directory into the demo1 project directory

cd to demo1

edit the Homestead.yml file as required (directory mappings if needed)

run vagrant up

(wait for vagrant to download and install the box image - again, you only need this to happen the one time. Once it’s in your vagrant install, it won’t need downloading again unless an update to the box image gets released)

Once complete, you’ll have the homestead improved virtual machine running and serving your app.

Once you’ve checked that it’s all working, you can then commit the vagrant files that came out of the homestead/ directory to your own demo1 repo. That way, you’ll have the config files that vagrant will need to duplicate that virtual machine set up any time you checkout your demo1 repo (i.e. work machine and home machine can have identical dev environments with only teeny tiny amounts of effort)

EDIT Just realised that demo1 and demo2 are probably just folders inside a repo called sitepoint_demos. No matter though, the principle is the same - checkout your repo, add the files from homestead/ folder into it. vagrant up and voila

1 Like

Ok, here’s an example:

Say you have a demo app on your drive somewhere in the /demo folder. You want to run this with vagrant so you no longer directly develop on your host machine.

You clone a vagrant setup like Homestead Improved:

git clone https://github.com/swader/homestead_improved hi_mydemo


Once this is cloned, you cd into the folder and configure Homestead.yaml's first line in the folders block (currently containing just .) to point to the absolute path to the root folder of your demo project. So instead of ., you would put /home/myusername/mydemos/demo.

You then execute vagrant up in the hi_mydemo folder (not your project’s folder!), and that’s literally it - vagrant will build an environment around your project - it will build a linux VM and convince it that its /home/vagrant/Code folder contains the contents of the host OS’s /home/myusername/mydemos/demo folder.

If you decide to power up another vagrant, like download Rasmus’ PHP7 box, and run the same project in it, you can do that. Clone his box setup into another folder, point its shared folder to the same folder, and vagrant up again. This will let you run the same code in different environments without ever touching the original folder - no need to move it around or anything.

The folder which contains your sources can be anywhere - all you need to do is point to it in the folder mapping and Vagrant takes over. I usually have my projects as subfolders in the vagrant setup I cloned (so I clone a separate Homestead Improved instance for every project) but that’s all entirely up to you.

Clearer?

Yes, that works, but I thought that one of the advantages to vagrant was you could include the VagrantFile (and any additional scripts necessary) in your repo with your project so as you take it from dev to dev or machine to machine, you always have an environment that is known to be good for testing.

So in that case, I’d want to clone the homestead_improved repo into an existing repo right? Or at least include it as a module with a custom yaml file? (does that make sense?)

No, that’s overcomplicating things, and that’s not really how it’s meant to be used. They should be separate, so that people can grab your project and run it on whatever (even on junk like MAMP if they want), but you should have your vagrant environment’s vagrantfile (and accompanying scripts) in a repo that’s unrelated to your project.

Combining the two is 30 seconds of work on any machine, dev to dev, like you say - just two clones instead of one.

1. Clone project source.
2. Clone vagrant environment setup.
3. Configure shared folders.
4. Vagrant up.

Then if people have several projects that need testing, they only repeat step 1. If they have several environments on which to test a single project, they only repeat step 2.

That keeps things nice and isolated, your project’s root folder is clear of any environmental shenanigans and your vagrant setup can run your project or any other (like HI can).

Ah okay, so where I’ve been struggling has been due to misinformation (phew, glad that is cleared up).

I guess my mindset was going that direction because the few projects I do use Vagrant for, have it in their repo. Granted these are very complex projects and have a lot of intricacies that must be setup properly for the project to run. So maybe it is a bit based on the complexity of the project on whether you include a VagrantFile in your repo? Granted, I can’t see why any of these projects couldn’t just make a second repo to host the Vagrant related data.

Yes, they absolutely should. The maximum a project should have in its project files in terms of environment setup is maybe an Ansible / Shell / Puppet / {insert your fave provisioner here} recipe which would allow a developer to simply run it on a new environment (as long as the related provisioner is installed) and have all the project dependencies installed (php extensions, other software, etc).

For example, including this as a file in your project’s sources would let anyone cloning the project immediately run Ansible with it, and have the environment auto-install PHP7. No need for Vagrant even or anything like it - run this on a dev, staging, production server - wherever! But, as I said, this is the absolute maximum a project should contain in terms of environment configuration - a way to install dependencies, sure. A way to set up a VM around it - unnecessary and cumbersome.

1 Like