Здравствуйте, Cyberax, Вы писали:
Ops>>Ну разве что собрать все вместе немного проще, и сложно пропустить, когда чего-то не хватает и тянется системная либа. C>Именно так. Докер — просто удобный инструмент для изоляции зависимостей. Можно и без него, но зачем создавать себе лишние сложности?
Лишние сложности у меня были как раз с докером, я так и не одолел постгрю в винде, не хочет она базу держать на хостовой FS, багу несколько лет, хотя вроде есть шансы, что с wsl2 будут чинить.
Все плюсы унификации пропадают, и мне нет смысла возиться с докером, проще настроить виртуалку.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Ops>>>Ну разве что собрать все вместе немного проще, и сложно пропустить, когда чего-то не хватает и тянется системная либа. C>>Именно так. Докер — просто удобный инструмент для изоляции зависимостей. Можно и без него, но зачем создавать себе лишние сложности?
Ops>Лишние сложности у меня были как раз с докером, я так и не одолел постгрю в винде, не хочет она базу держать на хостовой FS, багу несколько лет, хотя вроде есть шансы, что с wsl2 будут чинить. Ops>Все плюсы унификации пропадают, и мне нет смысла возиться с докером, проще настроить виртуалку.
вот это уже что-то более-менее конкретное,
ну так есть тут такие, у кого это получилось подружиться с postgre под docker на windows или таких тут нет?
Ну подружить-то можно, но база (ее файлы) будет не на хосте, а в docker volume или в контейнере. Если с volume еще можно как-то жить, хоть и сильно неудобно, то в контейнере — это вообще нерабочее решение, разве что для тестов годится, ибо при каждой пересборке контейнера база сбрасывается.
Короче, заниматься этим буду только если вынудят, а так, инструмент, который призван облегчить жизнь, наоборот, создает геморрой на ровном месте, а посему, по возможности обойдусь без него.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, takTak, Вы писали:
Ops>Ну подружить-то можно, но база (ее файлы) будет не на хосте, а в docker volume или в контейнере. Если с volume еще можно как-то жить, хоть и сильно неудобно, то в контейнере — это вообще нерабочее решение, разве что для тестов годится, ибо при каждой пересборке контейнера база сбрасывается.
Ops>Короче, заниматься этим буду только если вынудят, а так, инструмент, который призван облегчить жизнь, наоборот, создает геморрой на ровном месте, а посему, по возможности обойдусь без него.
Ops>Лишние сложности у меня были как раз с докером, я так и не одолел постгрю в винде, не хочет она базу держать на хостовой FS, багу несколько лет, хотя вроде есть шансы, что с wsl2 будут чинить. Ops>Все плюсы унификации пропадают, и мне нет смысла возиться с докером, проще настроить виртуалку.
БД в докере как раз скорее девелоперский вариант, в продакшене редко кто делает.
Здравствуйте, Sheridan, Вы писали:
S>>>Очень надеюсь, что в аду есть отдельный котёл для людей, который ставят в систему софт мимо манагера пакетов. C>>Например, с помощью Ansible. Ага. S>Нет например.
Ansible может использовать менеджер пакетов, но сам не отличается от "curl | sudo bash".
C>>Hint: Docker — это менеджер пакетов. S>Ну да, скриптом из цитаты устанавливается ждокер в ждокер. Угу.
Ops>Ну подружить-то можно, но база (ее файлы) будет не на хосте, а в docker volume или в контейнере. Если с volume еще можно как-то жить, хоть и сильно неудобно, то в контейнере — это вообще нерабочее решение, разве что для тестов годится, ибо при каждой пересборке контейнера база сбрасывается.
Ops>Короче, заниматься этим буду только если вынудят, а так, инструмент, который призван облегчить жизнь, наоборот, создает геморрой на ровном месте, а посему, по возможности обойдусь без него.
вообще, именно такой потребности: копаться в используемой реальной базе данных, может, обычно, и не нужно, достаточно возможности накатывать изменения на схему базы ну и каких-то конфигурационных параметров, которые могут храниться в каких-то таблицах, это-то легко получается ?
как данные из production доставать, анонимизировать и предоставлять разработчикам для отладки багов — это несколько другая задача
Здравствуйте, takTak, Вы писали:
T>вообще, именно такой потребности: копаться в используемой реальной базе данных, может, обычно, и не нужно, достаточно возможности накатывать изменения на схему базы ну и каких-то конфигурационных параметров, которые могут храниться в каких-то таблицах, это-то легко получается ?
Так конфиг базы, например, в той же папке.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Лишние сложности у меня были как раз с докером, я так и не одолел постгрю в винде, не хочет она базу держать на хостовой FS, багу несколько лет, хотя вроде есть шансы, что с wsl2 будут чинить. Ops>Все плюсы унификации пропадают, и мне нет смысла возиться с докером, проще настроить виртуалку.
Ну так купи Mac, там работает
Или как вариант — запустить БД на хосте и пробросить в Docker.
Здравствуйте, Ops, Вы писали:
C>>Ну так купи Mac, там работает C>>Или как вариант — запустить БД на хосте и пробросить в Docker. Ops>Ну вот костыли. А как же удобство, которое обещано, когда есть стабильное окружение где бы то ни было? Зачем тогда докер?
Ну так всё есть, надо только macOS или Linux в качестве среды разработки.
Здравствуйте, Sheridan, Вы писали:
MA>> Я писал, что при изменении внешних зависимостей, мало что можно гарантировать, в случае, если они меняются вне зависимости от нас. S>Смотри. Поменяться они могут только в двух случаях: S>1. Либа обновилась на более новую версию S>2. Либа откатилась на более старую версию.
Это крайне утрированно с твоей стороны. Мир чуточку сложнее и в то же время проще. Не хочу это продолжать, потому что прийдется выдать стену текста и потрать на нее часа 4.
S>А я веду к тому, что чем меньше будет ленивых, тем реже будет встречаться авралы обоих типов.
Ты идеалист. Это правильно, — всегда нужно стремиться к идеалу, и не лениться. Лень мешает во всем. Тем не менее это не технический аспект вопроса, и фактически, с ним вообще не связан.
Здравствуйте, Sheridan, Вы писали:
S>Очень надеюсь, что в аду есть отдельный котёл для людей, который ставят в систему софт мимо манагера пакетов.
Видишь ли, менеджер пакетов отлично работает только в случае если есть один источник и потребители. В реальной жизни это не совсем так и нюансов там вылезает хуева гора. При чем в разрешении типичных проблем — эта гора как раз и не нужна. При чем систему можно и не портить.
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, Mamut, Вы писали:
M>> Но 80 программистов могут спокойно делать то, что бизнесу нужно, не оглядываясь друг на друга и ломая друг другу код и прод из-за обновлений и несовместимостей. M>Представил себе месилово из 80-ти пограммистов, без оглядки ломающих друг-другу код. Эдакий бой во время празднования масленницы. M> M>Шутка. Я понял, что "не ломая".
Здравствуйте, Ops, Вы писали:
Ops>Это для БД антипатерн? А где ж ее держать, чтоб она при ребилде контейнера не сбрасывалась? Да, именно БД, которая с состоянием.
1. Докер: Named Volume
2. Kubernetes: PV + PVC
Не использовать для докера:
1. Host mount
2. --volumes-from. Не удивлюсь, если этот уже deprecated
