Установка на AWS

Это руководство проведет вас через выбор лучшего способа развертывания Baserow на AWS, какие предварительные условия вам потребуется настроить, а также предоставит конкретные инструкции по установке. Это руководство предназначено для тех, кто уже имеет опыт и знания по развертыванию приложений на AWS.

Обзор вариантов развертывания

Baserow можно развернуть на AWS следующими способами:

1. Развертывание универсального образа в Fargate/ECS для горизонтально масштабируемого, но простого в настройке развертывания. См. ниже подробное руководство.
2. Использование этого docker-compose файла или нашего примера конфигурации K8S в качестве отправной точки для настройки задач ECS/Fargate для более продвинутой, готовой к производству модели с одним сервисом на контейнер. См. ниже подробное руководство.
3. Использование сообщественного helm-чарта Baserow и EKS.
4. Настройка нашего примера конфигурации K8S и использование его с EKS.
5. Установка и использование docker/docker-compose на экземпляре EC2 с нашими универсальными или одним контейнером на сервис docker-образами.

Все эти методы развертывания будут хранить данные и состояние Baserow в RDS и S3, что делает переход между ними (например, миграцию на использование EKS позже) простым.

Предварительные условия для развертывания Baserow на AWS

Мы рассмотрим это более подробно позже в руководстве, но для быстрого обзора вот что потребуется для любого развертывания Baserow на AWS:

• Учетная запись AWS IAM с достаточными привилегиями для создания ресурсов AWS
• База данных Postgres (RDS)
• Бакет S3 для хранения файлов, загруженных пользователями, и экспорта таблиц, инициированных пользователями.
• Учетная запись AWS IAM с привилегиями для загрузки файлов в бакет S3.
  • В частности, потребуются их AWS Access Key ID и Secret Access Key для настройки Baserow для загрузки файлов в бакет.
  • VPC
  • Некластеризованный сервер Redis (Elasticache с включенным TLS и выключенным режимом кластера)
  • • SMTP-сервер для отправки электронной почты Baserow.

Вариант 1) Развертывание универсального образа на Fargate/ECS

Образ baserow/baserow:1.33.4 запускает все различные службы Baserow внутри контейнера для удобства использования.

Этот образ предназначен для развертывания на одном сервере или простых развертываний на горизонтально масштабируемых платформах контейнеров, таких как AWS Fargate или Google Cloud Run.

Почему выбрать этот метод

Преимущества

• Легко масштабируется горизонтально с достаточным контролем для большинства производственных установок путем увеличения количества контейнеров.
• Проще в использовании и настройке по сравнению с моделью одного контейнера на сервис, так как:
  • Вам не нужно беспокоиться о настройке и связывании различных служб, составляющих развертывание Baserow.
  • Настройка балансировщиков нагрузки проще, так как вы можете напрямую маршрутизировать все запросы на любой горизонтально масштабируемый контейнер, запускающий baserow/baserow:1.33.4.

Недостатки

• Не следует традиционной модели одного контейнера на задачу/сервис.
• Потенциально более высокое общее использование ресурсов, так как каждый из универсальных контейнеров будет иметь свои внутренние службы, поэтому у вас будет меньше гранулярного контроля над масштабированием конкретных служб.
  • Например, если вы горизонтально масштабируете 10 контейнеров baserow/baserow:1.33.4, по умолчанию у вас будет:
    • 10 веб-фронтенд-сервисов
    • 10 бэкенд-сервисов
    • 10 быстрых асинхронных рабочих процессов бэкенда
    • 10 медленных асинхронных рабочих процессов бэкенда
  • Вы можете использовать переменные окружения для некоторой настройки.
• Сложнее изолировать сбои, специфичные для определенных служб, так как логи каждого контейнера будут включать несколько служб.
  • Однако Baserow полностью поддерживает Open Telemetry, что позволяет подключить Baserow к многим облачным решениям для мониторинга приложений, таким как Honeycomb, Datadog, NewRelic или стек Grafana/Loki/Tempo/Prometheus.

Шаги установки

Мы пропустим настройку VPC, групп безопасности, пользователей IAM, менеджера секретов и специфику ELB, чтобы сделать это руководство более универсальным.

1) Создание бакета S3 для загрузки файлов пользователями

Сначала Baserow нужен бакет S3. Baserow будет использовать этот бакет для хранения файлов, загруженных пользователями в таблицы, и экспорта таблиц для последующего скачивания пользователями.

Baserow затем будет генерировать предварительно подписанные URL-адреса S3 для просмотра и скачивания файлов из этого бакета. В результате эти предварительно подписанные URL-адреса должны быть доступны из браузера пользователя, поэтому в зависимости от вашей конфигурации вероятно, что бакет должен разрешать публичные GET/ACL.

Рекомендуется создать отдельного пользователя IAM, с которым будут настроены учетные данные Baserow, чтобы он мог загружать и удалять файлы из бакета. Вот пример политики S3 для этого пользователя, чтобы предоставить минимально необходимые операции:

policy = <<EOF
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
                "s3:PutObject",
                "s3:GetObjectAcl",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObjectAcl"
            ],
             "Principal": {
                "AWS": "arn:aws:iam::xyz:user/YOUR_USER"
             },
        "Resource": [
            "arn:aws:s3:::YOUR_BUCKET_NAME/*",
            "arn:aws:s3:::YOUR_BUCKET_NAME"
        ]
    }]
}

Этот бакет также в текущей версии Baserow потребует правил CORS для корректной работы кнопки загрузки файлов в инструмент. Пример правила приведен ниже:

cors_rule {
allowed_headers = ["*"]
allowed_methods = ["GET", "HEAD", "OPTIONS"]
allowed_origins = ["REPLACE_WITH_YOUR_BASEROW_PUBLIC_URL"]
expose_headers  = ["ETag", "Content-Length", "Content-Type"]
max_age_seconds = 3000
}

Наконец, вот публичные параметры доступа, которые мы использовали, чтобы обеспечить возможность GET и скачивания файлов S3 из браузера пользователя:

 block_public_acls       = false
 block_public_policy     = true
 ignore_public_acls      = true
 restrict_public_buckets = true

2) Создание Postgres с использованием RDS

Baserow хранит все свои данные, кроме файлов, в базе данных PostgreSQL. В AWS рекомендуется использовать кластер RDS Postgres. Позже вам потребуется настроить Baserow для доступа к этому кластеру.

Baserow активно использует PostgreSQL, поэтому для больших развертываний потребуется масштабирование RDS кластера.

Не следует использовать RDS Proxy перед экземпляром RDS. Это связано с тем, что прокси завершает транзакцию после выполнения оператора определения языка (DDL). Baserow несовместим с этим, так как он выполняет изменения схемы, и если что-то пойдет не так после миграции схемы, транзакция не будет откатываться, что приводит к несоответствию данных. Дополнительная информация: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.howitworks.html#rds-proxy-transactions

3) Создание Redis с использованием Elasticache

Baserow использует Redis как кэш, для реального времени совместной работы через WebSocket и обработки асинхронных фоновых задач.

Рекомендуется создать Elasticache Redis в режиме без кластера с включенным TLS и режимом AUTH, где можно указать токен пароля AUTH для подключения Baserow к серверу Redis.

Обычно сервер Redis не является узким местом в развертываниях Baserow при их масштабировании.

4) Настройка ALB и группы целевых объектов

Теперь создайте группу целевых объектов на порту 80 и ALB для маршрутизации трафика к контейнерам Baserow.

При настройке проверки состояния ALB для контейнера baserow/baserow:1.33.4, который вы будете развертывать дальше, выберите порт 80 и URL проверки состояния /api/_health/. Рекомендуется длительный период ожидания в 900 секунд для учета первоначальных миграций при запуске первого контейнера.

5) Запуск Baserow на ECS/Fargate

Теперь мы готовы запустить наши контейнеры baserow/baserow:1.33.4. См. ниже полное определение задачи и переменные окружения. Рекомендуется запускать контейнеры с 2vCPU и 4 ГБ ОЗУ каждая. Вкратце вам нужно будет:

1. Выбрать образ baserow/baserow:1.33.4.
2. Добавить сопоставление портов 80 по протоколу TCP, так как этот образ HTTP-сервер слушает по умолчанию.
3. Отметить контейнер как основной.
4. Установить следующие переменные окружения:

Полный список всех доступных переменных окружения можно найти здесь.

5. Выберите желаемый тип запуска (мы использовали Fargate).
6. Установите семейство ОС как Linux.
7. Далее создайте службу ECS с использованием вашего ALB, группы целевых объектов и этого определения задачи.
8. Убедитесь, что группа безопасности входящего трафика для контейнеров ECS должна разрешать порты:
   1. HTTP-порт (80, если вы не настроили другие сопоставления портов)
   2. Порт Redis
   3. Порт Postgres

6) Пример определения задачи

Вот полное определение задачи с использованием ECS и Fargate.

container_definitions    = <<DEFINITION
  [
    {
      "name": "baserow_task",
      "image": "baserow/baserow:1.33.4", 
      "logConfiguration": {                     #логирование не обязательно
                "logDriver": "awslogs",
                "options": {
                    "awslogs-region" : "YOUR_REGION_NAME",
                    "awslogs-group" : "/ecs/baserow_log",
                    "awslogs-stream-prefix" : "baserow",
                    "awslogs-create-group": "true"
      }
    },
      "environment": [
      {
        "name": "DISABLE_VOLUME_CHECK",
        "value": "yes"
      },
      {
        "name": "BASEROW_PUBLIC_URL",
        "value": "<YOUR_PUBLIC_URL>"
      },
       {
        "name": "DATABASE_HOST",
        "value": "<YOUR_POSTGRES_DB_HOST>"
      },
      {
        "name": "DATABASE_USER",
        "value": "postgres"
      },
      {
        "name": "DATABASE_PORT",
        "value": "<PORT_NUMBER>"
      },
      {
        "name": "DATABASE_NAME",
        "value": "<YOUR_POSTGRES_DB_NAME>"
      },
      {
        "name": "DATABASE_PASSWORD",
        "value": "<YOUR_POSTGRES_DB_PASSWORD>"
      },
      {
        "name": "REDIS_URL",
        "value": "rediss://default:password@YOUR_REDIS_PRIMARY_ENDPOINT:6379/0?ssl_cert_reqs=required"
      },
      {
        "name": "AWS_STORAGE_BUCKET_NAME",
        "value": "<YOUR_BUCKET_NAME>"
      },
      {
        "name": "AWS_ACCESS_KEY_ID",
        "value": "<YOUR_AWS_ACCESS_KEY_ID>"
      },
      {
        "name": "AWS_SECRET_ACCESS_KEY",
        "value": "<YOUR_AWS_SECRET_ACCESS_KEY>"
      },
       {
        "name": "DOWNLOAD_FILE_VIA_XHR",
        "value": "1"
      },
      {
        "name": "BASEROW_EXTRA_ALLOWED_HOSTS",
        "value": "<YOUR_ALLOWED_HOSTS>"
      },
      {
        "name": "BASEROW_JWT_SIGNING_KEY",
        "value": "<YOUR_SIGNING_KEY>"
      },
      {
        "name": "SECRET_KEY",
        "value": "<YOUR_SECRET_KEY>"
      }
      ],
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80 
        }
      ],
      "memory": 8192,
      "cpu": 4096
    }
  ]
  DEFINITION
  requires_compatibilities = ["FARGATE"] 
  network_mode             = "awsvpc"    
  memory                   = 8192         
  cpu                      = 4096        

7) Дополнительные опции масштабирования

Кроме запуска большего количества задач baserow/baserow и масштабирования сервера RDS Postgres, образ baserow/baserow имеет следующие переменные окружения масштабирования, которые могут помочь уменьшить использование ресурсов на контейнер или распределить больше ресурсов на определенные службы внутри контейнера.

1. BASEROW_AMOUNT_OF_GUNICORN_WORKERS управляет количеством рабочих процессов REST API (те процессы, которые выполняют большую часть работы API) на контейнер. По умолчанию установлено значение 3. Каждый дополнительный рабочий процесс обычно занимает около 100-200 МБ ОЗУ.
2. BASEROW_AMOUNT_OF_WORKERS управляет количеством рабочих процессов Celery для выполнения фоновых задач, таких как реальное время совместной работы, очистка задач и другие медленные задачи, такие как большие экспорт/импорт файлов. Если вы масштабируете много этих контейнеров, вероятно, вам понадобится только один из этих фоновых рабочих процессов на контейнер, так как они будут объединяться вместе и собирать фоновые задачи, отправленные из любого другого контейнера через Redis.
3. Вы можете заставить образ запускать меньше внутренних процессов и таким образом уменьшить использование памяти, установив BASEROW_RUN_MINIMAL=yes И BASEROW_AMOUNT_OF_WORKERS=1.
   1. Это приведет к тому, что этот образ запустит только один процесс Celery, который будет обрабатывать как быстрые, так и медленные очереди.
   2. Последствием этого будет то, что будет только один процесс обработки задач на контейнер, поэтому медленная задача, такая как снимок большой базы данных Baserow, может задержать быструю очередь задачи, например отправку сигнала об обновлении строки всем пользователям, просматривающим таблицу.
   3. Однако если у вас достаточно других контейнеров, общий пул асинхронных рабочих процессов будет достаточно велик для обработки смеси медленных и быстрых задач.#### 8) Развертывание завершено

Теперь у вас должно быть полностью работающее кластерное развертывание Baserow. Первый пользователь, который зарегистрируется, станет первым администратором системы со статусом «staff». Этот пользователь затем сможет настроить параметры инструмента Baserow, активировать лицензии предприятия и продвигать других пользователей до статуса «staff».

Вариант 2) Развертывание Baserow как отдельных сервисов на Fargate/ECS

Образы baserow/backend:1.33.4 и baserow/web-frontend:1.33.4 позволяют запускать различные службы Baserow как отдельные контейнеры.

Эти образы используются сообщественным Helm-чартом, различными примерами конфигурации docker-compose.yml и являются лучшим выбором для производственных сред, где вам требуется полный контроль и гибкость управления Baserow.

Почему выбрать этот метод

Преимущества

• Каждая служба может масштабироваться отдельно, что дает вам детальный контроль.
• Следует более традиционной модели одного сервера на контейнер.
• Логирование и отладка проблем каждой службы проще.
• Контейнеры индивидуально проще имеют меньше движущихся частей.

Недостатки

• Более сложен в установке и обслуживании в целом.
• Требуется более сложная конфигурация ALB и сети для обеспечения правильной маршрутизации запросов к соответствующим службам.

Шаги установки

Следуйте шагам 1, 2 и 3 из руководства Вариант 1 выше, так как нам потребуется точно такой же бакет S3, RDS и Redis.

4) Настройка ALB и групп целевых объектов

Сначала вам нужно создать три отдельные группы целевых объектов с типом целевого объекта IP:

1. backend-asgi на порту 8000/HTTP с проверкой состояния по URL /api/_health/ для нашего сервиса WebSocket.
2. backend-wsgi на порту 8000/HTTP с проверкой состояния по URL /api/_health/ для нашего сервиса API бэкенда.
3. web-frontend на порту 3000/HTTP с проверкой состояния по URL /_health/ для нашего фронтенд-сервиса.

Завершающий слеш в конечных точках проверки состояния обязателен!

Теперь создайте ALB с прослушивателем HTTP порта 80, маршрутизирующим трафик к группе web-frontend. Затем перейдите к этому прослушивателю и настройте его с тремя разными правилами маршрутизации к каждой из отдельных групп.

1. Стандартное правило для перехвата всех остальных запросов, перенаправляющее их в группу web-frontend.
2. Условие пути /ws/*, перенаправляющее запросы в группу backend-asgi.
3. Условие пути /api/*, перенаправляющее запросы в группу backend-wsgi.

Позже служба фронтенда Baserow должна сможет общаться со службой backend-wsgi через балансировщик нагрузки. Вы можете использовать этот же балансировщик нагрузки как для внешних запросов, так и для этих межсервисных запросов при необходимости; однако убедитесь, что вы правильно настроили группы безопасности для обеспечения связи между задачами ECS и ALB.

5) Развертывание отдельных служб Baserow

Теперь давайте развернем каждую из отдельных служб Baserow на Fargate/ECS. Создайте новый кластер для Baserow и затем продолжайте создавать следующие определения задач.

Если вы знакомы с K8S, то этот пример конфигурации дает обзор служб.

Альтернативно этот docker-compose

также можно использовать в качестве справочника

6) Сервис backend WSGI

Эта служба является нашей службой HTTP REST API. При создании определения задачи вам следует:

1. В определении задачи использовать образ baserow/backend:1.33.4
2. В конфигурации Docker установить команду gunicorn-wsgi --timeout 60.

Рекомендуется установить таймаут каждого HTTP API запроса в 60 секунд в команде выше, так как значение по умолчанию в 30 секунд может быть слишком коротким для очень больших таблиц Baserow.

3. Рекомендуется начинать с 2vCPU и 4 ГБ ОЗУ на контейнер.
4. Сопоставьте порт контейнера 8000/TCP с протоколом приложения HTTP.
5. Отметьте контейнер как основной.
6. Установите следующие переменные окружения и запомните их, так как вам потребуется установить те же переменные позже в других определениях задач. Использование файла переменных окружения для их совместного использования также является хорошей идеей.| Переменная окружения | Описание | |---------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | BASEROW_PUBLIC_URL | Публичный URL или IP-адрес, который будет использоваться для доступа к Baserow в браузере пользователя. Всегда должен начинаться с http:// или https://, даже если доступ осуществляется через IP-адрес. | | DATABASE_HOST | Имя хоста PostgreSQL-базы данных, которую Baserow будет использовать для хранения данных. | | DATABASE_USER | Имя пользователя базы данных, которое Baserow будет использовать для подключения к базе данных на DATABASE_HOST. | | DATABASE_PORT | Порт, который Baserow будет использовать при попытке подключения к PostgreSQL-базе данных на DATABASE_HOST. | | DATABASE_NAME | Имя базы данных, которую Baserow будет использовать для хранения данных. | | DATABASE_PASSWORD | Пароль пользователя DATABASE_USER на сервере PostgreSQL на DATABASE_HOST. Альтернативно, можно предоставить DATABASE_PASSWORD_FILE и указать путь к файлу с секретом, встроенному в файловую систему контейнера. | | REDIS_URL | Стандартная строка подключения Redis в формате: redis://[redisuser]:[password]@[redishost]:[redisport]/0?ssl_cert_reqs=required. | | AWS_STORAGE_BUCKET_NAME | Имя вашего бакета хранения AWS. | | AWS_ACCESS_KEY_ID | Ключ доступа для вашей учетной записи IAM S3 AWS. При установке значения, отличного от пустого, Baserow переключится на использование совместимого с S3 бакета для хранения файлов, загруженных пользователем. | | AWS_SECRET_ACCESS_KEY | Секретный ключ доступа для вашей учетной записи IAM S3 AWS. Можно также предоставить AWS_SECRET_ACCESS_KEY_FILE. | | BASEROW_EXTRA_ALLOWED_HOSTS | Необязательный список хостов, разделенных запятыми, которые будут добавлены в настройку ALLOWED_HOSTS Django-бэкенда Baserow. Добавьте сюда IP-адрес вашего ALB, чтобы проверки состояния, которые он отправляет, проходили, или альтернативно настройте менее безопасное значение *, чтобы запустить все и ограничить хосты позже, когда все будет работать. | | BASEROW_JWT_SIGNING_KEY | Должна быть установлена, чтобы все контейнеры использовали один и тот же ключ подписи. Ключ подписи используется для подписи содержимого генерируемых токенов. Для подписи HMAC это должно быть случайная строка с количеством битов данных, не меньшим, чем требуется протоколом подписи. Подробнее см. здесь. Также поддерживается BASEROW_JWT_SIGNING_KEY_FILE. | | SECRET_KEY | Должна быть установлена, чтобы все контейнеры использовали один и тот же секретный ключ. Секретный ключ, используемый Django для криптографической подписи, такой как генерация безопасных ссылок для сброса пароля и управление сессиями. Подробнее см. здесь. Также поддерживается SECRET_KEY_FILE. | | EMAIL_SMTP_* | Существует несколько переменных окружения, связанных с SMTP, документированных в нашем руководстве по переменным окружения здесь, которые также должны быть установлены, чтобы Baserow мог отправлять приглашения и письма для сброса пароля. |

7) Сервис ASGI бэкенда

Возможно использовать только сервис ASGI без создания отдельных сервисов ASGI и WSGI, и затем маршрутизировать все HTTP и WebSocket-запросы в единый сервис ASGI. Однако, производительность сервиса ASGI при обработке обычных HTTP-запросов ниже, чем у сервиса в режиме WSGI. Также возможность масштабирования их отдельно полезна, так как часто требуется только несколько сервисов ASGI для обработки нагрузки от WebSocket.

Этот сервис является нашим API-сервисом WebSocket, и при настройке определения задачи вам следует:

1. Использовать baserow/backend:1.33.4.
2. В конфигурации Docker установить gunicorn в качестве команды.
3. Рекомендуется начать с 2vCPU и 4 ГБ ОЗУ на контейнер.
4. Привязать порт контейнера 8000/TCP.
5. Отметить контейнер как основной.
6. Установить те же переменные окружения, что и для сервиса backend-wsgi выше.

8) Сервис рабочего процесса celery бэкенда

Этот сервис используется для выполнения асинхронных задач высокого приоритета, таких как реальное сотрудничество и отправка электронной почты.

1. Использовать образ baserow/backend:1.33.4 с командой celery-worker.
2. В конфигурации Docker установить celery-worker в качестве команды.
3. Привязка портов не требуется.
4. Рекомендуется начать с 2vCPU и 4 ГБ ОЗУ на контейнер.
5. Отметить контейнер как основной.
6. Установить те же переменные окружения, что и для сервиса backend-wsgi выше.

9) Сервис рабочего процесса celery экспорта бэкенда

Этот сервис используется для выполнения асинхронных задач низкого приоритета, таких как пакетные процессы и выполнение потенциально медленных операций для пользователей, например, экспорт и импорт таблиц.

1. Использовать образ baserow/backend:1.33.4.
2. В конфигурации Docker установить celery-exportworker в качестве команды.
3. Привязка портов не требуется.
4. Рекомендуется начать с 2vCPU и 4 ГБ ОЗУ на контейнер.
5. Отметить контейнер как основной.
6. Установить те же переменные окружения, что и для сервиса backend-wsgi выше.

10) Сервис celery beat бэкенда

Этот сервис является планировщиком задач CRON, который может иметь несколько реплик.

1. Использовать образ baserow/backend:1.33.4.
2. В конфигурации Docker установить celery-beat в качестве команды.
3. Привязка портов не требуется.
4. Рекомендуется начать с 1vCPU и 3 ГБ ОЗУ на контейнер.
   1. Только один из этих контейнеров будет планировать задачи глобально в любой момент времени.
   2. Любые дублирующиеся контейнеры будут находиться в режиме горячего резерва, чтобы接管调度，如果第一个容器失败并释放调度的Redis锁。
5. Отметить контейнер как основной.
6. Установить те же переменные окружения, что и для сервиса backend-wsgi выше.

11) Web-frontend сервис

Наконец, этот сервис используется для серверной-side рендеринга и фронтенд-сервиса Baserow.

1. Использовать образ baserow/web-frontend:1.33.4, без параметров.
2. Привязать порт контейнера 3000.
3. Рекомендуется начинать с 2vCPU и 4 ГБ ОЗУ на контейнер.
4. Отметить контейнер как основной.
5. Установить следующие переменные окружения, отличающиеся от переменных окружения backend:

• BASEROW_PUBLIC_URL: Публичный URL или IP-адрес, который будет использоваться для доступа к Baserow в браузере пользователя. Всегда должен начинаться с http:// или https://, даже если доступ осуществляется через IP-адрес.
• PRIVATE_BACKEND_URL: Web-frontend контейнер должен иметь возможность отправлять HTTP-запросы к контейнеру backend-wsgi, который выполняет REST API.
  • Рекомендуется установить его на адрес ALB и он должен начинаться с http:// или https://.
  • Убедитесь, что группы безопасности настроены правильно, чтобы разрешить эти внутренние HTTP-запросы.
  • Если вы не установили BASEROW_EXTRA_ALLOWED_HOSTS=* для контейнеров backend-wsgi и backend-asgi, убедитесь, что значение этого параметра добавлено в переменную окружения BASEROW_EXTRA_ALLOWED_HOSTS этих сервисов, чтобы они разрешали соединения от web-frontend.
• DOWNLOAD_FILE_VIA_XHR: Должно быть установлено значение 1, чтобы работать с AWS S3 текущего использования, заставляя ссылки на скачивание файлов проходить через XHR запросы, чтобы обойти заголовок Content-Disposition: inline. Если ваши файлы хранятся в другом источнике, также необходимо добавить заголовки CORS в S3 бакет.

13) Создание ECS сервисов

Теперь вернитесь и создайте ECS сервисы для только что созданных определений задач. Помните о том, чтобы при подключении установить период ожидания проверки состояния равным 900 секундам.

Или вы можете создать один ECS сервис для всех задач Baserow, но вам нужно будет использовать API/CLI для подключения нескольких групп целевых объектов к этому одному ECS сервису, так как это невозможно сделать через AWS UI сейчас. Вам также может потребоваться убедиться, что backend-asgi и backend-wsgi экспонируются на разных портах, чтобы группы целевых объектов могли правильно маршрутизировать запросы к каждому сервису. Установите разные значения переменной окружения BASEROW_BACKEND_PORT на этих сервисах, чтобы они привязывались к разным портам внутри контейнера.

1. Сервис backend-wsgi, подключенный к группе целевых объектов backend-wsgi
2. Сервис backend-asgi, подключенный к группе целевых объектов backend-asgi
3. Сервис web-frontend, подключенный к группе целевых объектов web-frontend
4. Сервис celery-worker
5. Сервис celery-exportworker
6. Сервис celery-beat

12) Опции масштабирования

В большинстве случаев масштабирование ваших задач backend-wsgi и RDS Postgres будет первым выбором для обработки большего количества запросов. Если ваше реальное сотрудничество замедляется, можно масштабировать службы backend-asgi и celery-worker. Наконец, если вам приходится долго ждать начала выполнения заданий (они будут застревать на 0% в интерфейсе Baserow), можно добавить больше служб celery-exportworker.

Есть также следующие переменные окружения для изменения количества запускаемых рабочих процессов внутри каждого контейнера для вертикального масштабирования каждого контейнера:

1. Переменная окружения BASEROW_AMOUNT_OF_GUNICORN_WORKERS контролирует количество рабочих процессов REST API в каждом контейнере gunicorn-wsgi или gunicorn (компонент, выполняющий большую часть работы API). По умолчанию значение равно 3. Каждый дополнительный рабочий процесс обычно занимает около 100-200 МБ ОЗУ.
2. Переменная окружения BASEROW_AMOUNT_OF_WORKERS контролирует количество рабочих процессов Celery runner в контейнерах celery-worker и celery-exportworker.

13) Развертывание завершено

Теперь у вас должно быть полностью работающее кластерное развертывание Baserow. Этот метод развертывания более сложный, если вам нужна помощь, пожалуйста, создайте тему на нашем сообщественном форуме.

Первый зарегистрированный пользователь станет первым администратором экземпляра «staff». Этот пользователь сможет настроить внутренние параметры Baserow, активировать лицензии предприятия и повышать других пользователей до статуса «staff».

Обновление Baserow

Обновление развертывания Baserow на ECS/Fargate можно выполнить следующими шагами:

1. Создайте резервную копию/снимок вашей базы данных RDS Postgres.
2. Остановите все существующие контейнеры старой версии перед тем, как пользователи смогут получить доступ к ним во время обновления.
3. Обновите ваши определения задач для использования новых образов.
4. Первый запущенный новый контейнер baserow/baserow или baserow/backend-wsgi/asgi автоматически применит необходимые миграции базы данных и обновления.
5. После завершения все новые контейнеры Baserow начнут принимать запросы, и ваше обновление будет завершено.

Часто задаваемые вопросы

Исправление ошибки CROSSSLOT Keys in request don't hash to the same slot

Если вы видите эту ошибку в логах, это означает, что вы используете Redis в режиме кластера. Библиотеки, используемые Baserow, не поддерживают Redis в режиме кластера, поэтому вам нужно настроить новый Redis без режима кластера для его корректной работы. Redis без режима кластера все еще может быть масштабируемым и многорегиональным развертыванием; кроме того, Baserow обычно не вызывает Redis как бутылочное горло запросов.

Мои проверки состояния ELB не проходят

Первое развертывание или первая миграция после обновления могут занять некоторое время, поэтому вам может потребоваться увеличить период ожидания.

Во-вторых, убедитесь, что ELB может подключиться к контейнерам. Обратите внимание, что у контейнеров есть свои внутренние скрипты проверки состояния, которые также вызывают эндпоинты проверки состояния. Поэтому наличие ответа 200 от проверок состояния в логах не означает, что это были ответы от ELB.

При загрузке файлов из поля файлов Baserow возникает ошибка CORS

На вашем S3 бакете неправильно настроены CORS-правила. Проверьте пример конфигурации CORS выше или обратитесь за поддержкой.

Возникает предупреждение "Secure Redis scheme specified (rediss) with no ssl options, defaulting to insecure SSL behavior"

Убедитесь, что вы добавили параметр ?ssl_cert_reqs=required в конце вашей переменной окружения REDIS_URL.