Add Dockerfiles and docker-compose.yml

[PierreMesure]

Not fully ready to merge but a good first start that others can contribute to. cc @thomaswennersten 👻

There is a small issue with the frontend. Running the backend and its two dependencies works great.

docker compose up intric-backend intric-db intric-redis

After everything is built and started, the database can be initialised using:

docker exec $(docker ps | grep intric-backend | awk '{print $1;}') poetry run python init_db.py

I haven't forwarded the ports of the database containers so in the backend .env file, you will need to point the backend towards their Docker addresses:

POSTGRES_HOST=intric-db
REDIS_HOST=intric-redis

You can also point the frontend at the backend if you don't wish to forward its port 8123:

INTRIC_BACKEND_URL=intric-backend:8123

[PierreMesure]

Alright, I solved a few problems with inspiration from @CCimen:

• Made the frontend container accessible from the outside by adding host: '0.0.0.0', in vite.config.ts. I am unsure whether that is an issue when the app is run in another context.
• Added the command to migrate in the Dockerfile, it works as long as the backend container doesn't start before the DB container is up and running, which is easy to do with a simple healthcheck
• Made backend and frontend share the same network. This is not best practice but I had to do it because I realised that the frontend will send calls to the backend both through the web browser ("frontend-frontend" calls) and through node ("backend-frontend" calls). Both are sent to INTRIC_BACKEND_URL/... so when the app is in a container and the url is set to localhost:8123, the "backend-frontend" call will just not find the backend-backend at localhost, it is at intric-backend:8123. The solution would be to separate the url for these two in two environment variables. What do you think @Jontpan?

I think it's getting ready to merge but there's probably things I missed.

[Jontpan]

I think this looks good!

Two separate urls would be optimal as you say, but since we at the moment don't have that (and I am not sure how much of the frontend code we would need to change) I think that this is fine for now.

However I think we should add a section at the top of the README for the new (and improved!) way to spin up intric 🙌

[PierreMesure]

I added a section at the bottom of the README. Feel free to move it.

I don't think this docker-compose file is good enough for more than testing for now so I think it's good to gather a bit more feedback and improvements before making it the preferred way of installing. Have you tried it @Jontpan?

There are a few problems I'm having with importing non-text documents in Knowledge, or accessing the admin pages Users and getting disconnected. I don't think they're linked to running in containers, though.

[rawtaz]

I realised that the frontend will send calls to the backend both through the web browser ("frontend-frontend" calls) and through node ("backend-frontend" calls). Both are sent to INTRIC_BACKEND_URL/... so when the app is in a container and the url is set to localhost:8123, the "backend-frontend" call will just not find the backend-backend at localhost, it is at intric-backend:8123.

I'm curious, can you elaborate a bit on this? What makes you think/say that the frontend connects to the backend both from the web browser to e.g. <INTRIC_BACKEND_URL>/api/v1 and from the frontend service on the server to the backend service on the server? Can you point me to the code that does this, or anything that tells you this is the case? I was only aware of the frontend running in the browser making requests to the backend through the API endpoint, nothing else.

FWIW, I run Intric with Caddy as a reverse proxy in front of both the frontend and backend services, so that there is just one endpoint for clients to connect to (that is, the user visits the endpoint to get the frontend, and the frontend running in their browser then connects to e.g. /api/v1 through the same endpoint). Perhaps you should add a reverse proxy to the Docker Compose setup here, so that you can have this working nicely as well (and also get Let's Encrypt support at the same time)?

On a related note (if I'm not mistaken here), how did you deal with /version or /api/v1/version missing in the API and being required by initVersion()? From what I can tell there was nothing like this in the API, so I just commented out the existing code in initVersion() and returned a dummy string.

[axelander]

I get an error that gcc is not available. It works fine when switching to python:3.10, which should be ok if this is intended for development use. Otherwise installing gcc via apt-get below also works.

[vvpd]

• Made the frontend container accessible from the outside by adding host: '0.0.0.0', in vite.config.ts. I am unsure whether that is an issue when the app is run in another context.

If run locally (outside docker) it will expose the developer's machine in the local network, which might be an unwanted side-effect. The same could be achieved by using the --host 0.0.0.0 command line option when running vite dev, but that would require some other setup in the main package.json, something like

"scripts": {
  "dev:docker": "NODE_ENV=development FORCE_COLOR=1 pnpm -w run /^dev:docker:.*/",
  "dev:docker:web": "pnpm run --filter @intric/web dev --host 0.0.0.0",
  "dev:docker:ui": "pnpm run --filter @intric/ui dev",
  [...]
}

This would make more explicit what actually is happening?

On an other note: it might also be quite useful to mount the frontend directories as volumes, so changes in the underlying sources will actually affect the running app.