GitLab Dedicated Overview

Gitlab Dedicated Support overview.

Overview

GitLab Dedicated, from a support perspective, works as a combination of SaaS and Self-Managed. Customers have full Admin access to the instance, but no access to the infrastructure, nor to the backend configurations. This workflow captures the differences, and details of providing support for GitLab Dedicated.

If you’d like to work on GitLab Dedicated tickets, consider creating an issue using the template in Support Training, and read the overview.

Administrative access to a Dedicated instance

The GitLab Dedicated team does not have administrative access to the Admin Area in the GitLab application on Dedicated instances and neither does the GitLab Support team. Select individuals in the customer organization do have access to the Admin Area. Any support requests that require a GitLab instance administrator to make a change in the Admin Area, for example resetting 2FA, has to be performed by the appropriate team within the customer organization.

Working with logs

Working with logs has been moved

Working with Grafana

Working with Grafana has been moved

Switchboard

The Switchboard section has been moved

Monitoring system graphs are for internal use

We do not share internal graphs from our monitoring systems with Dedicated customers. The reason for this is that as the SaaS provider, we manage the underlying environment. Sharing internal graphs would not be actionable by the customer since they don’t have access to the environment and these graphs may not be interpreted correctly without a proper understanding of our system.

View instance metadata and upgrade history

GitLab Dedicated tenants are defined in the Switchboard repository’s tenant_models directory.

  • To view a customer’s instance metadata, click on the appropriate json file.
  • To view a customer’s instance upgrade history, view the appropriate json file’s commit history and search for commits that mention gitlab.
  • Use the blame feature to find why individual lines or changes were added. It makes it easier to find MRs and Issues with additional context.

Configuration changes

GitLab Dedicated uses the Cloud Native Hybrid reference architecture. Instance implementation and changes are done via the instrumentor project.

If it’s an emergency, escalate the emergency and contact GitLab Dedicated infrastructure team on Slack, using channel #g_dedicated-team.

When any changes are required besides those listed below, raise an issue in the GitLab Dedicated issue tracker using a Request for Help template. Be sure that the support::request-for-help label is added.

  1. In the ticket, ask the customer to provide the required information. In this case, it’s an IAM principal.
  • The IAM principal must be an IAM role principal or IAM user principal.
  • The IAM user principal has the following format: arn:aws:iam::<Customer_AWS_Account_ID>:user/user-name. The IAM role principal has the following format: arn:aws:iam::<Customer_AWS_Account_ID>:role/role-name. Keep the format of these two in mind to avoid prolonging the ticket if an unexpected format is provided.
  1. Open a new PrivateLink Request issue and confirm that the support::request-for-help label is added.
  2. Add the IAM principal to the issue. The Enviroment Automation team will provide a Service Endpoint Name.
  3. The customer will follow the steps in our documentation.
  1. Open a new PrivateLink Request issue and confirm that the support::request-for-help label is added.
  • As a comment in the issue, request two Availability Zone IDs (AZ IDs) that can be used by the customer.
  1. Provide the IAM role Principal to the customer. It has the following format: arn:aws:iam::<AWS_Account_ID>:role/reverse_private_link@<tenant_id>. Read the instructions in issue created for information on how to find the <AWS_Account_ID> and <tenant_id>.
  2. Provide the two AZ IDs from the issue to the customer. An example AZ ID is: use-az1 or usw-az4. Note: These are not AWS Zone IDs.
  • Provide the two AZ IDs early in the ticket to avoid prolonging the ticket. The AZ IDs must be in the same region as the customer’s tenant instance. The customer can then make the decision of which specific zones that can be used. AZ IDs are shared between different zones in a region but cannot be used outside of the region. For example, AZ IDs in us-west-1* cannot be used in us-west-2*. Some of the zones in each reach share AZ IDs with other zones in the same region but you must work with the customer to find the overlap.
  1. Ask the customer to provide the required information. In this case, it’s an Service Endpoint Name, a list of AZ IDs they will be using (should match provided AZ IDs), and Domain Name (with one of two options).
  • The Service Endpoint Name uses a reverse domain name notation and has the following format: com.amazonaws.vpce.<region>.<vpce-svc-identifier>
  1. Fill in the issue with the information provided by the customer and follow next steps in the issue.

IP Allowlist Request

  1. Ask the customer to provided the required information in the ticket. In this case, it’s a comma-separated list of IP addresses.
  2. Open a Request for Help issue and confirm that the support::request-for-help) in the GitLab Dedicated issue tracker.

SAML Request

  1. Ask the customer to provided the required information in the ticket. In this case, it’s a SAML configuration block or can be a list of information provided by a customer.
  2. Open a new SAML Config Request issue and confirm that the support::request-for-help label is added.
  3. Add the customer provided information and match it with the required formatting.

Application Logs Request

  1. In the ticket, ask the customer to provide the required information. In this case, it’s an IAM principal.
  1. Open a Request for Help issue in the GitLab Dedicated issue tracker.
  2. Provide the IAM principal to the Environment Automation team.
  3. Provide the name of the S3 bucket to the customer.

Filing issues

In cases where Customer Support needs to interact with GitLab Dedicated engineers to gather information or similarly debug a problem at tenant’s request (when Grafana or OpenSearch does not suffice), raise an issue in the GitLab Dedicated issue tracker using a Support Request template.

Escalating an Emergency issue

Emergencies from GitLab Dedicated will come through the Customer Emergencies On-call Rotation as with other emergency types.

The GitLab Dedicated Infrastructure team has a 24/7 PagerDuty rotation: GitLab Dedicated Platform Escalation. To manually create a PD Incident use the Dedicated Platform Service or use the Slack command /pd trigger and choose “Dedicated Platform Service” as the Impacted Service to escalate an emergency to an SRE after initial triage and analysis.

Troubleshooting tips

Tagging logs while running tests

Customers can add a custom identifier, such as the ticket ID, to the user-agent field when testing. This makes it easier to filter logs related to the test.

For example:

1

curl -k -vvv -A"GitLabSupport012345" "https://tenant.gitlab-dedicated.com/users/sign_in"
Last modified September 21, 2023: Add configure Dedicated workflows (34a62f3c)