nginx - external_url - ¿Cómo se sirven otros fantasmas junto al servidor Gitlab Omnibus?

gitlab rb configuration

Question

Instalé Gitlab CE en una edición de servidor Ubuntu 14.04 dedicada con el paquete Omnibus .

Ahora quisiera instalar otros tres servidores virtuales junto a gitlab.

Dos son aplicaciones web node.js lanzadas por un non-root user ejecuta en dos ports > 1024 distintos ports > 1024 , la tercera es una aplicación web PHP que necesita un servidor web desde el que iniciarse.

Existen:

• un registro de node.js privado ejecutándose en 8081 ( node.js )
• un registro privado de npm ejecutándose en 8082 ( node.js )
• un registro de compositor privado ( PHP )

Pero Omnibus escucha 80 y parece que no usa ni Apache2 ni Nginx, por lo que no puedo usarlos para servir mi aplicación PHP y proxy inverso para mis otras dos aplicaciones de nodo .

¿Qué mecánica de servicio usa Gitlab Omnibus para listen 80 ? ¿Cómo debería crear los otros tres hosts virtuales para poder proporcionar los siguientes vHosts?

• gitlab.mycompany.com ( :80 ) - ya en uso
• bower.mycompany.com ( :80 )
• npm.mycompany.com ( :80 )
• packagist.mycompany.com ( :80 )

Answer 1

Acerca de estos

Pero Omnibus escucha 80 y parece que no usa ni Apache2 ni Nginx [ , por lo tanto ...] .

y @stdob comentan:

¿Omnibus no usó nginx como servidor web? -

A lo que respondí

Supongo que no porque el paquete nginx no está instalado en el sistema ...

En hechos

De los documentos oficiales de Gitlab:

Por defecto, omnibus-gitlab instala GitLab con Nginx incluido.

¡Entonces sí!

¡El paquete Omnibus realmente usa Nginx!

pero fue incluido, explicando por qué no requiere ser instalado como dependencia del sistema operativo host.

¡Así SÍ! Nginx puede, y debe usarse para servir mi aplicación PHP y proxy inverso mis otras dos aplicaciones de nodo.

Entonces ahora

Omnibus-gitlab permite el acceso del servidor web a través del usuario gitlab-www que reside en el grupo con el mismo nombre. Para permitir el acceso de un servidor web externo a GitLab, se debe agregar al usuario del servidor web externo gitlab-www group.

Para usar otro servidor web como Apache o una instalación Nginx existente, deberá seguir los siguientes pasos:

Deshabilite el paquete Nginx especificando en /etc/gitlab/gitlab.rb

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

Verifique el nombre de usuario del usuario del servidor web no incluido. Por defecto, omnibus-gitlab no tiene una configuración predeterminada para el usuario del servidor web externo. ¡Debe especificar el nombre de usuario del usuario del servidor web externo en la configuración! Digamos, por ejemplo, que el usuario del servidor web es www-data . En el conjunto /etc/gitlab/gitlab.rb

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

Esta configuración es una matriz para que pueda especificar que se agregue más de un usuario al grupo gitlab-www.

Ejecute sudo gitlab-ctl reconfigure para que el cambio surta efecto.

Configuración de la dirección o direcciones de escucha NGINX

Por defecto, NGINX aceptará conexiones entrantes en todas las direcciones IPv4 locales. Puede cambiar la lista de direcciones en /etc/gitlab/gitlab.rb .

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

Para GitLab CI, use la ci_nginx[''listen_addresses''] .

Configurando el puerto de escucha NGINX

Por defecto, NGINX escuchará en el puerto especificado en external_url o usará implícitamente el puerto correcto (80 para HTTP, 443 para HTTPS). Si está ejecutando GitLab detrás de un proxy inverso, es posible que desee anular el puerto de escucha a otra cosa. Por ejemplo, para usar el puerto 8080:

nginx[''listen_port''] = 8080

Del mismo modo, para GitLab CI:

ci_nginx[''listen_port''] = 8081

Compatible con SSL con proxy

Por defecto, NGINX detectará automáticamente si se usa SSL si external_url contiene https:// . Si está ejecutando GitLab detrás de un proxy inverso, es posible que desee mantener el external_url como una dirección HTTPS, pero se comunica internamente con el GitLab NGINX a través de HTTP. Para hacer esto, puede deshabilitar HTTPS utilizando la opción listen_https :

nginx[''listen_https''] = false

Del mismo modo, para GitLab CI:

ci_nginx[''listen_https''] = false

Tenga en cuenta que puede necesitar configurar su proxy inverso para reenviar ciertos encabezados (por ejemplo, Host , X-Forwarded-Ssl , X-Forwarded-For , X-Forwarded-Port ) a GitLab.

Puede ver redirecciones o errores inadecuados (por ejemplo, "422 Entidad no procesable", "No se puede verificar la autenticidad del token CSRF") si olvida este paso. Para más información, ver:

• ¿Cuál es el estándar de facto para que un proxy inverso diga al backend que se usa SSL?
• https://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy

Para ir más lejos, puede seguir los documentos oficiales en https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#using-a-non-bundled-web-server

Configurando nuestro servidor virtual gitlab

Instalación de Phusion Passenger

Necesitamos instalar ruby ​​(gitlab ejecutar en conjunto con un ruby ​​incluido) globalmente en el sistema operativo

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

Recompile nginx con el módulo de pasajeros

En lugar de Apache2 por ejemplo, nginx no se puede conectar con módulos binarios sobre la marcha. Se debe volver a compilar para cada nuevo complemento que desee agregar.

El equipo de desarrolladores de pasajeros de Phusion trabajó arduamente para proporcionar un " paquete de versión nginx de pasajeros ": contenedores nginx compilados con plugin de pasajeros.

Entonces, vamos a usarlo:

requisito : tenemos que abrir nuestro puerto TCP 11371 (el puerto de la APT key ).

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 561F9B9CAC40B2F7 $ sudo apt-get install apt-transport-https ca-certificates creando passenger.list

$ sudo nano /etc/apt/sources.list.d/passenger.list

con estas líneas

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

usa el repositorio correcto para tu versión de Ubuntu. Para Ubuntu 15.04 por ejemplo: deb https://oss-binaries.phusionpassenger.com/apt/passenger vivid main

Editar permisos:

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

Actualización de la lista de paquetes:

$ sudo apt-get update

Permitirlo como unattended-upgrades

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

Encuentra o crea este bloque de configuración en la parte superior del archivo:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
// you may have some instructions here
};

Agregue lo siguiente:

// 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";
};

Ahora (re) instale nginx-extra y 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

configurarlo

Descomente las directivas passenger_root y passenger_ruby en el archivo /etc/nginx/nginx.conf :

$ sudo nano /etc/nginx/nginx.conf

... para obtener algo como:

##
# 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;

crear la configuración del sitio nginx (el conf de host virtual)

$ 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;
}

Ahora podemos habilitarlo:

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

No hay a2ensite equivalente de a2ensite venga de forma nativa con nginx, entonces usamos ln , pero si lo desea, hay un proyecto en github: nginx_ensite : nginx_ensite y nginx_dissite para habilitar y deshabilitar el host virtual rápido

Este es un script de shell (Bash) que replica para nginx el Debian a2ensite y a2dissite para habilitar y deshabilitar sitios como hosts virtuales en Apache 2.2 / 2.4.

Está hecho :-). Finalmente, reinicie nginx

$ sudo service nginx restart

Con esta nueva configuración, puede ejecutar otros hosts virtuales junto a gitlab para servir lo que desee

Simplemente cree nuevas configuraciones en /etc/nginx/sites-available .

En mi caso, hice funcionar y servir de esta manera en el mismo host:

• gitlab.mycompany.com - la asombrosa plataforma de git escrita en rubí
• ci.mycompany.com - el servidor de integración continua gitlab escrito en ruby
• npm.mycompany.com - un registro privado de npm escrito en node.js
• bower.mycompany.com - un registro de node.js privado escrito en node.js
• packagist.mycompany.com - un packagist privado para el registro del composer escrito en php

Por ejemplo, para servir npm.mycompany.com :

Crea un directorio para registros:

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

Y complete un nuevo archivo de configuración de vhost:

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

Con esta configuración

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;
}
}

Luego habilítelo y reinícielo:

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

Answer 2

Como no me gustaría cambiar el servidor nginx para gitlab (con algunas otras integraciones), la forma más segura estaría debajo de la solución.

también según

Gitlab: Ningx => Insertar configuraciones personalizadas en la configuración de NGINX

edita el /etc/gitlab/gitlab.rb de tu gitlab:

nano /etc/gitlab/gitlab.rb

y desplácese a nginx [''custom_nginx_config''] y modifique como se indica a continuación, asegúrese de descomentar

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

crea el nuevo dir de configuración:

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

y agrega contenido a tu nueva configuración

# 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; }
}

y reconfigure gitlab para obtener las nuevas configuraciones insertadas

gitlab-ctl reconfigure

para reiniciar nginx

gitlab-ctl restart nginx

para verificar el registro de errores de nginx:

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