This script assumes the make-sid-dance.com domain, but you should either:

Pick the least-recently used domain from the Google Doc (internal only). (Let's Encrypt limits SSL cert creation on a weekly basis, so rotating usage helps reduce hitting the limits), or

Buy a new domain for your demo and substitute throughout the script.

Google Domains is $12 for .com domains, which isn't the cheapest, but comes with privacy protection. You still have to configure DNS to use custom name servers, even though Google Domain name servers is the default since GCP cycles through many different name servers.

Open up new browser window so the audience doesn’t see all your other open tabs.

Resize your browser window to something reasonable for sharing. 1280x720 is a good option. Here's a handy Applescript if you're on a Mac and using Chrome. Add it to your User Scripts folder and how Applescript in your menu bar, and it'll be really easy to trigger.

Consider just sharing web browser window so the audience isn’t distracted by notes or other windows.

We'll name this cluster make-sid-dance and have it created in the us-central zone. I will bump up the machine type to have 2 virtual CPUs for performance reasons, but I’ll drop it down to 1 node. A real cluster should have 3 or more nodes for better availability.

Name the cluster after your domain name (e.g. make-sid-dance).

Note the Zone field should read us-central1-*, and will have a letter on the end. This letter does not matter.

Change the number of vCPU in Machine type to 2 vCPU.

Change the Size to 1. Note: The demo will run fine on more nodes, if desired

Set up GitLab itself

Now that we have our cluster configured, we're ready to install GitLab. To do this, we'll need the base domain name, the external IP address we just configured, and an email address to use with Let's Encrypt. Then we use helm to install all the necessary components.

Change the Namespace drop-down on the left. Change it from default to All Namespaces

Click on Workloads on the left.

GitLab is now deploying, and we can watch the status from the Workloads page in the Kubernetes dashboard. We'll watch here for all items to have a green checkmark showing that they have completed. This process can take a few minutes as GKE allocates resources and starts up the various containers. You can see here there are several containers. The main GitLab container has the Rails app, but also Mattermost for Chat, the integrated Docker Registry, and Prometheus for monitoring. Then there are separate containers for Postgres and Redis and the autoscaling GitLab Runner for CI and CD. This is everything you need for the DevOps lifecycle on Kubernetes.

While we're waiting: In the next demo, I’ll take you through everything you need to take ideas to production, including chat with Mattermost, issues and issue tracking, planning with issue boards, coding with terminal access, committing with git version control, merge requests for code review, testing with continuous integration, getting peer reviews with live review apps, continuous delivery to staging, deploying to production directly from chat, cycle analytics to measure how fast you’re going from planning to monitoring, and lastly, Prometheus monitoring of your GitLab instance. With GitLab, everything is integrated out of the box.

What takes 10 minutes in this demo would take days if you're not using GitLab and have to integrate different tools. Not only is GitLab faster to set up, but it is also more convenient to have everything in one interface. Developers want to work on creating a great product, not on learning and maintaining the integrations between theirs tools.

If there is more time talk about what a review app is and what cycle analytics are.

Wait for gitlab pod to go to green or deployment to show available

Looks like our deployment is finished. Let's check out GitLab…

Open a new tab with gitlab.make-sid-dance.com (Adjusting the URL to the domain you used for this demo)

Boom, we’ve got a shiny new GitLab installation!

Set root password

Before we get too carried away, we need to secure the root account with a new password.

Set password for root user (You don't need to actually log in as root, but you can)

Cleanup

Before you delete the cluster, delete all of the underlying services/pods/etc. using the CLI.

If you accidentally delete the cluster using the web UI, make sure you:

Troubleshooting

Various failures block Let's Encrypt, and thus GitLab

There are several scenarios which can cause deployment failures due to issues surrounding the kube-lego-nginx and the Let's Encrypt (LE) ACME process. The easiest way to find these errors is checking the logs of the kube-lego-nginx service in the kube-lego namespace of the dashboard for your Kubernetes cluster.

If your DNS records are not correctly configured, the Let's Encrypt servers may not be able to resolve your domain when the ACME requests are filed against it. Let's Encrypt performs a reachability test that depends on valid, resolvable Fully-Qualified Domain Names. You must confirm that your entry DNS is functional, and has propagated. You can do this by using an external host (anywhere not directly querying your primary DNS where this record is present) to ping test.my.tld where my.tld is the domain name you are using. Because you should have configured a wildcard record (*.my.tld), test.my.tld should resolve to that address.

Host not responding (reachability)

This has been observed as a failure of the LoadBalancer to be properly connected to the reserved statis external IP address. There are a few methods of failure here, but the primary cases are:

Unable to assign due to prior assignment.

Either an existing use, or a failure to fully remove the prior deployment. This has been seen in both scenarios by GitLab personnel. If you are re-creating a previous deployment, you need to wait a short period and/or confirm that the previously used GCP Networking LoadBalancer has been removed. You can manually remove these if you do not wish to wait for GCP to catch up with the de-provisioning.

Unable to assign due to incorrect region.

If you inadvertently create a GKE Kubernetes cluster in a region that is not the same as the static IP address you are attempting to use, your deployment will fail to attach to that IP address, and result in the inability to listen and respond to requests.