Как обслуживать другие vhosts рядом с сервером GitLab Omnibus? [Полное пошаговое решение]



Я установил GitLab CE на выделенный сервер Ubuntu 14.04 с пакетом Omnibus.



Теперь я хотел бы установить три других виртуальных хоста рядом с gitlab.



Два узла.веб-приложения js, запущенные с помощью non-root user, запущенного на двух различных ports > 1024, третье-это веб-приложение PHP, для запуска которого требуется веб-сервер.



Есть:




  • частный реестр bower, работающий на 8081 (node.js)

  • частный реестр npm, работающий на 8082 (node.js)

  • частный реестр композиторов (PHP)


Но Omnibus listen 80 и, похоже, не использует ни Apache2, ни Nginx, поэтому я не могу использовать их для обслуживания моего PHP-приложения и обратного прокси-сервера моих двух других приложений узла .




Какую обслуживающую механику GitLab Omnibus использует для listen 80?
Как я должен создать три других виртуальных хоста, чтобы иметь возможность предоставлять следующие vHosts ?





  • gitlab.mycompany.com (:80) -- уже используется


  • bower.mycompany.com (:80)


  • npm.mycompany.com (:80)


  • packagist.mycompany.com (:80)


792   2  

2 ответов:

Об этих

Но Omnibus слушает 80 и, похоже, не использует ни Apache2, ни Nginx [, таким образом ...] .

И @stdob комментарий:

Разве omnibus не использовал nginx в качестве веб-сервера ??? –

Что я ответил

Я думаю, что нет, потому что пакет nginx не установлен в системе ...

В фактах

Из официальных документов Gitlab:

По умолчанию omnibus-gitlab устанавливает GitLab в комплекте с Nginx.

Так что да!

Пакет Omnibus фактически использует Nginx !

Но он был упакован, объясняя, почему он не требует установки в качестве зависимости от хост-ОС.

Таким образом, да! Nginx может и должен использоваться для обслуживания моего PHP-приложения и обратного прокси-сервера двух других приложений узла.

Теперь

Omnibus-gitlab обеспечивает доступ к веб-серверу через пользователя gitlab-www, который проживает в группе с таким же названием. Чтобы разрешить доступ к внешнему веб-серверу GitLab, внешний пользователь веб-сервера должен быть добавлен gitlab-www группа.

Чтобы использовать другой веб-сервер, например Apache или существующую установку Nginx, вам придется сделать следующие шаги:

Отключите пакет Nginx, указав в /etc/gitlab/gitlab.rb

nginx['enable'] = false
# For GitLab CI, use the following:
ci_nginx['enable'] = false

Проверьте имя пользователя не связанного веб-сервера. По умолчанию omnibus-gitlab не имеет настроек по умолчанию для внешнего пользователя веб-сервера. Вы должны указать имя пользователя внешнего веб-сервера в конфигурации! Допустим, например, что пользователь веб-сервера - www-data. В /etc/gitlab/gitlab.rb множестве

web_server['external_users'] = ['www-data']

Этот параметр является массивом, поэтому вы можете указать несколько пользователей, которые будут добавлены в группу gitlab-www.

Запустите sudo gitlab-ctl reconfigure, чтобы изменения вступили в силу.

Установка адреса прослушивания NGINX или адресов

По умолчанию NGINX будет принимать входящие соединения на всех локальных IPv4-адресах. Вы можете изменить список адресов в /etc/gitlab/gitlab.rb.

nginx['listen_addresses'] = ["0.0.0.0", "[::]"] # listen on all IPv4 and IPv6 addresses

Для GitLab CI используйте параметр ci_nginx['listen_addresses'].

Установка порта прослушивания NGINX

По умолчанию NGINX будет слушать на порту, указанном в external_url или неявно используйте правильный порт (80 для HTTP, 443 для HTTPS). Если вы работаете GitLab за обратным прокси, вы можете переопределить порт прослушивания для что-то еще. Например, чтобы использовать порт 8080:

nginx['listen_port'] = 8080

Аналогично, для GitLab CI:

ci_nginx['listen_port'] = 8081

Поддержка проксированного SSL

By по умолчанию NGINX автоматически определит, следует ли использовать SSL, если external_url содержит https://. Если вы используете GitLab за обратным прокси-сервером, вы возможно, вы захотите сохранить external_url в качестве адреса HTTPS, но общаться с GitLab NGINX внутренне через HTTP. Для этого можно отключить HTTPS с помощью вариант listen_https:

nginx['listen_https'] = false

Аналогично, для GitLab CI:

ci_nginx['listen_https'] = false

Обратите внимание, что вам может потребоваться настроить обратный прокси-сервер для пересылки определенных данных. заголовки (напр.Host, X-Forwarded-Ssl, X-Forwarded-For, X-Forwarded-Port) чтобы Гитлаб.

Вы можете увидеть неправильные перенаправления или ошибки (например, " 422 Unprocessable Entity", "Не удается проверить подлинность токена CSRF"), если вы забыли этот шаг. Для большего информация, см.:

Чтобы пойти дальше, вы можете следовать официальным документам по адресу https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#using-a-non-bundled-web-server

Настройка нашего виртуального хоста gitlab

Установка Phusion Passenger

Нам нужно установить ruby (GitLab run in omnibus with a bundled ruby) глобально в ОС

$ sudo apt-get update 
$ sudo apt-get install ruby
$ sudo gem install passenger

Перекомпилировать nginx с пассажирским модулем

Вместо Apache2, например, nginx не может быть подключен к двоичным модулям на лету. Оно необходимо перекомпилировать для каждого нового плагина, который вы хотите добавить.

Команда разработчиков Phusion passenger усердно работала, чтобы обеспечить высказывание: "комплектная версия passenger nginx": nginx bins, скомпилированный с помощью плагина passenger.

Итак, давайте использовать его:

Требование : нам нужно открыть наш TCP порт 11371 (порт APT key).

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 561F9B9CAC40B2F7
$ sudo apt-get install apt-transport-https ca-certificates
создание passenger.list
$ sudo nano /etc/apt/sources.list.d/passenger.list

С этих линий

# Ubuntu 14.04
deb https://oss-binaries.phusionpassenger.com/apt/passenger trusty main

Используйте правильный РЕПО для вашего версия Ubuntu. Например, для Ubuntu 15.04: деб https://oss-binaries.phusionpassenger.com/apt/passenger яркая главная

Редактировать разрешения:

$ sudo chown root: /etc/apt/sources.list.d/passenger.list
$ sudo chmod 600 /etc/apt/sources.list.d/passenger.list

Обновление списка пакетов:

$ sudo apt-get update

Допуская его как unattended-upgrades

$ sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Найдите или создайте этот конфигурационный блок поверх файла:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {

  // you may have some instructions here

};

Добавить следующее:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {

  // you may have some instructions here

  // To check "Origin:" and "Suite:", you could use e.g.:
  // grep "Origin\|Suite" /var/lib/apt/lists/oss-binaries.phusionpassenger.com*
    "Phusion:stable";

};

Теперь (повторно)установите nginx-extra и passenger:

$ sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak_"$(date +%Y-%m-%d_%H:%M)"
$ sudo apt-get install nginx-extras passenger

Настройте его

Раскомментируйте passenger_root и passenger_ruby директивы в файле /etc/nginx/nginx.conf:

$ sudo nano /etc/nginx/nginx.conf

... чтобы получить что-то вроде:

##
# Phusion Passenger config
##
# Uncomment it if you installed passenger or passenger-enterprise
##

passenger_root /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini;
passenger_ruby /usr/bin/passenger_free_ruby;

Создайте конфигурацию сайта nginx (virtual host conf)

$ nano /etc/nginx/sites-available/gitlab.conf

server {
  listen *:80;
  server_name gitlab.mycompany.com;
  server_tokens off;
  root /opt/gitlab/embedded/service/gitlab-rails/public;

  client_max_body_size 250m;
  access_log  /var/log/gitlab/nginx/gitlab_access.log;
  error_log   /var/log/gitlab/nginx/gitlab_error.log;

  # Ensure Passenger uses the bundled Ruby version
  passenger_ruby /opt/gitlab/embedded/bin/ruby;

  # Correct the $PATH variable to included packaged executables
  passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";

  # Make sure Passenger runs as the correct user and group to
  # prevent permission issues
  passenger_user git;
  passenger_group git;

  # Enable Passenger & keep at least one instance running at all times
  passenger_enabled on;
  passenger_min_instances 1;

  error_page 502 /502.html;
}

Теперь мы можем включить его:

$ sudo ln -s /etc/nginx/sites-available/gitlab.cong /etc/nginx/sites-enabled/

Нет эквивалента a2ensite, идущего изначально с nginx, поэтому мы используем ln, но если вы хотите, есть проект на github: nginx_ensite : nginx_ensite и nginx_dissite для быстрого включения виртуального хоста и отключение

Это скрипт оболочки (Bash), который копирует для nginx Debian a2ensite и a2dissite для включения и отключения сайтов в качестве виртуальных хостов в Apache 2.2 / 2.4.

Это сделано : -). Наконец, перезагрузите nginx

$ sudo service nginx restart

С этой новой конфигурацией вы можете запускать другие виртуальные хосты рядом с gitlab, чтобы обслуживать то, что вы хотите

Просто создайте новые конфигурации в /etc/nginx/sites-available.

В моем случае я сделал бег и служение таким образом на том же хосте:

  • gitlab.mycompany.com - потрясающая платформа git, написанная на ruby
  • ci.mycompany.com -сервер непрерывной интеграции gitlab , написанный на ruby
  • npm.mycompany.com -частныйnpm реестр, записанный в node.js
  • bower.mycompany.com -частныйbower реестр, записанный в node.js
  • packagist.mycompany.com -частный упаковщик для composer реестр, написанный на php

Например, служить npm.mycompany.com:

Создайте каталог для журналов:

$ sudo mkdir -p /var/log/private-npm/nginx/

И заполните новый конфигурационный файл vhost:

$ sudo nano /etc/nginx/sites-available/npm.conf

С этой конфигурацией

server {
  listen *:80;
  server_name npm.mycompany.com

  client_max_body_size 5m;
  access_log  /var/log/private-npm/nginx/npm_access.log;
  error_log   /var/log/private-npm/nginx/npm_error.log;

  location / {
    proxy_pass http://localhost:8082;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

Затем включите его и перезагрузите:

$ sudo ln -s /etc/nginx/sites-available/npm.conf /etc/nginx/sites-enabled/
$ sudo service nginx restart

Поскольку я не хотел бы менять сервер nginx на gitlab (с некоторыми другими интеграциями), самый безопасный способ будет ниже решения.

Также согласно

GitLab:Ningx =>вставка пользовательских настроек в конфигурацию NGINX

Отредактируйте файл /etc/gitlab / gitlab.rb вашего gitlab:

nano /etc/gitlab/gitlab.rb

И sroll в nginx ['custom_nginx_config'] и изменить, как показано ниже, обязательно раскомментируйте

# Example: include a directory to scan for additional config files
nginx['custom_nginx_config'] = "include /etc/nginx/conf.d/*.conf;"

Создайте новую конфигурацию dir:

mkdir -p /etc/nginx/conf.d/
nano /etc/nginx/conf.d/new_app.conf

И добавьте контент в свой новый config

# my new app config : /etc/nginx/conf.d/new_app.conf
# set location of new app 
upstream new_app {
  server localhost:1234; # wherever it might be
}
# set the new app server
server {
  listen *:80;
  server_name new_app.mycompany.com;
  server_tokens off;
  access_log  /var/log/new_app_access.log;
  error_log   /var/log/new_app_error.log;
  proxy_set_header Host      $host;
  proxy_set_header X-Real-IP $remote_addr;
  location / { proxy_pass  http://new_app; }
}

И перенастроить gitlab, чтобы вставить новые настройки

gitlab-ctl reconfigure

Перезапустить nginx

gitlab-ctl restart nginx

Чтобы проверить журнал ошибок nginx:

tail -f /var/log/gitlab/nginx/error.log

Comments

    Ничего не найдено.