Не удается получить доступ к CouchDB на экземпляре AWS, используя URL-адрес

Question

Я установил CouchDB на экземпляр AWS Linux и могу получить к нему доступ через SSH, но не могу получить к нему доступ с использованием общедоступного URL-адреса экземпляра.

В SSH я могу запустить curl -X GET http://127.0.0.1:5984/_all_dbs, и это дает мне ["_replicator","_users","baseball"], что и я ожидаю.

Если я пытаюсь использовать URL-адрес экземпляра AWS в Chrome: http://ec2-xx-xxx-xx-xx.eu-central-1.compute.amazonaws.com:5984/_utils Chrome говорит, что веб-сайт отказался подключиться.

Я отредактировал файл CouchDB local.ini, чтобы добавить CORS. Local.ini теперь выглядит следующим образом:

; CouchDB Configuration Settings 
 

 
; Custom settings should be made in this file. They will override settings 
 
; in default.ini, but unlike changes made to default.ini, this file won't be 
 
; overwritten on server upgrade. 
 

 
[couchdb] 
 
;max_document_size = 4294967296 ; bytes 
 

 
[httpd] 
 
enable_cors = true 
 
bind_address = 0.0.0.0 
 

 
[cors] 
 
origins = * 
 

 
;port = 5984 
 
;bind_address = 127.0.0.1 
 
; Options for the MochiWeb HTTP server. 
 
;server_options = [{backlog, 128}, {acceptor_pool_size, 16}] 
 
; For more socket options, consult Erlang's module 'inet' man page. 
 
;socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}] 
 

 
; Uncomment next line to trigger basic-auth popup on unauthorized requests. 
 
;WWW-Authenticate = Basic realm="administrator" 
 

 
; Uncomment next line to set the configuration modification whitelist. Only 
 
; whitelisted values may be changed via the /_config URLs. To allow the admin 
 
; to change this value over HTTP, remember to include {httpd,config_whitelist} 
 
; itself. Excluding it from the list would require editing this file to update 
 
; the whitelist. 
 
;config_whitelist = [{httpd,config_whitelist}, {log,level}, {etc,etc}] 
 

 
[query_servers] 
 
;nodejs = /usr/local/bin/couchjs-node /path/to/couchdb/share/server/main.js 
 

 

 
[httpd_global_handlers] 
 
;_google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>} 
 

 
[couch_httpd_auth] 
 
; If you set this to true, you should also uncomment the WWW-Authenticate line 
 
; above. If you don't configure a WWW-Authenticate header, CouchDB will send 
 
; Basic realm="server" in order to prevent you getting logged out. 
 
; require_valid_user = false 
 

 
[log] 
 
;level = debug 
 

 
[log_level_by_module] 
 
; In this section you can specify any of the four log levels 'none', 'info', 
 
; 'error' or 'debug' on a per-module basis. See src/*/*.erl for various 
 
; modules. 
 
;couch_httpd = error 
 

 

 
[os_daemons] 
 
; For any commands listed here, CouchDB will attempt to ensure that 
 
; the process remains alive. Daemons should monitor their environment 
 
; to know when to exit. This can most easily be accomplished by exiting 
 
; when stdin is closed. 
 
;foo = /path/to/command -with args 
 

 
[daemons] 
 
; enable SSL support by uncommenting the following line and supply the PEM's below. 
 
; the default ssl port CouchDB listens on is 6984 
 
; httpsd = {couch_httpd, start_link, [https]} 
 

 
[ssl] 
 
;cert_file = /full/path/to/server_cert.pem 
 
;key_file = /full/path/to/server_key.pem 
 
;password = somepassword 
 
; set to true to validate peer certificates 
 
verify_ssl_certificates = false 
 
; Path to file containing PEM encoded CA certificates (trusted 
 
; certificates used for verifying a peer certificate). May be omitted if 
 
; you do not want to verify the peer. 
 
;cacert_file = /full/path/to/cacertf 
 
; The verification fun (optional) if not specified, the default 
 
; verification fun will be used. 
 
;verify_fun = {Module, VerifyFun} 
 
; maximum peer certificate depth 
 
ssl_certificate_max_depth = 1 
 

 
; To enable Virtual Hosts in CouchDB, add a vhost = path directive. All requests to 
 
; the Virual Host will be redirected to the path. In the example below all requests 
 
; to http://example.com/ are redirected to /database. 
 
; If you run CouchDB on a specific port, include the port number in the vhost: 
 
; example.com:5984 = /database 
 
[vhosts] 
 
;example.com = /database/ 
 

 
[update_notification] 
 
;unique notifier name=/full/path/to/exe -with "cmd line arg" 
 

 
; To create an admin account uncomment the '[admins]' section below and add a 
 
; line in the format 'username = password'. When you next start CouchDB, it 
 
; will change the password to a hash (so that your passwords don't linger 
 
; around in plain-text files). You can add more admin accounts with more 
 
; 'username = password' lines. Don't forget to restart CouchDB after 
 
; changing this. 
 
[admins] 
 
;admin = mysecretpassword

: UPDATE:

При работе:

netstat -a -n | grep 5984 

я получаю:

tcp  0  0 127.0.0.1:5984    0.0.0.0:*     LISTEN 

127.0.0.1, но должно быть 0.0.0.0, поскольку я установил привязки как в etc/couchdb/local.ini, так и в etc/couchdb/default.ini равным 0.0.0.0.

Похоже, что couchdb подбирает настройки в другом месте? Когда я бегу:

couchdb -c 

я получаю:

/usr/local/etc/couchdb/default.ini 
/usr/local/etc/couchdb/local.ini 

Когда SSHing в экземпляр AWS корневой каталог содержит два элемента:

apache-couchdb-1.6.1 apache-couchdb-1.6.1.tar.gz 

Я cd в apache-couchdb-1.6.1 и редактировать ини файл дела:

vim etc/couchdb/local.ini 

Я предполагаю, что это то же самое, что и /usr/local/etc/couchdb/local.ini?

Я остановил и перезапустил couchdb и перезапустил экземпляр AWS, но все же couchdb не собирает bind_address из конфигурационных файлов.

SORTED IT

Оказывается, что /usr/local/etc/couchdb/local.ini не то же самое, как etc/couchdb/local.ini. Когда я устанавливаю привязки в правильном порядке, все работает!

Answer 1

Для его видимости снаружи требуется всего две вещи: вы должны привязываться к внешнему IP-адресу (показанному как Public IP в свойствах экземпляра EC2) и открывать его на брандмауэре. Так что это должно быть между этими двумя.

Я вижу, что вы изменили адрес привязки на 0.0.0.0. Это должно касаться этапа привязки путем привязки ко всем интерфейсам.

Но вы все еще подключаетесь с помощью localhost с помощью ssh.Тогда вы не проверяете то же самое. Попытайтесь использовать машинный IP-адрес вместо 127.0.0.1 при попытке тестирования с помощью curl. Он должен быть показан как открытый IP-адрес в свойствах экземпляра EC2. Но если вы сомневаетесь, используйте ifconfig -a, чтобы выяснить, какие IP-адреса у вас есть. Вы также можете проверить, на каких интерфейсах он фактически связан, выполнив следующую команду: netstat -a -n | grep 5984. Он должен показывать 0.0.0.0:5984 (или *: 5984) как LISTEN (не 127.0.0.1:5984). В противном случае он не привязан к правильному порту, и вы должны проверить конфигурационный файл CouchDb, чтобы узнать, почему. Также стоит проверить, что CouchDB действительно использует конфигурацию, которую вы редактируете.

На стороне брандмауэра убедитесь, что вы открыли его в правильной группе безопасности. Это должно быть указано в свойствах «Группы безопасности» вашего экземпляра EC2, и правило, которое вы открываете, должно быть включено.

В некоторых случаях брандмауэр экземпляра иногда перескакивает и вызывает проблемы. Но у меня была эта проблема только на машинах Windows. Я считаю, что он отключен на машинах AWS Linux (по крайней мере, мне никогда не нужно было ничего настраивать - правил группы безопасности всегда было достаточно).

Если это все еще не работает. Я могу предложить только попробовать протестировать его с помощью telnet, независимо от того, подключается ли он вообще. Поскольку браузеры иногда ошибочно фиксируют точную стадию, чтобы сделать ее проще для обычного пользователя. Соединение с telnet является более низким уровнем теста, но имейте в виду, что вам нужно отделить порт с пространством для telnet вместо двоеточия, например. telnet 1.2.3.4 5984 где 1.2.3.4 - IP-адрес сервера.