Meteor на AWS с использованием Mup - SSL с ELB

Я переношу свое приложение Meteor на AWS, хочу использовать сертификат SSL, выданный ACM, прикрепленный к ELB. Моя текущая настройка:

  • ELB с сертификатом ACM SSL (подтверждено, что балансировка нагрузки и HTTPS работают на простом HTTP-сервере внутри компьютера EC ubuntu)
  • Meteor up развертывается на машине EC2 с использованием Mup (см. Мой mup.js, который хорошо работает с сертификатом SSL, физически доступным из файловой системы)

Я хочу полностью прекратить использование обратного прокси из конфигурации mup.js и позволить ELB запускать все материалы SSL. Проблема в том, что ELB не может связаться с Meteor, пробовал разные ROOT_URL, но ни один из них не работает:

Что я должен указать для ROOT_URL и изменит ли это правила приема запросов? т.е. если у меня неправильный ROOT_URL, сможет ли Meteor принимать входящие запросы?

  • Версия Mup: 1.4.3
  • Версия Meteor: 1.6.1

Mup config

module.exports = {
  servers: {
    one: {
      host: 'ec2-111111.compute-1.amazonaws.com',
      username: 'ubuntu',
      pem: 'path to pem'
    }
  },
  meteor: {
    name: 'my-app',
    path: 'path',
    servers: {
      one: {}
    },
    buildOptions: {
      serverOnly: true,
    },
    env: {
      ROOT_URL: 'https://ec2-111111.compute-1.amazonaws.com',
      MONGO_URL: 'mongo url',
    },
    dockerImage: 'abernix/meteord:node-8.9.1-base',
    deployCheckWaitTime: 30,
  },
  proxy: {
    domains: 'ec2-111111.compute-1.amazonaws.com,www.ec2-111111.compute-1.amazonaws.com',
    ssl: {
      crt: './cert.pem',
      key: './key.pem'
    }
  }
};

person Lev    schedule 23.03.2018    source источник


Ответы (1)


Решенная первая и общая проблема заключалась в том, что я использовал классический ELB, который не поддерживает WebSockets и препятствует подключению DDP. Помогла более новая Application Load Balancer, которая поставляется с WebSocket и Sticky Sessions. Подробнее о различиях здесь: https://aws.amazon.com/elasticloadbalancing/details/#details

Другая проблема, более специфичная для моего варианта использования, заключалась в отсутствии конечной точки для проверки работоспособности ELB, я скрывал / защищал все, что находится за basic_auth, проверка работоспособности вырабатывала 403 unauthorized сбой и не регистрировала экземпляр EC2 в ELB. Убедитесь, что у вас есть конечная точка для проверки работоспособности, которая возвращает 200 OK, а также еще раз посетите свои группы безопасности - проверьте inbound rules и убедитесь, что ELB имеет доступ к соответствующим портам для экземпляра EC2 (80, 443 и т. Д.).

person Lev    schedule 23.03.2018