Servidor listo para usar
GitLab
Gestión de Gits auto-apropiado & DevOps Toolchain
- Basado en Debian
- Actualizaciones de seguridad automáticas
- Libre y de código abierto
Capturas de pantalla GitLab
GitLab es una única aplicación para todo el ciclo de vida del desarrollo de software. Desde la planificación de proyectos y la gestión de código fuente a CI/CD, monitoreo y seguridad. GitLab proporciona control de la versión basado en Git, envasado con una cadena completa de herramientas DevOps. Algo como GitHub, pero mucho, mucho más.
Este appliance incluye todas las características estándar en TurnKey Core, y encima de eso:
Configuraciones GitLab:
GitLab, RubyGems, PostgreSQL, Nginx y todos los demás componentes necesarios instalados desde el río Paquete Omnibus.
Nota de seguridad: Actualizaciones a GitLab pueden requerir supervisión para que ARE NOT configurado para instalar automáticamente. Vea a continuación para actualizar GitLab. Y/o vea Documentación de GitLab.
Establecer la contraseña y el correo electrónico de GitLab admin en el primer arranque (conveniencia, seguridad).
Establecer el dominio GitLab para servir en la primera bota (conveniencia).
Activar GitLab Omnibus incorpora certificados Let's Encrypt a través de plugin Confconsole (bajo "Lets Encrypt").
Incluye postfix MTA (en adelante, localhost) para el envío de correo electrónico (por ejemplo, recuperación de contraseñas). También incluye el módulo de postfix webmin para comodidad.
Actualización manual supervisada GitLab
Compruebe las versiones instaladas y elegibles sin cambiar el appliance:
gitlab-update --check
Antes de una actualización, consulte la GitLab actualización de la ruta y la liberación específica Documentación de GitLab. GitLab requiere paradas de actualización intermedia. Retrocede el appliance, luego instale la siguiente versión elegible explícitamente:
apt update apt install gitlab-ce=<version>
Repita los cheques de aceptación de la aplicación antes de proceder a otra parada requerida. apt-cache Madison gitlab-ce y el blog de lanzamiento de GitLab.
Si APT reporta una clave de repositorio caducada o NO_PUBKEY, seguir el procedimiento de rotación de repositorio-key. Conserva el depósito por firmada restricción y verifica la huella completa publicada de GitLab.
Credenciales (palabras puestas en la primera bota)
Webmin, SSH: nombre de usuario root
GitLab: nombre de usuario root
Correr desde el navegador
V 18.1
GitHub
Detalles de uso " Iniciar sesión en Administración
No contraseñas predeterminadas: Por razones de seguridad no hay contraseñas predeterminadas. Todas las contraseñas se establecen en inicialización del sistema tiempo.
Ignora la advertencia del navegador SSL: los navegadores no les gustan los certificados SSL auto-firmados, pero este es el único tipo que se puede generar automáticamente. Si usted tiene un dominio configurado, entonces vía Confconsole Menú avanzado, usted puede generar gratis Vamos a encipt SSL/TLS certificados.
Web - apuntar su navegador en cualquiera de los dos:
- http://12.34.56.789/ - no cifrado así que no hay advertencia del navegador
- https://12.34.56.789/ - encriptado con certificado SSL auto-firmado
Nota: algunos appliances autodirecto http a https.
Nombre de usuario para gitlab:
Iniciar sesión como nombre de usuario root
Nombre de usuario para la administración del sistema operativo:
Iniciar sesión root excepto en Mercado AWS que utiliza el nombre de usuario admin.
- Indica tu navegador para:
- https://12.34.56.789:12321/ - Panel de control de sistemas
- https://12.34.56.789:12320/ - Terminal de línea de comandos basado en la web
- Iniciar sesión con SSH cliente:
ssh root@12.34.56.789
Caso especial para el mercado AWS:
ssh admin@12.34.56.789
* Reemplazar 12.34.56.789 con un IP válido o nombre de host.
Documentación
v15.2+ : Paquete Omnibus
En v15.2, el TurnKey GitLab appliance incluye GitLab instalado a través del Paquete Omnibus. versiones anteriores de TurnKey GitLab provistas a fuente de instalación. Desafortunadamente este cambio será un poco de dolor para el usuario existente ya que necesitará un migración manual de origen a Omnibus. Se prevé que este dolor a corto plazo se verá compensado por la mayor facilidad de mantenimiento/actualizaciones de GitLab que avanza (tanto usuarios finales como TurnKey). Este cambio se inició tras una reacción significativa de los usuarios, algunas conversaciones grandes que pesan los pros y contras, además del dolor continuo de mantener la instalación de la fuente appliance.
Migrando desde anteriores instancias TurnKey GitLab
Desafortunadamente, no hay una manera sencilla de migrar desde una instalación de origen de GitLab a una instalación Omnibus de GitLab. Se requiere un poco de atraco alrededor, incluyendo la migración de backend DB desde MySQL DB backend (como se utiliza en TurnKey v15.1 y anterior) a PostgreSQL backend (como se suministra por Omnibus instalar en TurnKey v15.2 y más tarde).
Sin embargo, se puede hacer. Los detalles principales están cubiertos en GitLab docs. Idealmente sería mejor migrar sus datos a un Omnibus instalar manualmente primero, entonces manualmente generar una copia de seguridad GitLab. La copia de seguridad que crea, más su directorio /etc/gitlab (o al menos su archivo gitlab-secrets.json), puede ser transferido al nuevo GitLab servidor. Coloca los archivos /etc en el lugar y restaurar su copia de seguridad según los doctores GitLab.
Vale la pena señalar que si tienes una versión realmente antigua de GitLab, es posible que necesites hacer algunas actualizaciones de la fuente primero. hilo en los foros, donde un usuario actualizó de GitLab v5.0.2 (TurnKey GitLab v13.0), todo el camino a la actual GitLab (v11.x en el momento de escribir). Si usted también necesita hacer algo así, entonces espero que ese hilo sea útil. Si usted necesita un poco de apoyo, por favor no dude en iniciar un nuevo hilo (necesita ser conectado - si no tiene una cuenta de usuario de foros TurnKey, por favor registro para uno).
Debido a las limitaciones y cambios en el proceso de copia de seguridad, es recomendable actualizar al menos GitLab v9.3.0 antes de crear la copia de seguridad y migrar sus datos a través de su nuevo servidor (aunque debería ser posible migrar a Omnibus en su antiguo servidor antes de eso). También tenga en cuenta que los respaldos sólo funcionan cuando van a/a exactamente la misma versión de GitLab. I.e. el mismo método de instalación (fuente o Omnibus), número de versión y canal de liberación (Enterprise Edition aka "ee"; o Community Edition aka "ce"). Una vez que haya migrado a Omnibus y esté en v9.3 o grande, entonces puede migrar datos y reducir la versión GitLab si es necesario. A continuación se indica la versión de GitLab en TurnKey en el siguiente cuadro Restaurar manualmente Omnibus sección.
FWIW, el proceso de migración desde un servidor GitLab no TurnKey a un servidor TurnKey GItLab appliance (v15.2+) será esencialmente el mismo que migrando desde un servidor TurnKey = 0.1.
TurnKey GitLab y TKLBAM
Restauración de versiones anteriores de TurnKey (Seguido=v15.1)
Desafortunadamente, copias de seguridad TKLBAM de GitLab appliances antes de v15.2 (es decir, appliances que incluye GitLab instalado desde la fuente) no puede ser restaurado automáticamente a TurnKey GitLab v15.2+ utilizando TKLBAM. Anterior appliances debe ser primero migrado manualmente a Omnibus, como se discutió en la sección anterior sobre migrando manualmente.
Restaurar manualmente la copia de seguridad de Omnibus
Para restaurar una copia de seguridad de GitLab, debe coincidir exactamente con la versión de GitLab que la copia de seguridad viene de, a la versión a la que está restaurando. Debido a las preocupaciones acerca de los problemas que pueden ocurrir, esto es mejor hecho manualmente. TKLBAM sí tiene experimental soporte para intentar hacer esto automágicamente, si desea probar eso, por favor lea la sección siguiente Versión automagic que coincide. Si desea proceder con la restauración manual (recomendada) entonces por favor lea.