Commit b14db9c3 authored by Marcel Amirault's avatar Marcel Amirault

Update capitalizations in charts

Update capitalization and backtick use in charts
in /advanced, /architecture, /backup-restore and
/development
parent de28e935
Pipeline #94975823 passed with stage
in 45 seconds
# Set up standalone Postgresql database
# Set up standalone PostgreSQL database
We'll make use of the [Omnibus GitLab](https://about.gitlab.com/install/#ubuntu) package for Ubuntu. This package provides versions of the services that are guaranteed to be compatible with the charts' services.
......
......@@ -40,7 +40,7 @@ If you use a mutual TLS connection to the database:
- `global.psql.ssl.clientCertificate`: The key inside the secret referring the client certificate.
- `global.psql.ssl.clientKey`: The client inside the secret.
For example, pass these values via helm's `--set` flag while deploying:
For example, pass these values via Helm's `--set` flag while deploying:
```sh
helm install
......
......@@ -51,7 +51,7 @@ If your external [Gitaly server listens over TLS port](https://docs.gitlab.com/e
you can make your GitLab instance communicate with it over TLS. To do this, you
have to
1. Create a kubernetes secret containing the certificate of the Gitaly
1. Create a Kubernetes secret containing the certificate of the Gitaly
server
```
......
# External nginx ingress controller
# External NGINX Ingress Controller
This chart configures `Ingress` resources for use with the official
[ingress-nginx](https://github.com/kubernetes/ingress-nginx) implementation. The
nginx ingress controller is deployed as a part of this chart. If you want to
reuse an existing nginx ingress controller already available in your cluster,
[NGINX Ingress](https://github.com/kubernetes/ingress-nginx) implementation. The
NGINX Ingress Controller is deployed as a part of this chart. If you want to
reuse an existing NGINX Ingress Controller already available in your cluster,
this guide will help.
## TCP services in the external ingress controller
## TCP services in the external Ingress Controller
The GitLab Shell component requires TCP traffic to pass through on
port 22 (by default; this can be changed). Ingress does not directly support TCP services, so some additonal configuration is necessary. Your nginx ingress controller may have been [deployed directly](https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md) (i.e. with a Kubernetes spec file) or through the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). The configuration of the TCP pass through will differ depending on the deployment approach.
port 22 (by default; this can be changed). Ingress does not directly support TCP services, so some additonal configuration is necessary. Your NGINX Ingress Controller may have been [deployed directly](https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md) (i.e. with a Kubernetes spec file) or through the [official Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress). The configuration of the TCP pass through will differ depending on the deployment approach.
### Direct deployment
In a direct deployment, the nginx ingress controller handles configuring TCP services with a
In a direct deployment, the NGINX Ingress Controller handles configuring TCP services with a
`ConfigMap` (see docs [here](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md)).
Assuming your GitLab chart is deployed to the namespace `gitlab` and your helm
Assuming your GitLab chart is deployed to the namespace `gitlab` and your Helm
release is named `mygitlab`, your `ConfigMap` should be something like this:
```
......@@ -27,8 +27,8 @@ data:
22: "gitlab/mygitlab-gitlab-shell:22"
```
After you have that `ConfigMap`, you can enable it as described in the nginx
ingress controller [docs](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md)
After you have that `ConfigMap`, you can enable it as described in the NGINX
Ingress Controller [docs](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md)
using the `--tcp-services-configmap` option.
```yaml
......@@ -37,12 +37,12 @@ args:
- --tcp-services-configmap=gitlab/tcp-configmap-example
```
Finally make sure that the `Service` for your nginx ingress controller is exposing
Finally make sure that the `Service` for your NGINX Ingress Controller is exposing
port 22 in addition to 80 and 443.
### Helm deployment
If you have installed or will install the nginx ingress controller via it's [Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), then you will need to add a value to the chart via the command line:
If you have installed or will install the NGINX Ingress Controller via it's [Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress), then you will need to add a value to the chart via the command line:
```bash
--set tcp.22="gitlab/mygitlab-gitlab-shell:22"
......@@ -57,19 +57,19 @@ tcp:
The format for the value is the same as describe above in the "Direct Deployment" section.
## Customize the GitLab ingress options
## Customize the GitLab Ingress options
The Nginx Ingress controller uses an annotation to mark which ingress controller
The NGINX Ingress Controller uses an annotation to mark which Ingress Controller
will service a particular `Ingress` (see [docs](https://github.com/kubernetes/ingress-nginx#annotation-ingressclass)).
You can configure the ingress class to use with this chart using the
`global.ingress.class` setting. Make sure to set this in your helm options.
You can configure the Ingress class to use with this chart using the
`global.ingress.class` setting. Make sure to set this in your Helm options.
```bash
--set global.ingress.class=myingressclass
```
While not necessarily required, if you're using an external ingress controller, you will likely want to
disable the ingress controller that is deployed by default with this chart:
While not necessarily required, if you're using an external Ingress Controller, you will likely want to
disable the Ingress Controller that is deployed by default with this chart:
```bash
--set nginx-ingress.enabled=false
......@@ -79,7 +79,7 @@ disable the ingress controller that is deployed by default with this chart:
The full scope of your TLS options are documented [elswhere](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/installation/tls.md).
If you are using an external ingress controller, you may also be using an external cert-manager instance
If you are using an external Ingress Controller, you may also be using an external cert-manager instance
or managing your certificates in some other custom manner. The full documentation around your TLS options is [here](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/installation/tls.md),
however for the purposes of this discussion, here are the two values that would need to be set to disable the cert-manager chart and tell
the GitLab component charts to NOT look for the built in certificate resources:
......
......@@ -40,7 +40,7 @@ For LFS, artifacts, uploads, packages and pseudonymizer an IAM role can be speci
```
For the [object-storage.yaml](../../charts/globals.md#connection) secret, omit the access and secret key.
As unicorn uses Fog for S3 storage, the [use_iam_profile](https://docs.gitlab.com/ee/administration/job_artifacts.html#s3-compatible-connection-settings) key should be added for Fog to use the role:
As Unicorn uses Fog for S3 storage, the [use_iam_profile](https://docs.gitlab.com/ee/administration/job_artifacts.html#s3-compatible-connection-settings) key should be added for Fog to use the role:
```yaml
provider: AWS
......
# Azure Minio Gateway
# Azure MinIO Gateway
[Minio](https://min.io/) is an object storage server that exposes S3-compatible APIs and it has a gateway feature that allows proxying requests to Azure Blob Storage. To setup our gateway, we will make use of Azure's Web App on Linux.
[MinIO](https://min.io/) is an object storage server that exposes S3-compatible APIs and it has a gateway feature that allows proxying requests to Azure Blob Storage. To setup our gateway, we will make use of Azure's Web App on Linux.
To get started, make sure you have installed Azure CLI and you are logged in (`az login`). Proceed to create a [Resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#resource-groups), if you don't have one already:
......@@ -38,7 +38,7 @@ The output should be in the format:
}
```
## Deploy Minio to Web App on Linux
## Deploy MinIO to Web App on Linux
First, we need to create an App Service Plan in the same resource group.
......@@ -51,7 +51,7 @@ az appservice plan create \
--location "WestUS"
```
Create a Web app configured with the [minio/minio](https://hub.docker.com/r/minio/minio) docker container, the name you specify will be used in the URL of the web app:
Create a Web app configured with the [`minio/minio`](https://hub.docker.com/r/minio/minio) docker container, the name you specify will be used in the URL of the web app:
```
az webapp create \
......
......@@ -5,7 +5,7 @@ By default, an S3-compatible storage solution named `minio` is deployed with the
chart, but for production quality deployments, we recommend using a hosted
object storage solution like Google Cloud Storage or AWS S3.
To disable minio, set this option and then follow the related documentation below:
To disable MinIO, set this option and then follow the related documentation below:
```
--set global.minio.enabled=false
......@@ -18,7 +18,7 @@ This documentation specifies usage of access and secret keys for AWS. It is also
## Azure Blob Storage
GitLab uses [fog](https://github.com/fog/fog), but [doesn't currently support fog-azure](https://gitlab.com/gitlab-org/gitlab-foss/issues/55624). To make use Azure Blob Storage, you will have to setup a [azure-minio gateway](./azure-minio-gateway.md).
GitLab uses [fog](https://github.com/fog/fog), but [doesn't currently support Fog Azure](https://gitlab.com/gitlab-org/gitlab-foss/issues/55624). To make use Azure Blob Storage, you will have to set up an [Azure MinIO gateway](azure-minio-gateway.md).
## Docker Registry images
......@@ -38,9 +38,9 @@ Create the secret per [registry chart documentation on storage](../../charts/reg
Examples for [S3](https://docs.docker.com/registry/storage-drivers/s3/)(any s3 compatible), [Azure](https://docs.docker.com/registry/storage-drivers/azure/) and [GCS](https://docs.docker.com/registry/storage-drivers/gcs/) drivers can be found in
[examples/objectstorage](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage).
- [registry.s3.yaml](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.s3.yaml)
- [registry.gcs.yaml](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.gcs.yaml)
- [registry.azure.yaml](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.azure.yaml)
- [`registry.s3.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.s3.yaml)
- [`registry.gcs.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.gcs.yaml)
- [`registry.azure.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.azure.yaml)
### Registry configuration
......@@ -95,12 +95,12 @@ See the [charts/globals documentaion on appConfig](../../charts/globals.md#confi
Create the secret(s) per the [connection details documentation](../../charts/globals.md#connection), and then configure the chart to use the provided secrets. Note, the same secret can be used for all of them.
Examples for [AWS][fog-aws](any S3 compatible like [Azure using Minio][minio-azure] ) and [Google][fog-gcs] providers can be found in
Examples for [AWS][fog-aws](any S3 compatible like [Azure using MinIO][minio-azure] ) and [Google][fog-gcs] providers can be found in
[examples/objectstorage](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage).
- [rails.s3.yaml](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.s3.yaml)
- [rails.gcs.yaml](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.gcs.yaml)
- [rails.azure.yaml](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.azure.yaml)
- [`rails.s3.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.s3.yaml)
- [`rails.gcs.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.gcs.yaml)
- [`rails.azure.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.azure.yaml)
[fog-aws]: https://fog.io/storage/#using-amazon-s3-and-fog
[fog-gcs]: https://fog.io/storage/#google-cloud-storage
......@@ -117,7 +117,7 @@ Examples for [AWS][fog-aws](any S3 compatible like [Azure using Minio][minio-azu
## Backups
Backups are also stored in object storage, and need to be configured to point
externally rather than the included minio service. The backup/restore procedure makes
externally rather than the included MinIO service. The backup/restore procedure makes
use of two separate buckets. A bucket for storing backups (`global.appConfig.backups.bucket`)
and a tmp bucket for preserving existing data during the restore process (`global.appConfig.backups.tmpBucket`).
Currently AWS S3-compatible object storage systems and Google Cloud Storage are supported backends
......
......@@ -21,7 +21,7 @@ Items below can be further customized if you are not using the defaults:
- `global.redis.port`: The port the database is available on, defaults to `6379`
For example, pass these values via helm's `--set` flag while deploying:
For example, pass these values via Helm's `--set` flag while deploying:
```
helm install . \
......
......@@ -4,6 +4,6 @@
- Using an [external Redis](external-redis/index.md)
- Using an [external Gitaly](external-gitaly/index.md)
- Using an [external object storage](external-object-storage/index.md)
- Using your own [Nginx ingress controller](external-nginx/index.md)
- Using your own [NGINX Ingress Controller](external-nginx/index.md)
- After install, [managing Persistent Volumes](persistent-volumes/index.md)
- Using [Red Hat UBI-based images](ubi/index.md)
......@@ -139,7 +139,7 @@ objects. For example: with expanding the disk storage size, the storage size
settings in the [PersistentVolumeClaim][pvc] will only be used when a new volume
resource is requested. So you would only need to increase the values in the
[PersistentVolumeClaim][pvc] if you intend to scale up more disks (for use in
additional gitaly pods).
additional Gitaly pods).
If you do need to have the changes reflected in Kubernetes, be sure that you've
updated your reclaim policy on the volumes as described in the [Before making storage changes](#before-making-storage-changes)
......@@ -429,19 +429,19 @@ Otherwise, if you have bound the claim to a new volume, move onto [apply the cha
## Apply the changes to the GitLab chart
After making changes to the [PersistentVolumes][pv] and [PersistentVolumeClaims][pvc],
you will also want to issue a helm update with the changes applied to the chart
you will also want to issue a Helm update with the changes applied to the chart
settings as well.
See the [installation storage guide](../../installation/storage.md#using-the-custom-storage-class)
for the options.
> **Note**: If you made changes to the Gitaly [volume claim][pvc], you will need to delete the
> Gitaly [StatefulSet][statefulset] before you will be able to issue a helm update. This is
> Gitaly [StatefulSet][statefulset] before you will be able to issue a Helm update. This is
> because the StatefulSet's Volume Template is immutable, and cannot be changed.
>
> You can delete the statefulset without deleting the Gitaly Pods:
> `kubectl --namespace <namespace> delete --cascade=false StatefulSet <release-name>-gitaly`
> The helm update command will recreate the StatefulSet, which will adopt and
> The Helm update command will recreate the StatefulSet, which will adopt and
> update the Gitaly pods.
Update the chart, and include the updated configuration:
......
......@@ -12,13 +12,13 @@ disable the internal services, and use external deployments or services.
The services that must be disabled and provided externally are:
- PostgreSQL
- Minio (Object Store)
- MinIO (Object Store)
- Redis
The services must be disabled are:
- CertManager (Let's Encrypt integration)
- Nginx Ingress
- NGINX Ingress
- Prometheus
- Grafana
- GitLab Runner
......
......@@ -29,10 +29,10 @@ The following GitLab components have images in the CNG repository.
- Gitaly
- GitLab Elasticsearch Indexer
- [mail_room](https://github.com/tpitale/mail_room)
- GitLab exporter
- GitLab Exporter
- GitLab Shell
- Sidekiq
- Gitlab task-runner
- GitLab task-runner
- Unicorn
- Workhorse
......@@ -69,23 +69,23 @@ At this high level, a customer can make decisions like:
- Whether they want to use the embedded Postgres chart, or to use an external
database like Amazon RDS for Postgres.
- To bring their own SSL certificates, or leverage Let's Encrypt.
- To use a load balancer, or a dedicated ingress.
- To use a load balancer, or a dedicated Ingress.
Customers who would like to get started quickly and easily should begin with this chart.
### Subcharts
The gitlab chart is made of multiple subcharts. These charts provide individual components of the GitLab software.
The GitLab chart is made of multiple subcharts. These charts provide individual components of the GitLab software.
Subcharts included are :
- [sidekiq](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/sidekiq)
- [unicorn](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/unicorn)
- [gitlab-shell](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/gitlab-shell)
- [gitaly](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/gitaly)
- [minio](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/minio)
- [redis](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/redis)
- [nginx](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/nginx)
- [Sidekiq](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/sidekiq)
- [Unicorn](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/unicorn)
- [GitLab Shell](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/gitlab-shell)
- [Gitaly](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/gitlab/charts/gitaly)
- [MinIO](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/minio)
- [Redis](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/redis)
- [NGINX](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/nginx)
- [registry](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/registry)
### Components list
......
......@@ -31,7 +31,7 @@ The sequence of execution is:
1. If the object storage backend is marked for skipping, skip this storage backend.
1. Tar the existing data in the corresponding object storage bucket naming it `<bucket-name>.tar`
1. Move the tar to the backup location on disk
1. Write a `backup_information.yml` file which contains some metadata identifying the version of gitlab, the time of the backup and the skipped items.
1. Write a `backup_information.yml` file which contains some metadata identifying the version of GitLab, the time of the backup and the skipped items.
1. Create a tar file containing individual tar files along with `backup_information.yml`
1. Upload the resulting tar file to object storage `gitlab-backups` bucket.
......@@ -50,8 +50,8 @@ of your artifacts by setting the `BACKUP_BACKEND` environment variable to `gcs`.
### Restore
The backup utility when given an argument `--restore` attempts to restore from an existing backup to the running instance. This
backup can be from either an omnibus-gitlab or a CNG Helm chart installation given that both the instance that was
backed up and the running instance runs the same version of gitlab. The restore expects a file in backup bucket using `-t <backup-name>` or a remote url using `-f <url>`.
backup can be from either an Omnibus GitLab or a CNG Helm chart installation given that both the instance that was
backed up and the running instance runs the same version of GitLab. The restore expects a file in backup bucket using `-t <backup-name>` or a remote url using `-f <url>`.
When given a `-t` parameter it looks into backup bucket in object storage for a backup tar with such name. When
given a `-f` parameter it expects that the given url is a valid uri of a backup tar in a location accessible from the container.
......
......@@ -19,7 +19,7 @@ Introduced in [!757 checkConfig: add methods to test for known errors](https://g
During the development of these charts, we occasionally make improvements that require
alterations to the properties of existing deployments. Two examples were the centralization
of configuring the use of Minio, and the migration of external object storage configuration
of configuring the use of MinIO, and the migration of external object storage configuration
from properties to secrets (in observance of our preference).
As a means of preventing a user from accidentally deploying an updated version of these
......@@ -28,7 +28,7 @@ have chosen to implement [deprecation](../development/index.md#handling-configur
properties have have been relocated, altered, replaced, or removed entirely, then inform
the user of what changes need to be made to the configuration. This may include informing
the user to see documentation on how to replace a property with a secret. These notifications
will cause the helm `install` or `upgrade` commands to stop with a parse error, and output a complete list of items that need to be addressed. We have taken care to ensure a user will not be placed into a loop of error, fix, repeat.
will cause the Helm `install` or `upgrade` commands to stop with a parse error, and output a complete list of items that need to be addressed. We have taken care to ensure a user will not be placed into a loop of error, fix, repeat.
All deprecations must be addressed in order for a successful deployment to occur. We believe
the user would prefer to be informed of a breaking change over experiencing unexpected
......@@ -105,20 +105,20 @@ Related issue:
The following charts have been forked or re-created in this repository following
our [guidelines for forking](../development/index.md#guidelines-for-forking)
### redis
### Redis
Our [redis chart](../charts/redis/index.md) was altered from upstream [redis](https://github.com/helm/charts/tree/master/stable/redis).
Our [Redis chart](../charts/redis/index.md) was altered from the upstream [Redis](https://github.com/helm/charts/tree/master/stable/redis).
- Populate the password directly into the `redis.conf` instead of via Environment
- Make use of pre-existing Kubernetes secrets instead of creating new ones from properties.
### redis-ha
### Redis HA
Our [redis-ha chart](../charts/redis-ha/index.md) was altered from upstream [redis-ha](https://github.com/helm/charts/tree/master/stable/redis-ha).
Our [Redis HA chart](../charts/redis-ha/index.md) was altered from the upstream [Redis HA](https://github.com/helm/charts/tree/master/stable/redis-ha).
### minio
### MinIO
Our [minio chart](../charts/minio/index.md) was altered from upstream [minio](https://github.com/helm/charts/tree/master/stable/minio).
Our [MinIO chart](../charts/minio/index.md) was altered from the upstream [MinIO](https://github.com/helm/charts/tree/master/stable/minio).
- Make use of pre-existing Kubernetes secrets instead of creating new ones from properties.
- Remove providing the sensitive keys via Environment.
......@@ -127,14 +127,14 @@ Our [minio chart](../charts/minio/index.md) was altered from upstream [minio](ht
### registry
Our [registry chart](../charts/registry/index.md) was altered from upstream [docker-registry](https://github.com/helm/charts/tree/master/stable/docker-registry).
Our [registry chart](../charts/registry/index.md) was altered from the upstream [docker-registry](https://github.com/helm/charts/tree/master/stable/docker-registry).
- Enable the use of in-chart Minio services automatically.
- Enable the use of in-chart MinIO services automatically.
- Automatically hook authentication to the GitLab services.
### nginx-ingress
### NGINX Ingress
Our [nginx-ingress chart](../charts/nginx/index.md) was altered from upstream [nginx-ingress](https://github.com/helm/charts/tree/master/stable/nginx-ingress).
Our [NGINX Ingress chart](../charts/nginx/index.md) was altered from the upstream [NGINX Ingress](https://github.com/helm/charts/tree/master/stable/nginx-ingress).
- Add feature to allow for the tcp configmap to be external to the chart
- Add feature to allow ingress class to be templated based on release name
- Add feature to allow Ingress class to be templated based on release name
......@@ -61,7 +61,7 @@ are per pod.
- memory: 1.2G
- **Stressful Task**
- Loading large MR diff (gitlab-ce master to 10-0-stable)
- Loading large MR diff (`gitlab-ce master` to `10-0-stable`)
- cpu: 400m
- memory: 1.4G
......@@ -81,7 +81,7 @@ are per pod.
### Sidekiq
Load was tested using <https://gitlab.com/andrewn/gitlab-load-kit> and a custom executor that targeted the pipeline trigger api on a single project. This api was hit with 20 requests concurrently for varying amounts of time.
Load was tested using <https://gitlab.com/andrewn/gitlab-load-kit> and a custom executor that targeted the pipeline trigger API on a single project. This API was hit with 20 requests concurrently for varying amounts of time.
- **Idle values**
- 0 tasks, 1 pods
......
......@@ -13,11 +13,11 @@ Technical details for how the utility works can be found in the [architecture do
## Object storage
We provide a minio instance out of the box when using this charts unless an [external object storage](../advanced/external-object-storage/index.md) is specified. The default behavior of the task-runner pod defaults to connect to our minio unless specific settings are given. The task-runner can also be configured to back up to Amazon S3 or Google Cloud Storage (GCS).
We provide a MinIO instance out of the box when using this charts unless an [external object storage](../advanced/external-object-storage/index.md) is specified. The default behavior of the task-runner pod defaults to connect to our MinIO unless specific settings are given. The task-runner can also be configured to back up to Amazon S3 or Google Cloud Storage (GCS).
### Backups to S3
The task-runner uses `s3cmd` to connect to object storage. In order to configure connectivity to external object storage `gitlab.task-runner.backups.objectStorage.config.secret` should be specified which points to a kubernetes secret containing a `.s3cfg` file. `gitlab.task-runner.backups.objectStorage.config.key` should be specified if different from the default of `config`. This points to the key containing the contents of a .s3cfg file.
The task-runner uses `s3cmd` to connect to object storage. In order to configure connectivity to external object storage `gitlab.task-runner.backups.objectStorage.config.secret` should be specified which points to a Kubernetes secret containing a `.s3cfg` file. `gitlab.task-runner.backups.objectStorage.config.key` should be specified if different from the default of `config`. This points to the key containing the contents of a .s3cfg file.
It should look like this:
......@@ -81,7 +81,7 @@ when restoring a backup.
As the backups are assembled locally outside of the object storage target, temporary disk space is needed. The required space might exceed the size of the actual backup archive.
The default configuration will use the task-runner pod's file system to store the temporary data. If you find pod being evicted due to low resources, you should attach a persistent volume to the pod to hold the temporary data.
On GKE, add the following settings to your helm command:
On GKE, add the following settings to your Helm command:
```
--set gitlab.task-runner.persistence.enabled=true
......
# Restoring a GitLab installation
> To obtain a backup tarball of an existing GitLab instance that used other installation methods like an omnibus-gitlab package or GitLab-Omnibus helm chart, follow the instructions [given in documentation](https://docs.gitlab.com/ee/raketasks/backup_restore.html#creating-a-backup-of-the-gitlab-system)
> To obtain a backup tarball of an existing GitLab instance that used other installation methods like an Omnibus GitLab package or Omnibus GitLab Helm chart, follow the instructions [given in documentation](https://docs.gitlab.com/ee/raketasks/backup_restore.html#creating-a-backup-of-the-gitlab-system)
>
> **Note**: If you are restoring a backup taken from another instance, you must migrate your existing instance to using object storage before taking the backup. See [issue 646](https://gitlab.com/gitlab-org/charts/gitlab/issues/646)
......@@ -99,7 +99,7 @@ kubectl delete pods -lapp=unicorn,release=<helm release name>
The restoration process does not update the `gitlab-initial-root-password` secret with the value from backup. For logging in as `root`, use the original password included in the backup. In the case that the password is no longer accessible, follow the steps below to reset it.
1. Attach to the unicorn pod by executing the command
1. Attach to the Unicorn pod by executing the command
```bash
kubectl exec <unicorn pod name> -it bash
......
......@@ -76,7 +76,7 @@ changes.
- **Bad:** Strip out `nil`s in the Array of Commit objects returned from
`find_commits_by_message_with_elastic`
- **Good:** Fix 500 errors caused by elasticsearch results referencing
- **Good:** Fix 500 errors caused by Elasticsearch results referencing
garbage-collected commits
The first example focuses on _how_ we fixed something, not on _what_ it fixes.
......
# checkConfig template
The purpose of this template is to provide a means to prevent users from deploying the helm chart, or updates to it, in what would be a broken state due to known problematic configurations.
The purpose of this template is to provide a means to prevent users from deploying the Helm chart, or updates to it, in what would be a broken state due to known problematic configurations.
The design makes use of multiple templates, providing a modular method of declaring and managing checks. This is to aid in simplification of both development and maintenance.
......
......@@ -18,9 +18,9 @@ git checkout <BRANCH_NAME>
> is very easy to miss the leading slash on the filepath.
Other steps from the [installation documentation](../installation/index.md) still apply. The difference is when deploying
a development branch, you need to update the local dependencies, and pass the local git repo location to the helm command.
a development branch, you need to update the local dependencies, and pass the local Git repo location to the Helm command.
From within your git checkout of the repo, run the following helm commands to install:
From within your Git checkout of the repo, run the following Helm commands to install:
```sh
helm repo add gitlab https://charts.gitlab.io/
......
# Deprecations template
The purpose of this template is to provide a means to prevent users from deploying the helm chart, or updates to it, in what would be a broken state due to changes in how the chart is configured.
The purpose of this template is to provide a means to prevent users from deploying the Helm chart, or updates to it, in what would be a broken state due to changes in how the chart is configured.
The design makes use of multiple templates, providing a modular method of declaring and managing deprecations. This is to aid in simplification of both development and maintenance.
......
......@@ -12,7 +12,7 @@ All `CHANGELOG.md` entries should be created via the [changelog entries](changel
## Installation from Repo
Details on installing from the git repo can be found in the [developer deployment](deploy.md) documentation.
Details on installing from the Git repo can be found in the [developer deployment](deploy.md) documentation.
## Running GitLab QA
......@@ -24,7 +24,7 @@ deployed cloud native GitLab installation.
## Kube monkey
[kube monkey](https://github.com/asobti/kube-monkey) is an implementation of
Netflix's [chaos monkey](https://github.com/Netflix/chaosmonkey) for kubernetes
Netflix's [chaos monkey](https://github.com/Netflix/chaosmonkey) for Kubernetes
clusters. It schedules randomly killing of pods in order to test fault tolerance
of a highly available system.
......@@ -45,11 +45,11 @@ Template functions are placed into namespaces according to the chart they are as
Examples:
- `gitlab.redis.host`: provides the host name of the Redis server, as a part of the `gitlab` chart.
- `registry.minio.url`: provides the URL to the Minio host as part of the `registry` chart.
- `registry.minio.url`: provides the URL to the MinIO host as part of the `registry` chart.
## Common structure for values.yaml
Many charts need to be provided with the same information, for example we need to provide the redis and postgres connection settings to multiple charts. Here we outline our standard naming and structure for those settings.
Many charts need to be provided with the same information, for example we need to provide the Redis and postgres connection settings to multiple charts. Here we outline our standard naming and structure for those settings.
### Connecting to other services
......@@ -87,7 +87,7 @@ We use secrets to store sensitive information like passwords and share them amon
The common fields we use them in are:
- **Certificates** - TLS certificates for the registry etc.
- **Passwords** - Sharing the redis password.
- **Passwords** - Sharing the Redis password.
- **Auth Tokens** - Sharing the inter-service auth tokens
### Certificates
......@@ -316,7 +316,7 @@ the registry. You can either [add the certificate](https://docs.docker.com/regis
[expose the registry over HTTP](https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry) (see `global.hosts.registry.https`).
Note that adding the certificate is more secure than the insecure registry solution.
Please keep in mind that Registry uses the external domain name of Minio service (see `global.hosts.minio.name`). You may
Please keep in mind that Registry uses the external domain name of MinIO service (see `global.hosts.minio.name`). You may
encounter an error when using internal domain names, e.g. with custom TLDs for development environment. The common symptom
is that you can login to the Registry but you can't push or pull images. This is generally because the Registry container(s)
can not resolve the Minio domain name and find the correct endpoint (you can see the errors in container logs).
can not resolve the MinIO domain name and find the correct endpoint (you can see the errors in container logs).
# Kube monkey
[kube monkey](https://github.com/asobti/kube-monkey) is an implementation of
Netflix's [chaos monkey](https://github.com/Netflix/chaosmonkey) for kubernetes
Netflix's [chaos monkey](https://github.com/Netflix/chaosmonkey) for Kubernetes
clusters. It schedules randomly killing of pods in order to test fault tolerance
of a highly available system.
......@@ -28,7 +28,7 @@ file. For more info read the official [kube monkey docs](https://github.com/asob
## Usage
The [GKE bootstrap script](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/gke_bootstrap_script.sh)
The [gke_bootstrap_script.sh](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/gke_bootstrap_script.sh)
takes an argument `chaos` which installs and unleashes kube monkey by
scheduling a run 60s after installing kube monkey by default. It also sets up
the needed service account and role if RBAC is enabled.
......
......@@ -155,7 +155,7 @@ For further details on Helm, see [Developing for Helm](../../installation/tools.
When deploying this chart into minikube, some chart resources need to be reduced or disabled.
It is not possible to use the `nginx-ingress` chart to provide ports `22`, `80`,
`443`. It's best to disable it and set the ingress class by setting
`443`. It's best to disable it and set the Ingress class by setting
`nginx-ingress.enabled=false,global.ingress.class="nginx"`.
The `certmanager` chart can not be used with minikube. You must disable this by
......
......@@ -9,7 +9,7 @@ and should perform the setup the day prior to the demo itself:
- [GKE setup](#gke-setup)
- [External resources](#external-resources)
- [Omniauth for Google OAuth2](#omniauth-for-google-oauth2)
- [OmniAuth for Google OAuth2](#omniauth-for-google-oauth2)
## GKE setup
......@@ -91,7 +91,7 @@ properties section of the global chart.
### Redis
Preparation of chart-external Redis services (as a pet or SaaS), can
be found in [advanced/external-redis](../../advanced/external-redis/index.md).
be found in [`advanced/external-redis`](../../advanced/external-redis/index.md).
This can be done as documented there. Once that is configured, the chart should
be configured with the external service by making use of the `globals.redis`
properties section of the global chart.
......@@ -99,15 +99,15 @@ properties section of the global chart.
### Gitaly
Preparation of chart-external Gitaly services can
be found in [advanced/external-gitaly](../../advanced/external-gitaly/index.md).
be found in [`advanced/external-gitaly`](../../advanced/external-gitaly/index.md).
This can be done as documented there. Once that is configured, the chart should
be configured with the external service by making use of the `globals.gitaly`
properties section of the global chart.
## Omniauth for Google OAuth2
## OmniAuth for Google OAuth2
Configuring a deployment with the capability to integrate with GKE requires
the use of Omniauth. You will need to ensure that a set of
the use of OmniAuth. You will need to ensure that a set of
**OAuth Client ID** credentials have been created for the hostname of the GitLab
endpoint in your cluster.
......
......@@ -8,7 +8,7 @@ Major releases will be for breaking changes **and** significant milestones in th
We will bump it for:
- significant additions/changes (let's say we add pages by default, or we drop nginx completely)
- significant additions/changes (let's say we add pages by default, or we drop NGINX completely)
- breaking changes in GitLab or in the charts (requiring manual interaction to your existing install to upgrade)
- Major updates in the GitLab image. (the release of 12.0.0)
......@@ -53,7 +53,7 @@ We will bump it for:
### Future iteration
While we considered just using the GitLab version as our own, we are not yet in lockstep with gitlab releases to the point where we would make a breaking change here in the chart, and require gitlab to bump the version number to 12 for instance. For now we will move forward with a chart specific version scheme, until we get to the point where we have the charts stable enough that we are comfortable with sharing the same version, and a chart update being a reasonable reason to bump GitLab's core version.
While we considered just using the GitLab version as our own, we are not yet in lockstep with GitLab releases to the point where we would make a breaking change here in the chart, and require GitLab to bump the version number to 12 for instance. For now we will move forward with a chart specific version scheme, until we get to the point where we have the charts stable enough that we are comfortable with sharing the same version, and a chart update being a reasonable reason to bump GitLab's core version.
## Branches and Tags
......@@ -91,7 +91,7 @@ Related to releasing using the proposed branching strategy
## Releasing the chart
Releasing a new version of the chart is handled by the helm release tasks in the [release tools repo](https://gitlab.com/gitlab-org/release-tools)
Releasing a new version of the chart is handled by the Helm release tasks in the [release tools repo](https://gitlab.com/gitlab-org/release-tools)
By default, this task will be automatically run from CI when a new release image is tagged in the [CNG image repo](https://gitlab.com/gitlab-org/build/CNG)
......@@ -111,9 +111,9 @@ git clone git@gitlab.com:gitlab-org/release-tools.git
bundle install
```
Then run the appropriate helm release task:
Then run the appropriate Helm release task:
- When you want to release without changing the gitlab app version, call the release task with the new chart version (eg `0.2.1`)
- When you want to release without changing the GitLab app version, call the release task with the new chart version (eg `0.2.1`)
- `bundle exec rake helm:tag_chart[0.2.1]`
- When you want to release and change both the chart version and the app version (eg `0.2.1` with GitLab `11.0.1`)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment