Логи чего говорят?

Ты реплай сделай. Он раз в сутки сюда заходит подкинуть и пойти. Может так и не увидеть.

господа, почему может не работать такая конструкция ARG MYSQL_VERSION=8.0 FROM mysql:${MYSQL_VERSION} в доке написано, что так делать можно, но оно материт, мол не понимает откуда ставить

Может так? FROM mysql:${MYSQL_VERSION}

Лучше сразу на документацию с примером https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact

ой, опечатался

там без ARG

Лучше сразу на документацию с примером https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact

я там смотрел

я там смотрел

а вместо ARG пробовал писать ENV?

нет

но только ARG можно же перед FROM писать

но только ARG можно же перед FROM писать

да, здесь ты прав. у меня Docker version 17.06.0-ce, build 02c1d87 нормально билдит, я скопировал твой текстю

а какая ос?

ubuntu 16.04

у меня в репах 17,04

может из-за этого

да, дело в версии, такая конструкция доступна с версии 17,05

Ну, если я слишком много хочу, то хотя бы хостинг с CI.

Можешь сам поднять у чебя на сервере или админа какого попросить: GitLab там можно в нём поднять docker registry и потом сделать в CI так как ты хочешь

https://www.instagram.com/p/BXXpTWGlNcp/ lol

Докир в облаках?

с легким намеком что упадет ?

с легким намеком что упадет ?

главное успеть поймать жи)))))

так оба же упадут.

так оба же упадут.

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

на картинке явный фатализм

на картинке явный фатализм

это через призму твоего восприятия

Девочка пытается поймать летящего кита. Ничего странного.

ага. проходите мимо

Товарищи, как корректно организовать простой процесс переезда виртуальных шардов базы на другие физические машины? Сейчас всё вот таким нехитрым способом делается: Есть Node-1, на которой запущены сервисы, в которых крутятся субд (по 1 контейнеру на каждый сервис) master-1, replica-1; master-2, replica-2; master-3, replica-3... К каждому сервису привязана какая-то хостовая директория как volume (volume-m1, volume-r1 и так далее). Процесс переезда одного шарда на новую физическую машину: 1. Стопается сервис replica-1 и рсинкается соответствующий volume на Node-2, удаляется на Node-1. 2. В docker-compose меняется указание ноды, на которой запускать replica-1, стартуется сервис replica-1. Теперь она работает на Node-2 и подхватывает нужный volume. Собственно, всё. Никакие конфиги на master-1 и на любых, использующих базу сервисах не меняются, благодаря тому, что адреса за нас разруливает сам docker swarm. Насколько плох такой вариант? Слишком ли огромен будет оверхед из-за того, что всё полагается на оверлей-сеть свармовую? Может есть какие-нибудь более адекватные типовые схемы автоматизации соответствующего процесса или корректнее всё-таки поддержать и на стороне базы и на стороне всех сервисов её использующих обновление адресов текущих шардов, то бишь всё руками сделать (зато потом обойтись без overlay-сети)?

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

это пиздец, господа

нафиг вам сервисы, если вы держите по одной реплике, еще и с локальными вольюмами?

нафиг вам вообще докер?

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

У нее роль можно поменять потом на мастер и прошлого мастера на другую машину тоже перенести.

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

Возможно, я плохо описал как-то. Если более коротко, то всё как раз предельно топорно: k сервисов, каждый привязан к конкретной ноде, на каждый по одному контейнеру, к которому привязан свой volume. Останавливаем сервис, перемещаем соответствующий ему volume, запускаем сервис. Всё, какой-то шард переехал на другую физическую машину. Никакие сервисы с логикой про это не знают, потому что общаются с ним по тому же имени.

Как минимум для того, чтобы много установок субд запускать на одной машине: база заранее разбита на k шардов, которые просто понемногу по физическим машинам разъезжаются.

нафиг вам вообще докер?

Занятно а как вы знаете какой сервис в какой шард кладёт? Или оно у вас вручную шардированно?

По хешику.

Центрального диспетчера нет. Количество шардов определяется в самом начале и не меняется на протяжении всего жизненного цикла.

т.е. вручную окей

Ну, собственно, нет диспетчера как точки отказа. Но и не переразрезать данные. Поэтому и создаются заранее "виртуальные" шарды, в количестве k штук. А по мере роста нагрузки они просто разъезжаются по разным физическим машинкам.

а что вы будете делать когда у вас будет горячий шард?

Ничего. Предполагается, что k достаточно большое, чтобы отдельные виртуальные шарды были достаточно маленькими.

Ничего. Предполагается, что k достаточно большое, чтобы отдельные виртуальные шарды были достаточно маленькими.

у вас может быть ОДИН объект, который будет супергорячим. он всегда будет попадать в один шард. я об этом кейсе. но понятно что он не для всех.

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

у вас может быть ОДИН объект, который будет супергорячим. он всегда будет попадать в один шард. я об этом кейсе. но понятно что он не для всех.

ВНЕЗАПНО. один объект ВСЕГДА будет попадать на один и тот же шард.

Но как это относится к теме разговора?

Более того, есть техническая возможность сделать шардов столько, что можно успешно переживать вырожденный случай, когда каждый объект в одном шарде будет горячим.

В общем, да, я понимаю преимущества диспетчера, но нет, в моём случае он скорее станет проблемой.

Так вот, собственно, вопрос по оверхеду с описанной мной схемы (из-за оверлей-сети) и по тому, как можно адекватнее это дело провернуть? :)

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

а что вы будете делать когда у вас будет горячий шард?

Read-only

Read-only

Открываем канал, нажимаем вверху три точки -> Report -> Spam.

Нате вам на начало недели https://medium.com/@schors/developer-virtual-environment-with-docker-sshd-pam-3ada63186ffe

Нате вам на начало недели https://medium.com/@schors/developer-virtual-environment-with-docker-sshd-pam-3ada63186ffe

хе-хе, из статьи узнал, что Compose запилили уже 3.3 версию файла

:))))

хе-хе, из статьи узнал, что Compose запилили уже 3.3 версию файла

да был бы с этого какой то прок ещё :)

Подъехали configs, вот только из-за иммутабельности нельзя просто взять и редеплой сделать. В итоге только руками что ли изменять?

фак. шок контент.

я пок ане видел большее колво слоев в публичном имидже

ну а чё, клёвая матрёшка, оно поди ещё все по старинке, новым методом поди бы куча всего выкинулось, кстати, а где нормальный мануал по новой сборке почитать, вот с этой выкинем всё посередине

там вообще в контейнере полный фарш.

сислог.

супервизор

консул...

едрить ))))

консул...

подожди, системд проявится

маескуэль еще нужен внутри

маескуэль еще нужен внутри

кассандра!