apache - Docker GitLab:将GitLab “external url”和 “ssh port”与GUI分离，然后复制并粘贴链接，Web资源，证书和实际端口

Question

请注意，此问题与个人使用专用服务器有关，而非专业用途。

我想在具有两个不同卷的同一台计算机上运行两个GitLab Docker容器，其中两个在主机计算机的端口443上“可用”。 http内容的端口80不可用。主机的HTTP不会是3xx重定向，它将是使用HSTS的网页。主机上的SSH端口类似于1 07 03和1 08 03。

这些网址将为 https://gitlab.example.com 和 https://sources.example.com 。证书由主机上的“让我们加密”维护。

内容将由Apache使用mod_proxy和虚拟主机提供。 Apache不在Docker内部运行。还有其他与GitLab无关的虚拟主机。为了简化证书，我尝试不将证书本身放在gitlab中。相反，Apache配置保存证书。

https://gitlab.example.com将转发到http://127.0.0.1:10701或用于服务Web内容的任何端口，具体取决于当前的GitLab配置

https://sources.example.com将转发到http://127.0.0.1:10801

现在问题来了。

如果我将https://gitlab.example.com指定为external_url:

https将被启用。 gitlab甚至会拒绝启动，因为缺少证书。正如我所说的，我正在使用mod_proxy，我不需要证书，因为Apache已经在做所有的工作。我希望GitLab在本地向Apache提供不安全的内容，以便通过不受信任的网络来确保安全性是Apache的工作。

如果我将http://gitlab.example.com指定为external_url，并让Apache转发至Docker容器上端口80的http://127.0.0.1:10701:

几乎所有gitlab Web资源都将通过http://gitlab.example.com提供，从而导致浏览器指示该站点实际上是不安全的，这是可以理解的。

克隆gitlab存储库的复制粘贴链接将是http://gitlab.example.com/group/something.git，导致克隆链接失败，因为它不是https。

SSH从主机计算机上的端口10703转发。在Docker容器内部，它运行在端口22上。当前的SSH克隆复制和粘贴链接仍为git@gitlab.example.com:group/something.git。我希望它是ssh://git@gitlab.example.com:10703/group/something.git(请参阅answer about cloning on other ports)

我的 X问题是:

用于在主机的标准https端口上安全地提供GitLab Web界面(443)。

在不影响安全性的情况下，保留Web界面内容的复制和粘贴链接的可用性。

约束:不能替换Apache。

我当前的 Y理想解决方案是:

我想将GitLab的配置与意向强烈分离。当前，当我将外部URL配置为https时，它会识别提供安全内容的意图，这需要证书。实际上，我只是希望更改外部URL。从容器的 Angular 来看，SSH相同，将外部显示的端口(用于复制和粘贴链接)与实际的网络端口分开。也许有一个允许这样做的配置。

我当前的 Y快速又肮脏的解决方案是:

使用https:// ...作为外部URL，并将占位符证书文件添加到/etc/gitlab/ssl/。 GitLab将完全忽略这些证书，但是只要它们存在于文件系统中，GitLab将能够启动并且主机将能够传递安全内容。 如果有更好的选择，我想避免这样做。

要解决SSH问题，也许我可以添加gitlab_rails['gitlab_shell_ssh_port'] = 10703(请参阅answer about changing SSH port)，然后使用docker run --publish 10703:10703 ...而不是当前的操作方式(docker run --publish 10703:22 ...)。 编辑:原来gitlab_rails['gitlab_shell_ssh_port']仅更改显示的端口。由于是sshd管理端口22而不是gitlab，因此docker run --publish 10703:10703 ...将导致主机上的端口10703转发到容器上的端口10703，该容器已关闭。 docker run --publish 10703:22 ... + gitlab_rails['gitlab_shell_ssh_port'] = 10703是应该怎么做。

我怎么解决这个问题？优雅，快速和肮脏的方式都受到赞赏。

Answer 1

4个月后，我将以一种不会回答原始问题的方式回答我的问题，而是为所有可能在此问题上绊脚石的读者提供迄今为止我如何做到的目标。

我已经做过一段时间了，所以此答案的内容可能不正确，这也可能是错误的做法，但我不知道。

请记住，这个问题与专用服务器的个人使用有关，而不是与专业有关。

容器配置

没有，不能保证这种配置足以拥有一个可移动的容器，用于保存数据。使用此方法后果自负。

这是我的docker run命令:

docker create \
    --name example-gitlab \
    --restart=unless-stopped \
    --hostname gitlab.example.com \
    --publish 2222:22 \
    --env GITLAB_OMNIBUS_CONFIG="external_url 'https://gitlab.example.com/'; gitlab_rails['gitlab_signup_enabled'] = false; gitlab_rails['gitlab_shell_ssh_port'] = 2222; nginx['real_ip_trusted_addresses'] = [ '172.17.0.0/16' ]; nginx['real_ip_header'] = 'X-Forwarded-For'" \
    --volume /data/docker-data/example-gitlab/config:/etc/gitlab \
    --volume /data/docker-data/example-gitlab/logs:/var/log/gitlab \
    --volume /data/docker-data/example-gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

我不确定 --hostname gitlab.example.com \是否有任何用途。

SSH端口公开和UI显示

GitLab并不在乎其逻辑中的SSH端口。当向用户显示存储库的SSH URL时，环境变量中提供的SSH端口仅用于显示目的。

我已将容器的实际端口22暴露到端口2222上:--publish 2222:22

我已将要显示的端口号传递给GitLab:gitlab_rails['gitlab_shell_ssh_port'] = 2222

HTTPS

至于https，我必须将 https://放入环境变量中。不能是http。如果是http，则将无法安全地提供该页面，因为几乎所有资源和链接都将通过http进行访问，而某些第三方资源也将是http。

在环境变量中添加https时，GitLab将检查有效的TLS证书。

我无法找到解决办法，所以我放弃了，现在我给GitLab提供了真实的证书。

由于它是个人服务器，因此我使用外部脚本将“让我们加密”证书复制到通过上面的 docker run命令公开的卷中。

cp /data/docker-data/http-realm/certs/live/gitlab.example.com/cert.pem /data/docker-data/example-gitlab/config/ssl/gitlab.example.com.crt
cp /data/docker-data/http-realm/certs/live/gitlab.example.com/privkey.pem /data/docker-data/example-gitlab/config/ssl/gitlab.example.com.key

不漂亮，但可以。

反向代理

自从最初的问题以来，有了很大的变化，因为现在我在Docker 中使用了 Apache。这导致Apache获得对Docker内部DNS解析的访问权限。

这是我使用Apache的虚拟主机配置。我本可以使用nginx，但是我正在使用自己有信心的东西。

<IfModule mod_ssl.c>
        <VirtualHost *:443>
                ServerAdmin webmaster@localhost
                ServerName gitlab.example.com

        ## REQUIRED so that external resources such as gravatar are fetched
        ## using https by the underlying nginx wizard stuff
        #RequestHeader set X-Forwarded-Proto "https"
        Header add X-Forwarded-Proto "https"

        ## http://stackoverflow.com/questions/6764852/proxying-with-ssl
        SSLProxyEngine On

        RewriteEngine On
        ProxyRequests     Off
        ProxyPreserveHost On


        ProxyAddHeaders On
        ## docker alias
        ProxyPass / https://example-gitlab:443/
        <Location />
          ProxyPassReverse /
          Require all granted
        </Location>

        SSLEngine on

        SSLCertificateFile      /etc/letsencrypt/live/gitlab.example.com/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/gitlab.example.com/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/gitlab.example.com/chain.pem

        SSLProtocol all -SSLv2 -SSLv3
        SSLHonorCipherOrder on
        SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"



        # Custom log file locations
        ErrorLog /var/log/apache2/example-gitlab_error.log
        CustomLog /var/log/apache2/example-gitlab_access.log combined

        </VirtualHost>
</IfModule>

在ProxyPass https://example-gitlab:443/行中:主机名example-gitlab可通过Docker自己的DNS解析，因为它是容器的名称。我正在使用Docker 1.12，以防特定于此版本的行为。

因此，我不需要将GitLab容器的端口443或端口80发布到主机，我的反向代理就可以解决这个问题。

网络层和X-Forwarded-For

需要设置gitlab以信任与您的网络层相对应的X-Forwarded-For header 。

否则，在管理面板中，所有用户的IP似乎都来自docker网络层。

如果您使用这种类型的网络层:

docker network create --driver=bridge \
  --subnet=192.168.127.0/24 --gateway=192.168.127.1 \
  --ip-range=192.168.127.128/25 strawberry

我相信您将需要更改docker run配置并替换为:

nginx['real_ip_trusted_addresses'] = [ '172.17.0.0/16' ]

有了这个:

nginx['real_ip_trusted_addresses'] = [ '192.168.127.128/25' ]

(除了在docker run配置中添加--net=strawberry之外)

另外，如果您使用的是nginx，则可能必须切换此设置:

nginx['real_ip_header'] = 'X-Forwarded-For'

有了这个:

nginx['real_ip_header'] = 'X-Real-IP'