Troubleshooting

• Join our slack channel and post the example causing trouble
• Email us at team@aperturedata.io with a description of the problem

Problems with dependencies version mismatches.

caution

Setting up (or updating) the virtual environment for the python client can sometimes cause version dependencies mismatches. This is because the ApertureDB SDK does not pin the version numbers of some of its dependencies, and those get released in separate cycles.

There's a docker image that is built during the CI process and is a guaranteed stable environment in such a case. This image also includes a installation of Jupyter Lab.

The docker compose file would include the following service in such a case.

name: aperturedb-community-local

services:
  ca:
    image: nginx
    restart: on-failure
    command: |
      bash -c "
      openssl genpkey -algorithm RSA -out /ca/ca.key -aes256 -pass pass:1234
      openssl req -x509 -new -nodes -key /ca/ca.key -sha256 -days 3650 -out /ca/ca.crt -subj \"/C=US/ST=CA/L=Los Gatos/O=ApertureData/OU=ApertureDataCA/CN=ApertureDataCA\" -passin pass:1234
      openssl genrsa -out /cert/tls.key 4096
      openssl req -new -key /cert/tls.key -out /ca/tcp.csr -days 3650 -subj \"/C=US/ST=NY/L=NYC/O=instance/OU=instanceDB/CN=${DB_TCP_CN:-lenz}\"
      openssl x509 -req  -CA /ca/ca.crt -CAkey /ca/ca.key -in /ca/tcp.csr -out /cert/tcp.crt -passin pass:1234
      openssl req -new -key /cert/tls.key -out /ca/http.csr -days 3650 -subj \"/C=US/ST=NY/L=NYC/O=instance/OU=instanceDB/CN=${DB_HTTP_CN:-nginx}\"
      openssl x509 -req  -CA /ca/ca.crt -CAkey /ca/ca.key -in /ca/http.csr -out /cert/http.crt -passin pass:1234"
    volumes:
      - ./aperturedb/certificate:/cert
      - ./ca:/ca

  lenz:
    depends_on:
      ca:
        condition: service_completed_successfully
      aperturedb:
        condition: service_healthy
    image: aperturedata/lenz:latest
    ports:
      - 55556:55551
    restart: always
    environment:
      LNZ_HEALTH_PORT: 58085
      LNZ_TCP_PORT: 55551
      LNZ_HTTP_PORT: 8080
      LNZ_ADB_BACKENDS: '["aperturedb:55553"]'
      LNZ_REPLICAS: 1
      LNZ_ADB_MAX_CONCURRENCY: 48
      LNZ_FORCE_SSL: false
      LNZ_CERTIFICATE_PATH: /etc/lenz/certificate/tcp.crt
      LNZ_PRIVATE_KEY_PATH: /etc/lenz/certificate/tls.key
    volumes:
      - ./aperturedb/certificate:/etc/lenz/certificate

  aperturedb:
    healthcheck:
      test:
        - CMD-SHELL
        - "bash -lc 'echo > /dev/tcp/127.0.0.1/55553'"
      interval: 2s
      timeout: 1s
      retries: 60
    image: aperturedata/aperturedb-community:latest
    volumes:
      - ./aperturedb/db:/aperturedb/db
      - ./aperturedb/logs:/aperturedb/logs
    restart: always
    environment:
      ADB_KVGD_DB_SIZE: "204800"
      ADB_LOG_PATH: "logs"
      ADB_ENABLE_DEBUG: 1
      ADB_MASTER_KEY: "admin"
      ADB_PORT: 55553
      ADB_FORCE_SSL: false

  webui:
    image: aperturedata/aperturedata-platform-web-private:latest
    restart: always

  nginx:
    depends_on:
      ca:
        condition: service_completed_successfully
    image: nginx
    restart: always
    ports:
      - 8087:80
      - 8443:443
    configs:
      - source: nginx.conf
        target: /etc/nginx/conf.d/default.conf
    volumes:
      - ./aperturedb/certificate:/etc/nginx/certificate

  notebook:
    image: aperturedata/aperturedb-notebook
    ports:
      - 8888:8888 # HOST_PORT:CONTAINER_PORT
    volumes:
      - ./ca:/ca
    restart: always
    command: bash -c "adb config create aperturedb_docker --host lenz --port 55551 --ca-cert=/ca/ca.crt --no-interactive && /start.sh"
    depends_on:
      lenz:
        condition: service_started

configs:
  nginx.conf:
    content: |
      server {
        listen 80;
        listen 443 ssl;
        client_max_body_size 256m;
        ssl_certificate /etc/nginx/certificate/http.crt;
        ssl_certificate_key /etc/nginx/certificate/tls.key;
        location / {
          proxy_pass http://webui;
        }
        location /api/ {
          proxy_pass http://lenz:8080;
        }
      }

SSL Errors.

ApertureDB client SDK supports full SSL encryption by default.

This security setting may hinder deployments on development environments and non public facing hosts. These are some settings that offer a relaxation of this security policy.

All of these options apply to the client, and some of them also need to be set on the server for the client-server communication to be established.

Option	Client configuration flags	Comment	Server environment variables
SSL_DEFAULT		The default will use encryption, and verify server hostname at handshake
SSL_WITH_CA	ca_cert = path to custom CA	In case of a certificate issued with a custom CA
SSL_NO_VERIFY	verify_hostname = false	Will use encryption on the connection, but will not validate the hostname (CN) on the certificate
SSL_OFF	use_ssl = false	Will not use SSL for communication	ADB_FORCE_SSL = false