Error registering runner failed

I’ve setup my gitlab installation from source, secured it with letsencrypt and deployed it under https://gitlab.mydomain.com. I can access the website and create repositories, etc. but I can’t find a way to register a gitlab ci runner for the installation.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci):
https://gitlab.mydomain.com/ci
Please enter the gitlab-ci token for this runner:
xxxxxxxx-xxxxxxxx
Please enter the gitlab-ci description for this runner:
[server]: test
Please enter the gitlab-ci tags for this runner (comma separated):
test
ERROR: Registering runner... failed     runner=xxxxxxx 
status=couldn't execute POST against https://gitlab.mydomain.com/ci/api/v1/runners/register.json:
Post https://gitlab.mydomain.com/ci/api/v1/runners/register.json: 
read tcp [ipv6address]:33518->[ipv6address]:443: read: connection reset by peer
PANIC: Failed to register this runner. Perhaps you are having network problems

My gitlab system is working fine and I really ran out of explanations why there would be a connection reset by peer. When I try to curl the address from the error message directly, it returns a correct response.

curl -v https://gitlab.mydomain.com/ci/api/v1/runners/register.json
*   Trying ipv6address...
* Connected to gitlab.mydomain.com (ipv6address) port 443 (#0)
* found 174 certificates in /etc/ssl/certs/ca-certificates.crt
* found 700 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: mydomain.com (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=mydomain.com
*        start date: Wed, 18 May 2016 14:35:00 GMT
*        expire date: Tue, 16 Aug 2016 14:35:00 GMT
*            issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
*        compression: NULL
* ALPN, server did not agree to a protocol
> GET /ci/api/v1/runners/register.json HTTP/1.1
> Host: gitlab.mydomain.com
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 405 Method Not Allowed
< Server: nginx
< Date: Sun, 29 May 2016 09:14:09 GMT
< Content-Type: application/json
< Content-Length: 2
< Connection: keep-alive
< Allow: OPTIONS, POST
< Cache-Control: no-cache
< Status: 405 Method Not Allowed

version: '2'

networks:
  lb_web:
    external: true
  back:
    driver: bridge


services:
  redis:
    restart: always
    image: sameersbn/redis:latest
    container_name: redis
    command:
    - --loglevel warning
    volumes:
    - /srv/docker/gitlab/redis:/var/lib/redis:Z
    networks:
    - back

  postgresql:
    restart: always
    image: sameersbn/postgresql:9.6-2
    container_name: postgresql
    volumes:
    - /srv/docker/gitlab/postgresql:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm
    networks:
    - back

  gitlab:
    restart: always
    image: sameersbn/gitlab:8.16.6
    container_name: gitlab
    depends_on:
    - redis
    - postgresql
    external_links: 
    - registry:registry.localhost
    expose:
        - "80"
    ports:
    - "10022:22"
    - "10443:443"
    - "5005:5005"
    volumes:
    - /srv/docker/gitlab/gitlab:/home/git/data:Z
    - /srv/docker/gitlab/gitlab/certs:/home/git/data/certs
    - /srv/docker/gitlab/logs:/var/log/gitlab
    - /var/run/docker.sock:/var/run/docker.sock
    hostname: localhost
    environment:   
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=America/Los_Angeles
    - GITLAB_TIMEZONE=America/Los_Angeles

    - GITLAB_HTTPS=true
    - SSL_SELF_SIGNED=true

    - GITLAB_HOST=localhost
    - GITLAB_PORT=10443
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=
    - GITLAB_SECRETS_DB_KEY_BASE=xxxxxxxx
    - GITLAB_SECRETS_SECRET_KEY_BASE=xxxxxxx
    - GITLAB_SECRETS_OTP_KEY_BASE=xxxxxx
    - GITLAB_ROOT_PASSWORD=xxxxx
    - GITLAB_ROOT_EMAIL=xxxx@gmail.com

    - GITLAB_NOTIFY_ON_BROKEN_BUILDS=true
    - GITLAB_NOTIFY_PUSHER=true


    - GITLAB_EMAIL=xxxxx@gmail.com
    - GITLAB_EMAIL_REPLY_TO=xxxxxx@gmail.com
    - GITLAB_INCOMING_EMAIL_ADDRESS=xxxxxx@gmail.com

    - GITLAB_BACKUP_SCHEDULE=daily
    - GITLAB_BACKUP_TIME=01:00

    - SMTP_ENABLED=true
    - SMTP_DOMAIN=www.gmail.com
    - SMTP_HOST=smtp.gmail.com
    - SMTP_PORT=587
    - SMTP_USER=xxxxx@gmail.com
    - SMTP_PASS=password
    - SMTP_STARTTLS=true
    - SMTP_AUTHENTICATION=login

    - IMAP_ENABLED=true
    - IMAP_HOST=imap.gmail.com
    - IMAP_PORT=993
    - IMAP_USER=xxxx@gmail.com
    - IMAP_PASS=password
    - IMAP_SSL=true
    - IMAP_STARTTLS=
    
    - VIRTUAL_HOST=localhost

    - SSL_CERTIFICATE_PATH=/home/git/data/certs/gitlab.crt
    - SSL_KEY_PATH =/home/git/data/certs/gitlab.key

    - SSL_CA_CERTIFICATES_PATH=/home/git/data/certs/gitlab.crt
    
    - SSL_DHPARAM_PATH=/home/git/data/certs/dhparam.pem

    - GITLAB_REPOS_DIR=/home/git/data/repositories
    - GITLAB_BACKUP_DIR=/home/git/data/backups
    - GITLAB_SHARED_DIR=/home/git/data/shared
    - GITLAB_BUILDS_DIR=/home/git/data/builds
    - GITLAB_ARTIFACTS_DIR=/home/git/data/shared/artifacts

    - GITLAB_PROJECTS_CONTAINER_REGISTRY=true
    - GITLAB_REGISTRY_DIR=/home/git/data/shared/registry

    - GITLAB_REGISTRY_ENABLED=true
    - GITLAB_REGISTRY_HOST=registry.localhost
    - GITLAB_REGISTRY_PORT=5005
    - GITLAB_REGISTRY_API_URL=http://registry.localhost:5000
    
    - GITLAB_REGISTRY_CERT_PATH=/home/git/data/certs/registry.crt
    - GITLAB_REGISTRY_KEY_PATH=/home/git/data/certs/registry.key
    - GITLAB_REGISTRY_ISSUER=gitlab-issuer

    - SSL_REGISTRY_KEY_PATH=/home/git/data/certs/registry.key
    - SSL_REGISTRY_CERT_PATH=/home/git/data/certs/registry.crt
    

    networks:
    - back
    - lb_web

  registry:
    restart: always
    image: registry:2.5
    container_name: registry
    volumes:
        - /srv/docker/registry:/registry
        - /srv/docker/gitlab/gitlab/certs:/home/git/data/certs
    ports:
        - "5000:5000"
    external_links:
        - "gitlab:localhost"
    environment:
        - REGISTRY_LOG_LEVEL=info
        - REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/registry
        - REGISTRY_AUTH_TOKEN_REALM=https://localhost:10443/jwt/auth
        - REGISTRY_AUTH_TOKEN_SERVICE=container_registry
        - REGISTRY_AUTH_TOKEN_ISSUER=gitlab-issuer
        - REGISTRY_AUTH_TOKEN_ROOTCERTBUNDLE=/home/git/data/certs/registry.crt
        - REGISTRY_STORAGE_DELETE_ENABLED=true

        - REGISTRY_HTTP_SECRET=xxxxxx
    networks:
        - back

  nginx:
    restart: always
    image: nginx
    container_name: nginx
    links:
        - registry
    volumes:
        - /srv/docker/nginx/nginx.conf:/etc/nginx/nginx.conf    
    environment:
        - VIRTUAL_HOST=registry.localhost
        - REGISTRY_HTTP_RELATIVEURLS=true  
    networks:
        - back
        - lb_web

  gitlab-runner:
    restart: always
    image: gitlab/gitlab-runner:latest
    container_name: gitlab-runner
    volumes:
        - /srv/gitlab-runner/config:/etc/gitlab-runner
        - /var/run/docker.sock:/var/run/docker.sock
        - /srv/docker/gitlab/gitlab/certs:/etc/gitlab-runner/certs
    environment:
        - CA_CERTIFICATES_PATH=/home/git/data/certs/gitlab.crt
    networks:
        - back

В статье расскажу про установку и регистрацию GitLab Runner, рассмотрев некоторые проблемы, с которыми возможно придется столкнуться. Для новичков могут быть интересны также некоторые теоретические концепы, на рассмотрение которых я обязательно буду давать ссылки.

Инструкция ниже актуальна для Centos 7.

Предварительные требования

Было бы странно не воспользоваться функционалом Docker в задачах CI/CD, а потому первым делом займемся его установкой. Поставить наиболее свежую версию можно с помощью официальной инструкции — Install Docker Engine on CentOS (доступна и для других дистрибутивов). Если версия вам не важна, просто выполните команду:

Но надо включить автозагрузку и запустить демон, потому что по умолчанию он остановлен:

Теперь переходим непосредственно к установке приложения GitLab Runner.

Установка

Установка доступна с помощью пакетов или путем простого скачивания исполняемого файла. Я остановлюсь на последнем варианте. Помимо официального ресурса — Install GitLab Runner manually on GNU/Linux — инструкция доступна также на вашем экземпляре GitLab. Для этого нужно зайти в проект (или группу, если ваши проекты объединены логически), далее Settings / CI/CD / Runners. Слева увидите следующее:

Нажимайте на Show Runner installation instructions и увидите пошаговую инструкцию. Очень удобно. А теперь выполним её по порядку.

Выкачиваем бинари:

Выставляем права на исполнение:

Добавляем пользователя:

Устанавливаем раннер и сразу его запускаем:

Сохраняем токен (см. на скриншоте выше) на будущее:

Он понадобится на следующем этапе.

Регистрация

Теперь пришло время зарегистрировать раннеры. Для одного хоста может быть зарегистрировано множество раннеров, но например с разными исполнителями (executors ¹). Перерегистрировать можно многократно, при этом не забывая удалять их в интерфейсе GitLab, если они вдруг стали не нужны или вы хотите изменить их область действия (например сделать доступными для конкретного проекта, а не для группы).

Итак, приступим:

Команды две, поскольку мы регистрируем два исполнителя на одном раннере. Некоторые задачи лучше выполнять напрямую в оболочке хоста (например сборку докер-образов), а для других постоянно будет требоваться дополнительное ПО и тогда логично запускать задачи внутри докер-контейнеров

На самом хосте информация о конфигурации раннеров доступна в файле /etc/gitlab-runner/config.toml. Вот его пример:

Регистрация исполнителей проста, но не всегда может пойти по плану.

Certificate signed by unknown authority

Текст из названия главы вы можете встретить в ошибке, которая вылезет в ответ на выполнение запроса о регистрации раннера на вашем экземпляре GitLab, если он использует сертификат от недоверенного источника (самозаверенный сертификат или подписанный локальным центром сертификации). Полный текст ошибки:

Если сертификат самозаверенный, то его легко прочитать и сразу скопировать в локальное хранилище доверенных сертификатов:

Сложнее будет, если сертификат GitLab содержит в себе промежуточные. В таком случае придется их склеивать вместе, совсем как описано в официальной статье ²:

Ну а после этих манипуляций перечитайте сертификаты из хранилища:

Выполнять описанные действия придется для каждого хоста, который планируется использовать для запуска раннеров, а потому лучше их автоматизировать в виде роли Ansible. Благо уже есть готовый модуль ³. Об этом возможно расскажу в следующих статьях. Успехов!

comments powered by HyperComments

GITLAB_RUNNER. ERROR: registering runner.. failed #1123

@sameersbn @panosoft @mikew
hi, first of all to thank you for this community and for the contribution you make to the informatics.
My problem is this, I’m working with docker-gitlab sameersbn: 8.16.6, postgresql:9.6-2, redis:latest, registry:2.5, nginx. All working properly as far as I could see but I have configured gitlab-runner:latest for continuous integration and I got the following error when registering a runner for gitlab: «ERROR: Registering runner. failed runner=xrz3LPZ status=couldn’t execute POST against https://localhost:10443/ci/api/v1/runners/register.json: Post https://localhost:10443/ci/api/v1/runners/register.json: dial tcp [::1]:10443: getsockopt: connection refused
PANIC: Failed to register this runner. Perhaps you are having network problems «_.
I do not know if something in my configuration is wrong or something is missing to configure for this to work, please I need help this is very important for the project.
Then I describe my working environment together with my configuration file docker-compose.yml.

docker version:

Docker version 17.03.0-ce, build 60ccb22

docker compose version:

docker-compose version 1.11.2, build dfed245

docker-compose.yml

Thanks in advance, any help and comment is welcome.

The text was updated successfully, but these errors were encountered:

Hey,
your problem is that you use localhost. Every container has is own interface and an own interface for localhost You should use the container name instead of localhost this should work than.

In your case gitlab

@solidnerd thanks for respond me. Let me see if I understood, I have to rename GITLAB_HOST = localhost for another name?? Which variable in specific do I have to modify. thanks solidnerd for your help and excuse my English. Stay tuned to your comments.
Gracias 🙂

@solidnerd I am sorry my friend, Even throw me do not understand that in specific of my docker-compose.yml I have to modify . please help my friend.

No, you should use gitlab as hostname when registring the runner.

$ gitlab-runner register —name my-runner —url http://gitlab —registration-token

• replace by the token visible in GitLab
• you must run this command within the gitlab-runner container 😉

In my case it has been in fact the solution to pass the value being attached to container_name for successfully registering my gitlab-runner , so thanks for that.

Although there’s one strange behavior which bugs me a bit:

Источник

Установка и регистрация GitLab Runner

В статье расскажу про установку и регистрацию GitLab Runner, рассмотрев некоторые проблемы, с которыми возможно придется столкнуться. Для новичков могут быть интересны также некоторые теоретические концепы , на рассмотрение которых я обязательно буду давать ссылки.

Установка и регистрация GitLab Runner

Инструкция ниже актуальна для Centos 7.

Предварительные требования

Было бы странно не воспользоваться функционалом Docker в задачах CI/CD, а потому первым делом займемся его установкой. Поставить наиболее свежую версию можно с помощью официальной инструкции — Install Docker Engine on CentOS (доступна и для других дистрибутивов). Если версия вам не важна, просто выполните команду:

Но надо включить автозагрузку и запустить демон, потому что по умолчанию он остановлен:

Теперь переходим непосредственно к установке приложения GitLab Runner.

Установка

Установка доступна с помощью пакетов или путем простого скачивания исполняемого файла. Я остановлюсь на последнем варианте. Помимо официального ресурса — Install GitLab Runner manually on GNU/Linux — инструкция доступна также на вашем экземпляре GitLab. Для этого нужно зайти в проект (или группу, если ваши проекты объединены логически), далее Settings / CI/CD / Runners. Слева увидите следующее:

Нажимайте на Show Runner installation instructions и увидите пошаговую инструкцию. Очень удобно. А теперь выполним её по порядку.

Источник

gitlab-runner registered but throws error #2129

ERROR: for application argument of type ‘NoneType’ is not iterable #51 -Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Issue:

gitlab-runner throws an error during job execution

Expected behavior:

gitlab-runner to run successfully

Reproduce:

1. Start gitlab and retrieve runner registration token
   docker-compose up -d gitlab
2. Modify .env file*

1. Modify docker-compose.yml (add networks: tag in gitlab-runner)*

1. Start gitlab-runner
   docker-compose up -d gitlab gitlab-runner
2. Register gitlab-runner

1. Confirm registration at Settings > CI / CD > Runners
2. Push code with the following .gitlab-ci.yml (Test script per https://docs.gitlab.com/ce/ci/introduction/)

Relevant Code:

*Initially I couldn’t register the gitlab-runner out of the box, hence the step 2 and 3. However after registration, the runner executes the run-test job above, and outputs the following error:

I also don’t understand why it’s trying to connect to localhost, when .env file is configured as GITLAB_CI_SERVER_URL=http://gitlab
Here is the cat /etc/gitlab-runner/config.toml for reference:

The text was updated successfully, but these errors were encountered:

Источник

How I solved “New runner. Has not connected yet” in GitLab CI

I hit on an issue with GitLab CI whereby newly added GitLab CI Runners would register successfully, but never start a build.

The error message was shown on the Projects > Settings as a brown triangle with the runner’s ID hash next to it.

The runner itself seemed to be active, but it had the message: “New runner. Has not connected yet” next to it.

Frustrated, I re-installed, re-installed again, tried doing a gitlab-ci-multi-runner register AND a sudo gitlab-ci-multi-runner register which only exacerbated the problem.

The Problem

Firstly, note that running a :

does something different to:

sudo gitlab-ci-multi-runner register

Both will create a config.toml file which may not be immediately obvious.

Normally when you run a command without sudo and it doesn’t work, you would expect it to fail and give a helpful error message.

This is a case of GitLab being flexible, but confusing.

gitlab-ci-multi-runner register will create a file in your home directory called config.toml .

sudo gitlab-ci-multi-runner register will create the file: /etc/gitlab-runner/config.toml .

My Solution to “New runner. Has not connected yet”

In my case, the solution was to delete the config.toml in my home directory. That’s the home directory of the user who I was ssh ‘d into the GitLab CI Runner instance.

As soon as I did this, the GitLab runner immediately started – no further intervention required.

If your’s doesn’t, my next course of action would be to delete both config.toml files, remove any references to that runner from GitLab CI Runner dashboard, and then re-run the command:

sudo gitlab-ci-multi-runner register

Published by

Code Review

CodeReviewVideos is a video training site helping software developers learn Symfony faster and easier. View all posts by Code Review

Источник

CentOS 7 — Gitlab runner register — self-signed certs — x509: certificate signed by unknown authority

I’ve installed Gitlab CE and gitlab runner via omnibus. (installed in /opt/gitlab) I’ve disabled the embedded nginx to use mine (I already had one running).

I’ve created my self-signed certs using the following bash command: openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:4096 -keyout ca.key -out ca.crt That I can use directly in nginx for my own services.

I’ve noticed it is an issue that comes back regularly here, but I all the solutions that I found and tried didn’t work for me:

• copied my ca.cert at the folder path /home/gitlab-runner/data/certs/ca.crt
• added to /etc/gitlab-runner/config.toml these variables : SSL_KEY_PATH=»/etc/nginx/ssl/gitlab/ca.key» CA_CERTIFICATES_PATH=»/etc/nginx/ssl/gitlab/ca.crt»
• created a hash-based symlink of the ca.crt using this script (https://www.madboa.com/geek/openssl/#verify-new) in /opt/gitlab/embedded/ssl/certs

and when I use the command gitlab-ci-multi-runner register I get the x509: certificate signed by unknown authority error.

Is there a way to tell (I don’t know like a —selfsigned flag) the runner not to verify the authority for the self-sign cert ? Has someone been able to use self-sign certs for the gitlab runners ? are my certs properly generated for it to work ? Is there a simple tutorial somewhere that would provide the necessary steps to do it ?

Источник

Aus Wiki-WebPerfect

Wechseln zu: Navigation, Suche

.gitlab-runner.exe install
.gitlab-runner.exe start

.gitlab-runner.exe install --user <ENTER-YOUR-USERNAME> --password <ENTER-YOUR-PASSWORD>
.gitlab-runner.exe start

 concurrent = 1
 check_interval = 0
 log_level = "warning"
 
 [session_server]
   session_timeout = 1800
 
 [[runners]]
   name = "<FQDN>"
   executor = "shell"
   shell = "powershell"
   environment = ["HTTP_PROXY=<your_Proxy>","HTTPS_PROXY=<your_Proxy>"]
   url = "https://<your_GitLab>/"
   token = "<your_token_from_registering_the_runner>"
   tls_verify = false 

New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesgitlab-runner" -Name "Environment" -Value "HTTPS_PROXY=server-proxy.xaas.swissic.ch:8080" -PropertyType MultiString

.gitlab-runner.exe register

intl.cpl

Self-signed certificates or custom Certification Authorities

Introduced in GitLab Runner 0.7.0

GitLab Runner provides two options to configure certificates to be used to verify TLS peers:

For connections to the GitLab server: the certificate file can be specified as detailed in the Supported options for self-signed certificates targeting the GitLab server section.

This solves the x509: certificate signed by unknown authority problem when registering a runner.

For existing Runners, the same error can be seen in Runner logs when trying to check the jobs:

A more generic approach which also covers other scenarios such as user scripts, connecting to a cache server or an external Git LFS store: a certificate can be specified and installed on the container as detailed in the Trusting TLS certificates for Docker and Kubernetes executors section.

An example job log error concerning a Git LFS operation that is missing a certificate:

Supported options for self-signed certificates targeting the GitLab server

This section refers to the situation where only the GitLab server requires a custom certificate. If other hosts (e.g. object storage service without proxy download enabled) also require a custom certificate authority (CA), please see the next section.

GitLab Runner supports the following options:

Default — Read the system certificate: GitLab Runner reads the system certificate store and verifies the GitLab server against the certificate authorities (CA) stored in the system. Note that reading from the system certificate store is not supported in Windows.

Specify a custom certificate file: GitLab Runner exposes the tls-ca-file option during registration ( gitlab-runner register —tls-ca-file=/path ), and in config.toml under the [[runners]] section. This allows you to specify a custom certificate file. This file will be read every time the Runner tries to access the GitLab server. If you are using GitLab Runner Helm chart, you will need to configure certificates as described in Providing a custom certificate for accessing GitLab.

Read a PEM certificate: GitLab Runner reads the PEM certificate (DER format is not supported) from a predefined file:

/etc/gitlab-runner/certs/gitlab.example.com.crt on *nix systems when GitLab Runner is executed as root .

If your server address is https://gitlab.example.com:8443/ , create the certificate file at: /etc/gitlab-runner/certs/gitlab.example.com.crt .

You can use the openssl client to download the GitLab instance’s certificate to /etc/gitlab-runner/certs :

To verify that the file is correctly installed, you can use a tool like openssl . For example:

/.gitlab-runner/certs/gitlab.example.com.crt on *nix systems when GitLab Runner is executed as non- root .

If your GitLab server certificate is signed by your CA, use your CA certificate (not your GitLab server signed certificate). You might need to add the intermediates to the chain as well. For example, if you have a primary, intermediate, and root certificate, you can put all of them into one file:

Git cloning

The Runner injects missing certificates to build the CA chain by using CI_SERVER_TLS_CA_FILE . This allows git clone and artifacts to work with servers that do not use publicly trusted certificates.

This approach is secure, but makes the Runner a single point of trust.

Trusting TLS certificates for Docker and Kubernetes executors

There are two contexts that need to be taken into account when we consider registering a certificate on a container:

• The user image, which is used to run the user script. In this scenario, the user must take ownership regarding how to install a certificate, since this is highly dependent on the image itself, and the Runner has no way of knowing how to install a certificate in each possible scenario.
• The Runner helper image, which is used to handle Git, artifacts, and cache operations. In this scenario, the user only needs to make a certificate file available at a specific location (for example, /etc/gitlab-runner/certs/ca.crt ), and the Docker container will automatically install it for the user.

Trusting the certificate for user scripts

If your build script needs to communicate with peers through TLS and needs to rely on a self-signed certificate or custom Certificate Authority, you will need to perform the certificate installation in the build job, as the Docker container running the user scripts doesn’t have the certificate files installed by default. This might be required to use a custom cache host, perform a secondary git clone , or fetch a file through a tool like wget , for example.

To install the certificate:

Map the necessary files as a Docker volume so that the Docker container that will run the scripts can see them. Do this by adding a volume inside the respective key inside the [runners.docker] in the config.toml file, for example:

Linux:

Linux-only: Use the mapped file (e.g ca.crt ) in a pre_build_script that:

Copies it to /usr/local/share/ca-certificates/ca.crt inside the Docker container.

Installs it by running update-ca-certificates —fresh . For example (commands vary based on the distribution you’re using):

If you just need the GitLab server CA cert that can be used, you can retrieve it from the file stored in the CI_SERVER_TLS_CA_FILE variable:

Trusting the certificate for the other CI/CD stages

You can map a certificate file to /etc/gitlab-runner/certs/ca.crt on Linux, or C:GitLab-Runnercertsca.crt on Windows. The Runner helper image installs this user-defined ca.crt file at start-up, and uses it when performing operations like cloning and uploading artifacts, for example.

Docker

Linux:

Windows:

Kubernetes

To provide a certificate file to jobs running in Kubernetes:

Store the certificate as a Kubernetes secret in your namespace:

Mount the secret as a volume in your runner, replacing and with appropriate values:

The mount_path is the directory in the container where the certificate is stored. If you used /etc/gitlab-runner/certs/ as the mount_path and ca.crt as your certificate file, your certificate is available at /etc/gitlab-runner/certs/ca.crt inside your container.

As part of the job, install the mapped certificate file to the system certificate store. For example, in an Ubuntu container:

Due to a known issue in the Kubernetes executor’s handling of the helper image’s ENTRYPOINT , the mapped certificate file isn’t automatically installed to the system certificate store.

Troubleshooting

Refer to the general SSL troubleshooting documentation.

In addition, you can use the tlsctl tool to debug GitLab certificates from the Runner’s end.

Источник

CentOS 7 — Gitlab runner register — self-signed certs — x509: certificate signed by unknown authority

I’ve installed Gitlab CE and gitlab runner via omnibus. (installed in /opt/gitlab) I’ve disabled the embedded nginx to use mine (I already had one running).

I’ve created my self-signed certs using the following bash command: openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:4096 -keyout ca.key -out ca.crt That I can use directly in nginx for my own services.

I’ve noticed it is an issue that comes back regularly here, but I all the solutions that I found and tried didn’t work for me:

• copied my ca.cert at the folder path /home/gitlab-runner/data/certs/ca.crt
• added to /etc/gitlab-runner/config.toml these variables : SSL_KEY_PATH=»/etc/nginx/ssl/gitlab/ca.key» CA_CERTIFICATES_PATH=»/etc/nginx/ssl/gitlab/ca.crt»
• created a hash-based symlink of the ca.crt using this script (https://www.madboa.com/geek/openssl/#verify-new) in /opt/gitlab/embedded/ssl/certs

and when I use the command gitlab-ci-multi-runner register I get the x509: certificate signed by unknown authority error.

Is there a way to tell (I don’t know like a —selfsigned flag) the runner not to verify the authority for the self-sign cert ? Has someone been able to use self-sign certs for the gitlab runners ? are my certs properly generated for it to work ? Is there a simple tutorial somewhere that would provide the necessary steps to do it ?

Источник

Установка и регистрация GitLab Runner

В статье расскажу про установку и регистрацию GitLab Runner, рассмотрев некоторые проблемы, с которыми возможно придется столкнуться. Для новичков могут быть интересны также некоторые теоретические концепы , на рассмотрение которых я обязательно буду давать ссылки.

Установка и регистрация GitLab Runner

Инструкция ниже актуальна для Centos 7.

Предварительные требования

Было бы странно не воспользоваться функционалом Docker в задачах CI/CD, а потому первым делом займемся его установкой. Поставить наиболее свежую версию можно с помощью официальной инструкции — Install Docker Engine on CentOS (доступна и для других дистрибутивов). Если версия вам не важна, просто выполните команду:

Но надо включить автозагрузку и запустить демон, потому что по умолчанию он остановлен:

Теперь переходим непосредственно к установке приложения GitLab Runner.

Установка

Установка доступна с помощью пакетов или путем простого скачивания исполняемого файла. Я остановлюсь на последнем варианте. Помимо официального ресурса — Install GitLab Runner manually on GNU/Linux — инструкция доступна также на вашем экземпляре GitLab. Для этого нужно зайти в проект (или группу, если ваши проекты объединены логически), далее Settings / CI/CD / Runners. Слева увидите следующее:

Нажимайте на Show Runner installation instructions и увидите пошаговую инструкцию. Очень удобно. А теперь выполним её по порядку.

Источник

Pipeline fails with «x509: certificate signed by unknown authority»

Summary

I have a self-hosted on-premise GitLab instance.

I successfully registered a runner on a new machine (setting Docker as the executor) by using sudo gitlab-runner register . Though, when I run the pipeline, it fails as soon as it tries to log in to the Docker registry, with the following error:

Certificate

I copied the certificate from my GitLab server (in /etc/gitlab/ssl/hostname.example.crt ) to my new machine (in /etc/gitlab-runner/certs/hostname.example.crt ).

Verifying the certificate

Running the following command on the new machine seems to work:

The output (truncated for the sake of brevity) includes:

This may indicate that the certificate is correctly installed on the machine, but the Docker executor is not using it.

Configuration

This is the configuration file that was generated in /etc/gitlab-runner/config.toml after registering the runner :

Attempted solutions

I am aware that this error has been reported several times before (this may indicate that the docs need to be fixed/updated), but none of the proposed solutions seem to work. Here are some solutions that I tried:

1. Setting volumes = [«/var/run/docker.sock:/var/run/docker.sock», «/cache»] in config.toml .
2. Setting volumes = [«/cache», «/etc/gitlab-runner/certs/hostname.example.crt:/etc/gitlab-runner/certs/hostname.example.crt:ro»] in config.toml .
3. Merging the two settings of volumes in 1. and 2. to use both at the same time.
4. Setting tls-ca-file = /etc/gitlab-runner/certs/hostname.example.crt in config.toml with 1.
5. Setting GIT_SSL_NO_VERIFY: ‘true’ in the variables section of .gitlab-ci.yml .

Versions

Machine: Ubuntu 20.04.1 LTS

What should I try next? I think it would be helpful if someone could provide a detailed list of all the steps that are necessary in order to set up a Docker executor that can correctly access a self-signed certificate.

Источник

x509: certificate signed by unknown authority problem when registering a runner even with self-certificate

I have a server running on linux OS. Docker is installed along with a container on which gitlab is installed too. Everything is working fine. I intend to install and register a runner on a windows 10 to use through my CI CD process (the reason is that I have multiple projects in .NET needed to be complied and build during the deployment time therefore I have decided to place them on windows and by registering a runner in Shell could run a batch script file to build those projects). When I am going to register the runner I am getting this error : x509: certificate signed by unknown authority
which it has been explained how to solve it (gitlab doc) through creating a ssl self certificate. after so much efforts I am still getting this error. I am a little bit new with ssl but I follow this way: first I created a self certificate with this commad on my gitlab container: https://docs.bitnami.com/aws/apps/gitlab/administration/create-ssl-certificate-nginx/ then, I use this file on windows to register the gitlab runner. But error is still thrown during registration. When I use the following command on windows to verify the self certificate:

I run into this error in the last lines:

can anyone provide some steps in details to solve this problem? I was in searching for a right and applicable answer but no result was achieved yet. PS: gitlab-runner x509: certificate signed by unknown authority did not fix my problem

Know someone who can answer? Share a link to this question via email, Twitter, or Facebook.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.1.13.43154

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник