feat: migrate to new dnpm:dip node #251
Conversation
This is an old relic, I used it to debug traffic ages ago. I think we should have removed that long ago. |
| volumes: | ||
| - /etc/bridgehead/dnpm:/bwhc_config:ro | ||
| - ${DNPM_DATA_DIR}:/bwhc_data | ||
| - dnpm-authup:/usr/src/app/writable |
There was a problem hiding this comment.
Can we mount that to a folder instead of a volume? Docker volumes are always forgotten
There was a problem hiding this comment.
I guess we could mount it to where it was before which is this DNPM_DATA_DIR path that was usually in /etc/bridgehead/dnpm somewhere but I am not a huge fan of that location. Not sure what data is actually stored there if its patient data I would not necessarily store it under /tmp/bridgehead or /var/cache/bridgehead
There was a problem hiding this comment.
/var/cache/ is not persistant enough for this kind of data, as it can't be reconstructed in case of a cache clearing. Obviously, /etc/bridgehead/... is a bad solution that was only used to use an already established path. I would propose to create a /var/bridgehead/ directory @lablans @torbrenner ?
| MYSQL_ROOT_HOST: "%" | ||
| MYSQL_ROOT_PASSWORD: ${DNPM_MYSQL_ROOT_PASSWORD} | ||
| volumes: | ||
| - dnpm-mysql:/var/lib/mysql |
There was a problem hiding this comment.
Can we mount that to a folder instead of a volume? Docker volumes are always forgotten
There was a problem hiding this comment.
I mean I tend to say that random docker volume paths are also often forgotten but yeah lets keep it in the spirit of the bridgehead and map it somewhere. /var/cache/bridgehead/dnpm/mysql?
| - NUXT_API_URL=http://dnpm-backend:9000/ | ||
| - NUXT_PUBLIC_API_URL=https://${HOST}/api/ | ||
| - NUXT_AUTHUP_URL=http://dnpm-authup:3000/ | ||
| - NUXT_PUBLIC_AUTHUP_URL=https://${HOST}/auth/ |
There was a problem hiding this comment.
If I see that correcly, there is still no way to expose the dnpm portal under a non-root path? Currently, it collides with the bridgehead landing page why I included all that override stuff in the dnpm-setup.sh logic.
There was a problem hiding this comment.
Well I guess we might be able to make it work under a different path with some traefik magic.
There was a problem hiding this comment.
I'm not convinced, as we would need to adapt all the links and calls of the frontend as well.
There was a problem hiding this comment.
But as you can see here the frontend actually lets you configure the public api url and the public auth url and for the calls to the frontend itself we could redirect those with traefiks StripPrefix middlewares I think. But of course we dont have to I just think it would be possible. If we want to actually do it I can try to figure something out
| - AUTHUP_URL=robot://system:${DNPM_AUTHUP_SECRET}@http://dnpm-authup:3000 | ||
| volumes: | ||
| - /etc/bridgehead/dnpm/config:/dnpm_config | ||
| - dnpm-backend-data:/dnpm_data |
There was a problem hiding this comment.
Why does this have persistance as well? Again, maybe bind to a directory
There was a problem hiding this comment.
Yeah I was also surprised by all the docker volumes. I just copied them as is to make it work quickly. This is the dnpm-backend tho which does contain patient data so we might want to have it in a docker volume as with blaze
| - "traefik.enable=true" | ||
| - "traefik.http.routers.dnpm-backend.rule=PathPrefix(`/api`)" | ||
| - "traefik.http.services.dnpm-backend.loadbalancer.server.port=9000" | ||
| - "traefik.http.routers.dnpm-backend.tls=true" |
There was a problem hiding this comment.
I assume whe have to expose the ETL endpoints as well. I forwarded you the configuration on the 5th of november.
There was a problem hiding this comment.
Hm looking into the mail it seems they made it work with the old bwhc backend. There the endpoint was under /bwhc which now seems to be /api in most cases so they might be able to ask for <BK_URL>/api/etl which would work with this traefik rule?
There was a problem hiding this comment.
I was hoping to clamp the ETL-API acces more down by enforcing at least a basic auth. But I have to study the DNPM:DIP API description to give an answer.
The files under
ccp/are only copies of the files underminimal/.I removed the
/apipath from traefik as it was conflicting with dnpms backend path.I have never seen anyone of us actually use the traefik frontend but I think
/dashboardis a better name anyway but if we want to keep it that way we might be able to do a bit of traefik path rewriting to make it work without this change.Maybe we can even backport this to the
dnpm-extra-brokerbranch?