WEBVTT 00:06.350 --> 00:13.410 There could be some changes to your virtual machine and you can find out that it no longer works. 00:13.430 --> 00:21.560 Thankfully, since we have a base box configuration file and provisioning files which are all stored 00:21.560 --> 00:30.440 separately, we can instruct Vagrant to destroy our virtual machine and then create it again using the 00:30.440 --> 00:33.240 configurations to set it up. 00:33.260 --> 00:41.340 This is done via the destroy sub command and then the up sub command to start it again. 00:41.360 --> 00:48.610 So first let's destroy the environment we already have and then let's start it again. 00:48.620 --> 00:55.890 I'll type vagrant, destroy, wait some time, and now I'll type vagrant up. 00:55.910 --> 01:05.210 Of course, if we have data, our vagrant file provisioning manifests or application code that can also 01:05.210 --> 01:06.290 break things. 01:06.290 --> 01:16.100 So it's important to use a version control system to properly manage our project's code and configuration 01:16.100 --> 01:19.940 so we can undo our changes there too. 01:19.970 --> 01:29.240 Now, if you want to connect to the virtual machine over SSH, you can run the vagrant SSH command. 01:29.270 --> 01:34.040 Vagrant will then connect to the VM over ssh. 01:34.070 --> 01:41.630 Of course you can also connect to the VM directly if you are connecting from linux box. 01:41.630 --> 01:44.510 You have a built in ssh client there. 01:44.510 --> 01:51.530 And if you if you are connecting from windows machine, you won't have a built in a client. 01:51.530 --> 01:56.050 So you have to download the client such as party. 01:56.060 --> 02:06.410 You can download it from the official side party dot org or alternatively you can use sig client segment 02:06.410 --> 02:14.990 terminal also available for Windows Now without any form of integration between the host machine and 02:14.990 --> 02:22.340 the guest, we would have a virtual server running on top of our own operating system, which is not 02:22.340 --> 02:23.960 particularly useful. 02:23.960 --> 02:31.600 We need our own machine to be capable of integrating tightly with the guest as virtual machine. 02:31.610 --> 02:40.580 Although the VM is running on our own machine, it acts and behaves like a completely different machine. 02:40.580 --> 02:43.130 Sometimes this is what we want. 02:43.160 --> 02:45.120 Other times it isn't. 02:45.140 --> 02:49.070 We may want to integrate the two more tightly. 02:49.100 --> 02:57.590 One option is port forwarding, where we can tune a port from a virtual machine to a port on the host 02:57.590 --> 02:58.360 machine. 02:58.370 --> 03:05.660 If, for example, we have a web server running on our own machine, we obviously don't want to map 03:05.660 --> 03:10.590 the web server port from Vagrant onto the same port. 03:10.610 --> 03:13.520 Otherwise, there would be a conflict. 03:13.520 --> 03:16.340 Instead, we can map it to another port. 03:16.340 --> 03:27.050 If we map the web server port on the VM to port 88, for example on the host, then visiting http local 03:27.050 --> 03:34.760 host colon 880 on our own machine would show us the web service will run on the guest port. 03:34.760 --> 03:38.390 Forwarding is done while lines in the vagrant file. 03:38.390 --> 03:45.050 We simply provide the guest and host ports we wish to map by typing config. 03:45.050 --> 03:55.970 Dot vmm dot network colon forwarded underscore port comma guest 80 comma host 88. 03:56.000 --> 04:04.580 If we have other vagrant managed virtual machines on our computer which we wish to run simultaneously, 04:04.580 --> 04:09.290 we can enable autocorrect on specific ports. 04:09.290 --> 04:17.840 This way if a conflict is found, for example, two VMs trying to map the same port, one will try a 04:17.840 --> 04:20.150 different port instead. 04:20.150 --> 04:22.610 So we can do this with this option. 04:22.610 --> 04:32.480 Autocorrect through ports below a certain range need elevated or root privileges on the host machine. 04:32.480 --> 04:36.280 So you may be asked for your administrative password. 04:36.290 --> 04:43.280 Another very useful form of integration is synced folders or synchronized folders. 04:43.280 --> 04:49.040 Synced folders allow us to share a folder between the host and the guest. 04:49.040 --> 04:58.010 By default, Vagrant shares the folder containing the Vagrant project as slash vagrant on the VM. 04:58.010 --> 05:05.480 We can use the following in our vagrant file to sync more folders if we wish. 05:05.680 --> 05:13.570 We can do this with a command config dot VM select folder and we have to specify the folders the path 05:13.570 --> 05:14.740 to the folders. 05:14.740 --> 05:19.280 So the first parameter is the path to the folder on our machine. 05:19.300 --> 05:23.470 The second being the amount point on the beam. 05:23.470 --> 05:29.860 If we use a relative pass on our machine, it would be relative to the project folder. 05:29.890 --> 05:37.450 The network file system can give us better performance with synched folders than the default settings. 05:37.480 --> 05:41.590 This won't work on Windows hosts and on Linux. 05:41.590 --> 05:50.620 It will require root privileges, but we can enable the NFS on a percent folder basis by adding the 05:50.620 --> 05:53.110 following to the preceding line. 05:53.260 --> 05:55.960 We should add NFS True. 05:55.990 --> 05:58.210 Now some words about networking. 05:58.210 --> 06:04.600 By default, our vagrant virtual machines are only accessible from the machines we run. 06:04.600 --> 06:05.870 Vagrant on. 06:05.890 --> 06:13.900 If we map ports on our host, then we can share services running on the VM with our colleagues within 06:13.900 --> 06:15.080 our network. 06:15.100 --> 06:24.340 If we want to allow our colleagues to access our vagrant managed VMs directly, we can attach the VM 06:24.340 --> 06:33.790 to our internal network, and VirtualBox will breach the network between our machine and the VM and 06:33.790 --> 06:39.970 the internal network between our machine and the rest of machines in our home or office. 06:40.000 --> 06:48.340 We can perform this with the following command config, dot VM, dot network, and then we have to specify 06:48.340 --> 06:52.570 that it is private network and its IP should be. 06:52.570 --> 06:53.800 For example. 06:53.800 --> 06:57.910 1922.168. 06:57.910 --> 07:04.360 1.100 or any IP unit right now. 07:04.630 --> 07:09.640 And of course one of the key concepts within vagrant is provisioning. 07:09.670 --> 07:18.640 This involves tuning a basic virtual machine with a base operating system into a server that is ready 07:18.640 --> 07:20.980 to run for your project. 07:20.980 --> 07:23.340 Meeting your requirements. 07:23.350 --> 07:32.590 There are key provision and options with Vagrant, SSH, Ansible, puppet or chef, Ansible or chef 07:32.590 --> 07:41.320 or third party tools which vagrant supports out of the box and provide specific languages for configure 07:41.320 --> 07:46.810 and servers in an way that can be used for different operating systems. 07:46.890 --> 07:55.630 A stage provisioning involves running a series of commands on the virtual machine over SSH when the 07:55.630 --> 07:57.830 VM is first setup. 07:57.850 --> 08:01.750 There are two ways we can use such provisioning. 08:01.750 --> 08:09.880 We can either directly run a command from our vagrant file with the following line config, dot vm, 08:09.880 --> 08:16.870 dot provision, shell and inline command followed by the command itself. 08:16.900 --> 08:21.940 Alternatively, we can tell Vagrant to run a particular shell script. 08:21.940 --> 08:30.130 The location of the script specify it is relative to our project root that is slash vagrant. 08:30.130 --> 08:39.790 For example, we could type config dot vm provisioned shell followed by path parameter and the shell 08:39.910 --> 08:41.200 script itself. 08:41.200 --> 08:45.430 For example provisioned dot ssh in double quotes. 08:45.430 --> 08:53.860 This shell script could contain all the commands we need to convert a base box which contains very little 08:53.860 --> 09:02.140 to a box which supports our project and application, perhaps install web and database servers. 09:02.140 --> 09:04.210 So let's wrap up. 09:04.210 --> 09:12.850 We created projects with Vagrant pooled vagrant boxes to use and we also looked at the commands needed 09:12.850 --> 09:17.860 to manage these boxes and to manage the vagrant virtual machines. 09:17.860 --> 09:26.320 We looked at how we can configure our vagrant environment with networking synced folders and forwarded 09:26.320 --> 09:34.000 ports, and finally we looked at how to provision software on our VM with SSH commands.