lwolf / gitlab-chart Goto Github PK

View Code? Open in Web Editor NEW

58.0 5.0 16.0 80 KB

Kubernetes Helm chart to deploy GitLab

Smarty 61.35% Shell 38.65%

gitlab gitlab-ci gitlab-runner helm-charts kubernetes minio docker-registry

gitlab-chart's People

Contributors

Stargazers

Watchers

Forkers

eduardocardoso 40a rimusz-lab ipaste barathvk weisjohn dand-oss benjscohen exfly sumhua xinsun-leo stainlessai manishalankala dinhvandinhtu openeye0 reinaldoca

gitlab-chart's Issues

Issue with the 'helm dep build' command

I'm using the instructions described here:

https://blog.lwolf.org/post/fully-automated-gitlab-installation-on-kubernetes-including-runner-and-registry/

When I run the helm dep build command, I get the following error:

Error: requirements.lock is out of sync with requirements.yaml

Should I run a helm dep updatebefore ?

couldn't find type: v1beta1.Job

Hello,

I'm getting the following error when installing the chart:
Error: error validating "": error validating data: couldn't find type: v1beta1.Job

I guess it is related to the file: gitlab/charts/runner/templates/registrator.yaml

Kubelet Version:
v1.6.2+coreos.0

Make ingress paths configurable

Hello,

I really like the great amount of configuration options with this chart.
Could you also add an option to change the ingress paths?

I want to be able to make an ingress like:
mysite.com/gitlab

Thank you!

kube-lego tls recursion

I am having issues with tls integration with kube-lego following the blog.

ACME account registration is successful.
and I have config.LEGO_URL=https://acme-v01.api.letsencrypt.org/directory for production

level=warning msg="authorization failed after 1m0s: reachability test failed: Get https://gitlab.mydomain.com/users/sign_in: dial tcp x.x.x.x:443: getsockopt: connection refused" context=acme domain=gitlab.mydomain.com

It seems as though the gitlab redirect is failing because it has no tls cert.
kube-lego seems to try reaching https://gitlab.mydomain.com which fails because of the redirect.

Did you say recursion? :)

support k8s v1.16

trying this helm chart w/ k8s v1.16 gives the following results:

λ helm install --name gitlab -f values-test.yml --dry-run
Error: [unable to recognize "": no matches for kind "Deployment" in version "apps/v1beta2", unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"]

Nginx entered FATAL state

Hi guys,

I've got some problems with the chart installation.

version: 0.2.5

After deploying gitlab

helm install -f value-test.yaml lwolf-charts/gitlab --name gitlab --namespace=gitlab

With those values

serviceType: NodePort

sshPort: 22
httpPort: 80
httpsPort: 443


ingress:
  enabled: false
  configNamespaceOverride: "default"

  ## Gitlab Ingress annotations
  ##
  annotations:
    kubernetes.io/ingress.class: nginx
    kubernetes.io/tls-acme: 'true'

  ## Gitlab Ingress hostnames
  ## Must be provided if Ingress is enabled
  ##
  hosts:
    - gitlab.example.com

  ## Gitlab Ingress TLS configuration
  ## Secrets must be manually created in the namespace
  ##
  tls:
    - secretName: gitlab-server-tls
      hosts:
        - gitlab.example.com

persistence:
  ## This volume persists generated configuration files, keys, and certs.
  ##
  enabled: true
  size: 1Gi
  ## If defined, volume.beta.kubernetes.io/storage-class: <storageClass>
  ## Default: volume.alpha.kubernetes.io/storage-class: default
  ##
  # storageClass: standard
  # storageClass: "slow"
  # accessMode: ReadWriteOnce


postgresql:
  image: "postgres"
  imageTag: "9.6.3-alpine"
  persistence:
    enabled: true
    # storageClass: "slow"
    size: 1Gi

redis:
  image: redis:3.2.9-alpine
  persistence:
    enabled: true
    # storageClass: "slow"
    size: 1Gi

minio:
  imagePullPolicy: "IfNotPresent"
  accessKey: "AKIAIOSFODNN7EXAMPLE"
  secretKey: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  persistence:
    enabled: true
    # storageClass: "slow"
    size: 2Gi

config:
  DEBUG: "true"
  GITLAB_ROOT_EMAIL: "[email protected]"

  GITLAB_ROOT_PASSWORD: "3Uhprz35WEYCmebz56dyvLciwvzQxz"
  GITLAB_SECRETS_DB_KEY_BASE: "kCFSUsLlyZETCpStxxKG"
  GITLAB_SECRETS_SECRET_KEY_BASE: "gPL3l6dQ4FXo6a9fwa6I"
  GITLAB_SECRETS_OTP_KEY_BASE: "SVEHkkfIViQ4xDuNN8LM"

  GITLAB_HOST: gitlab.example.com
  GITLAB_PORT: 443
  GITLAB_TIMEZONE: "America/Martinique"
  GITLAB_SHARED_RUNNERS_REGISTRATION_TOKEN: "186f6cdcb713adEXAMPLETOKEN"

  GITLAB_SSH_HOST: "git.example.com"
  GITLAB_SSH_PORT: "22"


  SMTP_ENABLED: false
  SMTP_DOMAIN: gitlab.example.com
  SMTP_HOST: smtp.mailgun.org
  SMTP_PORT: "587"
  SMTP_USER: admin
  SMTP_PASS: password
  SMTP_STARTTLS: "true"
  SMTP_AUTHENTICATION: login

  GITLAB_REGISTRY_ENABLED: true
  GITLAB_REGISTRY_HOST: dhub.example.com
  GITLAB_REGISTRY_PORT: 443
  GITLAB_REGISTRY_API_URL: https://dhub.example.com
  GITLAB_REGISTRY_KEY_PATH: /certs/tls.key
  SSL_REGISTRY_KEY_PATH: /certs/tls.key
  SSL_REGISTRY_CERT_PATH: /certs/tls.crt


runner:
  enabled: true
  image: gitlab/gitlab-runner:alpine-v9.2.2
  gitlabUrl: "https://gitlab.example.com/ci/"
  registrationToken: "186f6cdcb713adEXAMPLETOKEN"
  cache:
    enabled: true
    accessKey: "AKIAIOSFODNN7EXAMPLE"
    secretKey: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

registry:
  enabled: true
  authTokenRealm: "https://gitlab.example.com/jwt/auth"
  ingress:
    enabled: false
    annotations:
      kubernetes.io/ingress.class: nginx
      kubernetes.io/tls-acme: 'true'
    hosts:
      - dhub.example.com

  persistence:
    enabled: true
    size: 2Gi

See namespace content after deployement

See the gitlab-gitlab pod description

I've got this error inside gitlab-gitlab pod container

How i can solve this problem ?
Where i made a mistake ?

Deployment on Azure

Hi,

I'm trying out this chart on a Kubernetes cluster running in Microsoft Azure.
Changed the "slow" storageclass to "default.

All pvc are mounted.

I want to get Gitlab auto-deploy running with d2d image. for this the container registry of Gitlab is required. I got gitlab and the runner working via seperate charts. As Kubernetes is new to me, can somebody tell me how to create the gitlab container registry? Do I need a nginx-ingress?

Persistent Volumes for gitlab - what to do if you run out of space?

What would a be good approach to fix storage issues when your services run out of the presistent volume free space?

For example I have a gitlab service running on kubernetes installed with the helm chart. I have used the default settings, but now I ran out of free space (theoretically atm, but its inevitable at some point) for gitlab. What would be the ideal approach to fix this issue?

Is there anyway I can increase the PV in size?
Should I somehow backup the gitlab data, recreate it with more storage?
Can I somehow backup and restore data from PV-s so there is no dataloss?
Thank you for your answers, Bence Pjatacsuk

"helm dep build" fails if requirements.yaml contains local dependencies and remote one

Hello

I have a chart that contains two dependencies, one is located in our internal helm registry, one is copied into the charts sub-directory. I can either use "helm dep build" with only the one from the registry or the local one, but not in combination:

$ tree .
|-- Chart.yaml
|-- README.md
|-- charts
|   `-- oraclepdb
|       |-- Chart.yaml
|       `-- templates
|           `-- oraclepdb.yaml
|-- requirements.yaml
|-- templates
|   |-- _helpers.tpl
|   |-- deployment.yaml
|   |-- ingress.yaml
|   |-- secrets.yaml
|   `-- svc.yaml
`-- values.yaml

The helm registry is added:

$ helm repo list
NAME    URL
stable  https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts
mobi    https://git.bitbucket.server/projects/K8S/repos/charts/raw

Using this requirements yaml:

$ more requirements.yaml
dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql
  - name: oraclepdb
    version: 0.0.1

and then "helm dep list"

NAME            VERSION REPOSITORY      STATUS
mobi-postgresql 1.0.1   @mobi           missing
oraclepdb       0.0.1                   unpacked

then trying "helm dep update" fails:

Error: no repository definition for . Please add them via 'helm repo add'
Note that repositories must be URLs or aliases. For example, to refer to the stable
repository, use "https://kubernetes-charts.storage.googleapis.com/" or "@stable" instead of
"stable". Don't forget to add the repo, too ('helm repo add').

for some reason the sub-chart in charts is no longer a local one.

Just using this requirements.yaml and running "helm dep update" works:

dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql

It also works if both sub-charts are copied and extracted already.

I tried pointing to the file using this requirements.yaml:

dependencies:
  - name: mobi-postgresql
    version: 1.0.1
    repository: "@mobi"
    alias: postgresql
  - name: oraclepdb
    version: 0.0.1
    repository: "file://./charts/"

$ helm dep list
NAME            VERSION REPOSITORY              STATUS
mobi-postgresql 1.0.1   @mobi                   missing
oraclepdb       0.0.1   file://./charts/        unpacked

$ helm dep build
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "mobi" chart repository
...Successfully got an update from the "stable" chart repository
...Unable to get an update from the "local" chart repository (http://127.0.0.1:8879/charts):
        Get http://127.0.0.1:8879/charts/index.yaml: dial tcp 127.0.0.1:8879: connectex: No connection could be made because the target machine actively refused it.
Update Complete. ⎈Happy Helming!⎈
Saving 2 charts
Downloading mobi-postgresql from repo https://git.mobi.mobicorp.ch/projects/K8S/repos/charts/raw
Save error occurred:  chart metadata (Chart.yaml) missing
Deleting newly downloaded charts, restoring pre-update state
Error: chart metadata (Chart.yaml) missing

this does not download the mobi-postgresql file anymore.

So currently I can only use remote charts or both within the charts sub-directory. But mixing them havong one from remote and one unpacked (in case some chart does not yet offer some values, so we temporarly copy them) does somehow not work.

using helm 2.8.2 on windows.

Is there a workaround?

When I clone the project, cd into the project, and then run:

cp chart/values.yaml values-test.yaml

It will error off because there is not a chart directory in the main directory. So.... I though it may be:

cp gitlab/values.yaml values-test.yaml

Then it gives a new error when I do a dry run: Error: no Chart.yaml exists in directory ...

So I am wondering if there are a few changes that are not reflected yet in the docs??

update chart to 10.7.2

add support for new params:

[10.5]

Add GITLAB_UPLOADS_STORAGE_PATH
Add GITLAB_UPLOADS_BASE_DIR
Add LDAP_LOWERCASE_USERNAMES

[10.7]

GITLAB_SIDEKIQ_LOG_FORMAT
GITLAB_ARTIFACTS_OBJECT_STORE_ENABLED
GITLAB_ARTIFACTS_OBJECT_STORE_REMOTE_DIRECTORY
GITLAB_ARTIFACTS_OBJECT_STORE_BACKGROUND_UPLOAD
GITLAB_ARTIFACTS_OBJECT_STORE_PROXY_DOWNLOAD
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_PROVIDER
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_AWS_ACCESS_KEY_ID
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_AWS_SECRET_ACCESS_KEY
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_AWS_REGION
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_AWS_HOST
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_AWS_ENDPOINT
GITLAB_ARTIFACTS_OBJECT_STORE_CONNECTION_AWS_PATH_STYLE
GITLAB_LFS_OBJECT_STORE_ENABLED
GITLAB_LFS_OBJECT_STORE_REMOTE_DIRECTORY
GITLAB_LFS_OBJECT_STORE_DIRECT_UPLOAD
GITLAB_LFS_OBJECT_STORE_BACKGROUND_UPLOAD
GITLAB_LFS_OBJECT_STORE_PROXY_DOWNLOAD
GITLAB_LFS_OBJECT_STORE_CONNECTION_PROVIDER
GITLAB_LFS_OBJECT_STORE_CONNECTION_AWS_ACCESS_KEY_ID
GITLAB_LFS_OBJECT_STORE_CONNECTION_AWS_SECRET_ACCESS_KEY
GITLAB_LFS_OBJECT_STORE_CONNECTION_AWS_REGION
GITLAB_LFS_OBJECT_STORE_CONNECTION_AWS_HOST
GITLAB_LFS_OBJECT_STORE_CONNECTION_AWS_ENDPOINT
GITLAB_LFS_OBJECT_STORE_CONNECTION_AWS_PATH_STYLE
GITLAB_UPLOADS_OBJECT_STORE_ENABLED
GITLAB_UPLOADS_OBJECT_STORE_REMOTE_DIRECTORY
GITLAB_UPLOADS_OBJECT_STORE_DIRECT_UPLOAD
GITLAB_UPLOADS_OBJECT_STORE_BACKGROUND_UPLOAD
GITLAB_UPLOADS_OBJECT_STORE_PROXY_DOWNLOAD
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_PROVIDER
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_AWS_ACCESS_KEY_ID
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_AWS_SECRET_ACCESS_KEY
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_AWS_REGION
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_AWS_HOST
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_AWS_ENDPOINT
GITLAB_UPLOADS_OBJECT_STORE_CONNECTION_AWS_PATH_STYLE