Docker 撰写外部卷未与上传的文件同步
Docker compose external volume not synced with uploaded files
我有一个包含两个服务的 Docker 结构:一个 mysql 数据库和一个 nestJs 应用程序。
用户可以上传文件。
我想要实现的是这些文件和数据库保存在 docker 卷中。
因此,我创建了两个命名的外部卷,从 docker-compose up 和 运行 migration on nestJs 开始。我已经为那个案例写了一个 shell 脚本:
#!/bin/bash
docker volume create rrm_db_data_STAGING
docker volume create rrm_upload_data_STAGING
DB_PORT=3001 SERVER_PORT=5001 docker-compose -f docker-compose-stage.yml -p RRM_STAGING up --build -V --remove-orphans -d
docker exec rrm-app-api_STAGING npm run typeorm:migration:run
脚本运行良好。
这是我的 docker-compose 文件:
version: '3.7'
services:
api:
container_name: 'rrm-app-api_STAGING'
build:
context: .
target: production
command: npm run start:prod
restart: always
env_file:
- ./staging.env
environment:
- NODE_ENV=staging
volumes:
- type: volume
source: rrm_upload_data_STAGING
target: /uploads
ports:
- ${SERVER_PORT}:3000
networks:
- rrm-app-api-network_STAGING
depends_on:
- db
db:
image: mysql
container_name: 'rrm-app-mysql_STAGING'
volumes:
- rrm_db_data_STAGING:/var/lib/mysql
networks:
- rrm-app-api-network_STAGING
command: --default-authentication-plugin=mysql_native_password
restart: always
environment:
- MYSQL_ROOT_PASSWORD=dbpassword
- MYSQL_DATABASE=dbname
ports:
- ${DB_PORT}:3306
networks:
rrm-app-api-network_STAGING:
volumes:
rrm_db_data_STAGING:
external: true
rrm_upload_data_STAGING:
external: true
这是 docker 文件:
#Development stage
FROM node:13 AS development
LABEL key="removeme"
WORKDIR /usr/src/app
COPY package*.json ./
COPY . .
RUN rm -rf node_modules
RUN rm -rf dist
RUN npm install
RUN npm run build
FROM node:13 AS production
WORKDIR /usr/src/app
COPY . .
RUN rm -rf node_modules
RUN rm -rf dist
COPY package*.json ./
RUN npm install
COPY --from=development /usr/src/app/dist ./dist
卷已创建,数据库的卷工作正常。数据是持久化/同步的,并且在我 docker-compose down 之后仍然存在。
这不适用于 /uploads
文件夹!
卷的大小始终为 0。用户上传的文件不存储在卷中,而是存在于容器 /uploads
文件夹中。如您所见,我已经尝试在 api 服务的卷部分中编写“长”版本。
启动时容器中是否存在/uploads
文件夹没有区别。顺便提一句。这是绑定所必需的吗?因为文件夹是在第一次上传时创建的。无论如何,我认为这不是真正的错误。
你能告诉我我做错了什么吗?
谢谢!
感谢@DennisRuiter。
我将容器中的位置从 /uploads
更改为 Dockerfile 中指定的工作目录下的文件夹。现在它按预期工作。
我有一个包含两个服务的 Docker 结构:一个 mysql 数据库和一个 nestJs 应用程序。 用户可以上传文件。 我想要实现的是这些文件和数据库保存在 docker 卷中。 因此,我创建了两个命名的外部卷,从 docker-compose up 和 运行 migration on nestJs 开始。我已经为那个案例写了一个 shell 脚本:
#!/bin/bash
docker volume create rrm_db_data_STAGING
docker volume create rrm_upload_data_STAGING
DB_PORT=3001 SERVER_PORT=5001 docker-compose -f docker-compose-stage.yml -p RRM_STAGING up --build -V --remove-orphans -d
docker exec rrm-app-api_STAGING npm run typeorm:migration:run
脚本运行良好。
这是我的 docker-compose 文件:
version: '3.7'
services:
api:
container_name: 'rrm-app-api_STAGING'
build:
context: .
target: production
command: npm run start:prod
restart: always
env_file:
- ./staging.env
environment:
- NODE_ENV=staging
volumes:
- type: volume
source: rrm_upload_data_STAGING
target: /uploads
ports:
- ${SERVER_PORT}:3000
networks:
- rrm-app-api-network_STAGING
depends_on:
- db
db:
image: mysql
container_name: 'rrm-app-mysql_STAGING'
volumes:
- rrm_db_data_STAGING:/var/lib/mysql
networks:
- rrm-app-api-network_STAGING
command: --default-authentication-plugin=mysql_native_password
restart: always
environment:
- MYSQL_ROOT_PASSWORD=dbpassword
- MYSQL_DATABASE=dbname
ports:
- ${DB_PORT}:3306
networks:
rrm-app-api-network_STAGING:
volumes:
rrm_db_data_STAGING:
external: true
rrm_upload_data_STAGING:
external: true
这是 docker 文件:
#Development stage
FROM node:13 AS development
LABEL key="removeme"
WORKDIR /usr/src/app
COPY package*.json ./
COPY . .
RUN rm -rf node_modules
RUN rm -rf dist
RUN npm install
RUN npm run build
FROM node:13 AS production
WORKDIR /usr/src/app
COPY . .
RUN rm -rf node_modules
RUN rm -rf dist
COPY package*.json ./
RUN npm install
COPY --from=development /usr/src/app/dist ./dist
卷已创建,数据库的卷工作正常。数据是持久化/同步的,并且在我 docker-compose down 之后仍然存在。
这不适用于 /uploads
文件夹!
卷的大小始终为 0。用户上传的文件不存储在卷中,而是存在于容器 /uploads
文件夹中。如您所见,我已经尝试在 api 服务的卷部分中编写“长”版本。
启动时容器中是否存在/uploads
文件夹没有区别。顺便提一句。这是绑定所必需的吗?因为文件夹是在第一次上传时创建的。无论如何,我认为这不是真正的错误。
你能告诉我我做错了什么吗?
谢谢!
感谢@DennisRuiter。
我将容器中的位置从 /uploads
更改为 Dockerfile 中指定的工作目录下的文件夹。现在它按预期工作。