Попытка подключиться к сервису mongodb через консул Connect Sidecar Proxy - PullRequest
Новая
       51

Попытка подключиться к сервису mongodb через консул Connect Sidecar Proxy

0 голосов
/ 22 апреля 2020

У меня настроен Minikube и запущен экземпляр mon go. Я пользуюсь Consul + Consul Connect to me sh мои услуги. Только я не могу подключиться к mon go из другого сервиса с использованием боковых апстриков, происходят странные вещи ...

Мой экземпляр mon go устанавливается с помощью bitnami helm chart, я просто устанавливаю имя сервиса , задайте имя пользователя и измените класс хранилища в соответствии с моими потребностями, и поместите аннотации консула для службы me sh в разделе аннотаций модуля: 

image:
  registry: docker.io
  repository: bitnami/mongodb
  tag: 4.2.5-debian-10-r3
  pullPolicy: IfNotPresent
  debug: false
serviceAccount:
  create: true
  name: "svc-identity-data"
usePassword: true
mongodbRootPassword: rootpassword
mongodbUsername: identity
mongodbPassword: identity
mongodbDatabase: company
service:
  name: svc-identity-data
  annotations: {}
  type: ClusterIP
  port: 27017
useStatefulSet: true
replicaSet:
  enabled: false
  useHostnames: true
  name: rs0
  replicas:
    secondary: 1
    arbiter: 1
  pdb:
    enabled: true
    minAvailable:
      primary: 1
      secondary: 1
      arbiter: 1
annotations: {}
labels: {}
podAnnotations:
    "consul.hashicorp.com/connect-inject": "true"
    "consul.hashicorp.com/connect-service": "svc-identity-data"
    "consul.hashicorp.com/connect-service-protocol": "tcp"
persistence:
  enabled: true
  mountPath: /bitnami/mongodb
  subPath: ""
  storageClass: "standard"
  accessModes:
    - ReadWriteOnce
  size: 8Gi
  annotations: {}
configmap:
  storage:
    dbPath: /bitnami/mongodb/data/db
    journal:
      enabled: true
    directoryPerDB: false
  systemLog:
    destination: file
    quiet: false
    logAppend: true
    logRotate: reopen
    path: /opt/bitnami/mongodb/logs/mongodb.log
    verbosity: 0
  net:
    port: 27017
    unixDomainSocket:
      enabled: true
      pathPrefix: /opt/bitnami/mongodb/tmp
    ipv6: false
    bindIp: 0.0.0.0
  processManagement:
     fork: false
     pidFilePath: /opt/bitnami/mongodb/tmp/mongodb.pid
  setParameter:
     enableLocalhostAuthBypass: true
  security:
    authorization: enabled

Во-вторых, я запустил автономный модуль mongodb для использования mon * Клиент 1040 * и подключен к консулу, используя аннотации 

apiVersion: v1
kind: Pod
metadata:
  name: mongo-client
  labels:
    name: mongo-client
  annotations:
        "consul.hashicorp.com/connect-inject": "true"
        "consul.hashicorp.com/connect-service-upstreams": "svc-identity-data:28017"
        "consul.hashicorp.com/connect-service-protocol": "tcp"    
spec:
  containers:
  - name: mongo-client
    image: mongo:4.2.5
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
      - containerPort: 27017

Теперь у меня есть служба mongodb и клиентский модуль mon go со службой восходящего потока к mongodb, привязанной к 127.0.0.1:28017

Когда я пытаюсь подключиться к сервису mongodb, используя мой апстрим, я получаю поведение, которое не понимаю 

> kubectl exec -it mongo-client mongo --host 127.0.0.1 --port 28017 -u root -p rootpassword

MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:28017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("8c46012d-8083-4029-8495-167bbe8bf063") }
MongoDB server version: 4.2.5
Server has startup warnings: 
2020-04-22T12:20:14.777+0000 I  STORAGE  [initandlisten] 
2020-04-22T12:20:14.777+0000 I  STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2020-04-22T12:20:14.777+0000 I  STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
---
Enable MongoDB's free cloud-based monitoring service, which will then receive and display
metrics about your deployment (disk utilization, CPU, operation statistics, etc).

The monitoring data will be available on a MongoDB website with a unique URL accessible to you
and anyone you share the URL with. MongoDB may use this information to make product
improvements and to suggest MongoDB products and deployment options to you.

To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---

> 
bye

Нет проблем, все прекрасно работает, но если я использую mon go со строкой соединения вместо отдельных параметров, я получаю отказ в соединении 

> kubectl exec -it mongo-client mongo mongodb://root:roopassword@127.0.0.1:28017/?authSource=admin

MongoDB shell version v4.2.5
connecting to: mongodb://127.0.0.1:28017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
2020-04-22T15:04:07.955+0000 I  NETWORK  [js] DBClientConnection failed to receive message from 127.0.0.1:28017 - HostUnreachable: Connection closed by peer
2020-04-22T15:04:07.968+0000 E  QUERY    [js] Error: network error while attempting to run command 'isMaster' on host '127.0.0.1:28017'  :
connect@src/mongo/shell/mongo.js:341:17
@(connect):2:6
2020-04-22T15:04:07.973+0000 F  -        [main] exception: connect failed
2020-04-22T15:04:07.973+0000 E  -        [main] exiting with code 1

Я вообще не понимаю, в чем разница между использованием co строка подключения и отдельные параметры, если у вас есть какие-либо подсказки или решение, пожалуйста, дайте мне знать.

PS: я не установил никакой безопасной связи (tls), я нахожусь на мини-кубе (потому что я ' В микросервисной архитектуре и Kubernetes n00b) и это экспериментальный сервис для меня sh (нам нужно жить в нынешнюю эпоху), решение, включающее подключение к сервису без использования коляски, не имеет смысла, кстати, подключение напрямую к сервис работает отлично, используя строку подключения. 

> kubectl exec -it mongo-client mongo -mongodb://root:roopassword@svc-identity-data:28017/?authSource=admin

MongoDB shell version v4.2.5
connecting to: mongodb://svc-identity-data:27017/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("713febaf-2000-4ca6-8b1f-963c76986e72") }
MongoDB server version: 4.2.5
Server has startup warnings: 
2020-04-22T12:20:14.777+0000 I  STORAGE  [initandlisten] 
2020-04-22T12:20:14.777+0000 I  STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2020-04-22T12:20:14.777+0000 I  STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
---
Enable MongoDB's free cloud-based monitoring service, which will then receive and display
metrics about your deployment (disk utilization, CPU, operation statistics, etc).

The monitoring data will be available on a MongoDB website with a unique URL accessible to you
and anyone you share the URL with. MongoDB may use this information to make product
improvements and to suggest MongoDB products and deployment options to you.

To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---

> 
bye

EDIT : перезагрузка мини-куба заставляет все работать как задумано. Я буду исследовать больше по этому вопросу, чтобы понять, почему. Может быть, кто-то еще столкнется с той же проблемой.

EDIT 2 : я обнаружил одну вещь: ошибка подключения при подключении к mon go через коляску является случайной, когда я запускаю команду до тех пор, пока она не будет успешной вот что я получаю 

root@mongo-client:/# mongo mongodb://root:rootpassword@localhost:28017/?authSource=admin
MongoDB shell version v4.2.5
connecting to: mongodb://localhost:28017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
2020-04-24T12:51:15.641+0000 I  NETWORK  [js] DBClientConnection failed to receive message from localhost:28017 - HostUnreachable: Connection closed by peer
2020-04-24T12:51:15.702+0000 E  QUERY    [js] Error: network error while attempting to run command 'isMaster' on host 'localhost:28017'  :
connect@src/mongo/shell/mongo.js:341:17
@(connect):2:6
2020-04-24T12:51:15.729+0000 F  -        [main] exception: connect failed
2020-04-24T12:51:15.729+0000 E  -        [main] exiting with code 1
root@mongo-client:/# mongo mongodb://root:rootpassword@localhost:28017/?authSource=admin
MongoDB shell version v4.2.5
connecting to: mongodb://localhost:28017/?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("628bfcf9-6d44-4168-ab74-19a717d746f6") }
MongoDB server version: 4.2.5
Server has startup warnings: 
2020-04-24T06:43:39.359+0000 I  STORAGE  [initandlisten] 
2020-04-24T06:43:39.359+0000 I  STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2020-04-24T06:43:39.359+0000 I  STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
---
Enable MongoDB's free cloud-based monitoring service, which will then receive and display
metrics about your deployment (disk utilization, CPU, operation statistics, etc).

The monitoring data will be available on a MongoDB website with a unique URL accessible to you
and anyone you share the URL with. MongoDB may use this information to make product
improvements and to suggest MongoDB products and deployment options to you.

To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---

> 
bye

И на стороне mon go log: 

2020-04-24T12:51:19.281+0000 I  NETWORK  [conn6647] end connection 127.0.0.1:54148 (6 connections now open)
2020-04-24T12:51:19.526+0000 I  COMMAND  [conn6646] command admin.$cmd appName: "MongoDB Shell" command: saslStart { saslStart: 1, mechanism: "SCRAM-SHA-256", payload: "xxx", $db: "admin" } numYields:0 reslen:196 locks:{} protocol:op_msg 231ms
2020-04-24T12:51:19.938+0000 I  ACCESS   [conn6646] Successfully authenticated as principal root on admin from client 127.0.0.1:54142
2020-04-24T12:51:20.024+0000 I  NETWORK  [listener] connection accepted from 127.0.0.1:54168 #6648 (7 connections now open)
2020-04-24T12:51:20.027+0000 I  NETWORK  [conn6648] received client metadata from 127.0.0.1:54168 conn6648: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "4.2.5" }, os: { type: "Linux", name: "PRETTY_NAME="Debian GNU/Linux 10 (buster)"", architecture: "x86_64", version: "Kernel 4.19.94" } }
2020-04-24T12:51:20.215+0000 I  NETWORK  [conn6648] end connection 127.0.0.1:54168 (6 connections now open)
2020-04-24T12:51:21.328+0000 I  NETWORK  [conn6646] end connection 127.0.0.1:54142 (5 connections now open)

Я все больше смущаюсь, я не могу объяснить такое поведение.

Ответы [ 2 ]

0 голосов
/ 24 апреля 2020

Я нашел решение, оказалось, что это самая простая из возможных проблем: ресурсы

Моего мини-куба не хватило, чтобы все модули работали быстро, он вводил задержку между прокси-модулями коляски даже если kubenetes не поднял ошибку ни при каком отключении.

Я - ученик kubernetes, поэтому я не думал об этом сразу. Теперь, когда я знаю, что произошло, я могу исследовать в правильном направлении, чтобы понять, в каких случаях задержка может быть проблемой.

0 голосов
/ 24 апреля 2020

Проблема может заключаться в том, что CN сертификата не соответствует значению имени хоста в файле конфигурации MongoDB. Речь идет о спецификации MongoDB и параметрах, с которыми вы ее запускаете.

CN (общее имя) или SAN (альтернативное имя субъекта) сертификата должно соответствовать значению --hostname, которое вы указываете при запуске mon go. Ваш URI MongoDB: 

MONGODB_URI=mongodb://root:roopassword@127.0.0.1:28017/?authSource=admin

MongoDB НЕ находится на локальном хосте. Также сервер MongoDB должен разрешить ЛЮБОМУ хосту подключаться к базе данных. По умолчанию это разрешит ТОЛЬКО соединения из ЖЕ времени выполнения. Вам нужно получить IP-адрес сервиса, который назначен pod с вашим контейнером базы данных - svc-identity-data имеет адрес 10.107.99.51.

Взгляните: mongodb-ssl , MongoDB-неудавшийся Соединяемый

...