
Anatoly
04.08.2017
08:20:55
Логи чего говорят?
Ты реплай сделай. Он раз в сутки сюда заходит подкинуть и пойти. Может так и не увидеть.

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

Dmitry
04.08.2017
09:54:19
Может так?
FROM mysql:${MYSQL_VERSION}

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

Google

Vir
04.08.2017
09:55:22
ой, опечатался
там без ARG

Pavel
04.08.2017
10:00:29

Vir
04.08.2017
10:00:41
нет
но только ARG можно же перед FROM писать

Pavel
04.08.2017
10:11:47

Vir
04.08.2017
10:21:04
а какая ос?

Pavel
04.08.2017
10:22:56
ubuntu 16.04

Vir
04.08.2017
10:23:22
у меня в репах 17,04
может из-за этого
да, дело в версии, такая конструкция доступна с версии 17,05

Андрей
04.08.2017
14:11:36

Google

Николай
04.08.2017
14:32:19
https://www.instagram.com/p/BXXpTWGlNcp/ lol

Andrey
04.08.2017
14:37:01
Докир в облаках?

Алексей
04.08.2017
14:45:03
с легким намеком что упадет ?

Aion
04.08.2017
14:49:50

Алексей
04.08.2017
14:50:06
так оба же упадут.

Aion
04.08.2017
14:51:17

Алексей
04.08.2017
14:51:40
на картинке явный фатализм

Aion
04.08.2017
14:54:29

Котяй Негодяй
04.08.2017
15:01:19
Девочка пытается поймать летящего кита. Ничего странного.

Алексей
04.08.2017
15:04:14
ага. проходите мимо


Altai
04.08.2017
18:05:15
Товарищи, как корректно организовать простой процесс переезда виртуальных шардов базы на другие физические машины?
Сейчас всё вот таким нехитрым способом делается:
Есть 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 и другими одинаковыми параметрами, за исключением критерия выбора ноды. Но как тогда организовать заименовывание контейнеров, чтобы после их перезапуска не перепутать какой какому шарду соответствует?


zigmund
04.08.2017
18:28:01
это пиздец, господа
нафиг вам сервисы, если вы держите по одной реплике, еще и с локальными вольюмами?
нафиг вам вообще докер?


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

Google

Altai
04.08.2017
18:44:50
нафиг вам вообще докер?

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

Altai
04.08.2017
18:54:28
По хешику.
Центрального диспетчера нет. Количество шардов определяется в самом начале и не меняется на протяжении всего жизненного цикла.

Anatoly
04.08.2017
18:55:51
т.е. вручную окей

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

Sergey
04.08.2017
19:03:47
а что вы будете делать когда у вас будет горячий шард?

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

Sergey
04.08.2017
19:06:47

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

zigmund
04.08.2017
19:09:43
Но как это относится к теме разговора?

Altai
04.08.2017
19:11:03
Более того, есть техническая возможность сделать шардов столько, что можно успешно переживать вырожденный случай, когда каждый объект в одном шарде будет горячим.
В общем, да, я понимаю преимущества диспетчера, но нет, в моём случае он скорее станет проблемой.
Так вот, собственно, вопрос по оверхеду с описанной мной схемы (из-за оверлей-сети) и по тому, как можно адекватнее это дело провернуть? :)
Основная нагрузка на чтение, у каждого шарда тогда ещё довольно много реплик может быть.
а что вы будете делать когда у вас будет горячий шард?

Evgeny
05.08.2017
11:42:59
Read-only
Read-only

RNR ?
07.08.2017
03:42:47
Открываем канал, нажимаем вверху три точки -> Report -> Spam.

Google

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

Stephen
07.08.2017
12:40:58

Phil
07.08.2017
12:41:14
:))))

Andrey
07.08.2017
13:16:47

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

Алексей
07.08.2017
16:24:19
фак. шок контент.
я пок ане видел большее колво слоев в публичном имидже

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

Алексей
07.08.2017
16:32:23
там вообще в контейнере полный фарш.
сислог.
супервизор
консул...

Pavel
07.08.2017
16:33:01
едрить ))))

Sergey
07.08.2017
16:33:06

Pavel
07.08.2017
16:33:29
маескуэль еще нужен внутри

Sergey
07.08.2017
16:34:00