ubuntu docker部署minio pythonSDK及使用过程中文件不显示加载不出来 上传失败无法彻底删除的解决方法

ubuntu24卸载重新安装最新版docker、docker-compose本地化部署minio

1、下载安装minio

sudo docker pull minio/minio

2、创建配置和数据目录

mkdir /data/docker/minio/config

mkdir /data/docker/minio/data

3、docker创建容器

账号和密码注意自己设置

sudo docker run --privileged=true --net=bridge \
--name minio -p 9000:9000 -p 9001:9001 \
-e "MINIO_ACCESS_KEY=mykey" \
-e "MINIO_SECRET_KEY=mysecret" \
-v /data/docker/minio/data:/data \
-v /data/docker/minio/config:/root/.minio \
--console-address "0.0.0.0:9001" -address "0.0.0.0:9000"

启动参数参考如下：

	参数说明
--privileged=true	在Docker中，--privileged=true选项允许容器以特权模式（超级用户权限）运行，从而获得几乎与主机相同的权限。这意味着容器可以访问和控制主机的所有硬件设备、操作系统内核和其他系统资源。
--p 9000:9000 -p 9001:9001	端口映射，9000是服务器api接口访问的端口地址，9001是客户端web访问端口。
--name minio	给创建的容器指定一个名称。
--net=bridge	这是网络设置，默认是bridge配置，bridge表示使用容器内部配置网络，host表示容器将使用主机的网络栈。
-d	在Docker中，-d（全称 --detach） 选项用于启动一个分离模式的容器，这意味着容器会在后台运行，不会占用当前的终端会话。
-e "MINIO_ACCESS_KEY=mykey"	设置minio的用户名
-e "MINIO_SECRET_KEY=mysecret"	设置minio的密码
-v /data/docker/minio/data:/data	将宿主机上的 /data/docker/minio/data 目录挂载到容器内的 /data 目录。
-v /data/docker/minio/config:/root/.minio	将宿主机上的 /data/docker/minio/config 目录挂载到容器内的 /root/.minio 目录。
minio/minio server /data --console-address "0.0.0.0:8001" -address "0.0.0.0:8000"	容器内要运行的命令，启动一个名为 "minio" 的服务器，数据存储在 /data 目录下，服务器的控制台地址为 "0.0.0.0:8001"，服务地址为 "0.0.0.0:8000"。
--restart	设置容器重启策略，如 always、on-failure等
--env	设置环境变量

 4、运行成功会返回访问api和web的地址，打开web地址，输入设置的用户名和密码即可登录

登录后创建bucket及访问权限即可

注意事项：

1、如果是nginx配置访问web的，进入bucket文件列表一直在加载中或不显示

2、上传文件失败，原因是默认minio http上传文件默认大小是1m

以上两个问题可以在nginx配置中解决

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
chunked_transfer_encoding off;

#添加client_max_body_size 1000m 目的是为了增大Http允许上传文件的大小。
#默认值是 1m，这对于大多数场景来说太低了。或者直接禁用检查客户端请求正文大小，将 client_max_body_size 设置为 0。
client_max_body_size 0;

nginx示例如下

server {
    listen 80;
    server_name 123.cn;
    # Nginx 默认不允许特殊字符。设置 ignore_invalid_headers off 允许带有特殊字符的标题。
    ignore_invalid_headers off;
    #添加client_max_body_size 1000m 目的是为了增大Http允许上传文件的大小。
    #默认值是 1m，这对于大多数场景来说太低了。或者直接禁用检查客户端请求正文大小，将 client_max_body_size 设置为 0。
    client_max_body_size 0;
    # Nginx 默认缓冲响应。要禁止 Nginx 缓冲 MinIO 对临时文件的响应，请设置 proxy_buffering off;。这将改善客户端请求的第一个字节的时间。
    proxy_buffering off;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_connect_timeout 300;
        # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        chunked_transfer_encoding off;
        proxy_pass http://127.0.0.1:9001; # If you are using docker-compose this would be the hostname i.e. minio
        # Health Check endpoint might go here. See https://www.nginx.com/resources/wiki/modules/healthcheck/
        # /minio/health/live;
    }
}

3、前端如果是使用uni.uploadFile方法上传文件，需要传入timeout参数，这也是上传失败的原因之一

const task = uni.uploadFile({
				url: this.action,
				filePath: this.lists[index].url,
				name: this.name,
				formData: this.formData,
				header: this.header,
				timeout: 300000,
				success: res => {...}
})

4、minio pythonSDK7.2.5版本中，上传文件调用put_object方法报错问题，需要传参增加length和part_size

另外需要注意的是在minio的sdk接口上传、删除等操作时，object_name中不能包含bucket，这个和阿里云oss有区别，oss在操作时即使传入的object_name中包含bucket，也能正常处理，但是在minio中会操作失败

	async def upload_data(self, object_name: str, data: str, limit_size: int) -> str:
		"""
		上传本地文件到MinIO
		:param object_name: 对象名称（含路径，如：photos/2024/image.jpg）
		:param data: 文件信息
		:param limit_size: 上传文件限制大小
		:return: 上传成功返回True，否则False
		"""
		try:
			response = self.client.put_object(
				bucket_name=self.bucket_name,
				object_name=object_name,
				data=data,
				length=-1,
				part_size=limit_size
			)
			print(f"上传成功！版本ID: {response.version_id}")

		except S3Error as e:
			raise AppException(HttpResp.SYSTEM_ERROR, msg='上传文件失败:%s' % e.message)

5、minio删除文件remove_object、remove_objects时，不能彻底删除的问题解决方法

经过查询了解minio接口删除文件时，删除完成后会创建一个带有删除标记的对象版本，导致无法彻底删除

启用版本控制的情况下，可以remove_objects方法执行成功后，再通过list_objects方法获取到version_id和is_delete_marker标记，将is_delete_marker为True的版本再删除

# 删除文件
client.remove_object(
				bucket_name=self.bucket_name,
				object_name=object_name
			)

# 列出对象的所有版本（包括删除标记）
    objects = client.list_objects(
        bucket_name,
        prefix=object_name,
        include_version=True,
    )
# 筛选出删除标记版本
    delete_markers = [
        (obj.object_name, obj.version_id)
        for obj in objects
        if obj.is_delete_marker
    ]

# 假设要删除的版本ID存储在变量 delete_version_id 中
    delete_version_id = "your-delete-marker-version-id"
    
# 删除指定版本的删除标记
    client.remove_object(
        bucket_name,
        object_name,
        version_id=delete_version_id,
    )
    print(f"已删除删除标记版本: {delete_version_id}")

遇到一种情况是minio bucket中并未启用版本控制，但remove_object和remove_objects方法操作文件时，也没有彻底删除文件，也是添加了删除标记，在客户端中显示删除标记的情况下还可以查询到该文件

通过list_objects方法得到的对象属性中

is_delete_marker显示为True，

version_id 显示为 null

目前未查出原因，调用接口无法删除，只能在客户端控制台，通过筛选带删除标记的文件手动删除