GitLab: Montando un entorno GIT multiusuario

Tal como expusimos en otro post, un sistema de control de versiones debería ser algo que todos los que nos movemos en entornos de desarrollo y administración de sistemas deberíamos conocer y utilizar. Mucha gente conoce GIT gracias al gran sistema y comunidad montado entorno a GitHub, pero hoy vamos a ver cómo montar nuestro sistema GIT centralizado, con control de usuarios y permisos utilizando el paquete de software libre GitLab.

Instalando la edición Community de GitLab

Al igual que muchos otros proyectos de Software Libre, GitLab comenzó siendo un proyecto libre del cual terminaron surgiendo dos versiones diferenciadas:

  • Community edition: Versión completamente libre, apoyada por la comunidad y de la cual nos podemos descargar el código fuente (licencia MIT).
  • Enterprise edition: Versión basada en la anterior, con características añadidas a base de pagar un precio mensual. gitlab-install

Nosotros vamos a realizar la instalación de la edición Community en la última versión de Debian, la 8 conocida como Jessie, recientemente publicada. Utilizaremos una instalación del sistema base de Debian, utilizando el CD «netinst» y a partir de ahí instalaremos los paquetes que vayamos necesitando. Durante la instalación le hemos dado al servidor el nombre de repos.irontec.com, el cual usaremos luego para acceder al GitLab recién instalado.

Dentro de los modos de instalación de casi cualquier proyecto de Software Libre podemos elegir entre utilizar el código fuente y realizar una instalación basada en él, o realizar la manera sencilla, que es la utilización de paquetes creados para nuestra distribución. Dada la manera de funcionar de Debian, todavía no existen paquetes para GitLab en los repositorios oficiales, por lo que utilizaremos el sistema de instalación y los pasos que nos muestran en la web de GitLab. La ventaja de esta opción es que nos va a instalar todo el software que necesitamos en un «pack» autocontenido sin necesidad de tener que ir configurando cada servicio por separado.

Tal como se puede ver, existen paquetes de GitLab para las versiones LTS de Ubuntu 12.04 y 14.04, así como para Debian 7 y 8, sin olvidar las versiones 6 y 7 de CentOS (y sus versiones de RedHat). Elegiremos, tal como hemos comentado antes, Debian 8 para ver los pasos a seguir.

apt-get install curl ca-certificates postfix

GitLab manda e-mails cada vez que aparece un evento, por lo que necesitamos un servidor de correo. En este caso hemos elegido postfix, y durante la configuración del mismo hemos seleccionado que nuestro servidor es un «sistema satelite», configurándolo adecuadamente a nuestro entorno. Aquí cada uno es libre de elegir instalar otro servidor de correo como exim y utilizar la configuración que más le convenga.

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash

Con este comando nos añadirá un fichero /etc/apt/sources.list.d/gitlab_gitlab-ce.list en el que aparecerán los repositorios donde poder descargar el paquete y el código fuente.

# this file was generated by packages.gitlab.com for
# the repository at https://packages.gitlab.com/gitlab/gitlab-ce

deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ jessie main
deb-src https://packages.gitlab.com/gitlab/gitlab-ce/debian/ jessie main

Instalamos GitLab

apt-get install gitlab-ce

Y por último, tal como nos dice al finalizar la instalación, configuramos GitLab

gitlab-ctl reconfigure

Este comando ejecutará varias opciones de configuración, así como de cambio de permisos de ficheros, creará el usuario de administración global… y, por último, iniciará el servicio completo de GitLab. Una vez terminado, podremos ir a nuestro navegador a http://repos.irontec.com/ (antes deberéis realizar la configuración de vuestro DNS local) y veremos la página de login de GitLab. Como veremos más adelante, este comando lo tendremos que utilizar cada vez que realicemos alguna modificación en el fichero de configuración global.

gitlab-inicio

Tras la instalación, el usuario creado es root , y la contraseña de acceso es 5iveL!fe . Una vez introducidos estos credenciales, nos pedirá que cambiemos la contraseña dado el problema de seguridad que conlleva tener una contraseña genérica. Con esto, ya tendremos acceso a la parte de administración y podemos empezar a crear grupos, proyectos o modificar las configuraciones por defecto.

En este punto, ya tendremos nuestro sistema de repositorios centralizado con GitLab terminado, pero vamos a realizar un par de modificaciones que se adecúan mejor a nuestro entorno de trabajo en Irontec.

Modificando el archivo de configuración global de GitLab

Las modificaciones que realizaremos serán todas en el fichero de configuración global /etc/gitlab/gitlab.rb, que contiene gran parte de las opciones que podemos modificar, así como enlaces a la documentación. Cada vez que realicemos una modificación deberemos regenerar la configuración para que GitLab se de cuenta de ello y reinicie los servicios necesarios. Para ello deberemos ejecutar:

gitlab-ctl reconfigure

Securización con SSL

El código que almacenamos en los repositorios puede ser importante, pero si nos conectamos al servidor sin una conexión segura seguiremos siendo vulnerables. Por lo tanto, vamos a hacer que el servidor sea accesible vía HTTPS. Para ello, en el fichero de configuración comentado anteriormente nos aseguraremos que tenemos lo siguiente puesto:

external_url 'https://repos.irontec.com'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/ssl/irontec/irontec-bundle.crt"
nginx['ssl_certificate_key'] = "/etc/ssl/irontec/wildcard.key"

Con esto los repositorios serán accesibles por HTTPS y si intentamos conectarnos vía HTTP nos redirigirá al sistema seguro.

Autenticación mediante LDAP

Habitualmente en las empresas se suele tener un sistema basado en LDAP para la gestión de usuarios, por lo que nos puede interesar que usemos el LDAP ya montado para la autenticación. Para ello, usaremos la siguiente configuración (adaptándola a vuestro entorno, ya que este es el nuestro):

 gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
   main: # 'main' is the GitLab 'provider ID' of this LDAP server
     label: 'LDAP'
     host: '10.123.123.4'
     port: 636
     uid: 'uid'
     method: 'ssl' # "tls" or "ssl" or "plain"
     active_directory: true
     allow_username_or_email_login: false
     base: 'ou=irontec, ou=usuarios, dc=irontec, dc=com'
     user_filter: ''
EOS

Y para evitar que se puedan crear usuarios y poder autenticarse fuera del LDAP, desde el apartado settings deshabilitaremos la opción «Signup enabled».

Crear y usar repositorios

Ya estamos logueados con nuestro usuario de LDAP, y ya tenemos acceso seguro mediante SSL, ¿y ahora? Podemos crear un proyecto nuevo o importarlo de otro repositorio GIT que tengamos. Podemos crearlo con unos niveles de visibilidad dependiendo de lo que más nos interese:

  • Privado: Solo accesible por nosotros y por los usuarios a los que dejemos acceso.
  • Interno: Cualquier usuario logueado puede hacer un clon del proyecto
  • Público: El proyecto podrá ser clonado por cualquiera sin necesidad de autenticarse.

Para las pruebas crearemos un proyecto privado con nombre «probando-git». Ahora ya solo nos faltará clonar el repositorio en nuestro equipo y empezar a hacer commits de nuestro código.

Clonado por SSH

Si queremos clonar el repositorio utilizando el sistema basado en clave pública/privada de SSH deberemos asegurarnos que subimos nuestra clave pública (normalmente dentro del directorio ~/.ssh/) al apartado «SSH Keys» dentro del apartado de configuración de nuestro usuario. Una vez subida la clave, podremos realizar el clon de la siguiente manera:

git clone [email protected]:rgomez/probando-git.git

Podremos añadir varias claves públicas SSH de cuantos equipos queramos conectarnos. Si en algún momento creemos que nuestra clave pública ha sido comprometida, deberemos ir al apartado donde la hemos añadido y eliminar la clave comprometida.

Clonado por HTTPS

Si queremos utilizar el sistema de autenticación de LDAP puesto en el paso anterior, deberemos ejecutar el siguiente comando y cuando nos pida usuario y contraseña poner nuestros credenciales de LDAP:

git clone https://repos.irontec.com/rgomez/probando-git.git

Configuración ~/.gitconfig

Ya tenemos un repositorio clonado, y ahora es momento de ir añadiendo nuestro código. A lo largo del tiempo que he ido usando GIT he ido acumulando unos alias para facilitarme en el día a día que puede que sean de interés general. Esta configuración debe ir en nuestro fichero de configuración ~/.gitconfig

[user]
    name = TU NOMBRE
    email = [email protected]
[color]
    branch = auto
    diff = auto
    grep = auto
    status = auto
    ui = auto
    interactive = auto
[core]
    excludesfile = /home/ruben/.gitignore
[alias]
    a = add
    c = commit
    co = checkout
    d = diff --color-words
    dn = diff --name-status
    ds = diff --stat
    l = log
    b = branch
    #ficheros ignorados, por el .gitignored
    i = ls-files --others -i --exclude-standard
    sb = show-branch
    #distintas maneras de ver la grafica
    g = log --graph --pretty=fuller
    #lg = log --graph --all --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
    lg = log --graph --all --pretty=format:'%C(yellow)%h%Creset -%C(bold green)%d %Creset%s%C(cyan) %ar %Cblue%an'
    ld = log --graph --all --pretty=format:'%C(yellow)%h%Creset -%C(bold green)%d %Creset%s%C(cyan) %ar %Cblue%an' --date-order
    #me enseña los cambios del commit pasado como parametro o del último
    l1 = log -1 -p
    limpia = clean -fdx
    st = status
    track = "for-each-ref --format=\"local: %(refname:short) <--sync--> remote: %(upstream:short)\" refs/heads"

Hay muchas más y es fácil encontrar en internet gente que comparte sus configuraciones, por lo que os animo a que si tenéis algún alias útil nos lo dejéis en los comentarios. Por nuestra parte, seguiremos compartiendo nuestras experiencias y hallazgos del departamento de Sistemas de Irontec… ¡en próximos posts!



¿Te gusta este post? Es solo un ejemplo de cómo podemos ayudar a tu empresa...
Sobre Roman Gomez

Desarrollador full stack

1 Comentario

¿Por qué no comentas tú también?


  • […] anteriores entradas se ha hablado sobre qué es GitLab y qué es Composer. En esta ocasión vamos a combinar estas dos herramientas, para la gestión e […]

    Combinando GitLab y Composer en nuestros proyectos | Blog Irontec Hace 9 años Responde


  • Muy buen artículo pero
    Me gustaría saber si existe alguna forma de que, una vez montado el Gitlab y todo esté funcionando sepuede limitar que cuando un usuario se loguee por defecto no tenga permisos para crear proyectos o grupos
    Sldos Espero respuesta

    Yi Hace 7 años Responde


Queremos tu opinión :)