問題
一般在正式的環境下，通過給域名添加子路徑（如oss）用于下載文件服務器上的文件。但這種設置子路徑的方式不能直接通過API上傳文件，創建桶等，鑒于安全，也不能讓這種子路徑擁有創建、刪除文件的權限。所以，一般情況下，后臺還是通過訪問多個minio端口9000實現文件的操作，甚至有時，還需要在自己的代碼中寫一套負載均衡的邏輯（之前我的代碼中就是這樣實現的）。其實完全可以基于Nginx直接暴露9001,9000, 同時再給web通過/oss/xx的形式訪問的能力。
結構設計
- 實現API負載均衡，并可以直接通過nginx:9000商品操作文件服務器。
- 實現通過/oss/xx僅瀏覽某個指定的文件服務器上文件（必須是完整目錄）。
- 圖片服務器高可靠。
- 本次搭建使用bitnami/minio鏡像，此鏡像為官方認證的鏡像，方便使用、集群方便，唯一就是不能通過傳遞--address,--console-address修改端口號，此鏡像固定API端口為9000,console端口為9001。好在，如果使用非host模式，可以此端口號映射成你想要的即可。
本次環境在一臺主機上搭建：
主機
軟件
網卡
端口
192.168.56.61
bitnami/minio:2022.9.1
mybridge
不對外暴露
bitnami/minio:2022.9.1
mybridge
不對外暴露
bitnami/minio:2022.9.1
mybridge
不對外暴露
bitnami/minio:2022.9.1
mybridge
不對外暴露
nginx:1.23.1
mybridge
80,9000,9001
目錄結構
在任意目錄下，創建data{1..4}目錄，用于保存minio的數據。創建nginx用于添加nginx的配置文件。在nginx1.19版本以后，可以通過映射 /etc/nginx/templats文件，將此目錄下的xxx.conf.template文件自動的保存到nginx的配置文件下/etc/nginx/conf.d/，nginx將 templates下的 *.conf.template文件保存到/etc/nginx/conf.d/目錄下以后，會刪除.template擴展名。
目錄截圖：
配置文件Docker-compose.yml
此配置文件，用于管理4個minio容器和一個nginx容器。由于bitnami/minio在創建時，會自動創建mc client，這會影響創建的速度，我們可以通過MINIO_SKIP_client將它關閉。關閉后，如果需要使用此功能，可以進入容器自行設置。
配置文件default.conf.template
此配置文件為oss映射配置文件，配置后，web可以通過http://<或名>/oss/<桶名稱>/1.png直接訪問到到圖片，但不能操作minio的文件系統，如上傳、創建桶等。
配置文件minio_api.conf.template
此配置文件用于nginx影射9000端口，實現直接通過此端口創建桶、上傳等，也用于其他client接口。
配置文件minio_console.conf.template
此配置文件，用于影射9001端口，實現console ui的相關操作。
啟動所有容器
# docker compose up -d
啟動過程中，可以通過log查看啟動日志，如出現以下信息，即表示啟動成功，注意最后的 4 online表示4臺主機都已經上線并可以使用了。
通過以下啟動的容器可以看出，僅nginx對外影射了端口，minio所有端口僅對nginx開放。
可選的，進入任意一臺容器，查看集群狀態
訪問ui
由于只開放了nginx9000端口，而此端口后面，負載均衡了minio{1...4}:9000端口，所以，訪問時，如果有宕機的minio也不影響操作,登錄之后，可以查看到minio集群的運行狀態。
http://192.168.56.61:9001
創建一個桶，并設置訪問權限
宕機測試
現在讓其中一臺minio服務器下線，并繼續在console ui上操作，創建桶、上傳或下載文件，都可以正常操作。
下線某個minio后查看ui中的offline下線已經為1 servers ,1 drivers。
測試完成后，再重新啟動
docker compose start minio1
oss訪問測試（通過）
域名訪問測試（通過）
JAVAAPI訪問（通過）
直接訪問nginx的9000端口即后，再不用于自己手寫代碼實現api接口的負載均衡了。
deepin
另：本人的操作系統為deepin 20（絕對不是給deepin做宣傳），deepin是基于debian的linux系統，非常好用。推薦大家嘗試。上個圖：
