 Good to go. Hi, and good evening, everyone. Hi, and good evening, everyone. So for most of you, the Lunonghi and Vanessa, I'm currently working at NUS as an IT analyst and doing software development and some network infrastructure. Previously, I'm also working with IBM doing the technology innovations team using the technology adoption program. So this is a technology adoption program for internal web research and development for IBM. OK, so all right, let's go for the topic for tonight. Taming your dev environment with Vega. Vega is actually one of the most favorite tool of mine. And I often ask my team to use this in their web development because, of course, when we do web development in our local machine and then moving to production, we mostly encounter several problems. So can anyone guess what are the problems that we mostly encounter when doing our local development to production? Yes, it's affecting the industry, because for the thing, it's not OK. Exactly. That's the most problem that we get. So it works on my machine. Sometimes it works on my machine, and then it doesn't work in production. Or also, it works on my machine, but it doesn't work on your teammate's computer because you have a different environment overall. Your teammate might be using Mac OS and you're using Windows. Some are using Linux. The second one is, it previously worked on my machine, but now suddenly it's not working. Because sometimes your system might do a system update, and then suddenly it messes up with your libraries and it doesn't work anymore. Or it's just too messy that all your test configuration are there, all your other configurations are there, and it's just too messy to deal with. Or for the polyglots out here who are working on multiple projects, you can be working on LAMP, LAMP stack with PHP 7, or mean stack, .NET, Java, or Rails. Does anyone work with Rails under Windows? Yeah, because I remember last time when I have my computer machine and I'm working on Windows, right? And I need to run a Rails project. Rails works, Ruby on Rails works, the setup works, but some gems just doesn't work on Ruby on Rails with Windows, and that's exactly how I came to know of Vagrant. So when I installed Vagrant and I installed Rails in my Vagrant machine, right? Everything just works. So I package all of my stack or project for one Vagrant for each project. But if you don't have Vagrant, right? It's really a mess and it's a nightmare to configure all of that in one whole machine. So how does Vagrant work? So usually you will have a virtual machine. I hope everyone knows what virtual machine is. If not, it's a, if you have a watch inception, it's like dream within a dream. Virtual machine is a machine within the machine. So it has its own OS, it has its own software installed and its own resources or hardware running within your machine. So for example, you have a Mac OS and then you can run a Red Hat virtual machine inside. And then you will use VirtualBox or VMware or other providers to create your virtual machine. And then there's Vagrant. Vagrant will then wrap both the creation of virtual machine and also configuration. So it uses VirtualBox as a provider. It can also use VMware or other providers. And you can combine it with provisioners, for example, Ansible or Chef or Buffet to automate installation of the software and configuration of your virtual machine. So sometimes people ask, why do we need Vagrant if I create a virtual machine using VirtualBox? I can already use that, right? But if some of your software needs to be updated, then you have to update it on VirtualBox. And, but for Vagrant, you just update the configuration file and run the configuration file again. And it will update your VM for you. And then you can give it to any other people on your team to do the same. So we're using Vagrant. We have three steps on doing it. You have to do setup configuration and start working on Vagrant. And in the setup, of course, since it's using VirtualBox, you have to install VirtualBox on your machine and also download, install Vagrant. It works on Windows, Linux, and Mac OS. And then you will need to take a Vagrant BaseBox. This Vagrant BaseBox is actually available on these two links. So most probably you will be using Linux with PHP, so LempStack, and it's all there. So this VagrantBox encapsulates all those OS and software LempStack inside. Then you just do VagrantInit, name of VagrantBox. Oh, sorry. So when you're doing VagrantInit, it doesn't create the VM for you. So it just creates the VagrantFile, which is the configuration file. You need to configure the VM first before it gets spin up for you. So on configuration, you will need to update the VagrantFile to describe what are the software you want, what are the OS you need, what are the hardware or the resource that you need, and you will also put there what are how you want to access your VagrantBounds. Like for example, you want to access it via this URL or you want it to be able to access your local folders and all. So you do it all in the VagrantFile. Once you have it, there's also optional tool to work with ChefPapet and Ansible to this. Once you have it, you just do VagrantUp. VagrantUp will, on the first run, it will spin up the VM for you and then it will configure everything, install everything that you put on your VagrantFile. So once that is up and running, then you can work on that VM. By the way, Vagrant is headless, so there's no GUI for your VM. So it will be quite light in a way that doesn't need the UI for your VM. So here are some Vagrant commands. Vagrant in it will initialize your current directory. Vagrant add and works hand in hand with Vagrant package. So Vagrant package will do a Vagrant Basebox program and then you will need to do Vagrant add to do, to import it. VagrantUp will just boot the Vagrant SSH. So once you have the VagrantUp and running right, you can SSH and do all the command line inside your VM. And then VagrantDestroy at halt to shut down the Vagrant. If you don't really using it in, for example, you're running on one project and you don't want to use it, you just do Vagrant halt so it doesn't eat up your resources. And then VagrantDestroy to delete your Vagrant. Sample use case. So in line with what Michael have introduced later that we're having a workshop with WordPress, right, we will create a Vagrant box that has this, all this requirement. So it needs to be in the Ubuntu lab set between my and in WordPress. Should run with hostname WordPress.local.com. And WordPress should be accessible with their favorite code, should be accessible with their favorite text editor IDE. So if you have your sublime or other IDE, you should be able to do coding on your favorite IDE. And then it should work with WordPress.local.com. So doing this, I'll just show you a quick run through on how you do Vagrant box. So first one, we have to do setup, right? So you do set a Vagrant init. This is available, lamp stack on the link I provided earlier. So as you see, I created WordPress Vagrant dir and then I do a Vagrant init. Then the Vagrant file will be created for you. Then you do configuration. So in this one, this is the Vagrant file itself. It's written in Ruby, but you don't need to know Ruby to configure this box. So the most important thing here is the config VM network and config VM sync folder. Config VM network just configures the network of your machine. So you do port forwarding or you apply fixed IP on this VM. So as you can see, forward port guest 80 host 80, which just means that your guest will run port 80. Guest or VM created from Vagrant will do port 80. Then on your host machine, you can access it via port 80 as well. Same as this, AutoCorrect will just, if the port is not accessible, it will use available port to do port forwarding. Then private network, I have here the IP, one, two, something, something. So this IP is just local to your machine and it's not accessible outside of course. It's just on your local machine. And we need this to map to the WordPress.local.com, which is the host name that we wanted to use. And the sync folder, WordPress then it maps to this. So if you have the WordPress folder inside with your Vagrant file, it will just do the mapping or mount this folder inside your VM with the inside bar of the .dev.html. So this way you can do the requirements for here, the last two requirements, wherein you can do development on your code base and then it will just, since you will be configuring the .dev.html as your document truth later, then it will get that. This is just the internal mapping configuration as well. Then you also configure your WordPress with your Vagrant file and you just do Vagrant up. So when you do Vagrant up, right, it creates the VM for you. As you can see it does the forward forwarding and it also mount your WordPress to your WordPress code to Vard.dev.html. All right, to verify that it is really installed there. You do Vagrant SSH and you just, so when you do Vagrant SSH, you will be on your Vagrant box and you do the just test if the software are installed. And then you do, you need to configure WordPress within your engine X size enabled. Yeah, so once all the configuration are done and you do the Vagrant up, you just can see that this WordPress local is running and WordPresslocal.com for 888, which is forwarded to VM is running with your PHP method. Okay, now all is set for your VM, you need to create the base box. So when creating a base box, you see here the Vagrant package, it will create the Vagrant box for you. So the set up is just this package base name of the VM which you can see here. Vagrant file is the absolute path of your Vagrant file and output will be the Vagrant box. So this is sample one. At the end, it created a Vagrant WordPress box for you. So this Vagrant WordPress box, you can just hand it out to your team and when they do Vagrant up, they should be able to see that WordPress.local.com is running. Yeah, these are the steps that your team needs to do to use this Vagrant box. Summary, so we've discussed what Vagrant is and what are the benefits that they can do. So it keeps a consistent dev environment for each project. Once you have the Vagrant box, your team can just work on it. It encapsulates project dependencies. So whenever you update your system or anything or do other configuration on your local machine, that Vagrant is not affected at all. And you can easily distribute project settings with senses portable that you can easily use. And here are all the references. You can also take. So I think that's all for me and I hope you find this useful and also try it out on your development.