I'm following these instructions for setting up a Django app on Vagrant.
I have successfully completed them and started Django, but: how can I now edit the Django files within my usual text editor, TextMate?
I guess I can ssh and use vi to edit them from the command line, but I thought the point of Vagrant was to be able to use my usual editing tools.
I'm just not sure where the Django files are physically located.
Apologies if this question is off-topic, I'll happily post it elsewhere, if editors can let me know where is best.
That web site is exactly the same place I started a few months ago.
Since I've learned more about Vagrant since then, I've created my own GitHub repo. You can download it here:
https://github.com/FlipperPA/djangovagrant
The way it is setup:
git clone the repo to a local directory on your machine
cd into that directory
run "vagrant up"
the directory you run "vagrant up" in is mapped to /vagrant on the guest virtual machine
Here is a working example of the way one might do it:
cd $home
git clone https://github.com/FlipperPA/djangovagrant.git
cd djangovagrant
vagrant up
vagrant ssh djangovm
cd /vagrant
django-admin.py startproject django_project
cd django_project
python manage.py runserver [::]:8000
You will then see the Django Project build on your local machine in the "djangovagrant" folder you created by the clone command above. You can you Textmate, Sublime, or any text editor you like to edit the files locally, and they'll be mapped to the guest VM.
I hope this helps - good luck.
Vagrant always synchronizes the files in the project you set up with your PC.
So whenever you ssh into the vagrant, (usually) in /vagrant directory you can see all the files you have in the root folder of your project (directory where Vagrantfile ruby script is)
Now you can use your text editor and save the file in a folder you want (for convenience, always save new files inside the project directory). now mirroring your directory structure around the /vagrant directory you can see the file being saved in the appropriate folder in your guest machine.
For e.g if you created and saved a file in your project root folder then you can see it appear in /vagrant directory.
Related
I'm running Laravel on Vagrant Box (homestead)
When I'm doing vagrant up, I'm getting a message:
: A newer version of the box 'laravel/homestead' is available and already
: installed, but your Vagrant machine is running against
: version '6.3.0'. To update to version '7.1.0',
: destroy and recreate your machine.
What commands should I run and what are potential problems I should be prepared for?
You can create a second installation for Homestead before you destroy the working one.
1) follow official documentation on installing Installing The Homestead Vagrant Box, then, when Installing Homestead instead of this command
git clone https://github.com/laravel/homestead.git ~/Homestead
run this one
git clone https://github.com/laravel/homestead.git ~/MyHomestead
then you'll need to cd ~/MyHomestead and git checkout v8.4.0
now you need to go to ~\MyHomestead\scripts\homestead.rb file and replace homestead-7 to homestead-7-my it will give you a different name for virtual machine in your virtualbox.
Now you can follow the official documentation
1.1) and you can always destroy your old vagrant box from your vagrant folder usually ~/homestead by running
vagrant destroy
2) create a new vagrant box by running
vagrant up --provision
3) get in to vagrant
vagrant ssh
4) go to your project (I assume you have a set of database migrations and seeders )
cd ~/code/myproject
4.1) you'll find redis and mysql is working there already.
5) create database
php artisan migrate
6) make SUPERVISOR works if you need it
7) make cron work if you need it
Done
As ceejayoz mentioned, you do not have to do this, you can just continue running the same version. Homestead is meant to be able to be torn down / built back up quickly, with all configuration living within the Homestead.yaml and Vagrantfile files. It's supposed to be able to do the heavy lifting for you with those config files.
As you mentioned, you have your database in Homestead. If you have some data there that is not local test data, ensure you get that exported before destroying. Some people manually modify their Homestead VM via SSH which is not recommended (as you should be using the Homestead.yaml file for changes), but if you have, keep a list of the changes you made and where you made them.
Here is a rundown of things you may want to keep before destroying:
Your Homestead.yaml file, just in case
Your Vagrantfile file(s) (if you've made custom changes)
Database data
Files used / generated by your application (logs, for instance.)
aliases file, if you've made custom changes to it
Elasticsearch data (if you use it)
Neo4j data (if you use it)
As for commands to run, the documentation says it better than I ever could: https://laravel.com/docs/5.7/homestead#updating-homestead
This is JetBrain Documentation
states that Vagrant installation will create these shell files ( vagrant.bat / vagrant.sh ), which will be linked to by PHPStorm. However these files do not exist in my system.
Should I reinstall Vagrant or link PHPStorm to a different file?
use terminal $ which vagrant
to find the programs root. Use this file directory to direct PHPStorm to Vagrant's executable.
I have just set up a new Linux box and trying to install vagrant on it. The issue is that when I am running vagrant up command, I am getting the following error:
Vagrant failed to initialize at a very early stage:
The directory Vagrant will use to store local environment-specific
state is not accessible. The directory specified as the local data
directory must be both readable and writable for the user that is
running Vagrant.
Any idea how to fix this?
I think a better way is to provide your user the required permission to the directory by making the user the owner - where you want the vagrant to be booted:
$ sudo chown -R <user> <directory>
and then you will be easily able to do:
$ vagrant up
Using sudo for vagrant up is unusual as why do you want to run your virtual machine as a root user.
I met the same problem and I solved it by run the terminal with"run as administrator". It's quite easy.
Hope this can help you.
I encountered the same issue four years later and could not fix it using chmod or even #Ziya's comment under the initial question (which brought me closer to the resolution though).
In my case, I use Vagrant 2.2.6 on Windows 10, and use Cygwin as a command line interface.
For the error to disappear, I had to :
open Windows Explorer
right-click .vagrant folder in the location where I typed vagrant up
access the "Properties" menu
then, in the "Security" tab, update the authorizations for my user, granting total control
Properties window screenshot
Hope this can help someone else.
Please follow these steps:
1) install vagrant 1.7.1
2) install virtual box 4.1, 4.2, or 4.3
3) use the administrator name in the custom directory (e.g., for windows users c:\users\AdminName\myvagrant or for Mac/Linux users /home/Admin/myvagrant)
For instance: c:\users\safwan\myvagrant where safwan is the user with administrator rights/privileges.
Copy the file name Vagrantfile in the myvagrant forlder.
4) Now open DOS window as shown in the picture and follow the steps in the DOS window changing the admin name
Please note: although I mention Gradle/Groovy in this question, this is strictly about Vagrant usage, and could just as easily apply to any other language/build system.
I am new to Vagrant and am trying to figure out how Vagrantfiles, when pushed to source control, interact with that repo's build.
Say I have the following repo, built by Gradle:
src/
main/
groovy/
<lots of groovy source>
test/
groovy/
<lots of groovy test source>
build.gradle
settings.gradle
Now let's say that, without Vagrant, I would normally clone this repo and run gradle clean build to run unit tests on the code, and ultimately, package it into a running program (executable JAR). Then a gradle run starts the app.
Well, in a lot of GitHub repos I see Vagrantfiles committed. So obviously this is to make it easy to spin up a VM and run the respective app inside of. I'm trying to figure out the typical "flow" of incorporating a Vagrantfile into my repo above such that developers can:
Clone the repo
Build with Gradle
Somehow, deploy to the Vagrant box
Test the running app instance (running inside the box)
Tweak the code } #4, #5 and #6 quick/rapid dev-test-tweak cycles utilizing hot re-deploys
Re-test
Take a look at this Vagrantfile for a CAS server (chosen at random). I think this is where the magic happens, in terms of deploying and restarting the server on the box, but I checked the Vagrant docs for shell.inline and nothing concrete came up.
So I ask: How do I "integrate" my Vagrantfile with my build, such that the build produces a deployed, running app? Further, what do my run/deploy-test-code-redeploy cycles look like with Vagrant boxes (what I call "hot deploying")?
I'm going to explain how I would achieve what you are looking to do, this might not be the official way to do it, so anyone with more Vagrant experience should please provide pointers on where it can be improved. I've been working with Vagrant for about 6 months now. You say you are new to Vagrant, so I'll be as complete as I can, even though some parts you have probably already mastered, but might be useful to other users.
tl;dr; Skip to Creating the Vagrantfile section if you are already familiar with how the Vagrantfile works
Let's start with what the example Vagrantfile is doing.
config.vm.box = "puppetlabs/centos-6.5-64-puppet"
This is telling Vagrant to pull the box on which everything else is built. You can find a lot of official and community contributed boxes on the Vagrant Cloud. This one being from puppetlabs, based on CentOS 6.5 64-bit with Puppet already installed.
config.vm.network "forwarded_port", guest: 8080, host: 8088
This is telling Vagrant to forward port 8088 on your host to 8080 on the Vagrant box. So accessing http://127.0.0.1:8088 on your host will access port 8080 on the guest.
config.vm.provision :shell do |shell|
Provisioning is the process of setting up the Vagrant box when it is ran for the first time. Provisioning will only run once for a new VM, unless forced. See the provisioning section of the Basic Usage Vagrant Docs. This one specifically is executing a bunch of shell commands when it is being provisioned.
shell.inline = "command;
command;"
Shell inline is sending these commands, seperated by the semicolon, to the box. This is to automate the commands as if you were typing them in an SSH session yourself. The Vagrant Docs on Shell Provisioning has some more advanced uses where you can define an actual file to be executed.
Note: Your shell script should not try to execute tools that have not yet been installed. (ex. Running a Python script where Python is not available yet).
config.vm.provision "puppet" do |puppet|
I can't comment much on the Puppet section since I'm not a Puppet user (yet, probably). This is setting some Puppet values.
shell.inline = "cd /vagrant && mvn clean package;
sudo cp target/cas.war /srv/tomcat/cas/webapps/;
sudo /sbin/service tomcat-cas restart"
This is also executing shell commands. Basically changing directory, cleaning, copying cas.war to the webapps directory and then restarting the service. More on the /vagrant shared folder later. Now we have enough to start building our own Vagrant file on. I'm going to keep the sample simple to make it generic.
Creating the Vagrantfile
You will most likely want to build on a Vagrant box that already matches your requirements, but for now, let's not do that. You can however find a lot of already created boxes on the Vagrant Cloud. I'm going to show you how to get a (very) simple Python app running using Flask.
Pick your favourite distribution from the available Vagrant boxes. I'm going to use ubuntu/trusty64 since I use it on a daily basis. All command should be easily translated to other distributions.
Create a new directory for your project and open a shell / console window in it.
Using the console, initialize your Vagrant box vagrant init ubuntu/trusty64. This will create a base Vagrantfile for you to work from.
Open your Vagrantfile and uncomment config.vm.network "forwarded_port", guest: 5000, host: 8080. We want port 8080 to take us to port 5000 on the guest machine. Tip: For your project, it will be wise to choose a port that is most likely not already in use to avoid clashing with other apps. 8080 might be bad choice, 8089 will be better.
Let's add some scripts to execute on provisioning. Since Python is shipped with Ubuntu (and most other I know) we don't need to install Python, but we do need pip (a Python Package manager) and Flask.
config.vm.provision :shell do |shell|
shell.inline = "cd /vagrant;
sudo apt-get -y install python-pip;
sudo pip install Flask;"
end
This will change the directory to the Vagrant share. Install pip using Ubuntu's package manager, then install Flask using pip. The -y flag is to automatically have apt-get install without prompting for a yes/no question. You might need to run Vagrant up --provision a couple of times to get all your commands 100% correct.
Note on the Vagrant share: The Vagrant share is a directory that is synced between the host and guest machine and will be available under /vagrant. It includes all the files and directories in your project directory (where your Vagrantfile resides).
We now have all the tools we need to run our app. I've created an incredibly simple Flask app as a sample. Download it to your project directory from this Gist and name it app.py
Now we'll be able to run the Python app located in your project directory. I like to keep the install sections and running sections seperate. So add another section that starts the app.
Note: The & makes the app fork to the background so the vagrant up can complete. You'll probably want to do something more fancy than this with your app.
config.vm.provision :shell do |shell|
shell.inline = "/vagrant/app.py &"
end
Finally we can start everything and have Vagrant do its magic. In your console, in your project directory (where your Vagrant file is located). Run vagrant up.
Moment of truth. Open your browser (on the host) and browse to http://127.0.0.1:8080/. You should see Hello Vagrant Provisioned World!.
That takes care of the provisioning of your app. Automatically, from a Vagrantfile, that you can commit with your project code.
Now to get to your initial steps, and how this fits in.
Integrating into your development workflow
I'm listing your steps, integrated with Vagrant.
Clone the repo
This step stays the same, with the exception of a Vagrantfile included in your repo with provisioning for any required libraries and tools required for your project.
Run vagrant up in the project directory. This will automatically create and provision the box and share your project with the box.
You can build the project in the Vagrant provisioning steps, but if you are actively developing the application, you might not want to do that.
Test the running app instance (running inside the box) - Simply SSH into the box, enter the `/vagrant' directory and run your app.
Tweak the code } #4, #5 and #6 quick/rapid dev-test-tweak cycles utilizing hot re-deploys
Since your project is shared live between the host and the guest. you can simply stop the app (if running) and run the app again on the guest. No copying needed.
Re-test
This will give you quick developent cycles while keeping the environment the same. A new developer can simply clone and vagrant up to get going on the project without worrying about the environment and whatnot.
Continuous Integration is a vast topic. You can still apply the practises to your repo, etc. But I'd skip the CI deployment process while developing. I make use of Jenkins and Capistrano for my CI deployments, but it is too heavy weight for development. In production I won't use Vagrant since it will double-virtualize your VM already (unless you run bare metal). For production I'll make use of Docker and Fig.
I hope this explains how to integrate Vagrant into your flow for your project, please do comment if anything needs clarification. I believe the sample should word perfectly, since that is the goal of using Vagrant.
There has been a recent change lately when attempting to clone the laravel/homestead package from GitHub. I haven't had trouble in the past trying to add additional virtual machines to my system but now I'm running into a problem.
If you go into GitHub to look at the latest repository for Laravel Homestead you will see that the 'homestead.yaml' file is not in the root directory any longer and has now been replaced by the file 'homestead'.
In the past, I have used the steps below for creating additional virtual machines in my command prompt:
1) Create a new directory (Code2) from within the root directory where VirtualBox and VagrantBox are installed
2) Go into 'cmd' and change to 'Code2' directory
3) Type in 'vagrant box add laravel/homestead --force'
4) Type in 'git clone https://github.com/laravel/homestead.git Homestead_temp'
5) Go into the newly created 'Homestead_temp' directory, copy and paste the files from inside that directory into your 'Code2' root directory.
6) Edit 'src/stubs/homestead.yaml' so that it contains the correct paths for your 'Code2' directory.
7) Go back into 'cmd' and type in 'vagrant up'. When I try to do this, I keep getting a 'read: No such file or directory C:/Users/Jeff/.homestead/Homestead.yaml'
I haven't had trouble in the past adding additional virtual machines but now I am prevented from doing so. Any help is greatly appreciated.
I'm not really sure if this answers my question or not, I'll have to do some research on it but for anybody that is curious about the recent Laravel Homestead changes, check out this article for Laravel 2.0
Hope this information helps!