TOBA con DOCKER

[rfarias]

Hola a todos cómo están?
quería consultarles si existe alguna manera de setear el archivo docker-compose.yml para que el instalador de toba reconozca una clave para postgres diferente a la que viene por defecto (postgres). He intentado cambiando la variable POSTGRES_PASSWORD  del archivo, pero el instalador al parecer continúan intentando autenticarse con la clave por defecto.
Otra consulta, es si es posible setear el docker-compose.yml, o el docker.env, para que la instalación de toba se como instancia de producción.
La última consulta que quisiera hacer es donde alojar la sql que crea la base del proyecto. He configurado las siguientes variables en el docker-compose.yml pero la base del proyecto no se crea:

Código: [Seleccionar]

TOBA_DIR: /var/local/toba
TOBA_INSTALACION_DIR: /var/local/toba/docker-data/instalacion
TOBA_PROYECTO                     : tuinformation
TOBA_BASE_NOMBRE                  : tuinformation
TOBA_PROYECTO_DIR                 : /var/local/toba/proyectos/tuinformation
TOBA_PROYECTO_ALIAS               : /tutarjeta
TOBA_PROYECTO_INSTALAR            : "true"
TOBA_PROYECTO_INSTALAR_PARAMETROS : --base-nombre tuinformation

Saludos a todos

[richard]

Hola Roberto,

estas usando la imagen 'docker-toba' o vas por el camino que esta especificado en la wiki?, en este ultimo caso, te diria que al instalar uses el comando instalacion_silenciosa que fue hecho para scriptear toda la instalacion y por tanto tiene configurable cada uno de sus parametros. El comando instalar comun pregunta las cosas por pantalla asi que no presupone que el user de bd venga especificado por una variable de entorno.

En el caso de instalacion_silenciosa lo que te va a solicitar es el path a un archivo de texto que contenga la clave del motor, lo mismo si queres poner una clave de administrador para la instalacion.

Las guias de instalacion de la wiki estan siempre pensadas para desarrollo, para cuando se llega a la instalacion de produccion... se supone que ya tenes suficiente conocimiento del framework como para encararla por tu cuenta.

Saludos

[rfarias]

Gracias Richar por tu respuesta.
Desarrollamos un sistema  y los van a poner en producción en un entorno basado en docker.
Partimos del archivo docker-template.env, donde se usa la imagen siutoba/docker-toba para personalizarlo y crear un .env que permita la instalación en producción de toba.
Desconocía el comando instalacion_silenciosa.
La idea era poder setear correctamente el .env y que la instalación de toba como instancia de producción sea automática.
De todos modos aún sin poder hacerlo, podemos ingresar luego al contenedor y cambiar la instancia de desarrollo a producción, cambiar la clave del usuario postgres y crear la base datos del proyecto y el resto de las configuraciones sobre el contenedor que tienen que ves más con el apache  (para todo también estamos armando un script).
Todo esto se debe a que en realidad no tendremos acceso a la consola del servidor por políticas de seguridad de redes, por lo cual nos piden lograr la máxima automatización posible .
Volviendo al comando instalacion_silenciosa la estructura del archivo yml está en la wiki?

[richard]

Hola Roberto,

gracias por la aclaracion. La imagen docker-toba tiene un archivo toba.sh donde aparecen todas las variables de entorno que se usan durante la instalacion y donde podes ver que valores por defecto toma cada una. Seguramente vas a tener que tocar varias, tambien es un archivo que va a ir cambiando con las versiones de toba.. ya sea para incorporar o quitar cosas, asi que es bueno que tengas presente que mirandolo podes sacar info valiosa.

Por otro lado, esas imagenes fueron diseñadas pensando en desarrollo y por tanto hacen algunas concesiones y llevan a cabo pasos que en un entorno de produccion no tienen sentido alguno (instalar el editor por ejemplo). Ademas, la config de Apache no esta optimizada en lo mas minimo para produccion y la parte de SSL necesita encararse de otra manera, no tanto la parte de toba (que ya tiene una modificacion hecha para la proxima version grande) sino para la parte del SO y Apache (no confiar en la CA indicada, desactivar los algos inseguros (< TLS 1.2), etc).  La idea primordial aqui era brindarle a los desarrolladores espacios de trabajo donde no tuvieran que preocuparse por las versiones a instalar y que fuera algo replicable.

Dicho esto, no hay ningun problema con que la usen de modelo para generarse una imagen propia donde si se tomen en cuenta aspectos que son propios de un ambiente de produccion. O nos manden sugerencias sobre como ir mejorando estas.

Saludos