блин. я наверно на китайском пишу

я задал вопрос и он не странно был пропущен

я не уверен что правильно понял вопрос, для меня это звучало в стиле "вот у меня несколько инстансов docker-registry, хранилище в S3, прикрыты ELB (конкретное название прокси пофиг), что будет, если один из реджистри упадёт"

я неправильно понял?

это так, правильно. но мне почемуто кажется что тут закралась неполная картина. когда они все сервили уже готовые имаджи (читай в RO режиме) тогда все будет как вы говорили. когда туда кто-то пушил - то начинаются проблемы. просто проверьте. мой кейс: official registry2 image, некий шаред сторадж смонрированный для registry. мы не в амазоне, но это и не решает тут ничего. потому что проблема и вопрос не в сторадже совсем

> некий шаред сторадж смонрированный для registry какой?

и как классика: вопрос изначальный был не про что выбрать и почему. руссие чатики они такие

это меняет вопрос stateful или нет реджистри?

изначальный вопрос был более 10 часов назад

ну ок, в одном месте это gluster

это меняет вопрос stateful или нет реджистри?

не знаю, может у тебя сторейж с особенностями

ничего особенного. оно работает как локальныя FS... смонтировано же. а что там спрятано за mountpoint приложению пофиг

у mcs.mail.ru работает ha regystry, у вас нет. ну ок, русский же сервис, он такой.

ничего особенного. оно работает как локальныя FS... смонтировано же. а что там спрятано за mountpoint приложению пофиг

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

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

но вообще если у тебя уже есть шаред фс, то почему бы не иметь ровно 1 запущеный реджистри в каждый момент времени, если натыкались на какие-то проблемы с хранилищем в гластере?

а кто сказал что с этим проблемы или что мы так не делали?

что?

разве в этом вопрос / просьба обовновать стейтлесс? хотябы с registry2

что значит "обосновать стейтлесс"?

тебе сказали что докер-реджистри - стейтлесс

It is possible to run multiple containers against the same storage back-end for performance and availability reasons. Here is an example using a shared s3 storage back-end, Redis cache and MySQL search database (all should be common across containers for consistency)

там ещё просят mysql/redis, не только s3

не веришь - ок

там ещё просят mysql/redis, не только s3

само приложение всё равно стейтлесс

скорее всего из коробки там sqlite

стейт снаружи

поэтому могли быть траблы

ок, мы про разные реализации говорим значит. или я что-то сильно упустил

можно ссылочку?

ты явно что-то упустил, если у тебя реджистри был не стейтлесс

https://github.com/docker/docker-registry/blob/master/ADVANCED.md#high-availability-and-scaling

https://github.com/docker/docker-registry/blob/master/ADVANCED.md#high-availability-and-scaling

это v1

о блин

я в документации по нынешнему реджистри не вижу упоминаний никаких баз данных

https://docs.docker.com/registry/configuration/#list-of-configuration-options

redis есть

https://github.com/docker/distribution/blob/master/docs/configuration.md

ищвините, мне надо бежать на работу. может еще вернемся к обсуждению, если не против

это всё равно снаружи

мы тут уже больше для себя общаемся

это всё равно снаружи

ну так если это опустить возможны проблемы в ha

мы тут уже больше для себя общаемся

мы тут всегда для себя общаемся

ну так если это опустить возможны проблемы в ha

ну редис там вроде для кеша только

правда я не очень понял что такое blobdescriptor

это так, правильно. но мне почемуто кажется что тут закралась неполная картина. когда они все сервили уже готовые имаджи (читай в RO режиме) тогда все будет как вы говорили. когда туда кто-то пушил - то начинаются проблемы. просто проверьте. мой кейс: official registry2 image, некий шаред сторадж смонрированный для registry. мы не в амазоне, но это и не решает тут ничего. потому что проблема и вопрос не в сторадже совсем

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

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

А по изначальному вопросу есть инфа? У кого-то

Часто ли лежит quay.io?

вряд ли, оно теперь часть CI во многих проектах в RH

думаю и в гугле тоже

вряд ли, оно теперь часть CI во многих проектах в RH

а вы юзаете его только как хранилище или билдите там же?

а вы юзаете его только как хранилище или билдите там же?

билдим отдельно

gitlab не может знать какие image нужны. Я просто раз в пару месяцев удаляю все из registry.

я про реаизии одного имаджа с одним и тем же тегом. Вот если мне сам имадж нужен, а вот все 100-500 его предидущих вариаций не очень

Всем привет, никто не знает что нужно прописать в heapster чтобы он начал собирать метрики с кубера по iops ? Сейчас комманда типа такой прописана "containers": [ { "name": "heapster", "image": "gcr.io/google_containers/heapster-amd64:v1.4.0", "command": [ "/heapster", "--source=kubernetes:https://$KUBERNETES_SERVICE_HOST:443?inClusterConfig=true&useServiceAccount=true", "--sink=influxdb:http://monitoring-influxdb.kube-system.svc.cluster.local:8086?retention=0s", "--v=2" ],

я про реаизии одного имаджа с одним и тем же тегом. Вот если мне сам имадж нужен, а вот все 100-500 его предидущих вариаций не очень

gitlab не знает нужны ли прошлые реализации

может вам все 500 нужны и все сломается без них

gitlab не знает нужны ли прошлые реализации

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

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

тут должно быть решение основанное на вашей инфре. Если это только k8s, то можно оттуда брать список активных image и тп.

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

читай вычистить имджи без тегов

читай вычистить имджи без тегов

всё так, но хотелось уточнить может есть что-то нативное, а не очередные костыли

а, я что-то тупанул. Вы про image с одинаковым тегом... Это не best practices в принципе

ну latest переписывать - норм практика :)

ну не норм

так или иначе могут оставаться нетегированые имджи в реджистри

удалять раз в пол года все image под контролем в среду)

типа того

удалять раз в пол года все image под контролем в среду)

вот это прямо бестпрактис от лучших собаководов 🙂

ни у кого особо не болит, поэтому нет решения, думаю так

ни у кого особо не болит, поэтому нет решения, думаю так

https://gitlab.com/gitlab-org/gitlab-ce/issues/25322 уже как 2 года болит 🙂

У меня тоже болит

там второй ответ bash же готовый. У меня конктерно latest не болит, потому что не использую

а перезаписей тегов крайне мало (только на рестарт ci)

Я решил эту проблему использовав для registry['storage'] GCS

Там место никогда не кончится 😂

вот мне кажется все примерно так же решают

Там место никогда не кончится 😂

S3/GCS/Swift/etc

на baremetal пару TB лишних валяются по цене в районе 500р за ТБ. За 500р в месяц я пока не готов искать решения проблемы

это если есть куда их пихать