Как обслуживать другие 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)
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.rbnginx['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"), если вы забыли этот шаг. Для большего информация, см.:
- каков стандарт де-факто для обратного прокси-сервера, чтобы сообщить, что используется серверный SSL?
- https://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy
Чтобы пойти дальше, вы можете следовать официальным документам по адресу 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-certificatespassenger.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