Dify

[marioalexandreantunes]

Problemas com o Dify v0.11.2 file composer está no vosso script.

Erro 1

Como requisito vocês tem :
"Recomenda-se utilizar Ubuntu 20.04, com mínimo de 4Gb e 2vCPU."
Mas no Dify docker composer file tem como limite "4" e isso faz com que fique a instancia por iniciar dando erro!

resources:
        limits:
          cpus: "4" -> "2"

Erro 2

No vosso docker composer também tem:

volumes:
      - dify_storage:/app/api/storage0.2.10

no ficheiro original do dify é :

volumes:
      # Mount the storage directory to the container, for storing user files.
      - ./volumes/app/storage:/app/api/storage

sem o 0.2.10 no final do caminho!

Erro 3

Quando necessito subir uma imagem para customizar o componente ele não apresenta nenhuma, porque o caminho de file_url é o url da api. So mudando é que apresentou tudo bem!

- FILES_URL=https://api-dify.dominio.com

Erro 4

Se usar S3 no endpoint tem de ter https://

S3_ENDPOINT=https://s3.domain.com

Tips

Caso vc faça mude alguma coisa no ficheiro composer como alterar a versão do dify, deveria fazer um reset a base de dados do postgreSQL, por ssh :

docker ps 
- verique o CONTAINER ID do postgres
docker exec "CONTAINER ID" psql -U postgres -c "DROP DATABASE IF EXISTS dify(force);"
docker exec "CONTAINER ID" psql -U postgres -c "CREATE DATABASE dify;"

Atenção o 0.13.2 tem muitas alterações, exemplo já não tem o

- STORAGE_TYPE=local

[marioalexandreantunes]

Usando S3 MinIO e com as alterações que coloquei antes, o docker compose pode subir a versão 0.13.2

no repositorio já tem alterações File Storage Configuration, mas não foi para a v0.13.2

langgenius/dify#11508 [commit de 10-12-2024]

# ------------------------------
# File Storage Configuration
# ------------------------------

# The type of storage to use for storing user files.
# Supported values are `opendal` , `s3` , `azure-blob` , `google-storage`, `tencent-cos`, `huawei-obs`, `volcengine-tos`, `baidu-obs`, `supabase`
# Default: `opendal`

[marioalexandreantunes]

se alguém quiser ver as minhas alterações:

main...marioalexandreantunes:SetupOrion:main

[oriondesign2015]

Saudações @marioalexandreantunes, tranquilo?

Primeiramente quero agradecer pela sua inssue que de cara da para ver que vão contribuir bastante com o projeto. Em seu primeiro post descreve 4 erros, e gostaria de aborda-los:

Erro 1 - "Incompatibilidade de Requisitos com Limite de CPU no Docker Compose do Dify"

Na verdade isso não é um erro, na pagina do setup descrevemos o MINIMO para rodar o setup, isso não significa que é o mínimo para rodar qualquer aplicação do mesmo, já que nele possui ferramentas como Ollama do qual o recomendado é ter ao minimo 8Gb Ram dedicado ao mesmo.
Definimos esses recursos que estão presentes hoje na stack do dify com base nas sugestões de alguns criadores de conteúdos que usam arduamente o Dify e que solicitaram a tal modificação do mesmo para um melhor desempenho..

Toda via na próxima atualização do setup eu definirei CPU = 2 núcleos e RAM = 4 para voltar a servir de minimo para o mesmo.

Nota: Já expresso aqui que não concordo com tal configuração pois como o mesmo diz, é o mínimo para a ferramenta rodar, e não o recomendado.

Então reformulando, não é um erro, apenas uma confusão da representação das recomendações do SetupOrion =D

---

Erro 2 - "Volume errado"

Realmente, analisando aqui e acabamos colocando o 0.2.10 junto ao volume (do qual era para ser a versão do sandbox). No entanto já corrigimos e vai sair já na próxima atualização. Agradecemos pela observação.

---

Erro 3 - "Erro ao subir imagem devido ao file_url da API"

Agradecemos por essa informação, já vamos adicionar/configurar essa environment.

---

Erro 4 - "Utilizando S3 com Endpoint: HTTPS é Obrigatório no S3_ENDPOINT"

Agradecemos por essa informação, não havíamos encontrado ela em usa documentação nem no .env.example então definimos o padrão das demais aplicações (que é sem o https). Já vamos adicionar/configurar essa environment.

---

Novamente agradeço as contribuições realizadas por essa inssues!

---

Entre nos nossos grupos do WhatsApp e faça parte da comunidade SetupOrion! Troque experiências, tire suas dúvidas e fique por dentro das novidades.

👇🏽 Grupo #01 – SetupOrion
https://oriondesign.art.br/whatsapp1

👇🏽 Grupo #02 – SetupOrion
https://oriondesign.art.br/whatsapp2

👇🏽 Grupo #03 – SetupOrion
https://oriondesign.art.br/whatsapp3

---

🔔 Canal de Avisos/Atualizações:
https://whatsapp.com/channel/0029VaAcJhdHLHQg5lpmS51e

[marioalexandreantunes]

Tem toda a razão em relação ao Erro 1, mas como o projeto "SetupOrion" é uma solução para quem não sabe muito de linux/docker/portainer, será difícil se colocar cpu a 4 e o container não iniciar por esse motivo, uso muito Hetzner CX32 ou CCX13 onde tenho o necessário para rodar os meus serviços, mas CCX13 como tem só 2 CPU foi ai que dei pelo "erro" no composer do Dify.

Estou rodando dify v0.13.2 e até agora parece estável, gosto muito da framework (n8n, langflow e dify), apesar de achar que o projeto deveria definir melhor o software release flow, fazem um deploy e passado 2 dias outra!! Mas sendo OpenSource nada a dizer!

Só uma dica, onde coloca nos composers :latest eu forçaria uma versão, para que os usuários com menos conhecimentos não façam um re-pull da imagem e depois subam uma versão que possa destruir um projeto.

[oriondesign2015]

Saudações @marioalexandreantunes, tranquilo?

Referente a tag latest que mencionou, acaba que não é viável para nós manter com versões mocadas, pois com mais de 65 ferramentas no setup (sem contar as dependências), não daríamos conta de ver quando lançou uma atualização de cada uma para atualizar dentro do setup a mesma.
Já mantendo como latest podemos ficar mais tranquilo já que no ato da instalação de uma determinada ferramenta, já garante que ela vai ser a ultima versão, sem a necessidade de instalar, vir com uma antiga, e ter que saber atualizar para pegar algumas features novas e afins.

Toda via, estamos esperando só alguns equipamentos chegarem para voltar com a série em nosso canal, do qual teremos videos de cada ferramenta com os capitulos de:
• Como Instalar
• Como realizar múltiplas instalações
• Como Atualizar
• Como Desinstalar
• Observações importantes da ferramenta

O que creio que por si só creio que já vai ser mais que uma documentação para um bom uso de cada ferramenta.

---

Entre nos nossos grupos do WhatsApp e faça parte da comunidade SetupOrion! Troque experiências, tire suas dúvidas e fique por dentro das novidades.

👇🏽 Grupo #01 – SetupOrion
https://oriondesign.art.br/whatsapp1

👇🏽 Grupo #02 – SetupOrion
https://oriondesign.art.br/whatsapp2

👇🏽 Grupo #03 – SetupOrion
https://oriondesign.art.br/whatsapp3

---

🔔 Canal de Avisos/Atualizações:
https://whatsapp.com/channel/0029VaAcJhdHLHQg5lpmS51e

[oriondesign2015]

@marioalexandreantunes Saudações nobre, tranquilo?

Deixa eu te falar, realizei a atualização do setup, seguindo essas dicas que me passou e lendo a doc para acompanhar tudo certinho mas encontrei alguns problemas com a integração com o dify e o s3.

Realizei a instalação até seguindo o seu fork mas toda vez que eu tendo subir um arquivo o mesmo não sobe, ficando o status em Erro. Mas se eu deixo o - STORAGE_TYPE=local funciona tranquilamente, mas ao configurar o s3 já não sobe mais os arquivos.

No momento esta desta forma:

      ## Dados sobre armazenamento s3
      - STORAGE_TYPE=s3
      - STORAGE_LOCAL_PATH=storage
      - S3_ENDPOINT=https://<S3_ENDPOINT>
      - S3_BUCKET_NAME=dify
      - S3_REGION=eu-south
      - S3_ACCESS_KEY=<S3_ACCESS_KEY>
      - S3_SECRET_KEY=<S3_SECRET_KEY>

O erro é apresentado no worker com:

ERROR [Dummy-8] [ext_storage.py:105] - Failed to download file upload_files/4fade49b-c3de-48c9-86ab-243213c1597e/b1ac9cfe-adc0-43f5-9f8e-6161bf7c3ab1.pdf

Mas se eu acessar o https://<S3_ENDPOINT> + <file> o mesmo está presente.

Por acaso, você tem alguma recomendação ou observação sobre o motivo disso estar acontecendo?

Desde já, agradeço o apoio!

[marioalexandreantunes]

Vou fazer testes, colocando em:
LOG_LEVEL=DEBUG

acho que poderá ter a ver com
FILES_URL=

Já digo qualquer coisa, estamos em UTC diferentes :)

[marioalexandreantunes]

Erro é no worker e tem a ver com o caminho do url, quando o ficheiro tem de ser descarregado temporariamente por causa do embedding.

2024-12-15 13:10:59,090.090 ERROR [Dummy-9] [ext_storage.py:105] - Failed to download file upload_files/815160f2-d750-4ec6-9b4b-d173f643741f/021720aa-9c6e-452f-99e1-a7b3391f0f94.txt

Traceback (most recent call last):
  File "/app/api/extensions/ext_storage.py", line 103, in download
    self.storage_runner.download(filename, target_filepath)
  File "/app/api/extensions/storage/local_fs_storage.py", line 52, in download
    raise FileNotFoundError("File not found")
FileNotFoundError: File not found
2024-12-15 13:10:59,091.091 ERROR [Dummy-9] [indexing_runner.py:94] - consume document failed

Já testei com Supabase e API:

2024-12-15 13:55:09,127.127 INFO [Dummy-7] [_client.py:1038] - HTTP Request: GET https://msfgudkoercjjabmtilc.supabase.co/storage/v1/object/dify/upload_files/815160f2-d750-4ec6-9b4b-d173f643741f/f77d1926-52a0-4a44-b0b2-dd7cda83ba93.txt "HTTP/2 200 OK"

mas no worker dá erro também:

2024-12-15 13:55:17,349.349 INFO [Dummy-12] [document_indexing_task.py:59] - Start process document: 064334ce-7e2c-442e-8c5b-56cadbd8d12e

2024-12-15 13:55:17,360.360 ERROR [Dummy-12] [ext_storage.py:105] - Failed to download file upload_files/815160f2-d750-4ec6-9b4b-d173f643741f/f77d1926-52a0-4a44-b0b2-dd7cda83ba93.txt

Traceback (most recent call last):

Como estava usar uma base de vectores já existente não dei por esse erro, vou pesquisar mais.

langgenius/dify#4531

[marioalexandreantunes]

Erro resolvido:

na API temos

• STORAGE_TYPE=s3
• STORAGE_LOCAL_PATH=storage
• S3_ENDPOINT
• S3_BUCKET_NAME
• S3_ACCESS_KEY
• S3_SECRET_KEY

no worker temos

Dados Weaviate

• STORAGE_TYPE=local
• STORAGE_LOCAL_PATH=storage
• VECTOR_STORE=weaviate
• WEAVIATE_ENDPOINT=http://dify_weaviate:8080
• WEAVIATE_API_KEY=3de344abc34315abcebea98c795f2214
• WEAVIATE_CLIENT_TIMEOUT=20

Ou seja deveríamos ter também no worker os dados da S3 👍 e estamos a usar S3 na API e na worker Local! errado. STORAGE_TYPE e STORAGE_LOCAL_PATH nem pertencem ao Weaviate.

4de8f6c

[marioalexandreantunes]

Relembro que as variáveis de ambiente no ficheiro original do DIFY são usadas tanto na API como no WORKER e são as mesmas (shared-api-worker-env).

api:
    image: langgenius/dify-api:0.13.2
    restart: always
    environment:
      # Use the shared environment variables.
      <<: *shared-api-worker-env
      # Startup mode, 'api' starts the API server.
      MODE: api

worker:
    image: langgenius/dify-api:0.13.2
    restart: always
    environment:
      # Use the shared environment variables.
      <<: *shared-api-worker-env
      # Startup mode, 'worker' starts the Celery worker for processing the queue.
      MODE: worker

Poder-se-ia usar:

version: '3.7'

x-common-environment: &common-environment
   STORAGE_TYPE: s3
   STORAGE_LOCAL_PATH: storage
   S3_ENDPOINT: 
   S3_BUCKET_NAME:
   S3_ACCESS_KEY:
   S3_SECRET_KEY:

dify${1:+_$1}_api:
    image: langgenius/dify-api:0.13.2
    restart: always
    environment:
       - MODE=api
       <<: *common-environment

dify${1:+_$1}_worker:
    image: langgenius/dify-api:0.13.2
    restart: always
    environment:
       - MODE=worker
       <<: *common-environment

[oriondesign2015]

Saudações, ótimas observações. não notei shared-api-worker-env enquanto estava lendo.

Corrigido com sucesso!!

Grato.