Частный реестр докеров и высокая доступность

В настоящее время мы запускаем частный реестр на одном сервере, на котором размещены все наши образы. Если сервер выйдет из строя, мы в основном потеряем все наши изображения. Мы хотели бы найти способ обеспечить высокую доступность наших изображений. Простым решением, которое я вижу, было бы наличие экземпляра реестра на каждом сервере. Балансировщик нагрузки будет перенаправлять (циклический перебор) трафик на один из доступных экземпляров реестра. Экземпляры реестра будут использовать один и тот же сетевой диск данных (NFS) для хранения образов.

Видите ли вы какие-либо проблемы с этим решением? то есть: если пользователь нажимает изображение на экземпляр, а другой нажимает на другой (решение циклического перебора балансировщика нагрузки), будет ли он создавать какие-либо файлы блокировки в NFS?

Спасибо за ваш отзыв


person Florent Valdelievre    schedule 16.02.2015    source источник
comment
Не проще ли просто создать резервную копию и/или отразить файлы изображений?   -  person Adrian Mouat    schedule 16.02.2015
comment
Это проще, но мы не хотим прерывания обслуживания.   -  person Florent Valdelievre    schedule 16.02.2015


Ответы (3)


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

Если надежность для вас является реальной проблемой, возможно, было бы разумно взглянуть на одно из коммерческих предложений, например. корпоративный центр или Корпоративный реестр CoreOS. (Хотя они, кажется, подчеркивают безопасность и контроль доступа, а не высокую доступность).

person Adrian Mouat    schedule 16.02.2015

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

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

person Andy    schedule 16.02.2015
comment
Спасибо за ваш отзыв, приятно - person Florent Valdelievre; 16.02.2015

реестру необходимо кэшировать некоторые метаданные, используя по умолчанию inmemory. Вы можете изменить конфигурацию кеша, чтобы использовать Redis.

https://docs.docker.com/registry/configuration/#cache

пример конфига:

storage:
  filesystem:
    rootdirectory: /var/lib/registry
  cache:
    blobdescriptor: redis
redis:
  addr: redis-server-host:6379
  db: 1
  dialtimeout: 1s
  readtimeout: 1s
  writetimeout: 1s
  pool:
    maxidle: 16
    maxactive: 64
    idletimeout: 300s

Вы должны изменить метод хранения для s3 или любого другого глобального хранилища. Я запускаю два реестра для обеспечения высокой доступности.

person lutaoact    schedule 03.01.2018
comment
Я настроил два экземпляра EC2 с реестром Docker, используя S3 в качестве хранилища. Вскоре после этого следующие попытки docker push потерпели неудачу с blob upload unknown. Я отключил один из двух экземпляров EC2 (для устранения неполадок с одним), и все сразу же заработало. Это навело меня на мысль, что некоторые данные не синхронизировались/сохранялись в S3. В конце концов я нашел этот пост, и кажется, что это выстраивается. Я попробую с пулом Redis, но пока я отключил другой узел. Спасибо, что поделились этим, сэкономили мне кучу времени. К сожалению, сегодня у Docker нет возможности сохранить это в S3. - person makegofast; 29.05.2020