You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not exactly a problem with this emulator but more a description of my findings, since I didn't find > anything else here about this. I really hope this could help other people.
I added a question and proposal at the end, that might overcome this issue.
I'm building by integration of a system that uses GCS, so of course for development I needed to use an emulator.
I have a Docker Compose file that runs my app and the fake emulator with something like the following settings:
dev:
profiles: [dev]env_file: .env.devimage: name-xbuild: .ports:
- '${APP_SERVICE_PORT}:${APP_SERVICE_PORT}'environment:
APP_SERVICE_PORT: ${APP_SERVICE_PORT}GCS_BUCKET: ${GCS_BUCKET}STORAGE_EMULATOR_HOST: http://${GCS_EMULATOR_HOST}:${GCS_EMULATOR_PORT}depends_on:
- gcs-emulatorcommand: node dist/index.jsgcs-emulator:
profiles: [dev]image: fsouza/fake-gcs-servercommand: -scheme http -public-host ${GCS_EMULATOR_HOST}:${GCS_EMULATOR_PORT} -filesystem-root /datavolumes:
- ./gcs-emulator-data:/dataports:
- '${GCS_EMULATOR_PORT}:${GCS_EMULATOR_PORT}'# just to allow myself to make requests through Insomia or CURLexpose:
- '${GCS_EMULATOR_PORT}'
While trying to query the emulator through JS's @google-cloud/storage, I used this code, by relying on the fact that new Storage() assumes (or tries to use) STORAGE_EMULATOR_HOST environment variable (as described by GCS Go package Documentation and by another page I cannot find anymore).
Any request through CURL to http://0.0.0.0:4443/storage/v1/b/my-bucket/o works fine.
So I started digging in the package @google-cloud/storage and then in the issues:
Apparently, STORAGE_EMULATOR_HOST is used in a weird way:
// Note: EMULATOR_HOST is an experimental configuration variable. Use apiEndpoint instead.constEMULATOR_HOST=process.env.STORAGE_EMULATOR_HOST;if(typeofEMULATOR_HOST==='string'){apiEndpoint=Storage.sanitizeEndpoint(EMULATOR_HOST);customEndpoint=true;}if(options.apiEndpoint&&options.apiEndpoint!==apiEndpoint){apiEndpoint=Storage.sanitizeEndpoint(options.apiEndpoint);customEndpoint=true;}options=Object.assign({},options,{ apiEndpoint });// Note: EMULATOR_HOST is an experimental configuration variable. Use apiEndpoint instead.constbaseUrl=EMULATOR_HOST||`${options.apiEndpoint}/storage/v1`;
As you can see, when apiEndpoint is declared, it gets appended /storage/v1 while STORAGE_EMULATOR_HOST doesn't... and you can't even add it yourself, because otherwise we get upload request errors like:
Apparently, there is not an exact consensus about STORAGE_EMULATOR_HOST, which should have been only an experimental thing... which got then documented officially in the Go Client (as linked above).
Then, I looked, in the examples of this repository. Both STORAGE_EMULATOR_HOSTANDapiEndpoint are deliberately used, probably to overcome this issue (the reason is not explained).
I really hope this may help someone else, hitting the wall like me.
I'm not sure is there anything actionable in this project could be done to fix this.
I wonder if adding another route listener to serve /b/my-bucket could actually help for reading files. Like, in this file:
Note
This is not exactly a problem with this emulator but more a description of my findings, since I didn't find > anything else here about this. I really hope this could help other people.
I added a question and proposal at the end, that might overcome this issue.
I'm building by integration of a system that uses GCS, so of course for development I needed to use an emulator.
I have a Docker Compose file that runs my app and the fake emulator with something like the following settings:
While trying to query the emulator through JS's
@google-cloud/storage, I used this code, by relying on the fact thatnew Storage()assumes (or tries to use)STORAGE_EMULATOR_HOSTenvironment variable (as described by GCS Go package Documentation and by another page I cannot find anymore).If
STORAGE_EMULATOR_HOSTis set, upload works fine butgetFilesfails with logs like:Any request through CURL to
http://0.0.0.0:4443/storage/v1/b/my-bucket/oworks fine.So I started digging in the package
@google-cloud/storageand then in the issues:Apparently,
STORAGE_EMULATOR_HOSTis used in a weird way:https://github.com/googleapis/nodejs-storage/blob/189663a279d85451a65614b47a748d667d7eb3db/src/storage.ts#L726-L746
As you can see, when
apiEndpointis declared, it gets appended/storage/v1whileSTORAGE_EMULATOR_HOSTdoesn't... and you can't even add it yourself, because otherwise we get upload request errors like:Digging deeper, I found out some discussions about this: googleapis/nodejs-storage#2069 and linked threads.
Apparently, there is not an exact consensus about
STORAGE_EMULATOR_HOST, which should have been only an experimental thing... which got then documented officially in the Go Client (as linked above).Then, I looked, in the examples of this repository. Both
STORAGE_EMULATOR_HOSTANDapiEndpointare deliberately used, probably to overcome this issue (the reason is not explained).However, using
STORAGE_EMULATOR_HOSTalone would have been really convenient, in order to not mix in the code things for development.Instead, we can simply use
apiEndpointinstead, even if that mixes code with development details.I really hope this may help someone else, hitting the wall like me.
I'm not sure is there anything actionable in this project could be done to fix this.
I wonder if adding another route listener to serve
/b/my-bucketcould actually help for reading files. Like, in this file:fake-gcs-server/fakestorage/server.go
Lines 253 to 340 in 6f935ce
jsonAPIRouter := r.PathPrefix("/storage/v1").Subrouter() + jsonAPIAliasRouter := r.PathPrefix("").Subrouter()and this one (which may apply to all the routes).
jsonAPIRouter.Path("/b/{bucketName}/o/{objectName:.+}").Methods(http.MethodGet).HandlerFunc(s.downloadObject) + jsonAPIAliasRouter.Path("/b/{bucketName}/o/{objectName:.+}").Methods(http.MethodGet).HandlerFunc(s.downloadObject)