ReserveProxy 를 이용해서 gitlab을 운영하면, gitalb site 안에 있는 링크가 깨지는 경우가 있습니다. 이를 해결하기 위해서는 아래 파일에 dns domain 주소로 변경하면 됩니다.

아래와 같이 시스템이 구성이 되어 있는 상태입니다.

flowchart TD
apache(gitlab.xxxxxx.com) --proxy--> gitlab(10.2.2.2:8000)

설정

apache 설정

<VirtualHost *:443>
    ServerName gitlab.xxxxxxxx.com

    ProxyRequests Off       # Reserve Proxy Mode
    ProxyPreserveHost On
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyPass / https://192.168.20.100/ nocanon
    ProxyPassReverse / https://192.168.20.100/

    <Location />
        Order Deny,Allow
        Deny from all
        Allow from 162.21
    </Location>

    AllowEncodedSlashes NoDecode
    ErrorLog logs/gitlab_error_log
    TransferLog logs/gitlab_access_log
    LogLevel warn

    SSLEngine on
    SSLProxyEngine On

    SSLCertificateFile "/etc/pki/tls/certs/xxxxxxxxxx.com.crt"
    SSLCertificateKeyFile "/etc/pki/tls/private/xxxxxxxxxx.com.key"
    SSLCertificateChainFile "/etc/pki/tls/RootChain/chain_all_ssl.crt"
    SSLCACertificateFile "/etc/pki/tls/RootChain/chain_ssl.crt"


    CustomLog "/etc/httpd/logs/gitlab_" \
              "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

도메인주소로 proxy 해서 사용해서 사용할 것이라 ProxyPass 부분을 https 로 설정해 주었습니다.
필수옵션:

  1. nocanon
  2. AllowEncodedSlashesgitlab.rb 설정
external_url 'https://gitlab.domain.net
puma['enable'] = true
puma['ha'] = false
puma['worker_timeout'] = 60
puma['worker_processes'] = 2
puma['min_threads'] = 1
puma['max_threads'] = 4
puma['listen'] = '127.0.0.1'
puma['port'] = 8001
puma['socket'] = '/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket'
puma['somaxconn'] = 1024
puma['pidfile'] = '/opt/gitlab/var/puma/puma.pid'
puma['state_path'] = '/opt/gitlab/var/puma/puma.state'
puma['log_directory'] = "/var/log/gitlab/puma"
puma['exporter_enabled'] = false
puma['exporter_address'] = "127.0.0.1"
puma['exporter_port'] = 8083
letsencrypt['enable'] = false
  • external_url 에 domain 주소로 설정을 하면 letencrypt 기능이 자동으로 동작하는 것 같다. 그래서, 옵션으로 letsencrypt 부분을 false 처리 해 주었습니다.

Optional

위에 설정으로 gitlab 에 접속을 할 수 없을 경우에 아래와 같은 옵션을 사용할 수 있습니다.

1. /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml 에 있는 정보를 변경

nginx --> gitlab 으로 proxy로 연결해서 사용하게 되면, 링크가 깨지는 현상이 발생한다. 이를 해결하기 위해서 아래와 같은 설정으로 임시 해결할 수 있다. 단, 다른 기능이 또 안될 수 있다. (이 부분은 아직 해결을 못하고 있다.) 예를 들어 gitlab-runner 에 대한 설정을 하려고 들어가는 화면에서 링크가 깨진다.

production: base
  #
  # 1. GitLab app settings
  # ==========================

  ## GitLab settings
  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: gitlab.xxxxxxxxxxxxx.com
    port: 443
    https: false

2. gitlab restart

gitlab-ctl restart
반응형

'개발' 카테고리의 다른 글

Mac이 AI PC로서 최고인 이유  (0) 2024.02.03
2024년 프로그래밍 랭킹  (1) 2024.01.02
elixir vs rust 비교  (1) 2023.12.27
vscode dev containers  (1) 2023.12.22
svn to git 마이그레이션 (맥)  (0) 2023.12.13

gitlab 을 구현한 시스템

메일 WEB 서버에서 Reserve Proxy Server를 통해서 자체 설치한 gitlab과 연결을 하고 있는 구조입니다.

flowchart BR
    A[apache web server] --Reserve Proxy--> B[gitlab server on-promise]

일반 apache 설정에서는 gitlab 에 요청을 하면 하위 URL에 제대로 요청을 할 수가 없습니다. 이를 해결하기 위해서 apache 에 reserve proxy 에 관한 설정을 해줘야 합니다.
저는 아래와 같이 80 port 로 들어온 요청을 443 으로 redirect 시켜서 서버 구성을 했습니다.

<VirtualHost *:80>
        ServerName      gitlab.domain.com
        Redirect        / https://gitlab.domain.com
</VirtualHost>
<VirtualHost *:443>
        ServerName      gitlab.domain.com

        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPass / http://192.168.0.67:8000/
        ProxyPassReverse / http://192.168.0.67:8000/

        <Proxy *>
                Order allow
                Allow from all
        </Proxy>
        ....
</VirtualHost>

여기서 추가를 해 줘야 하는 옵션은 두가지 입니다.

  1. nocanon: ProxyPass 디렉티브와 함께 사용합니다.
    프록시 서버가 요청 URL을 정규화 하지 않도록 지정합니다. 정규화는 URL 경로를 표준화하여 중복된 슬래시를 제거하고 상위 디렉토리 참조를 해결하는 과정입니다. 원래 요청 URL의 경로를 그대로 유지할 수 있습니다.

  2. AllowEncodedSlashes NoDecode: ProxyPass 디렉티브와 함께 사용합니다.
    프록시 서버가 인코딩된 슬래시를 디코딩 하지 않도록 지정합니다. 기본적으로 Apache 는 인코딩된 슬래시를 디코딩하여 처리합니다. 인코딩된 슬래시를 그대로 유지할 수 있습니다. 일부 어플리케이션에서 인코딩 된 슬래시를 사용하는 경우 유용합니다.

<VirtualHost *:443>
        ServerName      gitlab.domain.com

        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPass / http://192.168.0.67:8000/ nocanon
        ProxyPassReverse / http://192.168.0.67:8000/

        ....
        AllowEncodedSlashes NoDecode
</VirtualHost>
반응형

2년동안 gitlab을 운영하면서 한번도 업그레이드를 하지 않았습니다. gitlab.com 사이트에서는 계속 신기술과 최적화가 이뤄지도 있었지만, 온프로미스에 설치되어 있는 사내 gitlab은 새로운 시대에 적응을 못하고 있었습니다. 그래서, 이번에 버전업을 진행하면서 작업 방법에 대해서 글을 남깁니다.

gitlab 은 업그레이드 주요버전을 넘어서 업그레이드 할 수 없습니다. 설치하려고해도 설치완료 되었다는 메세지를 확인할 수 없습니다. 아래와 같은 메세지 Complete!라는 메세지와 로고가 나와야 합니다.

gitlab Reconfigured!
Restarting previously running GitLab services
ok: run: alertmanager: (pid 29637) 0s
ok: run: gitaly: (pid 9202) 7121s
ok: run: gitlab-exporter: (pid 29649) 0s
ok: run: gitlab-kas: (pid 29612) 1s
ok: run: gitlab-workhorse: (pid 29623) 1s
ok: run: grafana: (pid 29653) 1s
ok: run: logrotate: (pid 29663) 0s
ok: run: nginx: (pid 29672) 1s
ok: run: node-exporter: (pid 29683) 0s
ok: run: postgres-exporter: (pid 29689) 1s
ok: run: postgresql: (pid 1562) 9127s
ok: run: prometheus: (pid 29707) 0s
ok: run: puma: (pid 29794) 0s
ok: run: redis: (pid 8759) 7201s
ok: run: redis-exporter: (pid 29800) 1s
ok: run: sidekiq: (pid 29807) 0s

     _______ __  __          __
    / ____(_) /_/ /   ____ _/ /_
   / / __/ / __/ /   / __ `/ __ \
  / /_/ / / /_/ /___/ /_/ / /_/ /
  \____/_/\__/_____/\__,_/_.___/


Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
The automatic database backup was skipped as requested.
You may enable it again anytime by running the following command:
  sudo rm /etc/gitlab/skip-auto-backup

  Verifying  : gitlab-ce-14.10.4-ce.0.el7.x86_64                                                                                                      1/2
  Verifying  : gitlab-ce-14.9.5-ce.0.el7.x86_64                                                                                                       2/2

Updated:
  gitlab-ce.x86_64 0:14.10.4-ce.0.el7

Complete!

1. 준비

1.1. 백업

원복하기 위한 작업입니다. 2년 넘게 작업해온 내역들이 날아갈 수 있습니다. 내용을 작성하면서 다시 한번 백업을 진행했습니다. 백업은 자주 해 주시면 좋습니다. 기왕이면 crontab을 사용해서 작성하시기 바랍니다.

$ gitlab-backup create
2022-07-05 23:04:05 +0900 -- Dumping repositories ... done
2022-07-05 23:04:05 +0900 -- Dumping uploads ...
2022-07-05 23:04:06 +0900 -- Dumping uploads ... done
2022-07-05 23:04:06 +0900 -- Dumping builds ...
2022-07-05 23:04:06 +0900 -- Dumping builds ... done
2022-07-05 23:04:06 +0900 -- Dumping artifacts ...
2022-07-05 23:04:06 +0900 -- Dumping artifacts ... done
2022-07-05 23:04:06 +0900 -- Dumping pages ...
2022-07-05 23:04:06 +0900 -- Dumping pages ... done
2022-07-05 23:04:06 +0900 -- Dumping lfs objects ...
2022-07-05 23:04:06 +0900 -- Dumping lfs objects ... done
2022-07-05 23:04:06 +0900 -- Dumping terraform states ...
2022-07-05 23:04:06 +0900 -- Dumping terraform states ... done
2022-07-05 23:04:06 +0900 -- Dumping container registry images ... [DISABLED]
2022-07-05 23:04:06 +0900 -- Dumping packages ...
2022-07-05 23:04:06 +0900 -- Dumping packages ... done
2022-07-05 23:04:06 +0900 -- Creating backup archive: 1657029839_2022_07_05_14.10.4_gitlab_backup.tar ...
2022-07-05 23:04:06 +0900 -- Creating backup archive: 1657029839_2022_07_05_14.10.4_gitlab_backup.tar ... done
2022-07-05 23:04:06 +0900 -- Uploading backup archive to remote storage  ... [SKIPPED]
2022-07-05 23:04:06 +0900 -- Deleting tar staging files ...
2022-07-05 23:04:06 +0900 -- Cleaning up /var/opt/gitlab/backups/backup_information.yml
2022-07-05 23:04:06 +0900 -- Cleaning up /var/opt/gitlab/backups/db
2022-07-05 23:04:06 +0900 -- Cleaning up /var/opt/gitlab/backups/repositories
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/uploads.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/builds.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/artifacts.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/pages.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/lfs.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/terraform_state.tar.gz
2022-07-05 23:04:07 +0900 -- Cleaning up /var/opt/gitlab/backups/packages.tar.gz
2022-07-05 23:04:07 +0900 -- Deleting tar staging files ... done
2022-07-05 23:04:07 +0900 -- Deleting old backups ... [SKIPPED]
2022-07-05 23:04:07 +0900 -- Warning: Your gitlab.rb and gitlab-secrets.json files contain sensitive data
and are not included in this backup. You will need these files to restore a backup.
Please back them up manually.

/var/opt/gitlab/backups 에 백업한 파일들이 있는 것을 확인할 수 있습니다.

1.2. DB 자동 백업 중지

gitlab은 버전업을 하면 DB 또한 버전에 맞춰서 갱신되는 작업을 합니다. 이 부분을 자동으로 갱신되는 것을 방지 합니다. /etc/gitlab폴더에 파일을 생성해 놓으면 gitlab에서 자동으로 백업되는 것을 방지할 수 있습니다.

$ touch /etc/gitlab/skip-auto-backup

2. 업그레이드 작업

2.1. 업그레이드 순서 확인

8.11.Z -> 8.12.0 -> 8.17.7 -> 9.5.10 -> 10.8.7 -> 11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> 13.8.8 -> 13.12.15 -> 14.0.12 -> 14.3.6 -> 14.9.5 -> 14.10.Z -> 15.0.Z -> latest 15.Y.Z

여기에 업그레이드 버전에 맞춰서 단계별로 진행해야 합니다. 현재 버전이 중간에 있다면, 그 다음 버전으로 업그레이드 해주면 됩니다.

주의: 한번씩 업그레이드 해 줄때마다 백그라운드 이전작업이 진행 됩니다. 이 부분을 반드시 확인하면서 진행하여야 합니다.
또한 redis 버전, progres 버전 등을 업그레이드 해줘야 하는 경우도 있습니다.

$ yum install gitlab-ce-13.8.8
$ yum install gitlab-ce-13.12.15
$ yum install gitlab-ce-14.0.12

2.2. 업그레이드 전에 백그라운드 업데이트 체크

업그레이드 후에 백그라운드에서 DB 데이터등을 업데이트 하는 작업이 있는지 확인하면서 진행합니다. 작업이 다 끝나지 않았는데 업그레이드를 진행하면 데이터가 깨질 수 있다고 합니다.

2.2.1. bash 명령어로 확인

# 작업 확인
$ sudo gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining'
0 # 작업중이면 '1'로 표기

2.2.2. 관리자 화면에서 확인

gitlab을 admin계정으로 접속을 한 후,
[Admin Area] - [Monitoring] - [Background Migrations] 에 들어가면 상단 Queue에 현재 작업 또는 대기중인 내역을 확인할 수 있다.

반응형

+ Recent posts