Deploy GitLab on Self-Hosted Infrastructure

0:00[AUDIO LOGO]

0:11Hi, guys.

0:11My name is Trevor Sullivan, and welcome back

0:14to another CBT Nugget skill.

0:16In this skill, we are going to be exploring

0:19how you can set up a GitLab instance

0:22on your own self-hosted infrastructure.

0:25Now, before we actually talk about how to deploy GitLab

0:28onto a Linux virtual machine, let's

0:31talk about why exactly you might want

0:33to consider hosting your own GitLab instance,

0:37rather than simply using the SaaS,

0:39or software as a service, version of GitLab.

0:43Well, first of all, there is the concept of security

0:47that we need to be thinking about any time

0:49that we're hosting source code or infrastructure code that

0:52may be we're deploying using infrastructure

0:54as code tools or proprietary applications

0:57that we're building internally at our organization.

1:00So security is a really important concept

1:02that we need to apply to any application that's hosting

1:06our application source code.

1:08And if we're choosing to use GitLab in order

1:10to store our source code but we don't

1:12want the risks of possibly leaking source code

1:16or leaking our infrastructure configurations that we're

1:19developing with infrastructure as code techniques

1:21out to other users, out on the internet,

1:24or malicious attackers, then we can actually

1:27configure our own self-hosted GitLab instance

1:30on our own private infrastructure

1:32so that we can apply our own security rules, things

1:35like firewall rules, to deploy onto a secured instance

1:40rather than hosting it on the GitLab SaaS instance.

1:44Now another reason that you might

1:45want to use GitLab as a SaaS instance is for resiliency.

1:50So if you want to ensure that you are applying

1:52your own backup processes for disaster recovery,

1:56then that gives you the direct control over the GitLab

1:59instance so that you can determine

2:01exactly what those disaster backup and recovery procedures

2:05are going to look like.

2:07This is great for business continuity

2:09as well, so resiliency of the infrastructure itself but also

2:13business continuity so that you can rapidly

2:16redeploy a new GitLab instance in the case

2:19of some kind of outage of your primary infrastructure.

2:23Now another reason that you might want to control GitLab

2:25as well is for performance reasons.

2:27So when you're using the SaaS version of GitLab,

2:30you are going to be hosting that environment--

2:33or that environment is going to be hosted

2:35with a bunch of shared users, also known sometimes

2:38as tenants.

2:39So the other tenants that are using

2:41a GitLab infrastructure could potentially overload a GitLab

2:45infrastructure depending on how they've architected it,

2:48and that means that you might end up competing for cloud

2:52resources in order to run things like your CI/CD pipelines

2:56or any other automation processes inside

2:59of your GitLab repositories.

3:01So by hosting GitLab yourself on your own infrastructure,

3:04you can ensure that you have the predictability

3:07of the performance of your GitLab instance

3:11because you can control exactly how

3:13many system resources like virtual CPUs, memory, and disk

3:17configurations are going to be applied to your GitLab

3:21instance.

3:22So now that we understand why we might want to deploy GitLab

3:25ourselves, let's discuss what the deployment of GitLab

3:29itself actually looks like on your own infrastructure.

3:32I hope this has been informative for you,

3:33and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys, and welcome back.

0:12So in the last video, we introduced the concept

0:15of self-hosting a GitLab instance.

0:17And now I wanted to dive into the architecture

0:20of what self-hosting GitLab is going to look like.

0:23Now, GitLab itself is kind of the central point

0:26of our architectural discussion here

0:28because GitLab is ultimately the application

0:31that us and any development teams within our organization

0:35are going to be accessing, typically using a web browser

0:38and Git client tools like the Git CLI, for example.

0:42But GitLab itself actually plugs into other services

0:46as well because GitLab itself can't provide things

0:50like TLS certificates, and also things

0:53like SMTP for email access for sending transactional emails.

0:57Those are not things that GitLab typically does on its own.

1:00So you'll need to rely on some external services

1:03for those purposes.

1:04So let's start out with you as a developer or DevOps engineer

1:08right over here.

1:09And we're going to talk about the process of deploying

1:12and configuring a GitLab instance.

1:14Now, the first thing that you'll want to do

1:15is to select a cloud provider that

1:18allows you to deploy virtual infrastructure.

1:20So basically, you've got different cloud providers

1:23out there like Amazon Web Services, or Microsoft Azure,

1:26or Google Cloud, or Digital Ocean, or Linode.

1:29And there's a whole plethora of cloud providers out there

1:32that allow you to simply deploy Linux virtual machines very

1:36easily.

1:36Now, some of the common ones that I use

1:38are things like Amazon Web Services or Microsoft

1:40Azure or DigitalOcean.

1:42But there's many other providers out there.

1:44There's literally too many to list here.

1:46So I've just picked out some icons or logos

1:48from some of the most common ones that I personally use,

1:50and listed them here.

1:52But I think we're probably going to end up

1:53using DigitalOcean or Linode just for simplicity

1:56as well as cost efficiency, since they're very inexpensive

2:00providers to use.

2:01Now, once you've set up your instance for GitLab,

2:04something that you're going to need to do

2:06is to set up a DNS endpoint for your users

2:09to access the GitLab instance.

2:11So you'll need to set up a DNS provider.

2:14And so typically, what you'll do is

2:15you'll register a domain name--

2:17for example, cbttrevor.com or awstrevor.com

2:21or cbtnuggets.com.

2:23Those are what we consider domain names.

2:26And then you can create a child domain name,

2:29like gitlab.cbttrevor.com.

2:31Or you can pretty much choose whatever kind of naming

2:33convention you want to.

2:35You could call it cbtnuggets.cbttrevor.com,

2:38whatever you want to.

2:39But basically, you'll create your own domain name

2:41that actually points to the virtual machine that's

2:44going to run your GitLab instance here.

2:47Now, you can also go ahead and install

2:50GitLab itself onto your virtual machine

2:52once you've set up your DNS.

2:54You don't necessarily have to do it in that order.

2:56You can install GitLab and then set up DNS later on.

2:59So there's not a strict requirement

3:01to do it one way or the other.

3:03But it's kind of up to you which direction you want to go.

3:06Now, as far as email goes, typically GitLab

3:09is going to need an email provider configured

3:11so that it can send what are known as transactional emails.

3:14An example of a transactional email

3:16would be somebody going to your GitLab instance

3:19and signing up for an account on your GitLab instance.

3:23When you sign up for a GitLab instance,

3:25you'll need to verify your email address.

3:28And so GitLab itself will need to send

3:30an email to the user that registered with that GitLab

3:33instance so that they can confirm their account.

3:36Another example of a transactional email

3:39is resetting a password.

3:41If you ever clicked on the Forgot Password link

3:44on any kind of SaaS service out there,

3:46you'll probably be familiar with the process of the service

3:49sending you an email.

3:51You click on a link in that email which

3:53has some kind of unique identifier

3:55to uniquely identify your password reset request.

3:58And then it takes you to a web page on that SaaS service.

4:01And it will allow you to then reset your password.

4:04So GitLab needs an SMTP provider configured

4:07so that it can send those transactional emails for things

4:11like sign-ups and password resets

4:13and I'm sure a bunch of other types of emails as well.

4:16Now, one other service that we're

4:17going to need to plug into is Let's Encrypt here.

4:20So GitLab, by default when you install it,

4:22is going to attempt to request a Let's Encrypt certificate.

4:26Now, Let's Encrypt is a managed service

4:29that allows web applications to dynamically request Transport

4:33Layer Security, or TLS, certificates

4:36so that you can secure data in transit across the network.

4:40As your users are accessing the GitLab instance that's

4:44running on a cloud virtual machine-- maybe

4:46you've got some different development users down here.

4:48Or maybe it's just yourself that's

4:50accessing the GitLab instance running

4:52on your virtual infrastructure here.

4:54You're going to want to make sure

4:56that network traffic to and from the GitLab instance

4:59is encrypted at the network layer

5:01so that no attackers or malicious users on the internet

5:04are able to intercept that network traffic

5:07and compromise the security credentials that you're

5:09using to log into that GitLab instance

5:12and then basically impersonate your different users

5:15and gain access to unauthorized data on that GitLab instance.

5:20So the nice thing about GitLab is that it natively

5:23integrates with Let's Encrypt.

5:24And if for some reason you don't have your DNS validated just

5:28yet, when you install GitLab, it will actually

5:31generate its own internal certificate as well.

5:34So even though it's not a trusted certificate

5:36by most client web browsers, at least it

5:39will have a certificate in place that is not necessarily

5:42trusted by default. But there is still

5:44a certificate that can be used to encrypt those network

5:48communications.

5:49Now, once you've got GitLab installed,

5:51you've got your DNS provider configured here,

5:54and you've got your SMTP configured here,

5:57there's other configuration that you can do as well.

6:00In fact, in order to configure SMTP itself,

6:02you actually have to go into this GitLab configuration file.

6:05So there is a GitLab configuration file

6:07that exists on the Linux file system

6:09that you can edit with any kind of text editor,

6:12like Vim, for example, or Nano.

6:14There's a ton of different text editors

6:16that you could potentially use out there.

6:18But that configuration file is going

6:19to allow you to tweak a lot of different settings

6:21on your GitLab instance, including the SMTP

6:25configuration, including the Let's Encrypt TLS configuration

6:28as well.

6:29So you'll want to be familiar with that.

6:31And then also, you'll have what's

6:33called a root user, by default, that gets created when you

6:37set up your GitLab instance.

6:38And that root user is what you're

6:40going to use to log into the GitLab instance

6:43and then approve any user sign-ups if you have disabled

6:47user sign-ups by defaults.

6:50So by default, when you set up GitLab,

6:51any users that attempt to sign up on your instance

6:54are going to have to be authorized explicitly

6:57by the super user or root account in that GitLab

7:00instance.

7:01Otherwise, they will not be able to confirm their account

7:03and then gain access to the GitLab instance.

7:07So anyways, now that we kind of understand at a high level

7:09some of the different services that GitLab will integrate

7:13with in order to provide a self-hosted instance of GitLab,

7:17let's go ahead and start by setting up

7:18the virtual infrastructure for our GitLab instance.

7:21I hope this has been informative for you,

7:23and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys.

0:11And welcome back.

0:12Now that we've talked about the high-level setup

0:14process for a self-hosted GitLab instance in the previous video,

0:19let's go ahead and actually start out

0:20by setting up the virtual infrastructure.

0:23Now one of the choices that you're going to need to make

0:25is which cloud provider you want to use

0:28for each of these components.

0:30In my particular case, I'm going to be setting up

0:33a virtual machine on the DigitalOcean cloud platform.

0:36They make it just really easy to spin up virtual infrastructure.

0:40And they provide a very competitive pricing as well.

0:43They also provide a REST API that you

0:45can plug into to manage your virtual infrastructure,

0:48plus they also have a CLI tool called DOCTL

0:51that you can use to manage those virtual machines.

0:54But you're more than welcome to use Amazon EC2 instances

0:57or Microsoft Azure virtual machines

0:59or any other virtual private server provider that

1:01allows you to spin up a simple Linux virtual machine

1:04and have a publicly routable IP address on the internet.

1:08You're also going to need to choose a DNS provider.

1:11And so you'll need to find a DNS provider that allows

1:13you to register a domain name.

1:15And you also need to be able to create a DNS-hosted zone so

1:19that you can actually host the DNS records to set up

1:22your GitLab instance.

1:24There's also some DNS configuration that

1:25goes into the SMTP config here.

1:29So in order to authorize your domain for sending emails

1:32from the SMTP protocol, you'll need

1:35to make sure that domain is authorized as well.

1:37And typically that is done using some DNS records.

1:41So I'm going to be using Amazon Route 53 as my DNS registrar.

1:46So I've already registered a DNS domain called cbttrevor.com

1:51So If I head over to my account and go to Route 53

1:55and come down to registered domains here,

1:58you should see that I've got cbttrevor.com registered.

2:01However, I'm not going to be using

2:03Route 53 to host my DNS zones.

2:06I do have the ability to use it as my hosted zone if I want to.

2:11However, I actually have my domain set up right now.

2:13If I go to cbttrevor.com under my registrar config here,

2:17you can actually see that my name servers here

2:19for this domain are set up to forward it

2:22to Google's DNS servers.

2:24And that's because I over here in the Google Cloud platform

2:28have chosen to use Google Cloud DNS as my DNS hosting

2:32for my DNS zone for my domain cbttrevor.com.

2:37So basically what we're going to do

2:39is be using CBTTrevor.com here.

2:41We're going to create a new child zone for GitLab

2:44specifically.

2:45I already have one set up here, but we're

2:46going to create a new one.

2:48And we'll take a look at how to set up

2:50that zone as the authoritative zone right

2:53here in my route zone for cbttrevor.com

2:56so that we can use that for our GitLab instance.

3:00But the first thing that I'm going to do

3:02is to go ahead and set up a GitLab server.

3:05So let's head over to the DigitalOcean cloud platform

3:08here.

3:09And of course, your steps are going

3:10to be different depending on what

3:11cloud provider you're using.

3:13But I'm just going to click on Create

3:15what's known as a droplet.

3:17So a droplet is just the kind of marketing term

3:19in the DigitalOcean platform for a virtual machine.

3:22And then I typically use Ubuntu Linux.

3:24But you could also use Debian Linux or CentOS or Fedora

3:28if you wanted to.

3:29And I typically use the LTS version of Ubuntu Linux

3:32because that is good for up to five years of updates.

3:35And it's typically just a reliable base operating

3:38system for any Linux services that you want to run.

3:42Now, as far as the system resources,

3:44regardless of what cloud platform you're using,

3:46we're going to need to make sure that GitLab has access

3:49to appropriate system resources because it

3:51is kind of a heavy application.

3:53It does a lot of activity in the background.

3:55And according to the documentation

3:58here for installing GitLab, if we go out

4:00to docs.gitlab.com and drill into Installing GitLab

4:04Requirements here, they do tell you

4:06that four cores or four virtual CPU cores

4:09is the recommended minimum number of cores.

4:12And that'll support approximately 500 users.

4:15And as far as memory or RAM goes,

4:18we need to have at least 4 gigabytes of memory.

4:21But it suggests maybe having 8 gigabytes of memory if you

4:24want to go up to 1,000 users.

4:27So I'm going to make sure that I choose a virtual machine

4:29type here that supports four CPUs and 8 gigabytes of memory.

4:34And that's were built by the hour.

4:35So it's only 7.1 cents per hour.

4:38So as you can see, that is pretty inexpensive, especially

4:41if I am only spinning this up for several hours.

4:43So I'm going to go ahead and just choose a region here.

4:46Let's choose maybe the New York 3 region here.

4:48And I'm going to go ahead and add my SSH

4:50key so I can authenticate to that virtual machine.

4:53I'm also going to enable an IPv6 address here.

4:56And we'll go ahead and give it a name.

4:59So for the host name here, I'll just call it GitLab.

5:02And we'll click on Create droplet.

5:04Now that virtual machine will take a couple of minutes

5:07to spin up.

5:08So why don't we go ahead and start

5:09by setting up our DNS configuration

5:12while this droplet is deploying here?

5:14In just a moment here, we're going

5:16to get an IPv4 address as well as an IPv6 address associated

5:20with this droplet.

5:21And those are the addresses that we're

5:23going to set up DNS A records for in just a moment here.

5:27So in our next video, we'll go ahead

5:29and jump into our DNS config and go from there.

5:32I hope this has been informative for you.

5:34And I'd like to thank you for viewing.

0:01[AUDIO LOGO]

0:05Hey, guys, and welcome back.

0:07So in the last video, we set up our DigitalOcean droplet

0:10running Ubuntu Linux, and now we need

0:12to go through our DNS configuration

0:14to ensure that we have some domain names set up

0:17to forward network traffic to this IPv4 or IPv6 address

0:22for our GitLab instance.

0:24Now, we haven't installed GitLab on this instance yet.

0:27We'll do that in a little bit here.

0:28But we need to go ahead and do our DNS zone configuration.

0:32Now, I'm going to be using Google Cloud DNS here

0:34for my DNS zone hosting.

0:36So the first thing that I need to do

0:38is to go into my root zone here and I

0:40need to create what's known as a name server record

0:43here so that I can specify what DNS servers are

0:48going to be hosting the child zone that I create.

0:51Now, I also need to create the child zone itself,

0:54so I'm just going to click on it Create Zone,

0:56and then we'll choose a public zone

0:58because this needs to be publicly

0:59accessible across the internet, and then

1:01I need to give it a zone name and a DNS name.

1:03So you'll want to pick a DNS name.

1:05I'll just call this cbtgitlab.cbttrevor.com,

1:09and so we're going to use cbtgitlab.cbttrevor.com

1:13in order to access our GitLab instance.

1:15And then in Google Cloud DNS we just need to give it a name.

1:18So typically what I do is I just use the same name,

1:21but I use dashes to separate the name, rather than periods

1:24because you can't use a period in the actual resource name

1:27itself.

1:28So we'll just specify that this is for GitLab hosting

1:33and we'll go ahead and click on Create.

1:35Now, once I create the child zone,

1:37you're going to see that we have this NS record in the child

1:40zone, and this tells us which Google DNS

1:43servers we need to set our name server record for.

1:47So basically it's just going to be NS cloud of B1

1:49through B4 on googledomains.com.

1:53So I'll just copy one of these and then come back

1:55to our parent zone here,

1:57And I'm going to add in a new record set,

1:59and we need to make sure that it is set to an NS record.

2:02And we'll give it a name, which is

2:04going to be our cbtgitlab.cbttrevor.com,

2:08and then we need to plug in all of those name servers

2:10down here under the name server list.

2:13So we'll just go ahead and add four items here,

2:15and we're going to make sure that we paste in each value

2:18and then we're just going to overwrite it

2:20with 1, 2, 3, and 4.

2:23All right, so once we've got that set up,

2:25we'll just click on Create here, and so that will basically

2:28set up the domain delegation so that any DNS lookups going

2:31across the internet to Google's DNS servers

2:34that are destined for cbtgitlab.cbttrevor.com

2:38are going to be forwarded to this DNS zone

2:41that we have created right here.

2:43So now what we need to do is to go ahead and set up

2:46an A record.

2:46So we'll click on Add Record Set.

2:48And I'm just going to leave this empty for the DNS name

2:51because we want cbtgitlab.cbttrevor.com

2:54to forward network traffic using an A record to the IP

2:58address of our virtual machine.

3:00So I'm just going to copy the IPv6 address here

3:03from our virtual machine and we'll

3:05paste that in for the IP address here and click on Create,

3:09and then I'm also going to add another record set here

3:12for a quad A record, and we are going to leave this empty again

3:16because we want cbtgitlab.cbttrevor.com

3:19to forward to the IPv6 address that we have right here.

3:22So we'll copy the IPv6 address from our console

3:25and then go back and paste that in as the IPv6 address.

3:29All right, so now we've got the A record and the quad

3:31a records set up, and we also need to set up

3:34DNS for our email as well.

3:37Now, you can use a bunch of different email services

3:39out there.

3:40I've just chosen to use the Amazon Simple Email

3:42service because that's a pretty simple service to set up.

3:45So I'm going to come back to the AWS console here

3:48and we're just going to set up a new domain verification so

3:51that we can authorize our domain to send emails through SES.

3:56So we're going to come down to Verified Identities here

3:58and then we're going to click on Create Identity,

4:01and then we're going to choose a domain identity here

4:03because we want to authorize our domain,

4:05and we're going to specify cbtgitlab.cbttrevor.com

4:09as the authorized domain, and then we'll just click on it

4:12Create Identity.

4:14Now, this is going to generate a series of CNAME records

4:17in DNS that we need to use to authorize SES to send emails

4:21using our domain.

4:23So as you can see, our status is currently

4:25set to Verification Pending.

4:26So what we need to do is create these CNAME records down here

4:29with these values on the right hand side,

4:32and that is what's going to tell SES to authorize our domain.

4:37So we'll copy the first value here,

4:39or I should say the first name, and bring it back

4:42into Google Cloud DNS right here.

4:44So we'll say Add Record Set, we'll paste in that name,

4:47and I'm going to cut off the domain name here

4:51because we already have that in the Google console here.

4:54So it should just be this random value, .domainkey,

4:58and then cbtgitlab.cbttrevor.com,

5:01and that's going to be a CNAME record, not an A record,

5:04and then we'll come back to SES here.

5:07We'll copy the value for that record

5:09and paste that in as the canonical name.

5:12Now, in Google Cloud DNS, you get

5:13this little error saying the record data

5:15must be in this format, and it's a little bit subtle,

5:17but you'll see that there's actually a period at the end.

5:20So make sure you plug in a period

5:21there and click on Create.

5:23And then we'll just do that two more times.

5:25So let's go back to our zone here,

5:27and then we'll say Add Record Set.

5:29We'll do that two more times for the other CNAME records here.

5:32We'll copy this first value here, plug it in,

5:36remove our domain name from that,

5:38change it to a CNAME record, and then we'll copy the value

5:42and then bring that back in, put a period at the end, and just

5:46one more time here.

5:47So we'll say Add Record Set, copy the CNAME here, bring it

5:52back in, and eliminate the domain name,

5:56change it to a CNAME record, and then

5:58once more we'll copy the value for that CNAME record,

6:01paste it in, put in a period at the end, and click on Create.

6:05All right, so that is setting up the authorization for SES,

6:09and in just a few moments here.

6:10We should see the DKIM configuration change

6:13from Pending to Verified to indicate

6:16that SES is authorized.

6:18So if I just hit Edit here and Save Changes,

6:21that should kind of force it.

6:22And as you can see, it's pretty fast.

6:23So DKIM configuration is now successful

6:26and our identity status is now set to verified.

6:30So now the SES service is authorized

6:33to send emails for this domain.

6:35So now that we've got this set up, let's go ahead

6:37and navigate to our GitLab instance

6:40and actually get GitLab installed onto that instance.

6:43I hope this has been informative for you

6:45and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hey, guys, and welcome back.

0:13So in the last video, we set up the DNS service to point

0:16to our GitLab instance, and we also

0:18authorized our SMTP provider, which, in this case,

0:22is the Amazon Simple Email Service,

0:24to allow our domain to send emails.

0:27Now we need to go ahead and get GitLab itself installed

0:30onto our virtual machine.

0:33And once we do that, it should automatically

0:35request a Let's Encrypt certificate.

0:37But if it doesn't, we'll just kick it in the rear

0:40and make sure that it does actually request

0:42a Let's Encrypt certificate.

0:44Regardless, we are going to have encryption

0:46to that endpoint, so don't worry about it from a security

0:50perspective as far as setting it up goes.

0:53Now, the nice thing about GitLab is

0:55that you have lots of different choices

0:56as far as how you can install GitLab

0:59into your virtual machine.

1:01First of all, you can use what's known as the Omnibus package

1:04for Linux, which is basically an all-encompassing package that

1:08contains all of the different components of GitLab.

1:11If you were to do a completely from-scratch installation

1:14of GitLab, it would be an incredibly complex setup

1:17process.

1:19So the GitLab development team has provided this Omnibus

1:23package to dramatically simplify the setup

1:26process for GitLab itself.

1:29Now, if you'd like to install GitLab without directly

1:32installing it onto Linux, if you want to containerize it,

1:35you do actually have the ability to run GitLab as a Docker

1:39container as well so that everything

1:40is kind of self-contained inside of that Docker container.

1:44And you can set up a file system as a Docker volume

1:47to persist any data that the GitLab instance needs

1:50to persist.

1:51So that's a really nice, simple way to install it as well.

1:54You also have the ability to install GitLab as a Helm chart

1:57onto a Kubernetes cluster.

1:59So Helm is basically a command-line interface tool

2:02that you can use to manage software packages that

2:05are deployed to a Kubernetes cluster.

2:07So that's a really nice way to install GitLab along

2:10with many other applications on Kubernetes clusters.

2:13And then you also have the ability

2:14to set it up on Kubernetes as an operator as well.

2:17So they provide that as a choice as well.

2:20And of course, if you want to do the painful method where

2:23you deploy it from scratch, then you certainly

2:25have the ability to deploy it from the source code as well.

2:28But we are going to go with a simpler option, which

2:31is to deploy it using the Omnibus package for Linux.

2:34And one other deployment mechanism

2:35that I wanted to mention as well is

2:37that on the major cloud providers that

2:39have marketplaces, like, Amazon Web Services has

2:43a marketplace where you can obtain

2:45vendor applications from.

2:47Same thing with Google Cloud Platform and Microsoft Azure.

2:50They actually have prebuilt the images for Linux operating

2:54systems that allow you to deploy GitLab as what's

2:57known as a virtual appliance, where everything is basically

3:00preinstalled, but you just deploy the entire operating

3:03system along with GitLab itself as a single image.

3:07So that's a really nice way to deploy it

3:09if you don't want to worry about having

3:11to log in to the virtual machine and configure things

3:15and just get into the nitty-gritty stuff.

3:18But typically, the Linux package is

3:20going to give you a lot of flexibility.

3:21But it's also going to balance things with ease of use

3:24as well.

3:25So we're going to be deploying the Omnibus package right here.

3:28And installation, it can be done using

3:30an RPM package or certain Linux distributions that

3:33use RPM packages.

3:35And you can also deploy with Debian packages

3:37or any Debian-based operating systems that

3:40use the D package command-line tool to install

3:43Debian packages.

3:44Now, installing it is going to be pretty easy.

3:46So basically, what we're going to do

3:48is install it from this package repository.

3:51And we're going to have the ability

3:52to deploy either the Enterprise Edition that

3:55has certain Enterprise exclusive features.

3:58Or we can simply deploy the GitLab Community Edition,

4:01which is the open source version that's,

4:03I believe, under the MIT License if I recall correctly.

4:06So we're going to go ahead and just install this Community

4:09Edition here.

4:10And so you'll see that when we go to the Community Edition

4:13package here, we have the ability

4:14to use a Debian or RPM package.

4:16And actually, I think we're going

4:18to do the Enterprise Edition here just so we have access

4:20to the full feature set.

4:21So let's choose the Debian package for Enterprise here.

4:24And then we'll copy this cURL command here

4:26into our terminal once we log in to our virtual machine,

4:30and that should get GitLab installed onto our system.

4:33So let's come over to DigitalOcean here.

4:36And we'll grab our IP address for our system.

4:40And I'm going to fire up a new terminal.

4:42And we'll just get SSH into that Linux virtual machine here.

4:46I'll say, ssh and then root at IP address.

4:49And there's also an option that I

4:50like to enable for SSH called ServerAliveInterval.

4:54And then I'll just set that to 60 seconds

4:56so that we get a periodic ping to our server,

4:58maybe even 30 seconds.

4:59And that helps to keep our SSH connection alive in the event

5:03that we have any kind of internet connection

5:05instability.

5:06All right, so now we are logged in to our Linux virtual machine

5:08on DigitalOcean, and so now what we're going to do

5:10is just paste in the cURL command.

5:14Let's do a Windows-V here, and then we'll

5:17paste this in and run that command.

5:20Now, this will take a little while

5:22to get all of the GitLab packages installed.

5:25But this is going to install the Omnibus package for GitLab.

5:28So let's just give this a couple of minutes to complete,

5:30and then we'll come right back.

5:32All right, so this command was pretty fast

5:34because it basically set up the package repository.

5:37But we have not yet actually installed the GitLab itself.

5:41And so, to do that, we'll need to run a couple

5:42of other commands here.

5:43We're going to use the APT package manager.

5:45So we'll do an APT update, and that

5:47will get the package repository metadata available

5:52on our local system.

5:53And then, in order to install GitLab Enterprise Edition,

5:56we're just going to do an apt install gitlab-ee.

6:00So we'll copy that command.

6:02And we don't need sudo because we're actually

6:03logged in to our virtual machine as the root user here already.

6:08And typically, I like to actually do the --yes parameter

6:11here because that will just prevent you

6:14from being asked any questions interactively

6:16in the terminal when you run that APT-install command.

6:19And it just automatically installs everything

6:21that you've requested.

6:22So as you can see we're going to install

6:24the gitlab-ee package here.

6:26It is pretty large.

6:27It's over a gigabyte in size here.

6:29So the first thing that APT needs to do

6:31is to download the package, and then it'll

6:33run the package installation on our virtual machine here.

6:36So we'll come right back in just a moment here

6:38once this has completed.

6:40All right, so our GitLab instance

6:41has finished installing here, but if you

6:44look through the output here, it says,

6:45thanks for installing GitLab!

6:47However, GitLab was unable to detect a valid DNS hostname

6:52for your GitLab instance.

6:53So we actually need to go into this configuration file right

6:56here called /etc/gitlab/gitlab.rb.

7:00That's basically a Ruby configuration file,

7:02as many of the components for GitLab

7:04are written in the Ruby language.

7:07And so what we need to do is change

7:09the setting inside of that file called the external_url.

7:12And we need to set that to our DNS domain, which

7:15is CBTGitLab.CBTTrevor.com, and then we

7:19need to run this command right down here.

7:21GitLab has a kind of control tool

7:24that allows you to manipulate the GitLab service running

7:27on this Linux virtual machine, and that is called gitlab-ctl.

7:30And it has a reconfigure command that basically

7:32tells it to reread the configuration file once we've

7:36made those edits, and then it will apply those changes

7:39to our GitLab instance.

7:41So we need to run that reconfigure command after we

7:43update this config file here.

7:45So we'll go ahead and do that DNS verification

7:48in our next video.

7:49I hope this has been informative for you,

7:51and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hey, guys.

0:11And welcome back.

0:12So in our last video, we got the GitLab Enterprise Edition

0:16package installed onto our Linux instance.

0:19And now what we need to do is to actually access that GitLab

0:22instance using our web browser.

0:24But at the moment, we are probably

0:26not going to be able to access that instance.

0:28So if we head over to our browser

0:30here and try to go to cbtgitlab.cbttrevor.com,

0:35technically, we set up this DNS record to forward

0:38to our service.

0:39However, GitLab itself does not know about this hostname,

0:42and so we're probably going to get an error message here

0:45indicating that GitLab was either not started up

0:47or it's not going to be able to process that request correctly.

0:50But we can validate DNS using a command line utility called dig

0:55on Linux.

0:56So over here on our Linux instance,

0:57you should be able to run the dig command

0:59or if you don't have it installed,

1:01you can install the dig package on your Linux instance here.

1:03But what we want to do is specify dig-t,

1:07and then we want to specify that we're

1:08searching for an A record, which is going to forward a DNS

1:13name to our IP address, our IPv4 address, specifically.

1:16And then we'll plug-in our host name, which

1:19is cbtgitlab.cbttrevor.com, and that

1:23should return the IP address of your Linux instance.

1:27You can also specify a quad A record,

1:29which is an IPv6 forward lookup record.

1:32And you should see in the answer section

1:35right down here that the IPv6 address

1:37for your DigitalOcean virtual machine

1:40matches up with what's in the console here.

1:43So we know that the A record and the quad A records are set up

1:47correctly but unfortunately, GitLab is not running because

1:50of that external URL setting that we saw

1:54was incorrectly configured right up

1:55here when we installed GitLab.

1:58So something else you can do to verify the GitLab status

2:00is run the systemctl command here.

2:03And this is basically allowing you to manipulate and inspect

2:06systemd services that are running

2:08and registered on your Linux instance here.

2:10So if we do systemctl status for GitLab here, let's do GitLab.

2:17So it looks like it actually has an installed it yet here

2:19because I can't tab complete that.

2:21But what we need to do now is run that GitLab CTL command

2:25to reconfigure it.

2:26But first, let's go ahead and run vim/etc/gitlab/gitlab.rb.

2:32And this is a massive configuration file

2:34that is going to allow us to manipulate the running

2:37configuration of our GitLab instance.

2:38All of our SMTP settings are in here as well.

2:41But I'm just going to do a forward slash in Vim

2:43to search for the text external.

2:46And as you can see, external URL is currently

2:48set to gitlab.example.com.

2:50Of course, we don't own example.com,

2:52somebody out there I'm sure owns it.

2:53But we don't.

2:55So what we need to do is change this external URL setting.

2:58So I'll do a dollar sign to delete to end of line,

3:02and then I'll hit a to go into append or insert mode here.

3:05And then I'll plug in cbtgitlab.cbttrevor.com.

3:10And I'm also going to set that to an HTTPS URL

3:14so that we're basically telling GitLab that we want

3:16to be accessing it over HTTPS.

3:19So we'll go ahead and do a WQ, colon WQ to save and quit

3:23to Vim.

3:23And then it will do a GitLab CTL reconfigure command.

3:29And hopefully, that will get our GitLab instance up and running.

3:32So we'll give that a second to run.

3:34It does take a little time to get everything reconfigured

3:36and we'll come right back.

3:39So after a minute or two, the GitLab CTL reconfigure command

3:43should complete.

3:44And as you can see, it looks like everything looks good

3:47here.

3:47As you can see, we've got a default admin account

3:50with the username, root.

3:52And then the password for root is actually stored in a file

3:56on the Linux file system under the /etc/github directory.

4:00So in order to access our GitLab instance,

4:02we're going to need that root password.

4:04Let's try and run our systemctl status command again.

4:07And we're going to look for a service,

4:09you can tab complete it, called gitlab-runsvdir.service.

4:15That's the unit file name for systemd.

4:17And as you can see, that service is up and running.

4:20Now, one utility that I like to use to monitor my Linux systems

4:23is called btop.

4:25And you can see I don't have btop installed by default,

4:28but I can just run a snap install btop

4:31here and get that installed on my Ubuntu system here.

4:34It should install pretty quickly,

4:36it's not a very large package.

4:38But once I run btop here, you should

4:40see a bunch of information about my virtual machine.

4:44So I can see things like my CPU utilization.

4:47It's refreshing currently at 2 seconds or 2000 milliseconds

4:50here, but I can use the plus and minus keys

4:52to reduce that to down to, let's say, maybe 500 milliseconds

4:55here.

4:56So I'm getting much more granular system information.

4:59So I can see that my CPU is working a little bit here.

5:02And I can also see some of the processes that

5:05are running on my system here.

5:06So I can see a bunch of GitLab processes

5:09down in the process list here, I can see a whole bunch

5:12of Ruby processes as well.

5:14And so it looks like everything is up and running.

5:17I can also see how much memory my system is currently using.

5:21As you can see, out of that 8 gigabytes

5:22that I have provisioned on my virtual machine here,

5:25I'm using about 50% of it, around 4 gigabytes of that.

5:29I can also see things like disk activity here as well.

5:32So as you're monitoring your production GitLab instances,

5:36the btop CLI is a great utility to get some real time

5:40information.

5:42So let's go ahead and quit that with hitting the Q command

5:44here.

5:45And now, what we're going to do is

5:47to attempt to access our GitLab instance.

5:50So we'll come back to our browser here,

5:53and we'll try to navigate to cbtgitlab.cbttrevor.com,

5:58and hopefully, we will be able to access our instance now.

6:03As you can see, we are now able to access our GitLab instance

6:07here.

6:07And so I'm being prompted to log in

6:09with a username and password.

6:11And so this is where we're going to use our root

6:13credentials by default in order to access this GitLab instance.

6:17Something else I can do is to check out the certificate

6:20in my browser here.

6:21You can see that I am connected securely to my custom instance

6:25here on cbtgitlab.cbttrevor.com, and it's

6:29a verified by Let's Encrypt.

6:31And if I click on More Information here,

6:33I can actually view the certificate details here,

6:36and I can see that the organization that

6:39provisioned this certificate is actually Let's Encrypt.

6:42And the little lock icon in my browser

6:44here on my self-hosted instance just

6:47indicates to me that I am connected

6:48using a trusted certificate.

6:51So now, we're going to log in with our username of root,

6:54and 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.

7:03And then we're going to find the initial root password file.

7:06And as you can see, our password is printed out right here.

7:09So we'll just go ahead and select that password

7:11and bring that back into our GitLab instance

7:14and click on Sign In.

7:16And now we are logged in to our GitLab instance

7:19using our root user account.

7:21As you can see, we have a little warning here

7:23that tells us that anybody that has access to this website

7:27here, which is basically at this point anybody on the internet,

7:30can theoretically register for an account.

7:33So it's recommending that we make it a private instance

7:36so that not just anybody is able to sign up for a GitLab account

7:41on our private instance.

7:43Now, there is an admin section that you can go to over here,

7:45and there are tons and tons of different settings

7:47here for administering your GitLab instance.

7:50But what we're going to do now that we've got our GitLab

7:53instance set up is to actually sign up

7:55as a new user on this service.

7:58But in order to do that, we need to actually set up SMTP first.

8:01So we'll go ahead and set up SMTP in the next video.

8:04I hope this has been informative for you,

8:06and I'd like to thank you for viewing.

0:01[AUDIO LOGO]

0:11Hi, guys, and welcome back.

0:12So in the last video, we finished the setup process

0:15for our GitLab instance, and we made sure

0:18that we had a Let's Encrypt TLS certificate associated

0:21with that GitLab instance for security purposes for data

0:24in transit across the wire, across the internet,

0:27and we also made sure that our DNS was set up properly

0:30so that we can access the website using

0:33our publicly accessible DNS name, which

0:35is cbtgitlab.cbttrevor.com.

0:39So at this point, we have a fully functioning GitLab

0:41instance, except that our new users will not

0:45be able to sign up because they won't get any sign

0:48up confirmation emails.

0:49So one of the things that we need to do

0:51is to configure the GitLab instance

0:54so that it knows how to use our SMTP or Simple Mail Transfer

0:57Protocol provider so that it can send out

1:00those transactional emails for things like signups

1:03and password resets and all that stuff,

1:05and then we'll go ahead and test out connectivity

1:07to that service and make sure that GitLab is actually

1:10able to send out emails through that SMTP service.

1:13So what we want to do is head over

1:15to the documentation for GitLab here,

1:18and we'll just go up here to the search

1:20and look for the SMTP documentation.

1:22And keep in mind that SMTP providers are one in a million.

1:27So, basically, you've just got a list

1:29of massive amounts of different email providers

1:31over here on the right hand side,

1:34or I should say a dime a dozen not one in a million,

1:38because there's just tons of different options

1:40here and pretty much any of them are going to work just fine.

1:43But what we're going to do is use the Amazon Simple Email

1:46Service here.

1:47And as you can see in the documentation,

1:49they provide a sample configuration

1:51that shows us how to configure Amazon SES or Simple Email

1:55Service in our GitLab configuration file.

1:59So once again, we're going to be modifying

2:01our gitlab.rb configuration file using Vim in our Linux system,

2:06and we're going to set some of these values for the Amazon SES

2:10Service.

2:11Now, keep in mind that you're welcome to use any of these.

2:13You could use Mail Gun if you want to.

2:15You could use Microsoft Office 365, you could use SendGrid,

2:20you could use Rackspace if you want to.

2:23There's a whole ton of options here.

2:25One other one that I've come across in the past

2:27is Mail Jet as well.

2:29They kind of specialize in sending transactional emails

2:32and marketing emails and that kind of thing,

2:34so feel free to check them out as well.

2:35I've had a good experience with Mail Jet in the past.

2:38But there are just tons of different options

2:39that you have here, and they provide sample configurations

2:42for each of those.

2:44So what we're going to do is make

2:46sure we have an AWS account here.

2:47We're going to navigate back over to the SES console

2:50here and go to our account dashboard.

2:53And one of the things that we'll need to do

2:55is in our SES service is to set up

2:58our credentials in our account.

3:01So we'll come down to SMTP settings here,

3:03and then we'll click on Create SMTP Credentials,

3:06and this is actually going to take us over

3:08to a separate service in AWS called the Identity and Access

3:12Management Service, and it will automatically

3:14create for us and SMTP IAM user account.

3:18So we'll click on Create and then

3:20it will give us some IAM credentials

3:22here that we can use inside of the configuration

3:25block for Amazon SES here.

3:28So we've got a couple of settings here.

3:30The SMTP username and the SMTP password, and those

3:34are going to be set to the IAM access

3:36key and the secret key that were generated over here

3:39in the IAM console.

3:41So we'll click on the username here and copy that,

3:45and let's go ahead and copy this.

3:47Actually, we're going to just modify the existing config

3:50rather than copying this.

3:51So we'll just come back to our terminal here,

3:53and then we'll say vim /etc/gitlab/gitlab.rb and hit

4:01Enter, and then we need to find inside of this huge

4:03configuration file-- as you can see,

4:05this is a really long kubeconfig file that's hundreds of lines

4:08long.

4:08What we want to do is just go up to the top

4:10and do a forward slash search for the lowercase SMTP.

4:15And as you can see, this entire section right here--

4:18let me try that once more here.

4:19This entire section right here is

4:22going to be lines 85 through about line 94 here,

4:27and all of these different settings

4:29here allow us to configure SMTP.

4:31So we're just going to remove the comments.

4:33So this little hash character here

4:35is a comment, which basically means that this setting is not

4:38going to be interpreted.

4:40So we want to remove those comments

4:42from each of these settings so that we can enable SMTP,

4:47and we're actually going to comment out SMTP TLS there.

4:51And so these are the settings from lines 85 through line 92

4:55that we want to enable here, and so we're

4:57going to make sure that SMTP Enable is set to True.

5:00We're going to set the SMTP address

5:02to the DNS name for SES.

5:05So we'll head back to the SES console

5:07here and copy this SMTP endpoint value here.

5:11We'll copy that and bring that in.

5:13And for the SMTP port here, you'll

5:16notice that there's a couple of different ports specified

5:18in the SES console here.

5:20So we've got the Start TLS port and then we've

5:21got the TLS Wrapper port here, and so I'm

5:24going to be using port 2587 because during my testing

5:27I'm pretty sure that's the one that worked.

5:30So I'll set SMTP port 2587, and then for the SMTP user

5:35we'll paste in our IAM access key.

5:38And then for the SMTP password here,

5:41let me just delete the text there.

5:43And then we'll say the secret key, so the SMTP password.

5:48We'll copy this value.

5:50Make sure you don't include that space at the end.

5:52And then we'll paste that in.

5:54Now, the SMTP domain down here, we'll check out the docs here.

5:58We're going to set that to whatever our domain is.

6:01So remember that we previously authorized the SES service

6:05to use our verified identity, which

6:08is cbtgitlab.cbttrevor.com.

6:11So 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.

6:18And everything else we should just leave to the default

6:22values and just verify that it matches in the documentation

6:26here.

6:26So once we've made those modifications,

6:28we'll just hit Escape and then colon wq

6:31on our keyboard to save that file.

6:34And then once again, after we've made any changes,

6:36we need to make sure we run the GitLab CTL reconfigure command,

6:40and this will take a moment to run

6:42and hopefully should configure our SMTP provider.

6:45Now, once that's done executing, what we'll do

6:48is come back to the documentation here,

6:50and there's actually a command that you

6:52can use to confirm your SMTP settings

6:55and just send out a sample email.

6:58So if we do notify.Test_email email here,

7:01basically what we want to do is run this GitLab Rails console

7:05command, and that will open up an interactive Ruby console

7:08in the GitLab service context, and then we can actually send

7:11a test email to ourselves.

7:14So 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.

7:22And as you can see, here's my email inbox,

7:24and so what we're going to do is actually

7:26authorize my CBT Nuggets email as an authorized user

7:31within SES, because we're still in what's

7:33known as the sandbox mode.

7:34We haven't requested production access to SES just yet,

7:37so there are certain limitations.

7:39And so what you want to do is go to Create Identity, go

7:42to Email Address, and then plug in your email address,

7:45and the SES service is actually going to send you an email,

7:48and you just need to click the link on the email,

7:50and that will authorize your email address.

7:53Otherwise, SES will not be able to send to your email

7:55as long as it's in the sandbox mode, which

7:58is the default for all new AWS accounts.

8:01So once you've authorized your email address

8:04as a verified identity inside of the SES service,

8:08we should be able to send ourselves

8:10an email from the GitLab instance using

8:12this little Notify command here.

8:14I'm just going to copy that command to my clipboard

8:17and then go into Notepad, and we'll just

8:19change the email address here.

8:22So trevor.sullivan@cbtnuggets.com,

8:26and then we'll just copy this to our clipboard

8:28and then we'll come back to our terminal here

8:30and we're now going to run the GitLab command here, so

8:35gitlab-rails and then console.

8:38And this command takes about a minute

8:40to initialize, so just be patient with it.

8:42I'm not quite sure why it takes so long.

8:44But once that runs, we'll get an interactive Ruby terminal,

8:47and then we can simply paste that Notify command to test out

8:51connectivity to SES.

8:53All right, so now we've got our interactive Ruby console here

8:55and I'm just going to go ahead and paste in this and Notify

8:58test email command and hit Enter to run it,

9:02and you should see this message that says Delivered Mail,

9:05and hopefully everything has worked properly here

9:08and we've received that email.

9:09So I'm going to come back to my email, and as you can see,

9:13we have this test email here.

9:15So at this point, I can go ahead and attempt

9:17to register for an account on my GitLab instance.

9:21So let me fire up a new container in Firefox here,

9:24and I'll just go to cbtgitlab.cbttrevor.com,

9:29and then we'll click on this little Register link here.

9:32So we'll say Register Now.

9:33I'll plug in my first name and last name

9:36and I'll just make my username Trevor, because it just

9:39needs to be unique on my instance,

9:41and then I'll plug in a password and click on Register,

9:46and now I should get an approval from my administrator basically

9:51saying that I am authorized to sign up,

9:55so we have to do that as the root user.

9:57So I'll switch back to the root user in this other tab

10:00right here, and what we'll do is go down to our users.

10:06Let me find that in this list of options here.

10:08So here's users up under Overview.

10:10And if we scroll over a little bit and look for pending

10:14approvals right here, you should see that Trevor Sullivan is

10:18in the pending approvals here.

10:20And so we're just going to click on User Administration

10:22and then choose Approve and authorize this new user

10:25to access our GitLab instance.

10:28So we'll come back over here and we

10:30should be able to authenticate as our new user account here,

10:34and I should have also received a confirmation email here

10:37basically just indicating that my user has been approved

10:41and that also confirms for me that SMTP is working properly

10:46so that my GitLab service can send confirmation emails to me.

10:49So at this point, I should be able to log in

10:51as the username Trevor and then plug in my password here,

10:57and I should get logged in to the GitLab instance,

11:00choose a couple of options here and click on Get Started,

11:05and we should now be able to log in to GitLab

11:08and start creating new Git repositories.

11:10I hope this has been informative for you

11:12and I'd like to thank you for viewing.