Как файл. dockercfg должен быть размещен в программе установки Mesosphere-on-AWS, чтобы только Mesosphere могла его использовать?

Поскольку Mesos docs довольно бедны в этом, я собираюсь ответить на этот Вики-стиль и обновить этот ответ по ходу.

---

Стратегии, которые должны работать

Разместить его на S3 (с сетевыми ограничениями доступа)

Хозяин .файл dockercfg на S3. Для большей безопасности, вы должны рассмотреть возможность поместить его в свое собственное ведро, или иначе ведро, предназначенное для хранения секретов. Это представляет некоторые интересные проблемы в создании политики безопасности, которая будет действительно работать. чтобы закрыть ведро S3 так, чтобы только Мезос мог его видеть, но это можно сделать.

Конфигурация задачи Mesos:

{
  ...
  "uris": ["https://s3-eu-west-1.amazonaws.com/my-s3-bucket-name/.dockercfg"]
  ...
}

Политика корзины S3 (с использованием конечной точки VPC):

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

{
  "Id": "Policy123456",
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Stmt123456",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::my-s3-bucket",
      "arn:aws:s3:::my-s3-bucket/*"
    ],
    "Condition": {
      "StringEquals": {
        "aws:sourceVpce": "vpce-my-mesos-cluster-vpce-id"
      }
    },
    "Principal": "*"
  }]
}

Вам также понадобится конфигурация VPCE, чтобы дать вам идентификатор VPCE для подключения к условию корзины S3 выше. (Я думаю, если вы не используете VPC конечные точки, которые вы могли бы просто сопоставить по идентификатору VPC вместо этого?)

Вы можете проверить, работает ли это, перейдя в пользовательский интерфейс Mesos (если вы используете DCO, это не очень красивый пользовательский интерфейс DCO) и наблюдая, появляются ли задачи с именем вашего приложения в списках активных задач или завершенных задач.

Заманчивые стратегии, которые не работают (пока)

Разместите его на S3 (с подписанными url)

В этом варианте S3 вместо использования сетевых ограничений доступа мы используем подписанный URL-адрес .вместо этого файл dockercfg.

Конфигурация задачи Mesos должна выглядеть следующим образом:

{
  ...
  "uris": ["https://my-s3-bucket/.dockercfg?AWSAccessKeyId=foo&Expires=bar&Signature=baz"]
  ...
}

К сожалению, вышеупомянутая стратегия S3 signed URLне работает из-заMesos-1686 , которая замечает, что любой загруженный файл точно сохраняет удаленное имя файла, включая строку запроса, ведущую к имени файла типа ".докеркерфг?AWSAccessKeyId=foo & Expires=bar&Signature=baz". Поскольку клиент Docker не распознает файл, если он не имеет точного имени ".dockercfg " это не удается увидеть учетные данные auth.

Перевод свой .файл dockercfg непосредственно для каждого ведомого устройства

Можно было бы SCP the .dockercfg для каждого раба Mesos. Хотя это быстрое решение, оно:

• требует знать всех рабов заранее
• не масштабируется, так как в кластер добавляются новые ведомые устройства
• требует SSH-доступа к ведомым устройствам, которые подготовлены внутри их собственного VPC (следовательно, их IP-адреса часто находятся в 10.0.[бла] диапазон).

Это можно было бы превратить в более жизнеспособный производственный подход, если автоматизировать его с помощью инструмента управления конфигурацией, такого как Chef, который будет работать на рабах и вытягивать .dockercfg файл в нужное место.

Это приведет к конфигурации типа:

{
  ...
  "uris": ["file:///home/core/.dockercfg"]
  ...
}

Поскольку "ядро" является пользователем по умолчанию на основе CoreOS Mesos slaves, и .по соглашению dockercfg должен находиться в домашнем каталоге текущего пользователя, который хочет использовать Docker.

Update : это должно быть это был самый надежный подход, но я еще не нашел способа сделать это. приложение по-прежнему навечно застряло в фазе "развертывания", насколько это касается марафона.

Использовать службу хранилища ключей

Поскольку мы имеем дело с именами пользователей и паролями, сервис AWS Key Management Service (или даже CloudHSM в крайнем случае) кажется, что это должно быть хорошей идеей, но AFAIK Mesos не имеет встроенной поддержки для этого, и мы обрабатываем не отдельные переменные, а множество переменных. файл.

---

Устранение неполадок

После того, как вы настроили свое решение выбора, вы можете обнаружить, что .файл dockercfg извлекается нормально, но ваше приложение все еще застряло в фазе "развертывания". Проверьте эти вещи...

Обеспечьте свое .dockercfg-это правильный формат для версии Mesos Docker

В какой-то момент формат поля "auth" был изменен. Если.dockercfg, который вы предоставляете, не соответствует этому формату, тогда вызов docker автоматически завершится неудачей. Формат что версия Mesos Docker на подчиненных устройствах кластера ожидает:

{
  "https://index.docker.io/v1/": {
    "auth": [base64 of the username:password],
    "email": "your_docker_registry_user@yourdomain.com"
  }
}

Не используйте порт 80 для вашего приложения

Если вы пытаетесь развернуть веб-приложение, убедитесь, что вы не использовали порт хоста 80 - это нигде не написано в документах, но веб-службы Mesos требуют порт 80 для себя, и если вы попытаетесь взять 80 для своего собственного приложения, оно просто будет висеть вечно. Проницательный читатель заметит, что, среди прочих причин, именно поэтому веб-приложение Mesosphere "Oinker" привязывается к слегка необычный выбор порта 0 вместо этого.