Saltar al contenido principal
Version: 1.8.1

Repositorio de configuración

El proyecto es distribuido a traves de un repositorio GIT compuesto por un conjunto de definiciones de stacks de Docker Swarm que permiten desplegar un entorno de producción de referencia. Para instalar el proyecto, comience clonando el repositorio.

git clone -b master https://hub.siu.edu.ar/siu/expedientes

El branch master es el que contiene siempre la última versión estable.

Si va a comenzar con la instalación de producción de su institución vea esta sección.

Contenido

Los siguientes archivos con formato Docker Compose especifican los stacks principales de la solución.

ArchivoArchivo
prod/sudocu/sudocu.ymlEspecificación stack Sudocu
prod/arai/usuarios.ymlEspecificación stack Araí-Usuarios
prod/arai/docs.ymlEspecificación stack Araí-Documentos
prod/arai/huarpe.ymlEspecificación stack SIU-Huarpe

Login en la Registry de Imagenes

Las imágenes de Docker referenciadas en las descripciones de los Stacks se encuentran en un repositorio del SIU que requiere autenticación. Para continuar auntentiquese en el mismo

docker login hub.siu.edu.ar:5005

Forma de trabajo

El repositorio entregado está pensado como una base para crear una instalación personalizada para la institución de la solución.

Para llevar adelante el deploy exitosamente se recomienda mantener un repositorio propio que se vaya sincronizando con el del SIU para poder acceder a las nuevas versiones.

A continuación veremos una forma simple de mantener el repositorio local.

Creación del repo

Imaginemos que se creó el repositorio https://git.uunn.local/deploy vacío. Para comenzar a trabajar lo primero que hay que hacer es clonar este repo:

git clone https://git.uunn.local/deploy

Luego hay que establecer como upstream el repositorio del SIU:

git remote add upstream https://hub.siu.edu.ar/siu/expedientes.git

Una vez hecho esto, se contará con un repositorio listo para sincronizarse con el del SIU

Descarga inicial

En este momento, el directorio de trabajo se encuentra vacío. Para obtener los fuentes desde upstream ejecutar el siguiente comando:

git fetch upstream

Una vez completado ese paso ejecutar

git merge upstream/master

Si ahora ejecutamos ls veremos que ya tenemos el código en nuestra working copy. Podemos ejecutar el siguiente comando para verificar a que versión estamos apuntando.

cat version

Este es un buen momento para subir el código a nuestro repositorio local:

git push

Modificar localmente

Una vez completados los pasos anteriores ya estamos listos para empezar a trabajar. Se deberán editar los archivos (como se ve a lo largo de todo el resto de la documentación) para reflejar nuestra instalación. Esto es, cambiar urls, configuraciones de certificados, secretos, etc.

Cuando llegamos a una configuración deseada en la que estamos contentos con el deploy realizado es momento de comitear nuestro trabajo y subirlo. Se deberan agregar los cambios al stage y crear un nuevo commit:

git commit -m "config inicial"

Es recomendable subirlo:

git push

Actualizar versión

Imaginemos que se libera una nueva versión de la solución. El objetivo de este paso es lograr incorporar los cambios de la nueva versión sin perder los cambios propios de nuestra instalación. Para hacer esto ejecutaremos (sobre la working copy sin cambios):

git fetch upstream

y

git merge upstream/master

En este estado tendremos en nuestra working copy los cambios de la nueva versión mezclados con nuestros cambios locales. Es posible que en este paso ocurra algún conflicto. Si es así, seguir los pasos indicados en el output del merge.

IMPORTANTE: Antes de hacer el deploy de estos cambios hay que mirar en detalle el CHANGELOG de la versión descargada para asegurarse que no haya ningún cambio bloqueante.

Una vez que se haga el deploy exitosamente, es momento de comitear los cambios y subirlos a nuestro repositorio.

git commit -m "Actualización a vX.Y.Z"
git push

Posibles Mejoras

El esquema de manejo de versiones aquí provisto asume que existe un sólo branch en el repositorio local y que en la institución se hace sólo un deploy, el de producción.

Esto puede llegar a ser limitado si quiere contar con diferentes stages que permitar probar las nuevas versiones antes de ponerlas en producción.

Si se desea hacer un manejo multi-stage es recomendable mantener un branch para cada stage por separado y cada uno manejarlo de la misma manera que se maneja master en el esquema presentado.