Click-to-deploy a GitLab Community Edition server on Google Compute Engine

Quickly deploy a GitLab Community Edition server on Compute Engine

The Google Developers Console provides a simple interface that you can use to quickly configure your GitLab Community Edition server deployment.

1. In the GitLab server click-to-deploy page in the Google Developers Console, specify your configuration settings or use the default values.

   Configuration option details

   Field	Default	Description
   Admin Password		The password for the default administrator account. The username is root.
   Admin email		The email address for the default administrator account.
   GitLab Domain Name	gitlab.example.com	The external domain name that you will assign to your GitLab Community Edition server.
   Advanced options
   Zone	us-central1-a	The Compute Engine zone in which instances will be created.
   Server node machine type	n1-standard-8	The Compute Engine machine type for the server.
   Network name	default	Existing Compute Engine network that instances will belong to.
   Boot disk size in GB	100	The disk size of the GitLab server in GB between 1 and 10,000.

2. Click Deploy GitLab Community Edition. The deployment process can take a few minutes to complete.

3. Optional: Install the Cloud SDK to be able to connect to your virtual machine instance using SSH when deployment finishes.

4. Log in to your GitLab Community Edition Server:

   1. Click the View your GitLab server in the Developers Console link, which opens the instances view in the console.
   2. Find the gitlab-xxxx instance and click the external IP address link to open the GitLab and log in with the credentials that you defined.

When you are finished with the virtual machine instance, you can click the Delete Stack button in the Developers Console to stop all instances, destroy the associated data disks, and delete the instances.

Deployment processing

The deployment of the GitLab Community Edition server is managed by the Google Cloud Deployment Manager. Deployment Manager uses templates to help you deploy your configuration. These templates can include actions, which specify shell scripts that can contain specific deployment instructions. In the click-to-deploy templates, these scripts are specific to the GitLab software and define the type of Compute Engine instance to create and how to install the GitLab software on the instance.

Next steps

Customize your GitLab Community Edition server

The software is installed via the GitLab Omnibus Installer for Debian. You can find out more information on customizing your installation via the Omnibus GitLab README.

Set up a DNS record for your server's external URL

When you deploy the GitLab server, a virtual machine instance with an external IP address is created for you. If you specified a hostname in the advanced options, you might want to create a DNS A record to associate that hostname with the external IP address. Visit your DNS provider or try Google Cloud DNS.

Configure virtual machine instance or Gitlab from the command line

You can use the gcloud compute ssh <instance-name> command to connect to the virtual machine directly. You can look up the instance name in the Developers Console or by running the gcloud compute instances list command to show the GitLab server instances.

Upgrade your GitLab installation

See Updating GitLab via omnibus-gitlab

Set up your GitLab server to send email

You need to configure the GitLab server to send email before you can add new users or send any notifications. See Sending Email from an Instance

Troubleshooting

A deployment might fail to complete successfully for one of the following reasons:

1. Deployment Manager failure to create a cloud resource, such as an instance, disk, or load-balancing forwarding rule
2. Deployment coordinator module failure to create a persisent disk (for those deployments that include data disks)
3. Software installation or configuration failure

The following will help you identify and address each of these problems should you encounter them.

Deployment Manager failure

If a deployment fails to complete successfully, each module status is displayed in the Developers Console, such as:

module: DEPLOYMENT_FAILED
Replica module-1234 failed with status PERMANENTLY_FAILING: Replica State
changed to PERMANENTLY_FAILING. Unexpected error: detailed message

If the detailed message indicates a CPU quota issue or other problem that you can correct, delete the deployment, correct the problem, and try again.

If the error message on the Developers Console does not provide sufficient detail about the failure, for example:

module: DEPLOYMENT_FAILED
Replica module-1234 failed with status PERMANENTLY_FAILING: Replica State
changed to PERMANENTLY_FAILING. Replica was unhealthy 2 consecutive times.

This message means that an error occurred on one or more Compute Engine instances that are part of the deployment.

Deployment coordinator or software installation failure

If the module indicating failure is the Deployment coordinator module, then the error is likely due to data disk creation. If another module is indicating failure, then the error is likely due to software installation or configuration.

The detailed failure logs can be found on the virtual machine instances that were launched. On each instance, there will be a directory:

  /gagent/metaOutput

The directory contains a set of output files:

  stdoutN.txt
  stderrN.txt
  exitcodeN.txt

Each set of such files corresponds to the sequenced command that was executed by Deployment Manager for your deployment on that instance. Execution terminates on the first command to exit with a non-zero exitcode. The specific cause of failure will be found in stderrN.txt for the largest value of N.

To get a list of your Compute Engine instances, check the Compute Engine list of virtual machine instances in the Developers Console or run the following command:

 $ gcloud compute instances list

To ssh to an instance:

 $ gcloud compute ssh --zone=<zone> <instance>

To output the last 10 lines from the last stderr file:

 $ tail $(ls -1tr /gagent/metaOutput/stderr.*.txt | tail -n 1)

If you have problems that you cannot resolve or have questions head to Stack Overflow.