GitLab Series 2 Рабочая лошадка GitLab

GitLab

GitLab Workhorse

Представлен в прошлый разБазовый функционал и архитектура GitLab, но я не объяснял, как обрабатывается запрос пользователя. Я только представил функции и обязанности каждого компонента. В этом разделе кратко представлены функции gitlab-workhorse


Первое резюме: GitLab использует Nginx для проксирования внешних http/https-запросов к gitlab-workhorse, который, в свою очередь, перенаправляет запросы на веб-сервер Unicorn. По умолчанию связь между gitlab-workhorse и интерфейсом осуществляется через доменный сокет unix, но также поддерживаются запросы на переадресацию TCP; GitLab использует веб-сервер Unicorn для предоставления динамических веб-страниц и API-интерфейсов.

1. Запись Nginx

Как видно из схемы архитектуры, первой остановкой HTTP/HTTPS-запросов для входа в GitLab является nginx.

скачатьОфициальный исходный код GitLab-ceпосле входа${gitlab-ce根目录}/lib/support/nginx,Открытымgitlab-sslВы можете увидеть конфигурацию nginx


GitLab по умолчанию перенаправляет http-запросы на https-запросы.

## Redirects all HTTP traffic to the HTTPS host
server {
  listen 0.0.0.0:80;
  listen [::]:80 ipv6only=on default_server;
  server_name YOUR_SERVER_FQDN;
  server_tokens off;
  return 301 https://$http_host$request_uri;
  access_log  /var/log/nginx/gitlab_access.log gitlab_ssl_access;
  error_log   /var/log/nginx/gitlab_error.log;
}

Настройка https относительно сложна, вот только одна изюминка:location: /следующееproxy_pass http://gitlab-workhorse;, объяснилЗа исключением некоторых статических страниц, nginx передает почти все запросы http/https компоненту gitlab-workhorse для обработки (используя связь через сокеты unix).

Socket Unix - это один вид разъемных функций межпроцессных коммуникаций, он не требует усложней упаковки данных, распаковки и проверку контрольной суммы и проверки, стек сети протокола не нужно принимать, безопасно и надежно. Unix Socket на самом деле является одним из типов сокетов AF_UNIX или AF_LOCAL.Он становится сокетом домена unix для локальной связи, то есть для реализации IPC, поэтому конструктору не нужны IP и порт, вместо этого это путь к файлу.

upstream gitlab-workhorse {
  # GitLab socket file,
  # for Omnibus this would be: unix:/var/opt/gitlab/gitlab-workhorse/socket
  server unix:/home/git/gitlab/tmp/sockets/gitlab-workhorse.socket fail_timeout=0;
}
...
## HTTPS host
server {
  listen 0.0.0.0:443 ssl;
  listen [::]:443 ipv6only=on ssl default_server;
  server_name YOUR_SERVER_FQDN;
  server_tokens off;

  ssl on;
  ssl_certificate /etc/nginx/ssl/gitlab.crt;
  ssl_certificate_key /etc/nginx/ssl/gitlab.key;

  ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 5m;
  real_ip_recursive off;    ## If you enable 'on'
  access_log  /var/log/nginx/gitlab_access.log gitlab_ssl_access;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    client_max_body_size 0;
    gzip off;
    proxy_read_timeout      300;
    proxy_connect_timeout   300;
    proxy_redirect          off;

    proxy_http_version 1.1;

    proxy_set_header    Host                $http_host;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-Ssl     on;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto   $scheme;
    proxy_set_header    Upgrade             $http_upgrade;
    proxy_set_header    Connection          $connection_upgrade_gitlab_ssl;

    proxy_pass http://gitlab-workhorse;
  }

  error_page 404 /404.html;
  error_page 422 /422.html;
  error_page 500 /500.html;
  error_page 502 /502.html;
  error_page 503 /503.html;
  location ~ ^/(404|422|500|502|503)\.html$ {
    root /home/git/gitlab/public;
    internal;
  }
}

2. GitLab-workhorse

ТакGitLab-workhorseЧто тогда? Официальное объяснение состоит в том, что это интеллектуальный обратный прокси-сервер GitLab, который используется для обработки HTTP-запросов с большой нагрузкой, таких как загрузка/выгрузка файлов, Git push/pull и загрузка архива Git. На самом деле все может быть сложнее

+-------+  +------------------+  +---------+
|       |  |                  |  |         |
| NGINX +->| gitlab-workhorse +->| Unicorn |
|       |  |                  |  |         |
+-------+  +------------------+  +---------+

Следующие компоненты Rails работают на веб-сервере Unicorn:

  1. workhorse может обрабатывать некоторые запросы без вызова компонентов Rails, таких как статические файлы ресурсов js/css


  2. workhorse может изменять ответы, отправляемые компонентами Rails. Например: предположим, что ваш компонент Rails используетsend_file, то gitlab-workhorse откроет файл на диске и вернет содержимое файла клиенту в виде тела ответа.
  3. рабочая лошадка может принимать запросы, запрашивающие у компонентов Rails разрешение на работу, например, на обработкуgit cloneПеред подтверждением разрешений текущего клиента рабочая лошадка продолжит работу после запроса подтверждения у компонента Rails.git cloneзапрос


  4. workhorse может изменить информацию о запросе до того, как она будет отправлена ​​компоненту Rails. Например: при обработке загрузок Git LFS рабочая лошадка сначала запрашивает компонент Rails, есть ли у текущего пользователя разрешение на выполнение, затем сохраняет тело запроса во временном файле, а затем отправляет измененное тело запроса, содержащее путь к временному файлу, на Компоненты рельсов
  5. рабочая лошадка управляет долгоживущими соединениями через веб-сокеты, которые взаимодействуют с компонентами Rails.


  6. рабочая лошадка не может напрямую подключаться к базе данных, она может взаимодействовать только с компонентами Rails и компонентами Redis (необязательно)
  7. Все запросы, поступающие на рабочую лошадку, перенаправляются вышестоящим прокси-сервером (nginx)
  8. рабочая лошадка не принимает соединения https
  9. рабочая лошадка не очищает неиспользуемые клиентские соединения
  10. Все запросы к компонентам Rails проходят через рабочую лошадку

Например, Unicorn относительно неэффективен в обработке статических файлов ресурсов, поэтому он передается для обработки рабочей лошадке. Из-за длины статьи здесь только один пример для пояснения: файл ресурсов gzip.

существует${gitlab-workhorse根目录}/internal/staticpages/servefile.goФункцияfunc (s *Static) ServeExistingВнутри определяет, как рабочая лошадка обрабатывает файлы статических ресурсов.

Предположим, нам нужно запросить относительный URL как/assets/locale/zh_CN/app-3396bd500e53f89d971d8c31ba7275f1c9ae2899062d4a7aeef14339084f44bd.js, потому что сassetsпрефикс, поэтому рабочая лошадка будет обрабатывать запросы так же, как статические файлы ресурсов, как показано в коде

// ${gitlab-workhorse根目录}/internal/upstream/routes.go
// Serve assets
route(
    "", `^/assets/`,
    static.ServeExisting(
        u.URLPrefix,
        staticpages.CacheExpireMax,
        NotFoundUnless(u.DevelopmentMode, proxy),
    ),
    withoutTracing(), // Tracing on assets is very noisy
),

Запрос файла статического ресурса js на следующем рисунке/assets/locale/zh_CN/app-3396bd500e53f89d971d8c31ba7275f1c9ae2899062d4a7aeef14339084f44bd.js, как использовать gzip


Если пользователь запрашивает оголовьеAccept-Encoding: gzipЕсли это так, рабочая лошадка прочитает gzip-файл соответствующего запрошенного статического ресурса (предварительно сжатый сервером файл статического ресурса) и отправит сжатое содержимое в браузер (не напрямую, а через сервер nginx), а Браузер получает ответ сервера, затем определяет, сжат ли контент, и распаковывает, если он сжат, конечно, если в заголовке запроса пользователя не указано использование gzip, то рабочая лошадка будет читать исходный файл


// ${gitlab-workhorse根目录}/internal/staticpages/servefile.go
// ...省略部分代码
file := filepath.Join(s.DocumentRoot, prefix.Strip(r.URL.Path))
// ...省略部分代码
// Serve pre-gzipped assets
if acceptEncoding := r.Header.Get("Accept-Encoding"); strings.Contains(acceptEncoding, "gzip") {
    content, fi, err = helper.OpenFile(file + ".gz")
    if err == nil {
        w.Header().Set("Content-Encoding", "gzip")
    }
}

На изображении ниже сжатый файл gz меньше 1/3 исходного файла, что, можно сказать, значительно экономит пропускную способность сети сервера.


В то же время мы должны также отметить, чтоПри обращении к статическим файлам ресурсов запрос не перенаправляется на веб-сервер Unicorn, а обрабатывается самой рабочей лошадкой, в этом и заключается наибольшее значение существования компонента рабочей лошадки, который должен компенсировать недостатки веб-сервера Unicorn. .. Это должно быть связано с известной поговоркой:

Any problem in computer science can be solved by another layer of indirection

Любую задачу в области информатики можно решить, добавив промежуточный слой, который, оказывается, переполнен рутиной.

Наконец, подведем итог: компонент «рабочая лошадка» изначально был разработан дляРешить проблему тайм-аута git-over-http/https, или другими словами,Компонент рабочей лошадки обрабатывает запросы, с которыми сервер unicorn не справляется., и такие запросы, как динамическая отрисовка страницы, будут проксироваться рабочей лошадкой на сервер единорога для обработки, потому что сервер единорога хорошо справляется с обработкой таких запросов. Что касается внешнего сервера nginx, то он в основном используется для настройки https и других целей.

приложение

Ссылка на ссылку

Официальный репозиторий GitLab Workhorse


Категории