Deploy GitLab on Self-Hosted Infrastructure

0:00[AUDIO LOGO] Hi, guys. My name is Trevor Sullivan, and welcome back to another CBT Nugget skill. In this skill, we are going to be exploring how you can set up a GitLab instance on your own self-hosted infrastructure. Now, before we actually talk about how to deploy GitLab onto a Linux virtual machine, let's talk about why exactly you might want to consider hosting your own GitLab instance, rather than simply using the SaaS, or software as a service, version of GitLab.

0:43Well, first of all, there is the concept of security that we need to be thinking about any time that we're hosting source code or infrastructure code that may be we're deploying using infrastructure as code tools or proprietary applications that we're building internally at our organization. So security is a really important concept that we need to apply to any application that's hosting our application source code. And if we're choosing to use GitLab in order to store our source code but we don't want the risks of possibly leaking source code or leaking our infrastructure configurations that we're developing with infrastructure as code techniques out to other users, out on the internet, or malicious attackers, then we can actually configure our own self-hosted GitLab instance on our own private infrastructure so that we can apply our own security rules, things like firewall rules, to deploy onto a secured instance rather than hosting it on the GitLab SaaS instance.

1:44Now another reason that you might want to use GitLab as a SaaS instance is for resiliency. So if you want to ensure that you are applying your own backup processes for disaster recovery, then that gives you the direct control over the GitLab instance so that you can determine exactly what those disaster backup and recovery procedures are going to look like. This is great for business continuity as well, so resiliency of the infrastructure itself but also business continuity so that you can rapidly redeploy a new GitLab instance in the case of some kind of outage of your primary infrastructure.

2:23Now another reason that you might want to control GitLab as well is for performance reasons. So when you're using the SaaS version of GitLab, you are going to be hosting that environment-- or that environment is going to be hosted with a bunch of shared users, also known sometimes as tenants. So the other tenants that are using a GitLab infrastructure could potentially overload a GitLab infrastructure depending on how they've architected it, and that means that you might end up competing for cloud resources in order to run things like your CI/CD pipelines or any other automation processes inside of your GitLab repositories.

3:01So by hosting GitLab yourself on your own infrastructure, you can ensure that you have the predictability of the performance of your GitLab instance because you can control exactly how many system resources like virtual CPUs, memory, and disk configurations are going to be applied to your GitLab instance. So now that we understand why we might want to deploy GitLab ourselves, let's discuss what the deployment of GitLab itself actually looks like on your own infrastructure.

3:32I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hi, guys, and welcome back. So in the last video, we introduced the concept of self-hosting a GitLab instance. And now I wanted to dive into the architecture of what self-hosting GitLab is going to look like. Now, GitLab itself is kind of the central point of our architectural discussion here because GitLab is ultimately the application that us and any development teams within our organization are going to be accessing, typically using a web browser and Git client tools like the Git CLI, for example.

0:42But GitLab itself actually plugs into other services as well because GitLab itself can't provide things like TLS certificates, and also things like SMTP for email access for sending transactional emails. Those are not things that GitLab typically does on its own. So you'll need to rely on some external services for those purposes. So let's start out with you as a developer or DevOps engineer right over here. And we're going to talk about the process of deploying and configuring a GitLab instance.

1:14Now, the first thing that you'll want to do is to select a cloud provider that allows you to deploy virtual infrastructure. So basically, you've got different cloud providers out there like Amazon Web Services, or Microsoft Azure, or Google Cloud, or Digital Ocean, or Linode. And there's a whole plethora of cloud providers out there that allow you to simply deploy Linux virtual machines very easily. Now, some of the common ones that I use are things like Amazon Web Services or Microsoft Azure or DigitalOcean. But there's many other providers out there.

1:44There's literally too many to list here. So I've just picked out some icons or logos from some of the most common ones that I personally use, and listed them here. But I think we're probably going to end up using DigitalOcean or Linode just for simplicity as well as cost efficiency, since they're very inexpensive providers to use. Now, once you've set up your instance for GitLab, something that you're going to need to do is to set up a DNS endpoint for your users to access the GitLab instance. So you'll need to set up a DNS provider.

2:14And so typically, what you'll do is you'll register a domain name-- for example, cbttrevor.com or awstrevor.com or cbtnuggets.com. Those are what we consider domain names. And then you can create a child domain name, like gitlab.cbttrevor.com. Or you can pretty much choose whatever kind of naming convention you want to. You could call it cbtnuggets.cbttrevor.com, whatever you want to. But basically, you'll create your own domain name that actually points to the virtual machine that's going to run your GitLab instance here.

2:47Now, you can also go ahead and install GitLab itself onto your virtual machine once you've set up your DNS. You don't necessarily have to do it in that order. You can install GitLab and then set up DNS later on. So there's not a strict requirement to do it one way or the other. But it's kind of up to you which direction you want to go. Now, as far as email goes, typically GitLab is going to need an email provider configured so that it can send what are known as transactional emails. An example of a transactional email would be somebody going to your GitLab instance and signing up for an account on your GitLab instance.

3:23When you sign up for a GitLab instance, you'll need to verify your email address. And so GitLab itself will need to send an email to the user that registered with that GitLab instance so that they can confirm their account. Another example of a transactional email is resetting a password. If you ever clicked on the Forgot Password link on any kind of SaaS service out there, you'll probably be familiar with the process of the service sending you an email. You click on a link in that email which has some kind of unique identifier to uniquely identify your password reset request.

3:58And then it takes you to a web page on that SaaS service. And it will allow you to then reset your password. So GitLab needs an SMTP provider configured so that it can send those transactional emails for things like sign-ups and password resets and I'm sure a bunch of other types of emails as well. Now, one other service that we're going to need to plug into is Let's Encrypt here. So GitLab, by default when you install it, is going to attempt to request a Let's Encrypt certificate. Now, Let's Encrypt is a managed service that allows web applications to dynamically request Transport Layer Security, or TLS, certificates so that you can secure data in transit across the network.

4:40As your users are accessing the GitLab instance that's running on a cloud virtual machine-- maybe you've got some different development users down here. Or maybe it's just yourself that's accessing the GitLab instance running on your virtual infrastructure here. You're going to want to make sure that network traffic to and from the GitLab instance is encrypted at the network layer so that no attackers or malicious users on the internet are able to intercept that network traffic and compromise the security credentials that you're using to log into that GitLab instance and then basically impersonate your different users and gain access to unauthorized data on that GitLab instance.

5:20So the nice thing about GitLab is that it natively integrates with Let's Encrypt. And if for some reason you don't have your DNS validated just yet, when you install GitLab, it will actually generate its own internal certificate as well. So even though it's not a trusted certificate by most client web browsers, at least it will have a certificate in place that is not necessarily trusted by default. But there is still a certificate that can be used to encrypt those network communications. Now, once you've got GitLab installed, you've got your DNS provider configured here, and you've got your SMTP configured here, there's other configuration that you can do as well.

6:00In fact, in order to configure SMTP itself, you actually have to go into this GitLab configuration file. So there is a GitLab configuration file that exists on the Linux file system that you can edit with any kind of text editor, like Vim, for example, or Nano. There's a ton of different text editors that you could potentially use out there. But that configuration file is going to allow you to tweak a lot of different settings on your GitLab instance, including the SMTP configuration, including the Let's Encrypt TLS configuration as well. So you'll want to be familiar with that.

6:31And then also, you'll have what's called a root user, by default, that gets created when you set up your GitLab instance. And that root user is what you're going to use to log into the GitLab instance and then approve any user sign-ups if you have disabled user sign-ups by defaults. So by default, when you set up GitLab, any users that attempt to sign up on your instance are going to have to be authorized explicitly by the super user or root account in that GitLab instance.

7:01Otherwise, they will not be able to confirm their account and then gain access to the GitLab instance. So anyways, now that we kind of understand at a high level some of the different services that GitLab will integrate with in order to provide a self-hosted instance of GitLab, let's go ahead and start by setting up the virtual infrastructure for our GitLab instance. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hi, guys. And welcome back. Now that we've talked about the high-level setup process for a self-hosted GitLab instance in the previous video, let's go ahead and actually start out by setting up the virtual infrastructure. Now one of the choices that you're going to need to make is which cloud provider you want to use for each of these components.

0:30In my particular case, I'm going to be setting up a virtual machine on the DigitalOcean cloud platform. They make it just really easy to spin up virtual infrastructure. And they provide a very competitive pricing as well. They also provide a REST API that you can plug into to manage your virtual infrastructure, plus they also have a CLI tool called DOCTL that you can use to manage those virtual machines. But you're more than welcome to use Amazon EC2 instances or Microsoft Azure virtual machines or any other virtual private server provider that allows you to spin up a simple Linux virtual machine and have a publicly routable IP address on the internet.

1:08You're also going to need to choose a DNS provider. And so you'll need to find a DNS provider that allows you to register a domain name. And you also need to be able to create a DNS-hosted zone so that you can actually host the DNS records to set up your GitLab instance. There's also some DNS configuration that goes into the SMTP config here. So in order to authorize your domain for sending emails from the SMTP protocol, you'll need to make sure that domain is authorized as well. And typically that is done using some DNS records.

1:41So I'm going to be using Amazon Route 53 as my DNS registrar. So I've already registered a DNS domain called cbttrevor.com So If I head over to my account and go to Route 53 and come down to registered domains here, you should see that I've got cbttrevor.com registered. However, I'm not going to be using Route 53 to host my DNS zones. I do have the ability to use it as my hosted zone if I want to. However, I actually have my domain set up right now.

2:13If I go to cbttrevor.com under my registrar config here, you can actually see that my name servers here for this domain are set up to forward it to Google's DNS servers. And that's because I over here in the Google Cloud platform have chosen to use Google Cloud DNS as my DNS hosting for my DNS zone for my domain cbttrevor.com. So basically what we're going to do is be using CBTTrevor.com here. We're going to create a new child zone for GitLab specifically.

2:45I already have one set up here, but we're going to create a new one. And we'll take a look at how to set up that zone as the authoritative zone right here in my route zone for cbttrevor.com so that we can use that for our GitLab instance. But the first thing that I'm going to do is to go ahead and set up a GitLab server. So let's head over to the DigitalOcean cloud platform here. And of course, your steps are going to be different depending on what cloud provider you're using. But I'm just going to click on Create what's known as a droplet.

3:17So a droplet is just the kind of marketing term in the DigitalOcean platform for a virtual machine. And then I typically use Ubuntu Linux. But you could also use Debian Linux or CentOS or Fedora if you wanted to. And I typically use the LTS version of Ubuntu Linux because that is good for up to five years of updates. And it's typically just a reliable base operating system for any Linux services that you want to run. Now, as far as the system resources, regardless of what cloud platform you're using, we're going to need to make sure that GitLab has access to appropriate system resources because it is kind of a heavy application.

3:53It does a lot of activity in the background. And according to the documentation here for installing GitLab, if we go out to docs.gitlab.com and drill into Installing GitLab Requirements here, they do tell you that four cores or four virtual CPU cores is the recommended minimum number of cores. And that'll support approximately 500 users. And as far as memory or RAM goes, we need to have at least 4 gigabytes of memory. But it suggests maybe having 8 gigabytes of memory if you want to go up to 1,000 users.

4:27So I'm going to make sure that I choose a virtual machine type here that supports four CPUs and 8 gigabytes of memory. And that's were built by the hour. So it's only 7.1 cents per hour. So as you can see, that is pretty inexpensive, especially if I am only spinning this up for several hours. So I'm going to go ahead and just choose a region here. Let's choose maybe the New York 3 region here. And I'm going to go ahead and add my SSH key so I can authenticate to that virtual machine. I'm also going to enable an IPv6 address here. And we'll go ahead and give it a name.

4:59So for the host name here, I'll just call it GitLab. And we'll click on Create droplet. Now that virtual machine will take a couple of minutes to spin up. So why don't we go ahead and start by setting up our DNS configuration while this droplet is deploying here? In just a moment here, we're going to get an IPv4 address as well as an IPv6 address associated with this droplet. And those are the addresses that we're going to set up DNS A records for in just a moment here. So in our next video, we'll go ahead and jump into our DNS config and go from there.

5:32I hope this has been informative for you. And I'd like to thank you for viewing.

0:01[AUDIO LOGO] Hey, guys, and welcome back. So in the last video, we set up our DigitalOcean droplet running Ubuntu Linux, and now we need to go through our DNS configuration to ensure that we have some domain names set up to forward network traffic to this IPv4 or IPv6 address for our GitLab instance. Now, we haven't installed GitLab on this instance yet. We'll do that in a little bit here. But we need to go ahead and do our DNS zone configuration.

0:32Now, I'm going to be using Google Cloud DNS here for my DNS zone hosting. So the first thing that I need to do is to go into my root zone here and I need to create what's known as a name server record here so that I can specify what DNS servers are going to be hosting the child zone that I create. Now, I also need to create the child zone itself, so I'm just going to click on it Create Zone, and then we'll choose a public zone because this needs to be publicly accessible across the internet, and then I need to give it a zone name and a DNS name.

1:03So you'll want to pick a DNS name. I'll just call this cbtgitlab.cbttrevor.com, and so we're going to use cbtgitlab.cbttrevor.com in order to access our GitLab instance. And then in Google Cloud DNS we just need to give it a name. So typically what I do is I just use the same name, but I use dashes to separate the name, rather than periods because you can't use a period in the actual resource name itself. So we'll just specify that this is for GitLab hosting and we'll go ahead and click on Create.

1:35Now, once I create the child zone, you're going to see that we have this NS record in the child zone, and this tells us which Google DNS servers we need to set our name server record for. So basically it's just going to be NS cloud of B1 through B4 on googledomains.com. So I'll just copy one of these and then come back to our parent zone here, And I'm going to add in a new record set, and we need to make sure that it is set to an NS record. And we'll give it a name, which is going to be our cbtgitlab.cbttrevor.com, and then we need to plug in all of those name servers down here under the name server list.

2:13So we'll just go ahead and add four items here, and we're going to make sure that we paste in each value and then we're just going to overwrite it with 1, 2, 3, and 4. All right, so once we've got that set up, we'll just click on Create here, and so that will basically set up the domain delegation so that any DNS lookups going across the internet to Google's DNS servers that are destined for cbtgitlab.cbttrevor.com are going to be forwarded to this DNS zone that we have created right here.

2:43So now what we need to do is to go ahead and set up an A record. So we'll click on Add Record Set. And I'm just going to leave this empty for the DNS name because we want cbtgitlab.cbttrevor.com to forward network traffic using an A record to the IP address of our virtual machine. So I'm just going to copy the IPv6 address here from our virtual machine and we'll paste that in for the IP address here and click on Create, and then I'm also going to add another record set here for a quad A record, and we are going to leave this empty again because we want cbtgitlab.cbttrevor.com to forward to the IPv6 address that we have right here.

3:22So we'll copy the IPv6 address from our console and then go back and paste that in as the IPv6 address. All right, so now we've got the A record and the quad a records set up, and we also need to set up DNS for our email as well. Now, you can use a bunch of different email services out there. I've just chosen to use the Amazon Simple Email service because that's a pretty simple service to set up. So I'm going to come back to the AWS console here and we're just going to set up a new domain verification so that we can authorize our domain to send emails through SES.

3:56So we're going to come down to Verified Identities here and then we're going to click on Create Identity, and then we're going to choose a domain identity here because we want to authorize our domain, and we're going to specify cbtgitlab.cbttrevor.com as the authorized domain, and then we'll just click on it Create Identity. Now, this is going to generate a series of CNAME records in DNS that we need to use to authorize SES to send emails using our domain. So as you can see, our status is currently set to Verification Pending.

4:26So what we need to do is create these CNAME records down here with these values on the right hand side, and that is what's going to tell SES to authorize our domain. So we'll copy the first value here, or I should say the first name, and bring it back into Google Cloud DNS right here. So we'll say Add Record Set, we'll paste in that name, and I'm going to cut off the domain name here because we already have that in the Google console here. So it should just be this random value, .domainkey, and then cbtgitlab.cbttrevor.com, and that's going to be a CNAME record, not an A record, and then we'll come back to SES here.

5:07We'll copy the value for that record and paste that in as the canonical name. Now, in Google Cloud DNS, you get this little error saying the record data must be in this format, and it's a little bit subtle, but you'll see that there's actually a period at the end. So make sure you plug in a period there and click on Create. And then we'll just do that two more times. So let's go back to our zone here, and then we'll say Add Record Set. We'll do that two more times for the other CNAME records here. We'll copy this first value here, plug it in, remove our domain name from that, change it to a CNAME record, and then we'll copy the value and then bring that back in, put a period at the end, and just one more time here.

5:47So we'll say Add Record Set, copy the CNAME here, bring it back in, and eliminate the domain name, change it to a CNAME record, and then once more we'll copy the value for that CNAME record, paste it in, put in a period at the end, and click on Create. All right, so that is setting up the authorization for SES, and in just a few moments here. We should see the DKIM configuration change from Pending to Verified to indicate that SES is authorized.

6:18So if I just hit Edit here and Save Changes, that should kind of force it. And as you can see, it's pretty fast. So DKIM configuration is now successful and our identity status is now set to verified. So now the SES service is authorized to send emails for this domain. So now that we've got this set up, let's go ahead and navigate to our GitLab instance and actually get GitLab installed onto that instance. I hope this has been informative for you and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, guys, and welcome back. So in the last video, we set up the DNS service to point to our GitLab instance, and we also authorized our SMTP provider, which, in this case, is the Amazon Simple Email Service, to allow our domain to send emails. Now we need to go ahead and get GitLab itself installed onto our virtual machine.

0:33And once we do that, it should automatically request a Let's Encrypt certificate. But if it doesn't, we'll just kick it in the rear and make sure that it does actually request a Let's Encrypt certificate. Regardless, we are going to have encryption to that endpoint, so don't worry about it from a security perspective as far as setting it up goes. Now, the nice thing about GitLab is that you have lots of different choices as far as how you can install GitLab into your virtual machine. First of all, you can use what's known as the Omnibus package for Linux, which is basically an all-encompassing package that contains all of the different components of GitLab.

1:11If you were to do a completely from-scratch installation of GitLab, it would be an incredibly complex setup process. So the GitLab development team has provided this Omnibus package to dramatically simplify the setup process for GitLab itself. Now, if you'd like to install GitLab without directly installing it onto Linux, if you want to containerize it, you do actually have the ability to run GitLab as a Docker container as well so that everything is kind of self-contained inside of that Docker container.

1:44And you can set up a file system as a Docker volume to persist any data that the GitLab instance needs to persist. So that's a really nice, simple way to install it as well. You also have the ability to install GitLab as a Helm chart onto a Kubernetes cluster. So Helm is basically a command-line interface tool that you can use to manage software packages that are deployed to a Kubernetes cluster. So that's a really nice way to install GitLab along with many other applications on Kubernetes clusters. And then you also have the ability to set it up on Kubernetes as an operator as well.

2:17So they provide that as a choice as well. And of course, if you want to do the painful method where you deploy it from scratch, then you certainly have the ability to deploy it from the source code as well. But we are going to go with a simpler option, which is to deploy it using the Omnibus package for Linux. And one other deployment mechanism that I wanted to mention as well is that on the major cloud providers that have marketplaces, like, Amazon Web Services has a marketplace where you can obtain vendor applications from. Same thing with Google Cloud Platform and Microsoft Azure.

2:50They actually have prebuilt the images for Linux operating systems that allow you to deploy GitLab as what's known as a virtual appliance, where everything is basically preinstalled, but you just deploy the entire operating system along with GitLab itself as a single image. So that's a really nice way to deploy it if you don't want to worry about having to log in to the virtual machine and configure things and just get into the nitty-gritty stuff. But typically, the Linux package is going to give you a lot of flexibility.

3:21But it's also going to balance things with ease of use as well. So we're going to be deploying the Omnibus package right here. And installation, it can be done using an RPM package or certain Linux distributions that use RPM packages. And you can also deploy with Debian packages or any Debian-based operating systems that use the D package command-line tool to install Debian packages. Now, installing it is going to be pretty easy. So basically, what we're going to do is install it from this package repository. And we're going to have the ability to deploy either the Enterprise Edition that has certain Enterprise exclusive features.

3:58Or we can simply deploy the GitLab Community Edition, which is the open source version that's, I believe, under the MIT License if I recall correctly. So we're going to go ahead and just install this Community Edition here. And so you'll see that when we go to the Community Edition package here, we have the ability to use a Debian or RPM package. And actually, I think we're going to do the Enterprise Edition here just so we have access to the full feature set. So let's choose the Debian package for Enterprise here. And then we'll copy this cURL command here into our terminal once we log in to our virtual machine, and that should get GitLab installed onto our system.

4:33So let's come over to DigitalOcean here. And we'll grab our IP address for our system. And I'm going to fire up a new terminal. And we'll just get SSH into that Linux virtual machine here. I'll say, ssh and then root at IP address. And there's also an option that I like to enable for SSH called ServerAliveInterval. And then I'll just set that to 60 seconds so that we get a periodic ping to our server, maybe even 30 seconds. And that helps to keep our SSH connection alive in the event that we have any kind of internet connection instability.

5:06All right, so now we are logged in to our Linux virtual machine on DigitalOcean, and so now what we're going to do is just paste in the cURL command. Let's do a Windows-V here, and then we'll paste this in and run that command. Now, this will take a little while to get all of the GitLab packages installed. But this is going to install the Omnibus package for GitLab. So let's just give this a couple of minutes to complete, and then we'll come right back. All right, so this command was pretty fast because it basically set up the package repository.

5:37But we have not yet actually installed the GitLab itself. And so, to do that, we'll need to run a couple of other commands here. We're going to use the APT package manager. So we'll do an APT update, and that will get the package repository metadata available on our local system. And then, in order to install GitLab Enterprise Edition, we're just going to do an apt install gitlab-ee. So we'll copy that command. And we don't need sudo because we're actually logged in to our virtual machine as the root user here already.

6:08And typically, I like to actually do the --yes parameter here because that will just prevent you from being asked any questions interactively in the terminal when you run that APT-install command. And it just automatically installs everything that you've requested. So as you can see we're going to install the gitlab-ee package here. It is pretty large. It's over a gigabyte in size here. So the first thing that APT needs to do is to download the package, and then it'll run the package installation on our virtual machine here. So we'll come right back in just a moment here once this has completed.

6:40All right, so our GitLab instance has finished installing here, but if you look through the output here, it says, thanks for installing GitLab! However, GitLab was unable to detect a valid DNS hostname for your GitLab instance. So we actually need to go into this configuration file right here called /etc/gitlab/gitlab.rb. That's basically a Ruby configuration file, as many of the components for GitLab are written in the Ruby language. And so what we need to do is change the setting inside of that file called the external_url.

7:12And we need to set that to our DNS domain, which is CBTGitLab.CBTTrevor.com, and then we need to run this command right down here. GitLab has a kind of control tool that allows you to manipulate the GitLab service running on this Linux virtual machine, and that is called gitlab-ctl. And it has a reconfigure command that basically tells it to reread the configuration file once we've made those edits, and then it will apply those changes to our GitLab instance. So we need to run that reconfigure command after we update this config file here.

7:45So we'll go ahead and do that DNS verification in our next video. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, guys. And welcome back. So in our last video, we got the GitLab Enterprise Edition package installed onto our Linux instance. And now what we need to do is to actually access that GitLab instance using our web browser. But at the moment, we are probably not going to be able to access that instance. So if we head over to our browser here and try to go to cbtgitlab.cbttrevor.com, technically, we set up this DNS record to forward to our service.

0:39However, GitLab itself does not know about this hostname, and so we're probably going to get an error message here indicating that GitLab was either not started up or it's not going to be able to process that request correctly. But we can validate DNS using a command line utility called dig on Linux. So over here on our Linux instance, you should be able to run the dig command or if you don't have it installed, you can install the dig package on your Linux instance here. But what we want to do is specify dig-t, and then we want to specify that we're searching for an A record, which is going to forward a DNS name to our IP address, our IPv4 address, specifically.

1:16And then we'll plug-in our host name, which is cbtgitlab.cbttrevor.com, and that should return the IP address of your Linux instance. You can also specify a quad A record, which is an IPv6 forward lookup record. And you should see in the answer section right down here that the IPv6 address for your DigitalOcean virtual machine matches up with what's in the console here. So we know that the A record and the quad A records are set up correctly but unfortunately, GitLab is not running because of that external URL setting that we saw was incorrectly configured right up here when we installed GitLab.

1:58So something else you can do to verify the GitLab status is run the systemctl command here. And this is basically allowing you to manipulate and inspect systemd services that are running and registered on your Linux instance here. So if we do systemctl status for GitLab here, let's do GitLab. So it looks like it actually has an installed it yet here because I can't tab complete that. But what we need to do now is run that GitLab CTL command to reconfigure it. But first, let's go ahead and run vim/etc/gitlab/gitlab.rb.

2:32And this is a massive configuration file that is going to allow us to manipulate the running configuration of our GitLab instance. All of our SMTP settings are in here as well. But I'm just going to do a forward slash in Vim to search for the text external. And as you can see, external URL is currently set to gitlab.example.com. Of course, we don't own example.com, somebody out there I'm sure owns it. But we don't. So what we need to do is change this external URL setting. So I'll do a dollar sign to delete to end of line, and then I'll hit a to go into append or insert mode here.

3:05And then I'll plug in cbtgitlab.cbttrevor.com. And I'm also going to set that to an HTTPS URL so that we're basically telling GitLab that we want to be accessing it over HTTPS. So we'll go ahead and do a WQ, colon WQ to save and quit to Vim. And then it will do a GitLab CTL reconfigure command. And hopefully, that will get our GitLab instance up and running. So we'll give that a second to run. It does take a little time to get everything reconfigured and we'll come right back.

3:39So after a minute or two, the GitLab CTL reconfigure command should complete. And as you can see, it looks like everything looks good here. As you can see, we've got a default admin account with the username, root. And then the password for root is actually stored in a file on the Linux file system under the /etc/github directory. So in order to access our GitLab instance, we're going to need that root password. Let's try and run our systemctl status command again. And we're going to look for a service, you can tab complete it, called gitlab-runsvdir.service.

4:15That's the unit file name for systemd. And as you can see, that service is up and running. Now, one utility that I like to use to monitor my Linux systems is called btop. And you can see I don't have btop installed by default, but I can just run a snap install btop here and get that installed on my Ubuntu system here. It should install pretty quickly, it's not a very large package. But once I run btop here, you should see a bunch of information about my virtual machine. So I can see things like my CPU utilization.

4:47It's refreshing currently at 2 seconds or 2000 milliseconds here, but I can use the plus and minus keys to reduce that to down to, let's say, maybe 500 milliseconds here. So I'm getting much more granular system information. So I can see that my CPU is working a little bit here. And I can also see some of the processes that are running on my system here. So I can see a bunch of GitLab processes down in the process list here, I can see a whole bunch of Ruby processes as well. And so it looks like everything is up and running.

5:17I can also see how much memory my system is currently using. As you can see, out of that 8 gigabytes that I have provisioned on my virtual machine here, I'm using about 50% of it, around 4 gigabytes of that. I can also see things like disk activity here as well. So as you're monitoring your production GitLab instances, the btop CLI is a great utility to get some real time information. So let's go ahead and quit that with hitting the Q command here. And now, what we're going to do is to attempt to access our GitLab instance.

5:50So we'll come back to our browser here, and we'll try to navigate to cbtgitlab.cbttrevor.com, and hopefully, we will be able to access our instance now. As you can see, we are now able to access our GitLab instance here. And so I'm being prompted to log in with a username and password. And so this is where we're going to use our root credentials by default in order to access this GitLab instance. Something else I can do is to check out the certificate in my browser here.

6:21You can see that I am connected securely to my custom instance here on cbtgitlab.cbttrevor.com, and it's a verified by Let's Encrypt. And if I click on More Information here, I can actually view the certificate details here, and I can see that the organization that provisioned this certificate is actually Let's Encrypt. And the little lock icon in my browser here on my self-hosted instance just indicates to me that I am connected using a trusted certificate. So now, we're going to log in with our username of root, and let's grab our password from our terminal right over here.

6:58So we'll go to our terminal, and we'll just say cat/etc/gitlab. And then we're going to find the initial root password file. And as you can see, our password is printed out right here. So we'll just go ahead and select that password and bring that back into our GitLab instance and click on Sign In. And now we are logged in to our GitLab instance using our root user account. As you can see, we have a little warning here that tells us that anybody that has access to this website here, which is basically at this point anybody on the internet, can theoretically register for an account.

7:33So it's recommending that we make it a private instance so that not just anybody is able to sign up for a GitLab account on our private instance. Now, there is an admin section that you can go to over here, and there are tons and tons of different settings here for administering your GitLab instance. But what we're going to do now that we've got our GitLab instance set up is to actually sign up as a new user on this service. But in order to do that, we need to actually set up SMTP first. So we'll go ahead and set up SMTP in the next video.

8:04I hope this has been informative for you, and I'd like to thank you for viewing.

0:01[AUDIO LOGO] Hi, guys, and welcome back. So in the last video, we finished the setup process for our GitLab instance, and we made sure that we had a Let's Encrypt TLS certificate associated with that GitLab instance for security purposes for data in transit across the wire, across the internet, and we also made sure that our DNS was set up properly so that we can access the website using our publicly accessible DNS name, which is cbtgitlab.cbttrevor.com.

0:39So at this point, we have a fully functioning GitLab instance, except that our new users will not be able to sign up because they won't get any sign up confirmation emails. So one of the things that we need to do is to configure the GitLab instance so that it knows how to use our SMTP or Simple Mail Transfer Protocol provider so that it can send out those transactional emails for things like signups and password resets and all that stuff, and then we'll go ahead and test out connectivity to that service and make sure that GitLab is actually able to send out emails through that SMTP service.

1:13So what we want to do is head over to the documentation for GitLab here, and we'll just go up here to the search and look for the SMTP documentation. And keep in mind that SMTP providers are one in a million. So, basically, you've just got a list of massive amounts of different email providers over here on the right hand side, or I should say a dime a dozen not one in a million, because there's just tons of different options here and pretty much any of them are going to work just fine. But what we're going to do is use the Amazon Simple Email Service here.

1:47And as you can see in the documentation, they provide a sample configuration that shows us how to configure Amazon SES or Simple Email Service in our GitLab configuration file. So once again, we're going to be modifying our gitlab.rb configuration file using Vim in our Linux system, and we're going to set some of these values for the Amazon SES Service. Now, keep in mind that you're welcome to use any of these. You could use Mail Gun if you want to. You could use Microsoft Office 365, you could use SendGrid, you could use Rackspace if you want to.

2:23There's a whole ton of options here. One other one that I've come across in the past is Mail Jet as well. They kind of specialize in sending transactional emails and marketing emails and that kind of thing, so feel free to check them out as well. I've had a good experience with Mail Jet in the past. But there are just tons of different options that you have here, and they provide sample configurations for each of those. So what we're going to do is make sure we have an AWS account here. We're going to navigate back over to the SES console here and go to our account dashboard.

2:53And one of the things that we'll need to do is in our SES service is to set up our credentials in our account. So we'll come down to SMTP settings here, and then we'll click on Create SMTP Credentials, and this is actually going to take us over to a separate service in AWS called the Identity and Access Management Service, and it will automatically create for us and SMTP IAM user account. So we'll click on Create and then it will give us some IAM credentials here that we can use inside of the configuration block for Amazon SES here.

3:28So we've got a couple of settings here. The SMTP username and the SMTP password, and those are going to be set to the IAM access key and the secret key that were generated over here in the IAM console. So we'll click on the username here and copy that, and let's go ahead and copy this. Actually, we're going to just modify the existing config rather than copying this. So we'll just come back to our terminal here, and then we'll say vim /etc/gitlab/gitlab.rb and hit Enter, and then we need to find inside of this huge configuration file-- as you can see, this is a really long kubeconfig file that's hundreds of lines long.

4:08What we want to do is just go up to the top and do a forward slash search for the lowercase SMTP. And as you can see, this entire section right here-- let me try that once more here. This entire section right here is going to be lines 85 through about line 94 here, and all of these different settings here allow us to configure SMTP. So we're just going to remove the comments. So this little hash character here is a comment, which basically means that this setting is not going to be interpreted.

4:40So we want to remove those comments from each of these settings so that we can enable SMTP, and we're actually going to comment out SMTP TLS there. And so these are the settings from lines 85 through line 92 that we want to enable here, and so we're going to make sure that SMTP Enable is set to True. We're going to set the SMTP address to the DNS name for SES. So we'll head back to the SES console here and copy this SMTP endpoint value here.

5:11We'll copy that and bring that in. And for the SMTP port here, you'll notice that there's a couple of different ports specified in the SES console here. So we've got the Start TLS port and then we've got the TLS Wrapper port here, and so I'm going to be using port 2587 because during my testing I'm pretty sure that's the one that worked. So I'll set SMTP port 2587, and then for the SMTP user we'll paste in our IAM access key. And then for the SMTP password here, let me just delete the text there.

5:43And then we'll say the secret key, so the SMTP password. We'll copy this value. Make sure you don't include that space at the end. And then we'll paste that in. Now, the SMTP domain down here, we'll check out the docs here. We're going to set that to whatever our domain is. So remember that we previously authorized the SES service to use our verified identity, which is cbtgitlab.cbttrevor.com. So we'll just copy that domain name and plug it in here.

6:15So let's delete what's in there and then just paste that in. And everything else we should just leave to the default values and just verify that it matches in the documentation here. So once we've made those modifications, we'll just hit Escape and then colon wq on our keyboard to save that file. And then once again, after we've made any changes, we need to make sure we run the GitLab CTL reconfigure command, and this will take a moment to run and hopefully should configure our SMTP provider.

6:45Now, once that's done executing, what we'll do is come back to the documentation here, and there's actually a command that you can use to confirm your SMTP settings and just send out a sample email. So if we do notify.Test_email email here, basically what we want to do is run this GitLab Rails console command, and that will open up an interactive Ruby console in the GitLab service context, and then we can actually send a test email to ourselves. So I'm going to be using my CBT Nuggets email for this purpose.

7:18So let me bring up my email over on the other screen here. And as you can see, here's my email inbox, and so what we're going to do is actually authorize my CBT Nuggets email as an authorized user within SES, because we're still in what's known as the sandbox mode. We haven't requested production access to SES just yet, so there are certain limitations. And so what you want to do is go to Create Identity, go to Email Address, and then plug in your email address, and the SES service is actually going to send you an email, and you just need to click the link on the email, and that will authorize your email address.

7:53Otherwise, SES will not be able to send to your email as long as it's in the sandbox mode, which is the default for all new AWS accounts. So once you've authorized your email address as a verified identity inside of the SES service, we should be able to send ourselves an email from the GitLab instance using this little Notify command here. I'm just going to copy that command to my clipboard and then go into Notepad, and we'll just change the email address here. So trevor.sullivan@cbtnuggets.com, and then we'll just copy this to our clipboard and then we'll come back to our terminal here and we're now going to run the GitLab command here, so gitlab-rails and then console.

8:38And this command takes about a minute to initialize, so just be patient with it. I'm not quite sure why it takes so long. But once that runs, we'll get an interactive Ruby terminal, and then we can simply paste that Notify command to test out connectivity to SES. All right, so now we've got our interactive Ruby console here and I'm just going to go ahead and paste in this and Notify test email command and hit Enter to run it, and you should see this message that says Delivered Mail, and hopefully everything has worked properly here and we've received that email.

9:09So I'm going to come back to my email, and as you can see, we have this test email here. So at this point, I can go ahead and attempt to register for an account on my GitLab instance. So let me fire up a new container in Firefox here, and I'll just go to cbtgitlab.cbttrevor.com, and then we'll click on this little Register link here. So we'll say Register Now. I'll plug in my first name and last name and I'll just make my username Trevor, because it just needs to be unique on my instance, and then I'll plug in a password and click on Register, and now I should get an approval from my administrator basically saying that I am authorized to sign up, so we have to do that as the root user.

9:57So I'll switch back to the root user in this other tab right here, and what we'll do is go down to our users. Let me find that in this list of options here. So here's users up under Overview. And if we scroll over a little bit and look for pending approvals right here, you should see that Trevor Sullivan is in the pending approvals here. And so we're just going to click on User Administration and then choose Approve and authorize this new user to access our GitLab instance.

10:28So we'll come back over here and we should be able to authenticate as our new user account here, and I should have also received a confirmation email here basically just indicating that my user has been approved and that also confirms for me that SMTP is working properly so that my GitLab service can send confirmation emails to me. So at this point, I should be able to log in as the username Trevor and then plug in my password here, and I should get logged in to the GitLab instance, choose a couple of options here and click on Get Started, and we should now be able to log in to GitLab and start creating new Git repositories.

11:10I hope this has been informative for you and I'd like to thank you for viewing.