и в этой части докер такая же "виртуалка"

а в "докере один процесс" просто неверно

Да, вот только он никогда не умирает.

Откройте для себя switch_root, там управление как раз передаётся другому init

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

Драсте ?

Хай ?

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

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

нужно как-то регаться за исключением meetup сайта?

Тэкс

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

код + окружение -> имейдж

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

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

а докер для чего используете если для запуска на стороне разработчика то код отдельно

если для деплоя то код внутри

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

По поводу апдейта и миграций могу посоветовать смотреть в сторону zero downtime docker doployment.

спасибо за ответы, буду разбираться дальше

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

ошибка возникает при docker-compose down

какая система?

дебиан 8

докер из репозитория, композ с сайта докера

версия докера?

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

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

вместо aufs? или это что-то другое?

вместо aufs

хорошо, спасибо, попробую собрать с этой системой

хотя все должно и так работать

а это может возникать из-за того, чтго в момент выключения идёт запись или чтение?

причем это сразу у всех контейнеров в связке проблема возникает

то есть не отдельный один контейнер не может выключиться

aufs депрекейтед и не рекомендуется к использованию вообще

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

ну... почему нет

а смысл?

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

Чтобы вся система в сборе шла одной коробкой

А умножаем на B Умножаем на C, если затраты на доработку больше X, возврата не будет

если обновлять всю байду дешевле в монолитном виде, то не нужно.

подозреваю что и докер при этом вам не особо нужен )

ну как, для сервиса понятно, зачем он нужен, чтобы не думать про зависимости. Для nginx - не знаю…

ДЛя базы вообще очень странная история

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

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

ну как бы база - это не то, что хочется ставить докером )

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

хм, бд может меняться очень часто, конкретно у нас так и происходит

вы говорите про миграции или про обновление ПО самой БД?

миграции - АКА изменение пользовательских данных ... как правило, хотя многие в миграциях меняют системные данные

миграции - изменение структуры бд, сиды - изменение данных

я говорю именно о миграциях

новые фичи почтоянно требуют новых таблиц/полей в уже существующих таблицах

так-что каждый третий билд в нашей компании включает в себя и миграции тоже

А как докер помогает с миграциями?

Я предположу что лучше всего делать миграции в два шага

Сначала добавить допустим новое поле

следующим билдом научить приложение это поле использовать

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

а если поле переименоывается/убирается?

У тебя база в проде, и она может быть большой

а если поле переименоывается/убирается?

Ага, косяк моей идеи.

она и есть большая

убирается то легко.

А вот переименовать ...

угу, и половина вьюх слетит

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

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

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

Почему пять, трёх не хватит?

я лучше потом в личку воспроизведу, если не горит. сейчас чутка занят

я лучше потом в личку воспроизведу, если не горит. сейчас чутка занят

ok)

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

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

Миграции нужны чтобы мигрировать схему базы. Точка.

ну нет, это слишком строгое ограничение.

это не ограничение, а определение

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

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

зачем в два?)

На больших базах выполнение миграций это жесть по времени.

зачем в два?)

Потому что если делать в один шаг то придется полный цикл миграций накатить

ну миграции тоже разные бывают

Например, добавить поле и удалить еще какое то.

это не ограничение, а определение

класс, вы предлагаете все делать по букве?

Все это долго. Если раскатить это на несколько шагов то это позволит достичь меньшего даунтайма.

И научить код работать с двумя полями одновременно

Сложные миграции должны накатываться без простоя имхо. Либо простой должен быть гарантированно небольшим.

Иначе прод будет простаивать пару часов