Moderator: General Moderators
I have 55 local copies of live projects running in my XAMPP based localhost.
Each has thier own www.foobar.xamp local domain name in the hosts file. There are other projects I have not set up a local domain for.
Some of them are older, current, and in-progress versions of the same project and I need to be able to visit them simultaneously at their local domain instead of swapping them in and out of a single port number like http://localhost:8080
Over a dozen of them use the same core php files and when testing for bugs in one I need to be able to quickly open at least 6 other projects to test the same bug or bugfix in all of those as well.
My php version is 5.5.19 because it is the closest version I could find to the versions in use on the live servers where most of the projects live. Those live servers use: 5.3.15, 5.3.26, 5.4.44. It is very likely that those servers will never be upgraded.
Three projects are on a server using 5.6.31. It is possible that 3 more will be moved to that server next year. It is also possible that at least 1 project next year will be migrated to a php7 server and another one built from scratch on a php7 server. But at the moment 90% of my income is from maintaining old projects on these old servers.
I want to start using modern tools like composer and npm and homebrew cask. But the very old version of XAMPP I have installed at the moment has added something to my terminal environment named HEAD that is definitely not the HEAD script that many other terminal things like homebrew expect.
There are other problems I've encountered that are probably also the fault of XAMPP. For example: https://github.com/composer/composer/is ... t-69469119
And I couldn't tell you the last time I successfully updated or installed anything using Homebrew.
So to avoid these kinds of problem entirely I'd like to completely remove XAMPP from my OSX terminal environment, but I do not know the best way to replace it with something that would allow me to just as easily run all projects simultaneously with their own local domain name. I also think it would be best if I could somehow stick to an older version of php or preferably the exact same php version used by the live servers most of these projects live on.
I have not updated to the latest version of OSX yet because I heard there was a problem with it an Laravel Homestead and I was considering trying to move all of the projects into a Homestead VM.
The thing I don't like about my experience with Homestead so far is that I've accidentally destroyed the VM on multiple occassions without first remembering to export all of my databases. I think I would have to set up a 2nd VM that I never destroy in which to store all my databases and then modify the local env config of every project to connect to that VM's mysql service when running locally. The thought of doing that depresses me.
Can you give me any advice?
Laravel Homestead, to the best of my knowledge, uses Vagrant under the hood, and can be an option if you don't want to have to install and configure web servers, DB servers, and the like, but the reality is you'd likely need to do that in a production environment anyway and getting to choose your own base box and set of packages gives you better flexibility.
For the database conundrum, well, I'm not sure I have any concrete solutions. I am generally pretty slow to call vagrant destroy, so it isn't a problem I have really encountered. Unless you have removed the vagrant files, though, that should all be recoverable. Having a dedicated VM that holds all your databases makes it less likely that you will accidentally delete it, but it will make it more catastrophic if you do, in addition to just generally slowing down your sites (calling out to DB over HTTP vs. Unix socket)
I don't understand. It seemed to me that running vagrant destroy erased the VM disk file and all the mysql data contained within. How is that recoverable?Unless you have removed the vagrant files, though, that should all be recoverable.
How would that work if you need to run several projects at the same time (like thinsoldier needs), network setup wise? Would projectA.xamp and projectB.xamp point to different IPs, where different vagrant boxes would be running? Are vagrant box IPs persistent?This sounds like the perfect solution for something like Vagrant.
They could. Depends on the needs of the project. You can run multiple projects on the same box if they have the same requirements for PHP/Apache/etc versions, and you can run multiple boxes with multiple different configurations. Each box gets its IP configured in its Vagrantfile and then written to your /etc/hosts file.Weirdan wrote:Would projectA.xamp and projectB.xamp point to different IPs, where different vagrant boxes would be running?
Yes, you specify IP at the Vagrant level and in your hosts file.Weirdan wrote:Are vagrant box IPs persistent?
Not off hand, but it's pretty simple to set up and the documentation is quite good. Also, I have a multi-site Vagrant file lying around somewhere. I'll post it once I've located and redacted it.thinsoldier wrote:Do you know anyone I could hire to create the vagrant config files for me that would create the setup I need?
Code: Select all
# -*- mode: ruby -*- # vi: set ft=ruby : # All Vagrant configuration is done below. The "2" in Vagrant.configure # configures the configuration version (we support older styles for # backwards compatibility). Please don't change it unless you know what # you're doing. Vagrant.configure(2) do |config| # The most common configuration options are documented and commented below. # For a complete reference, please see the online documentation at # https://docs.vagrantup.com. config.vm.box = "Project Fruit" config.vm.box_url = "https://vagrant.company.com/boxes/fruit.box" config.vm.network "private_network", ip: "192.168.33.10" config.vm.provider "virtualbox" do |vb| vb.name = "Project Fruit" vb.memory = 2048 end # Configuration for both Project Apples and Project Pears below. Both code bases can # easily be run off the same virtual machine. Comment/uncomment sections as # required. Note that Vagrant will complain if you try to start the VM with a # synced folder specified but not present config.vm.synced_folder "./apples/", "/var/www/apples.com/" config.vm.synced_folder "./apples/uploads/", "/var/www/apples.com/uploads/", id: "apples-uploads", owner: "vagrant", group: "www-data", mount_options: ["dmode=775,fmode=664"] config.vm.synced_folder "./pears/", "/var/www/pears.com/" config.vm.synced_folder "./pears/uploads/", "/var/www/pears.com/uploads/", id: "pears-uploads", owner: "vagrant", group: "www-data", mount_options: ["dmode=775,fmode=664"] end
But they said something about needing to snapshot the box because someday I'll do `vagrant up` and vitrualbox or ubuntu may decide to update a bunch of stuff within the box and I'll be stuck with versions of php/mysql/apache that no longer match my desired versions.
Do you have any idea what they are talking about? Is there any way to prevent that from happening?