Я неделю возился с Docker на AWS. Docker on
AWS — это совместная работа AWS и Docker, обеспечивающая быстрый запуск
Docker Data Center (Universal Control Plane и Docker Trusted Registry)
, развернутого одним щелчком мыши через CloudFormation. шаблон. Это своего рода
эталонная реализация развертывания. Лично меня это очень
обрадовало, так как я провел неделю или две, взламывая свой собственный
шаблон CloudFormation для начальной загрузки системы UCP. Я получил пробную
лицензию сразу же после того, как понял, что приглашения больше не нужны.
В этом блоге я суммирую свой опыт.

Мой вариант использования несколько прост. Мне нужен роевой кластер, чтобы команда
также развернула внутреннее приложение на основе docker-compose. Меня не интересует
DTR, потому что у нас есть платная учетная запись в официальном реестре. Организация
имеет команды разработчиков в Индии и Швеции. Таким образом, я хотел
одну установку UCP в eu-west-1 и ap-south-1. Затем мне захотелось
автоматизировать развертывание CloudFormation с помощью наших учебников Ansible. Мои
первоначальные требования к шипу, где:

  1. Разверните официальный стек CloudFormation с помощью Ansible
  2. Настройте DNS-записи CloudFlare для UCP и DTR в рамках
    Ansible playbook.
  3. Получите «клиентский пакет» от UCP
  4. Загрузите это и запустите docker-compose команды против UCP.

Мне грустно сообщать, что первая неделя была полна многих проблем.
Я задокументировал проблемы как проблемы GitHub и отправил запросы на вытягивание
, где это возможно. Мне не удалось добиться полного успеха по
причинам, изложенным ниже. О большинстве проблем сообщается в
этом длинном выпуске github.

  1. Таймауты стека два низких. Диагностика заняла много времени, потому что
    сколько времени требуется для создания стека. Стек применяет тайм-аут 15
    для операций начальной загрузки, установки и настройки. То есть
    установка всех пакетов, запуск, докер и выполнение операций UCP/DTR
    должны завершиться в течение 15 минут, иначе произойдет сбой развертывания. Репозиторий
    имеет CI, поэтому теоретически должно быть достаточно. Однако все
    мои развертывания на ap-southeast-1 постоянно занимают около 20 минут.
    Я отправил исправление, чтобы увеличить время ожидания до 30
    минут. Это должно охватывать стек во всех регионах.
  2. Настройки по умолчанию (с которыми большинство пользователей развертывают) не обеспечивают
    достаточно места на диске. Тип экземпляра по умолчанию для
    контроллера, узлов UCP и реплик — m3.medium. Он поставляется с
    корневым томом размером 4 ГБ, из которого остается примерно 3 ГБ, когда все установлено.
    Наше тестовое приложение имеет примерно 25 контейнеров. Мой первоначальный запрос заполнил
    один из узлов после нескольких изображений. Стек принимает типы instance
    через Parameters, но это проигрышная битва. Вам не нужно
    переходить на какой-либо экземпляр xxlarge только для того, чтобы получить больше места на диске
    . Я отправил заплатку для подключения твердотельного накопителя на 120 ГБ
    к каждому узлу.
  3. m4.* не поддерживается. Я изменил тип экземпляра и развернул его.
    В сопоставлении шаблона была ошибка, из-за которой m4.* экземпляров были
    разрешенными параметрами, но не сопоставлены с AMI. Я сообщил о
    проблеме, которая была исправлена ​​сопровождающими.
    Исправление уже в открытом доступе.
  4. Реплики DTR просто не загружаются правильно. Это была
    проигранная битва. Я отказался от попыток отладить эту проблему. Все журналы
    и промежуточные сбои задокументированы в моем основном
    выпуске    . Я смог продолжить свой всплеск, только скопировав
    официальный шаблон CloudFormation и удалив все, что связано с
    DTR. Это было возможно только потому, что нам не нужен DTR. Я
    отправил исправление, чтобы включить флаги --debug во все
    команды UCP/DTR, чтобы помочь пользователям в подобных ситуациях.
  5. Случайные ERROR: No elected primary cluster manager при извлечении
    изображений в рой. Я не уверен, почему это происходит, и
    не знаю, где искать или как решить эту проблему.
  6. Официальный шаблон стека плохо отформатирован с неправильным и
    несогласованным отступом. Это лишило меня возможности читать
    и изучать их реализацию. Я представил заплатку для исправления ошибок.

К счастью, я смог продолжить свой всплеск, удалив детали DTR. Теперь я могу
продолжить экспериментировать с самим роем/UCP. При этом
говорится, что в эталонном развертывании все еще есть большие открытые проблемы.
Каждый пункт также задокументирован в Github
Issue.

  1. Вы не можете добавлять свои собственные SSL-сертификаты во время развертывания. Вы можете добавить их
    позже. Я могу понять, почему они не являются обязательными для быстрого
    запуска (у скольких людей есть SSL-сертификаты для пробных целей?).
    Это создает путаницу, когда URL-адреса UCP и DTR используются только
    > доступен через HTTPS и ненадежные сертификаты. Было бы неплохо
    разрешить использование сертификатов, указанных пользователем, или откатиться на сгенерированные сертификаты.
  2. Нет доступа по SSH. Это было настоящим раздражением при отладке, почему
    что-то ломается. Будем надеяться, что в будущих версиях стека будет создан общедоступный
    бастион (или «узел перехода») для доступа к частным узлам. Я добавил
    правила группы безопасности и создал новый экземпляр в общедоступной
    подсети каждый раз, когда не удалось развернуть стек (это было довольно утомительно, как
    вы можете себе представить). Это можно легко сделать в шаблоне CloudFormation
    . Я голосую за то, чтобы доступ по SSH рассматривался в эталонном
    развертывании.
  3. Поддержка всех регионов. Текущий стек не поддерживает
    ap-south-1. Некоторые другие регионы также не поддерживаются. Это
    исправлено путем обновления встроенного сопоставления для региона охвата. К счастью, стек
    использует официальные образы AMI Ubuntu 14.04, которые доступны
    во всех регионах. Я предложил заплатку для поддержки addap-south-1.

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