Commit 54e56cdc authored by Suzanne Selhorn's avatar Suzanne Selhorn

Docs: Updated alert box styles

Related to: gitlab-org&5020
parent 4acde42d
Pipeline #226938961 passed with stages
in 1 minute and 43 seconds
......@@ -24,5 +24,5 @@ The end result will be `repo.example.com/image:custom-tag`.
There is an [example values file](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml) that demonstrates how to configure a custom Docker registry/repository and tag. You can copy relevant sections of this file for your own releases.
NOTE: **Note:**
NOTE:
Some of the charts (especially third party charts) sometimes have slightly different conventions for specifying the image registry/repository and tag. You can find documentation for third party charts on the [Artifact Hub](https://artifacthub.io/).
......@@ -24,7 +24,7 @@ To use an external database with the `gitlab` chart, there are a few prerequisit
1. A [Kubernetes Secret](https://kubernetes.io/docs/concepts/configuration/secret/) with the password for the user above.
1. Ensure that the database is reachable from the cluster. Be sure firewall policies are in place to allow traffic.
NOTE: **Note:**
NOTE:
The `pg_trgm` and `btree_gist` extensions need to be added to the GitLab
database. This means that the `CREATE EXTENSION` command should be executed
while connected to the GitLab database (by default named `gitlabhq_production`)
......
......@@ -11,7 +11,7 @@ This document intends to provide documentation on how to configure this Helm cha
If you don't have Gitaly configured, for on-premise or deployment to VM,
consider using our [Omnibus GitLab package](external-omnibus-gitaly.md).
NOTE: **Note:**
NOTE:
External Gitaly _services_ can be provided by Gitaly nodes, or
[Praefect](https://docs.gitlab.com/ee/administration/gitaly/praefect.html) clusters.
......@@ -127,7 +127,7 @@ have to
tlsEnabled: true
```
NOTE: **Note:**
NOTE:
You can choose any valid secret name and key for this, but make
sure the key is unique across all the secrets specified in `customCAs` to avoid
collision since all keys within the secrets will be mounted. You **do not**
......
......@@ -19,7 +19,7 @@ refer to the [Mattermost Helm configuration guide](https://github.com/mattermost
- [Tiller](https://rancher.com/docs/rancher/v2.x/en/installation/options/helm2/helm-init/) (the Helm server-side component)
installed on the cluster if using Helm v2.
NOTE: **Note:**
NOTE:
For the Team Edition you can have just one replica running.
## Deploy the Mattermost Team Edition Helm Chart
......@@ -54,7 +54,7 @@ helm upgrade --install gitlab gitlab/gitlab \
--set certmanager-issuer.email=<email>
```
NOTE: **Note:**
NOTE:
If using Helm v2, please see notes about the `--timeout` option
in the [Deployment documentation](../../installation/deployment.md#deploy-using-helm).
......@@ -69,7 +69,7 @@ Once you've deployed the GitLab instance, follow the instructions for the [initi
The next part of the process is setting up the GitLab SSO integration.
To do so, you need to [create the OAuth application](https://docs.mattermost.com/deployment/sso-gitlab.html) to allow Mattermost to use GitLab as the authentication provider.
NOTE: **Note:**
NOTE:
Only the default GitLab SSO is officially supported. “Double SSO”, where GitLab SSO is chained to other SSO solutions, is not supported. It may be possible to connect
GitLab SSO with AD, LDAP, SAML, or MFA add-ons in some cases, but because of the special logic required they’re not officially
supported and are known not to work on some experiences.
......
......@@ -50,7 +50,7 @@ Direct support for Azure Blob storage is available for
The Azure MinIO gateway is still needed for backups. Follow [this issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2298)
for more details.
NOTE: **Note:**
NOTE:
GitLab [does not support](https://github.com/minio/minio/issues/9978) the Azure MinIO gateway as the storage for the Docker Registry.
Please refer to the [corresponding Azure example](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.azure.yaml) when [setting up the Docker Registry](#docker-registry-images).
......@@ -154,18 +154,15 @@ diffs, and pseudonymizer is done via the `global.appConfig.lfs`,
--set global.appConfig.dependencyProxy.connection.key=connection
```
NOTE: **Note:**
Currently a different bucket is needed for each, otherwise performing a restore from backup will not properly function.
Notes:
NOTE: **Note:**
Storing MR diffs on external storage is not enabled by default. So,
for the object storage settings for `externalDiffs` to take effect,
`global.appConfig.externalDiffs.enabled` key should have a `true` value.
NOTE: **Note:**
The dependency proxy feature is not enabled by default. So,
for the object storage settings for `dependencyProxy` to take effect,
`global.appConfig.dependencyProxy.enabled` key should have a `true` value.
- Currently a different bucket is needed for each, otherwise performing a restore from backup will not properly function.
- Storing MR diffs on external storage is not enabled by default. So,
for the object storage settings for `externalDiffs` to take effect,
`global.appConfig.externalDiffs.enabled` key should have a `true` value.
- The dependency proxy feature is not enabled by default. So,
for the object storage settings for `dependencyProxy` to take effect,
`global.appConfig.dependencyProxy.enabled` key should have a `true` value.
See the [charts/globals documentation on appConfig](../../charts/globals.md#configure-appconfig-settings) for full details.
......
......@@ -245,7 +245,7 @@ In order to deploy this chart as a Geo Primary, we'll start [from this example c
helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml
```
NOTE: **Note:**
NOTE:
This assumes you are using the `gitlab` namespace, if you want to use a different namespace,
you should also replace it in `--namespace gitlab` throughout the rest of this document.
......@@ -396,7 +396,7 @@ Once the configuration above is prepared:
write:errno=0
```
NOTE: **Note:**
NOTE:
If this step fails, you may be using the wrong IP address, or a firewall may
be preventing access to the server. Check the IP address, paying close
attention to the difference between public and private addresses and ensure
......@@ -548,7 +548,7 @@ In order to deploy this chart as a Geo Secondary, we'll start [from this example
helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml
```
NOTE: **Note:**
NOTE:
With Helm v2, one may need to specify the namespace that the release was
deployed to with the `--namespace <namespace>` option.
......
......@@ -460,6 +460,6 @@ helm upgrade --install review-update-app-h8qogp gitlab/gitlab \
<your other config settings>
```
NOTE: **Note:**
NOTE:
With Helm v2, one may need to specify the namespace that the release was
deployed to with the `--namespace <namespace>` option.
......@@ -59,7 +59,7 @@ Backups are made using the following steps, in order:
It is also possible to specify the storage class in which the backup is stored using `--storage-class <storage-class-name>`, allowing you to save on backup storage costs. If unspecified, this will use the default of the storage backend.
NOTE: **Note:**
NOTE:
This storage class name is passed through as-is to the storage class argument of your specified backend.
#### GitLab backup bucket
......@@ -92,5 +92,5 @@ After fetching the backup tar the sequence of execution is:
- clean up the corresponding bucket
- restore the backup content into the corresponding bucket
NOTE: **Note:**
NOTE:
If the restore fails, the user will need to revert to previous backup using data in `tmp` directory of the backup bucket. This is currently a manual process.
......@@ -99,7 +99,7 @@ The steps for restoring a GitLab installation are
1. This process will take time depending on the size of the tarball.
1. The restoration process will erase the existing contents of database, move existing repositories to temporary locations and extract the contents of the tarball. Repositories will be moved to their corresponding locations on the disk and other data, like artifacts, uploads, LFS etc. will be uploaded to corresponding buckets in Object Storage.
NOTE: **Note:**
NOTE:
During restoration, the backup tarball needs to be extracted to disk.
This means the Task Runner pod should have disk of necessary size available.
For more details and configuration please see the [Task Runner documentation](../charts/gitlab/task-runner/index.md#persistence-configuration).
......
......@@ -182,7 +182,7 @@ gitlab:
runAsUser: ""
```
NOTE: **Note:**
NOTE:
The example syntax eliminates the `securityContext` setting entirely.
Setting `securityContext: {}` or `securityContext:` does not work due
to the way Helm merges default values with user provided configuration.
......@@ -210,7 +210,7 @@ workhorse:
The following values are used to configure the Gitaly Pods.
NOTE: **Note:**
NOTE:
Gitaly uses an Auth Token to authenticate with the Workhorse and Sidekiq
services. The Auth Token secret and key are sourced from the `global.gitaly.authToken`
value. Additionally, the Gitaly container has a copy of GitLab Shell, which has some configuration
......@@ -224,13 +224,13 @@ volume for the Git repository data. You'll need physical storage available in th
Kubernetes cluster for this to work. If you'd rather use emptyDir, disable PersistentVolumeClaim
with: `persistence.enabled: false`.
NOTE: **Note:**
NOTE:
The persistence settings for Gitaly are used in a volumeClaimTemplate
that should be valid for all your Gitaly pods. You should *not* include settings
that are meant to reference a single specific volume (ie volumeName). If you want
to reference a specific volume, you need to manually create the PersistentVolumeClaim.
NOTE: **Note:**
NOTE:
You can't change these through our settings once you've deployed. In [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
the `VolumeClaimTemplate` is immutable.
......@@ -259,7 +259,7 @@ persistence:
### Running Gitaly over TLS
NOTE: **Note:**
NOTE:
This section refers to Gitaly being run inside the cluster using
the Helm charts. If you are using an external Gitaly instance and want to use
TLS for communicating with it, refer [the external Gitaly documentation](../../../advanced/external-gitaly/index.md#connecting-to-external-gitaly-over-tls)
......@@ -281,7 +281,7 @@ Follow the steps to run Gitaly over TLS:
kubectl exec -it <Task Runner pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml
```
NOTE: **Note:**
NOTE:
A basic script for generating custom signed certificates for
internal Gitaly pods [can be found in this repo](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh).
Users can use or refer that script to generate certificates with proper
......
......@@ -20,7 +20,7 @@ The `migrations` creates a new migrations [Job](https://kubernetes.io/docs/conce
For now we also have the jobs remain as objects in the cluster after they complete. This is so we can observe the migration logs. Currently this means these Jobs persist even after a `helm uninstall`. This is one of the reasons why we append random text to the Job name, so that future deployments using the same release name don't cause conflicts. Once we have some form of log-shipping in place, we can revisit the persistence of these objects.
NOTE: **Note:**
NOTE:
If using Helm v2, the uninstall command would be `helm delete --purge`.
The container used in this chart has some additional optimizations that we are not currently using in this Chart. Mainly the ability to quickly skip running migrations if they are already up to date, without needing to boot up the rails application to check. This optimization requires us to persist the migration status. Which we are not doing with this chart at the moment. In the future we will introduce storage support for the migrations status to this chart.
......
......@@ -32,7 +32,7 @@ The default number of replicas to deploy is 3. This can be changed by setting `g
Praefect uses its own database to track its state. This has to be manually created in order for Praefect to be functional.
NOTE: **Note:**
NOTE:
These instructions assume you are using the bundled PostgreSQL server. If you are using your own server,
there will be some variation in how you connect.
......@@ -92,7 +92,7 @@ To run Praefect over TLS follow these steps:
kubectl exec -it <Task Runner Pod> -- grep gitaly_address /srv/gitlab/config/gitlab.yml
```
NOTE: **Note:**
NOTE:
A basic script for generating custom signed certificates for internal Praefect Pods
[can be found in this repo](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh).
Users can use or refer that script to generate certificates with proper SAN attributes.
......
......@@ -346,7 +346,7 @@ on a per-pod basis.
| `maxReplicas` | Integer | `10` | Maximum number of replicas |
| `maxUnavailable` | Integer | `1` | Limit of maximum number of Pods to be unavailable |
NOTE: **Note:**
NOTE:
[Detailed documentation of the Sidekiq memory killer is
available](https://docs.gitlab.com/ee/administration/operations/sidekiq_memory_killer.html#sidekiq-memorykiller)
in the Omnibus documentation.
......@@ -357,7 +357,7 @@ The `pods` declaration provides for the declaration of all attributes for a work
pod. These will be templated to `Deployment`s, with individual `ConfigMap`s for their
Sidekiq instances.
NOTE: **Note:**
NOTE:
The settings default to including a single pod that is set up to monitor
all queues. Making changes to the pods section will *overwrite the default pod* with
a different pod configuration. It will not add a new pod in addition to the default.
......@@ -404,7 +404,7 @@ these files in the GitLab source:
1. [`app/workers/all_queues.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml)
1. [`ee/app/workers/all_queues.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/workers/all_queues.yml)
NOTE: **Note:**
NOTE:
When [`cluster`](#cluster) is `false`, this must be an array of queue names as strings.
### negateQueues
......@@ -419,7 +419,7 @@ This is useful if you have a pod processing important queues, and another pod
processing other queues: they can use the same list of queues, with one being in
`queues` and the other being in `negateQueues`.
NOTE: **Note:**
NOTE:
`negateQueues` _should not_ be provided alongside `queues`, as it will have no effect.
### cluster
......@@ -436,7 +436,7 @@ not using Sidekiq Cluster, they must be an array of strings. The latter option
will [not be supported from GitLab
14.0](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/337).
NOTE: **Note:**
NOTE:
Unlike in other installation methods, `cluster` will never start
more than one Sidekiq process inside a pod. To run additional Sidekiq processes,
run additional pods.
......
......@@ -366,7 +366,7 @@ can be customized using the `unicorn.memory.min` and `unicorn.memory.max` chart
default values are sane, you can increase (or lower) these values to fine-tune
them for your environment or troubleshoot performance issues.
NOTE: **Note:**
NOTE:
These settings are effective on a _per process basis_, not for an entire Pod.
### Memory requests/limits
......
......@@ -127,7 +127,7 @@ If you wish to use an external `cert-manager`, you must provide the following:
## GitLab Version
NOTE: **Note:**
NOTE:
This value should only used for development purposes, or by explicit request of GitLab support. Please avoid using this value
on production environments and set the version as described
in [Deploy using Helm](../installation/deployment.md#deploy-using-helm)
......@@ -192,7 +192,7 @@ from the global, by design.
### PostgreSQL SSL
NOTE: **Note:**
NOTE:
SSL support is mutual TLS only.
See [issue #2034](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2034)
and [issue #1817](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1817).
......@@ -1084,7 +1084,7 @@ Example `--set` configuration items, when using the global chart:
--set global.appConfig.ldap.servers.main.password.key='the-key-containing-the-password'
```
NOTE: **Note:**
NOTE:
Commas are considered [special characters](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set)
within Helm `--set` items. Be sure to escape commas in values such as `bind_dn`:
`--set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net'`.
......@@ -1445,7 +1445,7 @@ is killed by the Webservice master process. The default value is 60 seconds.
## Custom Certificate Authorities
NOTE: **Note:**
NOTE:
These settings do not affect charts from outside of this repository, via `requirements.yaml`.
Some users may need to add custom certificate authorities, such as when using internally
......
......@@ -2,7 +2,7 @@
redirect_to: '../../installation/deployment.md#redis'
---
NOTE: **Note:**
NOTE:
The Redis HA chart was removed in the `3.0` release of the GitLab Helm chart. Please
refer to an older edition of the documentation if you need access to it's documentation.
......
......@@ -2,7 +2,7 @@
redirect_to: '../../installation/deployment.md#redis'
---
NOTE: **Note:**
NOTE:
Our fork of the Redis chart was switched in the `3.0` release of the GitLab
Helm chart to use the [upstream Redis chart](https://github.com/bitnami/charts/tree/master/bitnami/redis).
Please refer to an older version of the docs if you are looking for the documentation
......
......@@ -491,7 +491,7 @@ If you chose to use the `filesystem` driver:
For the sake of resiliency and simplicity, it is recommended to make use of an
external service, such as `s3`, `gcs`, `azure` or other compatible Object Storage.
NOTE: **Note:**
NOTE:
The chart will populate `delete.enabled: true` into this configuration
by default if not specified by the user. This keeps expected behavior in line with
the default use of MinIO, as well as the Omnibus GitLab. Any user provided value
......
......@@ -74,7 +74,7 @@ shared-secrets:
enabled: false
```
NOTE: **Note:**
NOTE:
If you disable this sub-chart, you **must** manually create all secrets,
and provide all necessary secret content. See [installation/secrets](../../installation/secrets.md#manual-secret-creation-optional)
for further details.
......@@ -41,6 +41,6 @@ helm upgrade --install gitlab . \
--set certmanager-issuer.email=me@example.com
```
NOTE: **Note:**
NOTE:
If using Helm v2, please see notes about the `--timeout` option
in the [Deployment documentation](../installation/deployment.md#deploy-using-helm).
......@@ -92,7 +92,7 @@ tests against the deployed GitLab instance:
gitlab-qa Test::Instance::Any EE:$GITLAB_VERSION $GITLAB_URL
```
NOTE: **Note:**
NOTE:
The above command runs with _nightly_ because the containers used as a
part of this chart are currently based on nightly builds of the `master` branches
of `gitlab-(ee|ce)` repositories.
......@@ -113,7 +113,7 @@ Developers may encounter unique issues while working on new chart features.
[Refer to the troubleshooting guide](troubleshooting.md) for
information if your **_development_** cluster seems to have strange issues.
NOTE: **Note:**
NOTE:
The troubleshooting steps outlined in the link above are for development
clusters only. Do not use these procedures in a production environment or
data will be lost.
......@@ -11,7 +11,7 @@ In this guide, we'll be using [KinD](https://kind.sigs.k8s.io). It creates a Kub
We will also make use of [nip.io](https://nip.io), which lets us map any IP address to a hostname using a format like this: `192.168.1.250.nip.io`, which maps to `192.168.1.250`. No installation is required.
NOTE: **Note:**
NOTE:
With the SSL-enabled installation options below, if you want to clone repositories and push changes, you will have to do so over HTTPS instead of SSH. We are planning to address this with an update to GitLab Shell's service exposure via NodePorts.
## Preparation
......@@ -23,7 +23,7 @@ All of the following installation options require knowing your host IP. Here are
- Linux: `hostname -i`
- MacOS: `ipconfig getifaddr en0`
NOTE: **Note:**
NOTE:
Most MacOS systems use `en0` as the primary interface. If using a system with a different primary interface, please substitute that interface name for `en0`.
### Using namespaces
......@@ -67,7 +67,7 @@ helm repo update
Select from one of the following deployment options based on your needs.
NOTE: **Note:**
NOTE:
The first full deployment process may take around 10 minutes depending on network and system resources while the Cloud Native GitLab images are downloaded. Confirm GitLab is running with the following command:
```shell
......@@ -100,7 +100,7 @@ kubectl get secret gitlab-wildcard-tls-ca -ojsonpath='{.data.cfssl_ca}' | base64
Now that the root CA is downloaded, you can add it to your local chain (instructions vary per platform and are readily available online).
NOTE: **Note:**
NOTE:
If you need to log into the registry with `docker login`, you will need to take additional steps to configure the registry to work with your self-signed certificates. More instructions can be found [here](https://docs.docker.com/registry/deploying/#run-an-externally-accessible-registry) and [here](https://blog.container-solutions.com/adding-self-signed-registry-certs-docker-mac).
### NGINX Ingress NodePort without SSL
......@@ -117,7 +117,7 @@ helm upgrade --install gitlab gitlab/gitlab \
Access GitLab at `http://gitlab.(your host IP).nip.io`.
NOTE: **Note:**
NOTE:
If you need to log into the registry with `docker login`, you will need to tell Docker to [trust your insecure registry](https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry).
### Handling DNS
......@@ -135,5 +135,5 @@ When you're ready to clean up your local system, run this command:
kind delete cluster
```
NOTE: **Note:**
NOTE:
If you named your cluster upon creation, or if you are running multiple clusters, you can delete specific ones with the `--name` flag.
......@@ -68,13 +68,13 @@ change according to the pieces being tested, and the requirements as listed:
[database](https://docs.gitlab.com/ce/install/requirements.html#database)
requirements.
NOTE: **Note:**
NOTE:
This is created in your home directory under `~/.minikube/machines/minikube/`.
- `--kubernetes-version string`: The Kubernetes version that the Minikube VM will use (e.g., `v1.2.3`).
- `--registry-mirror stringSlice`: Registry mirrors to pass to the Docker daemon.
NOTE: **Note:**
NOTE:
Changing these values in a second `start` command, requires to first delete
the existing instance with `minikube delete`, or manually you can alter the
properties with VirtualBox Manager.
......@@ -198,7 +198,7 @@ helm upgrade --install gitlab . \
-f https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube.yaml
```
NOTE: **Note:**
NOTE:
If using Helm v2, please see notes about the `--timeout` option
in the [Deployment documentation](../../installation/deployment.md#deploy-using-helm).
......@@ -216,7 +216,7 @@ helm upgrade --install gitlab . \
-f https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml
```
NOTE: **Note:**
NOTE:
If using Helm v2, please see notes about the `--timeout` option
in the [Deployment documentation](../../installation/deployment.md#deploy-using-helm).
......
......@@ -46,7 +46,7 @@ obj.dig('ConfigMap/test-gitaly', 'data', 'config.toml.erb')
This will return the contents of the `config.toml.erb` file contained in the
`test-gitaly` ConfigMap.
NOTE: **Note:**
NOTE:
Using the `HelmTemplate` class will always use the release name of "test"
when executing the `helm template` command.
......
......@@ -30,7 +30,7 @@ claims.
kubectl delete secrets,pvc -lrelease=RELEASE_NAME
```
NOTE: **Note:**
NOTE:
This deletes all Kubernetes secrets including TLS certificates and all data
in the database. This should not be performed in a production instance.
......@@ -42,6 +42,6 @@ The database environment can be reset in a development environment by:
1. Delete the PostgreSQL PersistentVolumeClaim
1. Deploy GitLab again with `helm upgrade --install`
NOTE: **Note:**
NOTE:
This will delete all data in the databases and should not be run in
production.
......@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
This is the official, recommended, and supported method to install GitLab on a cloud native environment.
NOTE: **Note:**
NOTE:
It is not necessary to have GitLab installed on Kubernetes in order to use
the [GitLab Kubernetes integration](https://docs.gitlab.com/ee/user/project/clusters/).
......@@ -118,7 +118,7 @@ To uninstall the GitLab Chart, run the following:
helm uninstall gitlab
```
NOTE: **Note:**
NOTE:
With Helm v2, you need to use the command `helm delete --purge gitlab`.
For the purposes of continuity, these charts have some Kubernetes objects that
......@@ -199,7 +199,7 @@ helm repo add gitlab https://charts.gitlab.io/
helm search repo -l gitlab/gitlab
```
NOTE: **Note:**
NOTE:
With Helm v2, the search command would be `helm search -l gitlab/gitlab`
For more information, visit the [version mappings docs](installation/version_mappings.md).
......
......@@ -69,7 +69,7 @@ Administrators may also want to consider the
[new AWS Service Operator for Kubernetes](https://aws.amazon.com/blogs/opensource/aws-service-operator-kubernetes-available/)
to simplify this process.
NOTE: **Note:**
NOTE:
Enabling the AWS Service Operator requires a method of managing roles within the cluster. The initial
services handling that management task are provided by third party developers. Administrators should
keep that in mind when planning for deployment.
......@@ -107,7 +107,7 @@ You can fetch your ELB's hostname to place in the CNAME record with the followin
kubectl get ingress/RELEASE-webservice -ojsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
NOTE: **Note:**
NOTE:
For environments where internal load balancers are required,
[Amazon's Elastic Load Balancers](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html)
require [special annotations](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/eks_loadbalancer_annotations.yml).
......
......@@ -10,7 +10,7 @@ For a fully functional GitLab instance, you will need a few resources before
deploying the `gitlab` chart. The following is how these charts are deployed
and tested within GitLab.
NOTE: **Note:**
NOTE:
Google provides a whitepaper for [deploying production-ready GitLab on
Google Kubernetes Engine](https://cloud.google.com/solutions/deploying-production-ready-gitlab-on-gke), including all steps and external
resource configuration. These are alternative to this document, and the
......
......@@ -24,6 +24,6 @@ different pipelines.
When you decide to use CRD prefix, you need to pass it to the Chart as well, so the Operator will be able to work with
the expected CRD. To do so, use `gitlab.operator.crdPrefix` value.
NOTE: **Note:**
NOTE:
This utility uses `kubectl`. For versions prior to v1.14 you also need `kustomize`. To use an external
`kustomize` set `KUSTOMIZE_CMD` environment variable, e.g. `export KUSTOMIZE_CMD="kustomize build"`.
......@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Installing GitLab using Helm
NOTE: **Note:**
NOTE:
There are currently [known limitations](../index.md#limitations)
when using this chart, and not all features of GitLab are available.
......@@ -21,7 +21,7 @@ In order to deploy GitLab on Kubernetes, the following are required:
1. Helm v2 (2.12 or higher, excluding 2.15) or v3 (3.0.2 or higher).
1. A Kubernetes cluster, version 1.13 or higher. 8vCPU and 30GB of RAM is recommended.
NOTE: **Note:**
NOTE:
Helm is released as v2 and v3 versions. While Helm v2 is still in
use, it is recommended that Helm v3 be moved to future proof updates and
support a better security model. If GitLab has been previously installed
......@@ -38,7 +38,7 @@ Before proceeding to deploying GitLab, you need to prepare your environment.
### Cloud cluster preparation
NOTE: **Note:**
NOTE:
[Kubernetes 1.13 or higher is required](#requirements), due to the usage of certain
Kubernetes features.
......
......@@ -38,7 +38,7 @@ on some Deployments and StatefulSets are immutable and can not be changed from `
To work around this use the following instructions:
NOTE: **Note:**
NOTE:
These instructions _forcefully replace resources_, notably Redis StatefulSet.
You need to ensure that the attached data volume to this StatefulSet is safe and remains intact.
......
......@@ -26,7 +26,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w