Se me presento una duda al momento de integrar Diaguita al portal Huarpe, en el instructivo dice que debemos desplegar el contenedor usr-cmd para luego importar la cuentas de usuarios.
Cuando realizo el deploy y luego hay que conectarse al contenedor para importar el archivo JSON con las cuentas de usuarios a qué contendor se refiere? Porque como usr-cmd solo veo un servicio pero no encuentro un contenedor con un nombre similar, o se refiere a otro contenedor?
En efecto no esta corriendo, fijate que la cantidad de replicas dice 0/1. yo miraria los logs de ese contenedor en particular a ver por que motivo al hacer el deploy del stack no quedo corriendo.
docker logs usr-cmd_idm
Por otro lado, el instructivo esta armado alrededor de la v1.0.2 de Expedientes, el cual utiliza la version 3.0.2 de Arai-Usuarios, es mas el archivo yml que se menciona tambien tuvo cambios justamente en dicha version, no digo que no pueda funcionar con la version anterior… pero quizas necesita ajustes manuales que fueron resueltos en la nueva version.
Si al mirar los logs no encontras alguna causa basica, por ej: que falto configurar algun secret…etc… haria el intento con las versiones tal cual aparecen en el instructivo.
si, hace unos dias salio la version 1.0.2 de Expendientes, la misma tiene la version 3.0.2 de Arai-Usuarios y se corresponde con la documentacion que estas mirando.
normalmente, con “docker stack deploy” se actualiza los contenedores web y/o servicios definidos. Para los cambios que hay en el repositorio de expedientes, es suficiente.
Lo que no se actualiza con ese comando es las bases de datos. Eso tienen que tener en cuenta, por ej ir revisando lo que informa cada sistema y/o lo que se documenta. Por ej, en arai-usuarios sólo les faltaría insertar el número de la versión.
boot_idm: solo se usa para inicializar el IDM (registrar como app y crear user admin)
crear_db_docs_crear-base: se usa para inicialziar la db de documentos
usr-cmd_idm: se usa para correr algún comando administrativo sobre el IDM (importar usuarios vía json, por ej.)
Todos estos servicios, normalmente se pueden eliminar, no deberían quedar ejecutandose ni son requeridos en forma constante. Tienen misiones muy puntuales y de corta duración.
Respecto a si el servicio esta teniendo réplicas o no, depende. Pudo haberse iniciado, ejecutado su tarea, finalizado con éxito. Como es el caso de “crear_db_docs_crear-base”. Puede pasar que también haya sucedido un error. Cuando administren contenedores, tienen que manejar el orquestador en profundidad… podes por ejemplo revisarlo con “docker service ps boot_idm --no-trunc” para ver el estado del servicio. O mientras se ejecuta el servicio, podes ver los logs de la ejecución con “docker service logs usr-cmd_idm”.
De acuerdo a lo que me comento Richard acá, me dice que el problema está con el servicio usr-cmd_idm
En efecto no esta corriendo, fijate que la cantidad de replicas dice 0/1. yo miraria los logs de ese contenedor en particular a ver por que motivo al hacer el deploy del stack no quedo corriendo.
El error que reporte es este:
/usr/local/proyectos/expedientes/prod/arai/util# docker exec -it v99c2defbdwo bash
Error: No such container: v99c2defbdwo
Y el log no tiene informacion.
Y no puedo contnuar con la integracion de Diaguita al ecosistema.
Lo que intente fue explicarte por que motivo estabas viendo esa respuesta de parte de docker, quizas deberia haber sido mas explicito y decirte que no se le puede pedir a un contenedor que no esta corriendo que ejecute un comando en su interior o conectarse al mismo, asumi que esa parte ya la tenias cocinada por lo que habias avanzado en la documentacion.
Y el log no tiene informacion.
Aca la pifie yo con el comando que te pase, no me percate que cuando estas en swarm necesitas accederlos via [b]docker service [/b] para todo, inclusive los logs. Proba con los comandos que puso Sergio para revisar el contenedor a ver si aparece algun log, por mas minimo que sea algo deberia de tener si se crea.