文档化Python脚本在访问存储到/tmp的文件时遇到问题

Question

我想事先道歉，我没有具体的代码示例来分享(虽然我已经在下面包含了我的坞-撰写文件，这可能是有用的，也可能没有帮助)。我有一个奇怪的问题，我似乎无法追踪，我也不能百分之百地确定要分享什么。

我有一个django +芹菜设置运行在Docker (基于炊具-django)。一开始一切似乎都很顺利。我已经在Docker之外对这个设置进行了广泛的测试和使用，Dockerized芹菜任务的行为通常与我所期望的一样(即，它们在没有Dockerized的情况下所做的事情)。

不过，这是事情变得奇怪的地方。出于各种原因，我需要加载一些数据文件，并在运行时创建临时文件，这些文件是我不能仅仅放在我的docker文件中的。一个例子是使用NamedTemporaryFile。另一个是从空间性安装数据文件。在这两种情况下，我的脚本都将数据存储到/tmp (我知道这里简单的答案是将它们放在我的停靠文件中，但我无法预测我需要提前哪些文件，遗憾的是)。当我的芹菜任务工作人员试图访问它应该创建、下载和/或存储到/tmp中的数据文件时，我总是得到文件没有找到错误。奇怪的是，我的日志中没有任何错误文件创建或下载失败.

然而，当我/bin/bash进入我的celeryworker容器并将cd放到/tmp目录中时，足够肯定的是，没有文件.如果使用容器中的python控制台运行相同的代码，则没有问题，文件也会出现在/tmp中。我没有得到一致的错误消息，而且这种行为在不同的脚本中表现得不同，所以很难给出特定的错误消息/堆栈跟踪。当我的芹菜任务试图在/tmp中动态地存储数据并在此之后立即访问数据时，常见的元素似乎来自于某个问题。我是个码头工人，不知道下一步该怎么办。我怀疑这可能是一个许可问题，但我尝试过将/tmp修改为777，但它没有修复任何问题。我还认为这可能是一个卷问题，但如果是这样的话，我不知道为什么我可以让所有的工作，如果我使用bash在我的容器。

这里有人有什么建议吗？花了几天的时间试图找出问题的根源，现在已经到了死胡同。我的docker文件和信任文件几乎都是Django Cookiecutter默认值的普通普通副本。

version: '3'

volumes:
  local_postgres_data: {}
  local_postgres_data_backups: {}

services:
  django: &django
    build:
      context: .
      dockerfile: ./compose/local/django/Dockerfile
    image: gremlin_gplv3_local_django
    container_name: django
    depends_on:
      - postgres
      - tika
      - redis
    volumes:
      - .:/app
    env_file:
      - ./.envs/.local/.django
      - ./.envs/.local/.postgres
    ports:
      - "8000:8000"
    command: /start

  postgres:
    build:
      context: .
      dockerfile: ./compose/production/postgres/Dockerfile
    image: gremlin_gplv3_production_postgres
    container_name: postgres
    volumes:
      - local_postgres_data:/var/lib/postgresql/data
      - local_postgres_data_backups:/backups
    env_file:
      - ./.envs/.local/.postgres

  redis:
    image: redis:5.0
    container_name: redis

  celeryworker:
    <<: *django
    image: gremlin_gplv3_local_celeryworker
    container_name: celeryworker
    depends_on:
      - redis
      - postgres

    ports: []
    command: /start-celeryworker

  celerybeat:
    <<: *django
    image: gremlin_gplv3_local_celerybeat
    container_name: celerybeat
    depends_on:
      - redis
      - postgres

    ports: []
    command: /start-celerybeat

  flower:
    <<: *django
    image: gremlin_gplv3_local_flower
    container_name: flower
    ports:
      - "5555:5555"
    command: /start-flower

  tika:
    image: lexpredict/tika-server
    command: /start-tika

Answer 1

我想出来了..。嗯，主要是。问题在于Spacy (以及其他类似的下载数据文件的库和工具)将它们放到文件系统的本地目录中，并可能创建指向它们的符号链接)。但是，在停靠器容器中，这些文件和符号链接不是持久的，除非父目录位于停靠器卷中。

我最后所做的是为Spacy (或其他库)用来存储数据文件/库的文件夹创建停靠卷。在我的例子中，Spacy总是通过芹菜调用，而芹菜在我的坞-组合堆栈中有自己的坞映像，所以我需要将每个Spacy数据目录的卷附加到我的celeryworker中，如下所示：

version: '3'

volumes:
  local_postgres_data: {}
  local_postgres_data_backups: {}
  worker_usr: {}
  worker_root: {}
  worker_tmp: {}

services:
  
  [...]

  celeryworker:
    <<: *django
    image: local_django:latest
    container_name: celeryworker
    depends_on:
      - redis
      - postgres
    volumes:
      - worker_usr:/usr
      - worker_tmp:/tmp
      - worker_root:/root
      - .:/app

    ports: []
    command: /start-celeryworker

尽管如此，我注意到在某些情况下，在我的工作容器中安装数据文件(比如Spacy模型)会引发一个错误，即数据文件仍然无法访问，但是，当这种情况发生时(并不是所有时间)，我就可以再次运行安装，并且99%的时间，这似乎解决了问题。我还没有时间试着解决这个问题。也许其他人能弄清楚这部分。