
Andrew
02.10.2016
13:43:02
и в этой части докер такая же "виртуалка"
а в "докере один процесс" просто неверно

Denis
02.10.2016
13:57:50

Alex
02.10.2016
13:59:16
Я про стандартную конфигурацию говорю. Ну хорошо я в принципе понял что был неправ.

Google

Filipp
02.10.2016
19:53:48
Драсте ?

Arthur
02.10.2016
19:54:26
Хай ?

Denis
02.10.2016
20:25:14
Если кто ещё не видел, то приходите в четверг на DevOps-митап про Docker на Новоданиловской набережной http://www.meetup.com/DevOps-Moscow-in-Russian/events/234448355/

Алексей
02.10.2016
20:33:06

Александр
02.10.2016
23:11:23
Тэкс

Anton
03.10.2016
11:28:17
привет, я новичок в докере, каким образом лучше делать апдейт вендоров, применять миграции и подобное? и по поводу кода - лучше сделать дата контейнер, или тянуть из гита?

Roman
03.10.2016
11:29:09
код + окружение -> имейдж

Yuriy
03.10.2016
11:29:35
Лучше код отдельно держать. Тогда при изменении кода не надо будет имадж билдить заново.

Roman
03.10.2016
11:29:46
а вообще лучше посмотреть туториал для технологий которыми пользуетесь
а докер для чего используете если для запуска на стороне разработчика то код отдельно
если для деплоя то код внутри

Yuriy
03.10.2016
11:31:34

Anton
03.10.2016
11:32:39
спасибо за ответы, буду разбираться дальше

Google

Roman
03.10.2016
12:20:59
Коллеги, приветствую, помогите советом. Уже несколько раз при перезапуске докера на демо площадке вываливалась ошибки Driver aufs failed to remove root filesystem. Ткните пожалуйста носом в решение этой проблемы. Всё что нахожу в интернете касается старых верси и сводится к "обнови докер". Почему вообще возникает эта ошибка?
ошибка возникает при docker-compose down

Alexander
03.10.2016
12:22:49
какая система?

Roman
03.10.2016
12:23:02
дебиан 8
докер из репозитория, композ с сайта докера

Alexander
03.10.2016
12:23:32
версия докера?

Roman
03.10.2016
12:23:56
Client:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 05:02:53 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 05:02:53 2016
OS/Arch: linux/amd64

Alexander
03.10.2016
12:24:49
у тебя что-то с драйвером стороджей, как вариант можно overlay2 попробовать подключить

Roman
03.10.2016
12:25:51
вместо aufs? или это что-то другое?

Alexander
03.10.2016
12:26:08
вместо aufs

Roman
03.10.2016
12:28:21
хорошо, спасибо, попробую собрать с этой системой

Alexander
03.10.2016
12:28:45
хотя все должно и так работать

Roman
03.10.2016
12:29:40
а это может возникать из-за того, чтго в момент выключения идёт запись или чтение?
причем это сразу у всех контейнеров в связке проблема возникает
то есть не отдельный один контейнер не может выключиться

Andrew
03.10.2016
12:46:57
aufs депрекейтед и не рекомендуется к использованию вообще

Стас Щетинников
03.10.2016
12:48:45
Всем, привет! Наверняка тут уже обсуждали. Но у меня возник вопрос - а вообще есть какой-нибудь смысл например, докеризировать nginx? или postgres? Если они находятся вокруг веб-сервиса.

Ssi
03.10.2016
12:55:44
ну... почему нет

Стас Щетинников
03.10.2016
12:56:32
а смысл?

Michael
03.10.2016
12:57:44

Google

Ruslan
03.10.2016
12:57:44
А умножаем на B Умножаем на C, если затраты на доработку больше X, возврата не будет
если обновлять всю байду дешевле в монолитном виде, то не нужно.
подозреваю что и докер при этом вам не особо нужен )

Стас Щетинников
03.10.2016
12:59:46
ну как, для сервиса понятно, зачем он нужен, чтобы не думать про зависимости. Для nginx - не знаю…
ДЛя базы вообще очень странная история

Michael
03.10.2016
12:59:57
Хотя зависит от ситуации, конечно. Если это один сервис у компании (или их всего парочку), то можно и отдельно хостить
а если много разных сервисов, то лучше одной коробкой ставить

Стас Щетинников
03.10.2016
13:04:11
ну как бы база - это не то, что хочется ставить докером )

Ruslan
03.10.2016
13:06:38
теоретически у вас файловое БД монтируется снаружи , но скорее всего практически там дофига проблем. + БД не так часто меняется как приложение, как исходники так и какая-то конфигурация ... так что да, скорее всего вы правы, нафига оно надо )

Anton
03.10.2016
13:21:49
хм, бд может меняться очень часто, конкретно у нас так и происходит

Ruslan
03.10.2016
13:23:04
вы говорите про миграции или про обновление ПО самой БД?
миграции - АКА изменение пользовательских данных ... как правило, хотя многие в миграциях меняют системные данные

Anton
03.10.2016
13:26:32
миграции - изменение структуры бд, сиды - изменение данных
я говорю именно о миграциях
новые фичи почтоянно требуют новых таблиц/полей в уже существующих таблицах
так-что каждый третий билд в нашей компании включает в себя и миграции тоже

Стас Щетинников
03.10.2016
13:29:59
А как докер помогает с миграциями?

Alex
03.10.2016
13:30:45
Я предположу что лучше всего делать миграции в два шага
Сначала добавить допустим новое поле
следующим билдом научить приложение это поле использовать

Google

Anton
03.10.2016
13:31:05
я новичек, но пока вижу это как таск в дженкинсе а-ля стянуть все из гита, выполнить миграции/сиды, прогнать тесты, запихнуть в контейнер, и задеплоить на продакшн, если все ок
а если поле переименоывается/убирается?

Alex
03.10.2016
13:31:29
У тебя база в проде, и она может быть большой

Anton
03.10.2016
13:31:48
она и есть большая

Alex
03.10.2016
13:31:50
убирается то легко.
А вот переименовать ...

Anton
03.10.2016
13:32:04
угу, и половина вьюх слетит
миграции для того и нужны, чтоб изменения бд и кода применялись одновременно

Ruslan
03.10.2016
13:35:10
не все миграции совместимы с обновлением кода.
например, в схеме, когда у вас head/tail базы (в проде используется одна из и с каждым релизом они меняются местами) самый сложный вариант миграции
это изменение формата поля ... так вот он делался в 5 шагов. то есть в 5 релизов
чтобы было forward & backward compatibility

Ilya
03.10.2016
13:36:21

Ruslan
03.10.2016
13:36:46
я лучше потом в личку воспроизведу, если не горит. сейчас чутка занят

Ilya
03.10.2016
13:37:31

Anton
03.10.2016
13:38:46
возможно, я не встречался пока с какими-то случаями, но если миграции транзакционны, и имеют полноценны down (да, это не всегда возможно, или очень трудозатратно), то достаточно одной бд, если же дауна нет, то две бд, и переключение в зависимости от версии релиза

Alex
03.10.2016
14:03:47

Ruslan
03.10.2016
14:05:25
ну нет, это слишком строгое ограничение.

Aleksandr
03.10.2016
14:06:08
это не ограничение, а определение

Anton
03.10.2016
14:06:49
если бы они не помогали обеспечивать косистентность версии бд с версией кода - я бы их не испольовал)

Alex
03.10.2016
14:07:07
Делайте в два шага, что я еще могу сказать.

Anton
03.10.2016
14:07:25
зачем в два?)

Google

Alex
03.10.2016
14:07:32
На больших базах выполнение миграций это жесть по времени.
зачем в два?)
Потому что если делать в один шаг то придется полный цикл миграций накатить

Anton
03.10.2016
14:07:52
ну миграции тоже разные бывают

Alex
03.10.2016
14:07:55
Например, добавить поле и удалить еще какое то.

Ruslan
03.10.2016
14:08:15

Alex
03.10.2016
14:08:18
Все это долго. Если раскатить это на несколько шагов то это позволит достичь меньшего даунтайма.
И научить код работать с двумя полями одновременно
Сложные миграции должны накатываться без простоя имхо. Либо простой должен быть гарантированно небольшим.
Иначе прод будет простаивать пару часов