Transcript
  • Servers and Tools

Provisioning a Deployment Machine

From the class:  Git Deploy

Started. Let me give you a high level overview of what we're doing here and introduce some vocabulary as it relates to deployment. So when we talk about deployment, normally we talk about it as an environment. There's a deployment environment. That's a set of machines that are going to be up in the cloud, or we could be hosting them ourselves if you want to do that, and each one of those machines is going to play a role in our environment. A role could be something like an application server or a web server, or a database server, or it could just be dedicated to deployment. So it has some role in our overall application.

One machine could have multiple roles. We could just have one machine, for example, that is the app server, the web server, the database, and also the machine that we deploy to. In this case, we're just going to have one machine, so one virtual machine that's going to be our [INAUDIBLE] instance. And it's going to play two roles. The first role is going to be as an app server, so it's going to be our app. And it's also going to be a deployment server. This is what we're actually going to send up our code to, and it's going to trigger whatever it needs to do to make sure that the application is up to the latest version.

The first thing we need to do to set up a virtual-- or to set up a machine in our environment is to provision it. This means to install all the prerequisite software and make sure that the machine is set up and ready for whatever roles it's going to play. Now, there's a ton of tools out there to help you provision more quickly, or even automatically. And if you're using, of course, a platform as a service, all of this will be done for you. But we're going to do it all by hand, so you get an idea of exactly how to do it and how to troubleshoot when you run into something that doesn't work properly.

So to start off by provisioning our machine, we need to figure out what software needs to be installed on it. And since we're going to be deploying to it by Git, we're going to need Git installed on it. And we're also going to need Node.js, since we're running our application server using the node runtime. Let's SSH into the deploy server, and it'll start off by upgrading the package list that we have on local machine. So I'm going to say sudo apt-get update. And that will just retrieve all the latest package information from the servers.

Then we'll install any of the base packages that are required. For instance, sudo apt-get install build essential will give us compilation tools. Now, this machine already has those, but just in case. Oftentimes, you'll start off with build essential. We're also going to be deploying to Git, so I'll install the Git package here. And again, we already have Git on this machine. But these are two examples of where you might have to install a package to get up and running or to get this machine provisioned.

The next step we need, to get Node.js installed. And there's a couple of different ways we can do that. Probably the easiest is to say sudo apt-get install Node.js. And that's how you've seen me do it in a lot of the other classes. But I'm going to do it by hand this time. We're actually going to compile Node.js from source. And the reason for that is I want to get a specific version of Node.js that isn't available to me via the Package Manager here. And I also just want to show you how to compile something from source. It's a useful thing to know how to do. So let's head over to the Node.js website and grab the link to the latest set of source code.

From the Node.js homepage, if you look over on the lower right, you'll see this stable branch with the latest features. That's the one we're going to be using. And I'm going to click on other downloads and look at this page here. We've got a bunch of different types of systems that we can install Node.js on. They're listed over on the left. And these binary downloads, the binaries, that's where the source code has been compiled for us. And what we're going to get is the actual resulting executables. But in this case, I'm going to go down to the source code, and we're going to compile it from scratch. So we'll grab this link, just right click on that last link there, right click on it and say copy link address. Back in the virtual machine, change into the home directory and make a directory for source code that we can use to download this into. And I'll use the wget command and paste in that link that I cut earlier.

When that process completes, we'll gzipped tar file that we'll need to untar. So I can say tar, and then x for extract, z for zip, and the file path is going to be node- and I'll just press the Tab key to complete that. Now, we have the unzipped folder. And I can go ahead and just get rid of the tar file, because we don't need it anymore, and then change into the new Node directory.

When you're compiling a source project from scratch that's written in C or C++, if you look at the project folder, you're going to see something called a configure file most often. And you're also going to see this other file called a makefile. There's a program called make. It comes with build essential. It's a command that we can use to automatically compile and perform other tasks. You can think of its equivalent in JavaScript as being grunt or something like that, or in Ruby it would be rake, and make is one that was used all the time for C projects, and it's still used for other types of projects as well. But now you may not have heard of it, so I wanted to give you a sense of what it is.

And this makefile here tells make about the different commands that are available. And the configure command is going to be used to configure this for compilation on whatever machine we happen to be on. So it's going to perform some automated tasks for us. And all I need to do to execute that file is typed ./configure. And it'll just take a second to complete. And when it's finished, we can type make and this is actually going to do the compilation of the source code for us. Now, this could take quite a long time, because it's an awful lot to compile. That's why it's usually easier to grab the binaries or to install from one of the packages if you can, but I'm just going to-- let's see, go get some coffee. And when I come back, hopefully the compilation process will be done.

All right. Holy, moly. That took a pretty long time. For me, it was about 10 minutes. It might take a little bit longer or shorter, depending upon how quick your machine is. And once that has finished, we can now go ahead and install the software. And we'll say pseudo make install. And that will take the different executables, put them where they're supposed to go, and it will take the documentation and put that where it's supposed to go. And when it's all said and done, you should be able to type node and then the V option to see we've got node version 5.8.0. And of course, we should be able to just type node and that should drop this into the Node command line prompt.

So that should be everything we need to provision the server to get up and running. We have Git installed. We have Node installed, and systemd is already installed because that comes with Ubuntu by default.

Next up, let's create all the folders where we're going to put the deployment. I'm going to change into the root directory. And first off, let's add the Vagrant user to a group called ADM. ADM, it stands for admin. And that's because we're going to create these folders and the ADM group will be the group owner for the folders that we create. That way anyone in that group can write to these folders.

So use the sudo command and the usermod command, and we're going to add to the group ADM, the user Vagrant. And if I take ID, I use the ID command and past the Vagrant parameter, you should see that the Vagrant user is now part of the ADM group. To make that take effect you're going to have to exit out of the shell and SSH back in.

Now we'll change into the root folder and make the first directory, which is going to be called Apps. We're going to need to do that with sudo privileges. And now we've got a new folder called Apps where we can put all of our applications. And notice that it's owned by the user roots and the group root. I want to change this a bit. I would like the owner to stay as root but the group to change to the ADM group. So I can say sudo, and use the change ownership command, and make the user the root and the group ADM. And I'm going to change that for the application directory. OK. Now, if we look at the folder now, notice that the group is ADM and the user is main-- is still root.

Next thing I want to do is any time we create a folder in this directory, regardless of who I create the folder as, I want the group to be sticky so I want the group to remain as ADM. And so what we need to do is to set the write permission and the Sticky Bit permission on the group. So let's do that with the change mode command.

So again I'll say, sudo, change mode, and for the group we're going to add the write permission and then we're also going to add the Sticky Bit permission to the group. And that's going to be for the Apps folder. Now anybody in the admin group should be able to write to this folder. And also the S is set, which means that if we create a new folder underneath this one it will automatically get its group to be ADM. So this will make our lives easier.

Now, inside of the Apps folder let's create the one for the application we're going to be deploying. I'll make a directory inside of Apps called Boom. That's going to just be the name of our application. Let's change into the Apps directory and take a look. And notice that the user that created this folder is Vagrant because that's who we're logged in as but the group is sticky. It stays as ADM instead of being Vagrant. So that's exactly what we want.

Inside of the boom directory let's create a couple of other subdirectories. The first one will be called Current. That's going to be where we're going to put the latest source code that we want to deploy. Then I'll create a couple of other folders are going to be useful for configuration, and logging, and stuff like that. So the first will be Config. That's where we can put settings for the application or files they don't directly relate to the app but are related to configuring it. And then a log folder to put any kind of deployment logs. And a temporary folder where we can put any kind of garbage that we want to be able to delete easily. Just sort of a temporary area put stuff.

The folder we're going to be using most often for this class is just the current folder. So we're going to put our source code inside of this and this is where the application is going to run from. Now we can examine the Ubuntu instance and open up the project. I want to show you another file. It's in the config directory under systemd.

If you can remember back to the systemd class, these service files are going to be-- they're called unit configuration files. And they're what's required to tell systemd how to work with our service. And they start off with a unit description at the top end. This is indeed an amazing web application, if I say so myself. And we want to boot up after the network is available since it's a web app. And then in the service section we say that it's simple because it's not forking. And this is the script that we can use to start up the server.

So it's going to use the Server command that's located in the Apps folder that we just created, the boom folder, the current, which is we're going to put the source code, and then inside of the bin server. So that's going to be the same command that's inside of here in the server command. And that's what we'll start up. And then when we reboot the machine or when we install the service we're telling systemd that this boom application service is wanted by the multi-user target. So once multi-user services become available that's when this one should boot up.

So we somehow have to get this file up to our deployment server and put into the right place so systemd can find it. We can use Secure Copy to do that. And we'll Secure Copy the boom.service file up to the deploy machine. And I can't copy it to the systemd folder quite yet, I'm going to need system-- or sudo privileges to do that.

So I can put it in the temp folder to start. We'll put it in the apps/boom/tmp temp folder. And then I can SSH into that machine, change into the directory, make sure it's there. And then use the sudo command to copy that file into lib/systemd/system, just like any other systemd service.

Now system control should be aware of the new service but it should be inactive. So we haven't actually enabled it yet. And these are some logs I had from before so you can ignore those. But you can see that it knows about the service and you would just need to activate it. So go ahead and type sudo systemctl enable boom.

And we can't start it yet because we don't have our source code uploaded yet. So we can do that next.