157 lines
5.6 KiB
Markdown
Executable File
157 lines
5.6 KiB
Markdown
Executable File
# GitLab
|
|
|
|
GitLab es una plataforma HostSelf para Git, bastante pesada pero con muchas propiedades, utilidades
|
|
y funcionalidades. Ésta será la plataforma de trabajo compartido que se usará.
|
|
|
|
> El Git sólo se mirará para trabajar desde Linux desde la propia VM que gestiona el proyecto. Si se
|
|
hace uso de otro sistema será mejor Googlear y no seguir esta guía.
|
|
|
|
## Instalación de GitLab
|
|
|
|
En este caso se usó un Debian puro versión 10.9.0 amd64 en Core con 4GB de RAM y 1 Core virtualizado
|
|
sobre un i7 4970K con 32GB de RAM Dual Channel 1600 en VirtualBox. Se seleccionaron solo 4GB de RAM
|
|
y 1 Core por el hecho de no trabajar, previsiblemente más de 50 personas simultáneamente, preveendo
|
|
más o menos unos 10, el resto de usuarios serán visitantes no autenticados.
|
|
|
|
La estructura de Red es acceso mediante un Router el cual establece una apertura de puertos mediante
|
|
iptables contra una máquina que vincula y balancea la carga con Nginx, y ésta será la encargada de
|
|
gestionar las peticiones contra la máquina que contiene el GitLab.
|
|
|
|
```mermaid
|
|
graph TB
|
|
R[Router] --> N[VM Nginx]
|
|
G --> N
|
|
N --> R
|
|
subgraph Servidor
|
|
N --> G[VM GitLab]
|
|
end
|
|
```
|
|
|
|
El primer problema al que nos enfrentamos es que GitLab no será quien recoja la petición de forma
|
|
directa, sino que pasará por un Proxy de entrada el cual redirigirá la petición a la máquina de
|
|
GitLab. De primeras, ésto no debería de ser un problema pero GitLab posee otro Nginx por detrás que
|
|
es el que gestiona las peticiones Web del mismo. La dirección DNS no la pilla de la petición, sino
|
|
de la cabecera X-FORWARDED-FOR, que por lo general es la dirección IP de la que parte la petición,
|
|
por lo que es necesario implementar, en este caso, una línea en la configuración del sitio Nginx con
|
|
la dirección DNS para dicha cabecera.
|
|
|
|
> **NOTA**: No vale poner $server-name, en la definición de cabeceras no funciona, lo que nos obliga
|
|
a usar una única dirección DNS como sale en el ejemplo siguiente.
|
|
|
|
```conf
|
|
server {
|
|
listen XXXXX;
|
|
server_name ~^git\.k3y\.pw$;
|
|
location / {
|
|
proxy_set_header Host $host;
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
proxy_set_header X-Forwarded-Proto https;
|
|
proxy_set_header X-Forwarded-For $remote_addr;
|
|
proxy_set_header X-Forwarded-Host git.k3y.pw;
|
|
proxy_pass https://XXX.XXX.XXX.XXX$request_uri;
|
|
}
|
|
}
|
|
```
|
|
|
|
Sabiendo esto, simplemente hemos de seguir los pasos de la guía de instalación del GitLab Enterprise
|
|
Edition, pero cambiando en todo momento "gitlab-ee" por "gitlab-ce" desde la guía oficial, la cual
|
|
dejamos a continuación:
|
|
|
|
https://about.gitlab.com/install/#debian
|
|
|
|
> En nuestro caso no tenemos instalado "sudo", por lo que hay que adaptar los comandos sobre un
|
|
entorno "su". En el caso del CURL para el Script Deb se descargó mediante "wget" y se ejecutó sobre
|
|
"su", por ejemplo.
|
|
|
|
## Establecer Memoria en el Login
|
|
|
|
Lo primero es instalar el Git en nuestro equipo, donde tendríamos las siguientes opciones más
|
|
comunes:
|
|
|
|
<table style="width:100%;">
|
|
<thead>
|
|
<tr>
|
|
<th>Debian</th>
|
|
<th>Fedora / Red Hat</th>
|
|
<th>Arch</th>
|
|
<th>Windows 10</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
```sh
|
|
apt install git
|
|
```
|
|
</td>
|
|
<td>
|
|
```sh
|
|
yum install git
|
|
```
|
|
</td>
|
|
<td>
|
|
```sh
|
|
pacman install git
|
|
```
|
|
</td>
|
|
<td>
|
|
```bat
|
|
widget install git
|
|
```
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
> La instalación por CMD de Windows 10 depende de tener el paquete del repositorio Widget. Además,
|
|
no fujncionarán algunos pasos de este manual por falta de comandos así como de recursos, como es el
|
|
almacenamiento de Keys. Por ello, desaconsejamos el uso, en la medida de lo posible, de Windows 10
|
|
para dichas tareas, y hacer uso de conexiones SSH para poder gestionarlas desde la unidad Linux
|
|
donde se encuentre el proyecto.
|
|
|
|
A continuación, independientemente del OS en el que se esté, accedemos al Terminal o Comandos y
|
|
escribimos el siguiente comando:
|
|
|
|
```sh
|
|
git clone https://git.k3y.pw/Whalers/WMarkDown.git
|
|
```
|
|
|
|
> No tenemos abierto el puerto SSH ni FTP por seguridad, por lo que la dirección SSH no funcionará.
|
|
|
|
Ahora que ya tenemos nuestro repositorio accedemos al directorio del mismo y luego a su directorio
|
|
".git" donde hallaremos un fichero llamado "config", el cual requeriremos abrir como si fuera un
|
|
fichero de texto. Dentro de éste encontraremos una línea la cual se llama "url" y se encuentra
|
|
dentro del bloque '[remove "origin"]', con la URL del repositorio. La copiamos y comentamos una, y
|
|
la otra le añadimos nuestro nombre de usuario en el servidor Git tal que así:
|
|
|
|
```conf
|
|
[core]
|
|
repositoryformatversion = 0
|
|
filemode = true
|
|
bare = false
|
|
logallrefupdates = true
|
|
[remote "origin"]
|
|
#url = https://git.k3y.pw/Whalers/WMarkDown.git
|
|
url = https://USUARIO@git.k3y.pw/Whalers/WMarkDown.git
|
|
fetch = +refs/heads/*:refs/remotes/origin/*
|
|
[branch "master"]
|
|
remote = origin
|
|
merge = refs/heads/master
|
|
```
|
|
|
|
Finalmente, establecemos un tiempo de memoria caché para que la contraseña solo nos la pida una vez
|
|
cada X tiempo que nosotros decidamos mediante el siguiente comando, teniendo en cuenta que el tiempo
|
|
se establece en segundos.
|
|
|
|
```sh
|
|
git config --global credential.helper "cache --timeout TIEMPO"
|
|
```
|
|
|
|
> Los valores de tiempo serían los siguientes:
|
|
- TIEMPO = 7200 => 2 horas.
|
|
- TIEMPO = 3600 => 1 hora.
|
|
- TIEMPO = 84600 => 1 día.
|
|
|
|
Sobre todas estas operaciones solo nos pedirá la contraseña una vez hasta pasado el tiempo del
|
|
Timeout de la Caché.
|