Deuxfleurs/garage
48
56
Fork 73
Code Issues 99 Pull requests 13 Releases 30 Wiki Activity

Unclear how to troubleshoot connection to Docker image #801

New issue
Open
opened 2024-04-09 19:23:16 +00:00 by DougReeder · 5 comments
DougReeder commented 2024-04-09 19:23:16 +00:00
Copy link

As my dev machine runs MacOS rather than linux, I tried following the instructions at https://garagehq.deuxfleurs.fr/documentation/quick-start/ but substituting the Docker image for a binary.

The last config file I tried is

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "sqlite"

replication_mode = "none"

rpc_bind_addr = "127.0.0.1:3901"
rpc_public_addr = "127.0.0.1:3901"
rpc_secret = "xxxxxxx"

[s3_api]
s3_region = "garage"
api_bind_addr = "127.0.0.1:3900"
root_domain = ".s3.garage.localhost"

[s3_web]
bind_addr = "127.0.0.1:3902"
root_domain = ".web.garage.localhost"
index = "index.html"

[k2v_api]
api_bind_addr = "[::]:3904"

[admin]
api_bind_addr = "127.0.0.1:3903"
admin_token = "xxxxx"
metrics_token = "xxxxxxx"

I tried several variations on network addresses, but they all suffer the problem below.

/etc/garage.toml, /var/lib/garage/meta and /var/lib/garage/data on my dev machine are all owned by me.

I can create a container so:

docker run \
  -d \
  --name garaged \
  --restart always \
  --network host \
  -v /etc/garage.toml:/etc/garage.toml \
  -v /var/lib/garage/meta:/var/lib/garage/meta \
  -v /var/lib/garage/data:/var/lib/garage/data \
  dxflrs/garage:v0.9.4

The image starts up and the log includes

2024-04-09 14:36:39 2024-04-09T18:36:39.513469Z  INFO garage::server: Initializing background runner...
2024-04-09 14:36:39 2024-04-09T18:36:39.513504Z  INFO garage::server: Spawning Garage workers...
2024-04-09 14:36:39 2024-04-09T18:36:39.513777Z  INFO garage::server: Initialize Admin API server and metrics collector...
2024-04-09 14:36:39 2024-04-09T18:36:39.581100Z  INFO garage::server: Launching internal Garage cluster communications...
2024-04-09 14:36:39 2024-04-09T18:36:39.581188Z  INFO garage::server: Create admin RPC handler...
2024-04-09 14:36:39 2024-04-09T18:36:39.581202Z  INFO garage::server: Initializing S3 API server...
2024-04-09 14:36:39 2024-04-09T18:36:39.581205Z  INFO garage::server: Initializing K2V API server...
2024-04-09 14:36:39 2024-04-09T18:36:39.581208Z  INFO garage::server: Initializing web server...
2024-04-09 14:36:39 2024-04-09T18:36:39.581218Z  INFO garage::server: Launching Admin API server...
2024-04-09 14:36:39 2024-04-09T18:36:39.581287Z  INFO garage_net::netapp: Listening on 127.0.0.1:3901    
2024-04-09 14:36:39 2024-04-09T18:36:39.581316Z  INFO garage_api::generic_server: S3 API server listening on http://127.0.0.1:3900
2024-04-09 14:36:39 2024-04-09T18:36:39.581381Z  INFO garage_web::web_server: Web server listening on http://127.0.0.1:3902
2024-04-09 14:36:39 2024-04-09T18:36:39.581586Z  INFO garage_api::generic_server: K2V API server listening on http://[::]:3904
2024-04-09 14:36:39 2024-04-09T18:36:39.581836Z  INFO garage_api::generic_server: Admin API server listening on http://127.0.0.1:3903

so it appears to running properly.

I create an alias so: alias garage="docker exec -ti garaged /garage"

and garage status returns

2024-04-09T19:08:18.467817Z  INFO garage_net::netapp: Connected to 127.0.0.1:3901, negotiating handshake...    
2024-04-09T19:08:18.509152Z  INFO garage_net::netapp: Connection established to d08e1c7b9177d649    
==== HEALTHY NODES ====
ID                Hostname        Address         Tags  Zone  Capacity   DataAvail
d08e1c7b9177d649  docker-desktop  127.0.0.1:3901  []    dc1   1000.0 MB  3.2 TB (79.5%)

I can create and apply a cluster layout:

$ garage layout apply --version 2
2024-04-09T19:14:36.866461Z  INFO garage_net::netapp: Connected to 127.0.0.1:3901, negotiating handshake...    
2024-04-09T19:14:36.908111Z  INFO garage_net::netapp: Connection established to d08e1c7b9177d649    
==== COMPUTATION OF A NEW PARTITION ASSIGNATION ====

Partitions are replicated 1 times on at least 1 distinct zones.

Optimal partition size:                     3.9 MB (3.9 MB in previous layout)
Usable capacity / total cluster capacity:   1000.0 MB / 1000.0 MB (100.0 %)
Effective capacity (replication factor 1):  1000.0 MB

A total of 0 new copies of partitions need to be transferred.

dc1                 Tags  Partitions        Capacity   Usable capacity
  d08e1c7b9177d649        256 (0 new)       1000.0 MB  1000.0 MB (100.0%)
  TOTAL                   256 (256 unique)  1000.0 MB  1000.0 MB (100.0%)


New cluster layout with updated role assignment has been applied in cluster.
Data will now be moved around between nodes accordingly.

I can use the command line to create a bucket and API key, and give the key permission to use the bucket:

$ garage bucket info cl-first
2024-04-09T19:10:00.595340Z  INFO garage_net::netapp: Connected to 127.0.0.1:3901, negotiating handshake...    
2024-04-09T19:10:00.636526Z  INFO garage_net::netapp: Connection established to d08e1c7b9177d649    
Bucket: 6bd35158ce746f19bdde4e00d57d7ae00c74cfe6f5590b1d05ec264ade49c034

Size: 0 B (0 B)
Objects: 0
Unfinished uploads (multipart and non-multipart): 0
Unfinished multipart uploads: 0
Size of unfinished multipart uploads: 0 B (0 B)

Website access: false

Global aliases:
  cl-first

Key-specific aliases:

Authorized keys:
  RWO  GK5bec374936673b0b236b1618  cl-second

I can set environment variables for AWSCLI:

AWS_ENDPOINT_URL=http://localhost:3900
AWS_DEFAULT_REGION=garage
AWS_SECRET_ACCESS_KEY=xxxxx
AWS_ACCESS_KEY_ID=xxxxx

But AWSCLI can't access Garage via the S3 API:

$ aws s3 ls

Could not connect to the endpoint URL: "http://localhost:3900/"

With appropriate configuration, I can use AWSCLI to access a Min.IO server running locally.

Also, I have a Node.JS app, which, when properly configured, can access the Min.IO server. When I use the AWS configuration above for Garage, I get:

Error: connect ECONNREFUSED 127.0.0.1:3900
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)

I've been through all this, using localhost or http://[::]:3900 as the endpoint, but all fail with the above errors.

Is there a guide to troubleshooting connection issues?

As my dev machine runs MacOS rather than linux, I tried following the instructions at https://garagehq.deuxfleurs.fr/documentation/quick-start/ but substituting the Docker image for a binary. The last config file I tried is ``` metadata_dir = "/var/lib/garage/meta" data_dir = "/var/lib/garage/data" db_engine = "sqlite" replication_mode = "none" rpc_bind_addr = "127.0.0.1:3901" rpc_public_addr = "127.0.0.1:3901" rpc_secret = "xxxxxxx" [s3_api] s3_region = "garage" api_bind_addr = "127.0.0.1:3900" root_domain = ".s3.garage.localhost" [s3_web] bind_addr = "127.0.0.1:3902" root_domain = ".web.garage.localhost" index = "index.html" [k2v_api] api_bind_addr = "[::]:3904" [admin] api_bind_addr = "127.0.0.1:3903" admin_token = "xxxxx" metrics_token = "xxxxxxx" ``` I tried several variations on network addresses, but they all suffer the problem below. /etc/garage.toml, /var/lib/garage/meta and /var/lib/garage/data on my dev machine are all owned by me. I can create a container so: ``` docker run \ -d \ --name garaged \ --restart always \ --network host \ -v /etc/garage.toml:/etc/garage.toml \ -v /var/lib/garage/meta:/var/lib/garage/meta \ -v /var/lib/garage/data:/var/lib/garage/data \ dxflrs/garage:v0.9.4 ``` The image starts up and the log includes ``` 2024-04-09 14:36:39 2024-04-09T18:36:39.513469Z INFO garage::server: Initializing background runner... 2024-04-09 14:36:39 2024-04-09T18:36:39.513504Z INFO garage::server: Spawning Garage workers... 2024-04-09 14:36:39 2024-04-09T18:36:39.513777Z INFO garage::server: Initialize Admin API server and metrics collector... 2024-04-09 14:36:39 2024-04-09T18:36:39.581100Z INFO garage::server: Launching internal Garage cluster communications... 2024-04-09 14:36:39 2024-04-09T18:36:39.581188Z INFO garage::server: Create admin RPC handler... 2024-04-09 14:36:39 2024-04-09T18:36:39.581202Z INFO garage::server: Initializing S3 API server... 2024-04-09 14:36:39 2024-04-09T18:36:39.581205Z INFO garage::server: Initializing K2V API server... 2024-04-09 14:36:39 2024-04-09T18:36:39.581208Z INFO garage::server: Initializing web server... 2024-04-09 14:36:39 2024-04-09T18:36:39.581218Z INFO garage::server: Launching Admin API server... 2024-04-09 14:36:39 2024-04-09T18:36:39.581287Z INFO garage_net::netapp: Listening on 127.0.0.1:3901 2024-04-09 14:36:39 2024-04-09T18:36:39.581316Z INFO garage_api::generic_server: S3 API server listening on http://127.0.0.1:3900 2024-04-09 14:36:39 2024-04-09T18:36:39.581381Z INFO garage_web::web_server: Web server listening on http://127.0.0.1:3902 2024-04-09 14:36:39 2024-04-09T18:36:39.581586Z INFO garage_api::generic_server: K2V API server listening on http://[::]:3904 2024-04-09 14:36:39 2024-04-09T18:36:39.581836Z INFO garage_api::generic_server: Admin API server listening on http://127.0.0.1:3903 ``` so it appears to running properly. I create an alias so: `alias garage="docker exec -ti garaged /garage"` and `garage status` returns ``` 2024-04-09T19:08:18.467817Z INFO garage_net::netapp: Connected to 127.0.0.1:3901, negotiating handshake... 2024-04-09T19:08:18.509152Z INFO garage_net::netapp: Connection established to d08e1c7b9177d649 ==== HEALTHY NODES ==== ID Hostname Address Tags Zone Capacity DataAvail d08e1c7b9177d649 docker-desktop 127.0.0.1:3901 [] dc1 1000.0 MB 3.2 TB (79.5%) ``` I can create and apply a cluster layout: ``` $ garage layout apply --version 2 2024-04-09T19:14:36.866461Z INFO garage_net::netapp: Connected to 127.0.0.1:3901, negotiating handshake... 2024-04-09T19:14:36.908111Z INFO garage_net::netapp: Connection established to d08e1c7b9177d649 ==== COMPUTATION OF A NEW PARTITION ASSIGNATION ==== Partitions are replicated 1 times on at least 1 distinct zones. Optimal partition size: 3.9 MB (3.9 MB in previous layout) Usable capacity / total cluster capacity: 1000.0 MB / 1000.0 MB (100.0 %) Effective capacity (replication factor 1): 1000.0 MB A total of 0 new copies of partitions need to be transferred. dc1 Tags Partitions Capacity Usable capacity d08e1c7b9177d649 256 (0 new) 1000.0 MB 1000.0 MB (100.0%) TOTAL 256 (256 unique) 1000.0 MB 1000.0 MB (100.0%) New cluster layout with updated role assignment has been applied in cluster. Data will now be moved around between nodes accordingly. ``` I can use the command line to create a bucket and API key, and give the key permission to use the bucket: ``` $ garage bucket info cl-first 2024-04-09T19:10:00.595340Z INFO garage_net::netapp: Connected to 127.0.0.1:3901, negotiating handshake... 2024-04-09T19:10:00.636526Z INFO garage_net::netapp: Connection established to d08e1c7b9177d649 Bucket: 6bd35158ce746f19bdde4e00d57d7ae00c74cfe6f5590b1d05ec264ade49c034 Size: 0 B (0 B) Objects: 0 Unfinished uploads (multipart and non-multipart): 0 Unfinished multipart uploads: 0 Size of unfinished multipart uploads: 0 B (0 B) Website access: false Global aliases: cl-first Key-specific aliases: Authorized keys: RWO GK5bec374936673b0b236b1618 cl-second ``` I can set environment variables for AWSCLI: ``` AWS_ENDPOINT_URL=http://localhost:3900 AWS_DEFAULT_REGION=garage AWS_SECRET_ACCESS_KEY=xxxxx AWS_ACCESS_KEY_ID=xxxxx ``` But AWSCLI can't access Garage via the S3 API: ``` $ aws s3 ls Could not connect to the endpoint URL: "http://localhost:3900/" ``` With appropriate configuration, I can use AWSCLI to access a Min.IO server running locally. Also, I have a Node.JS app, which, when properly configured, can access the Min.IO server. When I use the AWS configuration above for Garage, I get: ``` Error: connect ECONNREFUSED 127.0.0.1:3900 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16) ``` I've been through all this, using localhost or http://[::]:3900 as the endpoint, but all fail with the above errors. Is there a guide to troubleshooting connection issues?
lx commented 2024-04-09 19:50:33 +00:00
Owner
Copy link

Hello, I think your issue is that you are using --network host, which is not supported under mac os. You should instead try forwarding ports individually using the --port argument.

Hello, I think your issue is that you are using `--network host`, which is not supported under mac os. You should instead try forwarding ports individually using the `--port` argument.
DougReeder commented 2024-04-09 20:35:42 +00:00
Author
Copy link

Thanks, but creating the container with

docker run \
>   -d \
>   --name garaged \
>   --restart always \
>   -p 3900:3900 \
>   -v /etc/garage.toml:/etc/garage.toml \
>   -v /var/lib/garage/meta:/var/lib/garage/meta \
>   -v /var/lib/garage/data:/var/lib/garage/data \
>   dxflrs/garage:v0.9.4

only results in different error messages. AWSCLI returns

Connection was closed before we received a valid response from endpoint URL: "http://localhost:3900/"

and my Node.JS app gets

Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:217:20)

Thanks, but creating the container with ``` docker run \ > -d \ > --name garaged \ > --restart always \ > -p 3900:3900 \ > -v /etc/garage.toml:/etc/garage.toml \ > -v /var/lib/garage/meta:/var/lib/garage/meta \ > -v /var/lib/garage/data:/var/lib/garage/data \ > dxflrs/garage:v0.9.4 ``` only results in different error messages. AWSCLI returns `Connection was closed before we received a valid response from endpoint URL: "http://localhost:3900/"` and my Node.JS app gets `Error: read ECONNRESET at TCP.onStreamRead (node:internal/stream_base_commons:217:20)`
DougReeder commented 2024-04-10 17:59:35 +00:00
Author
Copy link

FWIW, when I use alias garage="docker exec -ti garaged /garage" to run garage bucket list, I see some messages in the log, starting with INFO garage_net::netapp: Accepted connection from 75b6268c2b8f3587 at 127.0.0.1:49370

When I try to use AWSCLI to connect, I don't see anything whatsoever in the log, even when I set RUST_LOG=garage=trace

Do I need to rebuild the image, after editing the Dockerfile to assert that the image uses the various ports?

FWIW, when I use `alias garage="docker exec -ti garaged /garage"` to run `garage bucket list`, I see some messages in the log, starting with `INFO garage_net::netapp: Accepted connection from 75b6268c2b8f3587 at 127.0.0.1:49370` When I try to use AWSCLI to connect, I don't see anything whatsoever in the log, even when I set `RUST_LOG=garage=trace` Do I need to rebuild the image, after editing the Dockerfile to assert that the image uses the various ports?
lx commented 2024-04-10 18:02:10 +00:00
Owner
Copy link

You might need to set api_bind_addr = "[::]:3900" in your config file to allow connctions arriving through the Docker port forward.

You might need to set `api_bind_addr = "[::]:3900"` in your config file to allow connctions arriving through the Docker port forward.
DougReeder commented 2024-04-10 20:46:51 +00:00
Author
Copy link

Yep, one needs to leave the network addresses as [::]:3900 but change --network host to -p 3900:3900 -p 3901:3901 -p 3902:3902 -p 3903:3903.

I've submitted a doc PR for this: #803

Yep, one needs to leave the network addresses as `[::]:3900` but change `--network host` to `-p 3900:3900 -p 3901:3901 -p 3902:3902 -p 3903:3903`. I've submitted a doc PR for this: https://git.deuxfleurs.fr/Deuxfleurs/garage/pulls/803
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
update-dependencies-1.1
feat-metrics-metadata-engine
improve-secret-error-message
hotfix/1.0.0-rc1-red-ftr-wquorum
main-0.9.x
db-no-unsafe
main-0.8.x
k2v/shared_http_client
feat/website-redir
smithy2
test/compilation
poc/nomad-ci
test-ci-wait
pnet_datalink-0.33.0
optimal-layout
k2v-watch-range
db-debug-log
build-convert-db
demonstrate-cargo2nix-bug
dangerous/no-fsync
dev0.7.3
doc/benchmarks
bug/check_static
bucket-cors-more
storage-optimizations
old-main
v1.0.1
v1.0.0
v0.9.4
v1.0.0-rc1
v0.8.7
v0.9.3
v0.9.2
v0.8.6
v0.9.2-rc1
v0.9.1
v0.8.5
v0.10.0-beta1
v0.9.0
v0.9.0-rc2
v0.9.0-rc1
v0.9.0-beta4
v0.9.0-beta3
v0.9.0-beta2
v0.8.4
v0.9.0-beta1
v0.8.3
v0.8.3-rc1
format_table-v0.1.1
format_table-v0.1.0
v0.8.2
v0.8.1
v0.8.0
v0.8.0-rc2
v0.8.0-rc1
v0.8.0-dangerous-no-fsync
v0.8.0-beta2-k2v
v0.8.0-beta2
v0.8.0-beta1-k2v
v0.8.0-beta1
v0.7.99.3-k2v
v0.7.3
v0.7.3-beta2
v0.7.3-beta1
v0.7.2.1
v0.7.2
v0.7.2_ci-test-2
v0.7.2+ci-test-version
v0.7.99.2-k2v
v0.7.99.1-k2v
v0.7.99-k2v
v0.7.2-k2v
v0.7.1-admin-k2v-2
v0.7.1-admin-k2v
v0.7.1-k2v
v0.7.1
v0.7.0
v0.7.0-rc1
v0.6.1
v0.6.0
v0.6.0-rc1
v0.5.1
v0.5.0.1
v0.5.0
v0.5-beta1
v0.4.0
v0.4-rc2
v0.4-rc1
0.4-beta
0.4-alpha
v0.3.0.2
v0.3.0.1
v0.3.0
v0.2.1.5
v0.2.1
v0.2.0
0.1.1b
0.1.1
0.1.0b
0.1.0
Labels
Clear labels   
action
check-aws
The behaviour should be checked against AWS S3

  
action
discussion-needed
We need to discuss if the feature is desirable and/or better specify the envisioned behavior or technical implementation

  
action
for-external-contributors
Core team does not plan working on this in the near future however an external contribution will be reviewed & merged

  
action
for-newcomers
An issue that should be newcomer friendly.

  
action
more-info-needed
More information is needed to investigate this issue

  
action
need-funding
This issue represents lots of work, we need to find money to pay our core team work

  
action
triage-required
It's not very clear what we want to do with this issue yet, more thoughts is required

  
kind
correctness
Issues of theoretical correctness that may impact edge-case scenarios

  
kind
ideas
For abstract ideas/proposal to make Garage better, to better communicate our not yet achieved aims

  
kind
improvement
Feature requests that do not fall in other categories

  
kind
performance
Deceptive performance observed OR idea to improve performances

  
kind
testing
Functional tests, integration tests, Jepsen, etc.

  
kind
usability
Propositions to make Garage easier to operate, by improving error reporting, CLI, etc.

  
kind
wrong-behavior
Unintended behavior

  
prio
critical
Could impact integrity or availability of production clusters

  
prio
low
For issues that we don't want to spend time on until made absolutely necessary

  
scope
admin-api
Issues concerning the administration API

  
scope
background-healing
Background healing covers repair tasks, anti-entropy, merkle trees, etc. ; everything related to replicating data appropriately.

  
scope
build
Issues with Nix, Drone, Rust Compiler, etc.

  
scope
documentation

  
scope
k8s
Kubernetes related, including Helm Charts

  
scope
layout
Linked to the cluster layout and storage management

  
scope
metadata
Metadata Engine (LMDB, sqlite, etc.)

  
scope
ops
Operations related to operations/maintenance issue, tooling related (like CLI missing info ; impossible, too dangerous, too complicated migration, etc.)

  
scope
rpc
Linked to RPC

  
scope
s3-api
Related to the S3 API (especially compatibility issues).

  
scope
security
Cryptography-related, auth-related, authorization-related issues

  
scope
telemetry
OpenTelemetry (traces, metrics, etc.)

No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#801
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?