budibase
budibase copied to clipboard
Access Minio, and CouchDB from outside of ARM Single Docker
Describe the feature request Single BudiBase Docker image for ARM works great. But my cases require access to Minio server inside the container to fetch the file via Minio SDK. I wish we could enable minio browser for this image, but if not, at least allow Minio SDK to access the server.
Right now we can't do any of those actions. When I try to access minio instance via SDK, it throws an error The request signature we calculated does not match the signature you provided. Check your key and signing method. According to this issue https://github.com/minio/minio/issues/7936, the configuration lack of proxy_set_header Host $http_host; config on the nginx part.
I tried to do it by overriding the nginx config via docker compose, and it work as expected. Shall I raise PR for it?
version: "3"
services:
budibase:
restart: unless-stopped
image: budibase/budibase:v2.1.15
environment:
JWT_SECRET: ${JWT_SECRET}
COUCHDB_USER: ${COUCHDB_USER}
COUCHDB_PASSWORD: ${COUCHDB_PASSWORD}
MINIO_ACCESS_KEY: ${MINIO_ACCESS_KEY}
MINIO_SECRET_KEY: ${MINIO_SECRET_KEY}
INTERNAL_API_KEY: ${INTERNAL_API_KEY}
REDIS_PASSWORD: ${REDIS_PASSWORD}
ports:
- "10000:80"
volumes:
- ./default:/etc/nginx/sites-available/default
- budibase_data:/data
and this is the diff of default file, mostly taken from https://github.com/Budibase/budibase/blob/develop/hosting/single/nginx/nginx-default-site.conf
git diff default
diff --git a/default b/default
index 136ec56..4999422 100644
+++ a/default
--- b/default
@@ -79,7 +79,6 @@ server {
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;
proxy_http_version 1.1;
Screenshots If applicable, add screenshots to help explain your problem.
@dirathea can you paste a snippet of how you are using the SDK to get access to a file?
We are going to be making a change soon for the minio container and how we set the host header (for presigned urls), so I'm concerned we might have a conflict if we do make the suggested change.
@dirathea can you paste a snippet of how you are using the SDK to get access to a file?
We are going to be making a change soon for the minio container and how we set the host header (for presigned urls), so I'm concerned we might have a conflict if we do make the suggested change.
Sure.
func initMinio() {
endpoint := os.Getenv("MINIO_URL")
accessKeyId := os.Getenv("MINIO_ACCESS_KEY")
secretKeyId := os.Getenv("MINIO_SECRET_KEY")
log.Printf("Configuring connection to minio on %s", endpoint)
client, err := minio.New(endpoint, &minio.Options{
Creds: credentials.NewStaticV4(accessKeyId, secretKeyId, ""),
Secure: false,
})
if err != nil {
log.Fatalln(err)
}
minioClient = client
}
Which function on the client are you using to retrieve the file? i.e. are you calling GetObject or PresignedGetObject?
Which function on the client are you using to retrieve the file? i.e. are you calling
GetObjectorPresignedGetObject?
Right now I’m calling FGetObject to download the file. In my use case, I think I will not use PresignedGetObject anytime soon.
In the broader sense, I wish ARM based image could be deployed in micro service fashion. Oracle has Always Free tier, that offer 4 cores and 26G Ram in ARM based architecture, which a perfect place to run budibase for slightly more than a hobby project.
Seeing for futher scaling, if we already deploy it in e.g Docker Compose as multiple components, we could easily migrate to K8S Helm. That’s why I’m asking for access to both couchdb and minio inside the container.
I'll have a look at this in the next few days to ensure what you are suggesting for the single image is possible and compatible with our presigned url changes. I do agree that it would be best if we could get access to couch and minio consoles via the single image, by exposing the underlying relevant ports it might be pretty straightforward.
For your other points around ARM hosting, best to raise a discussion. Right now deploying the single image in a clustered fashion won't work, as there is additional infrastructure required around routing, centralised volumes etc. The best option here is the k8s installation. The docs are here if you haven't seem them yet: https://docs.budibase.com/docs/kubernetes-k8s
This issue has been automatically marked as stale because it has not had recent activity.
This issue has been automatically marked as stale because it has not had recent activity.