Приветы Помогите докер-нубу) Хочу собирать приложение в стабильной среде: нужная версия монги, нужная версия ноды и там запускаются тесты. Пока всё это только для тестирования. Как правильно и почему: 1. собрать правильное окружение в image и в качестве команды в нём делать npm install && npm run deploy 2. собирать новый образ каждый раз, в котором будет и правильное окружение как в п.1. и собранное приложение?

Лучше сделай это на CI с помощью services

поясни

Это концептуально выглядит как костыль. Да и не хочется перезапускать nginx

Да, речь про CI. Пойду покурю services

Это концептуально выглядит как костыль. Да и не хочется перезапускать nginx

У меня в вольюме хранится вольюм шарится между разными контейнерами

Блин

Зараза докер

У меня в вольюме хранится вольюм шарится между разными контейнерами

Okey, а как вы обновления статики то доставляете?

Освободился 5 гигов от удаления. Снова заполнился

😭😭

Okey, а как вы обновления статики то доставляете?

В Dockerfile аппки обьявляется волюм, и он потом подключается в nginx через параметр volumes_from

docker-compose run proj python manage.py collectstatic

будет время добавлю в git post commit hook

Всем привет! Кто может подсказать. Используется бд бэкенд, под nextxloud.Крутится APP на пользовательском образе . Вышел официальный образ. Хочу на него мигрировать. Файлики перетянул все работает - если только создавать новую бд. Если пробую подключится к текущей то докер при запуске(APP) создаёт заново таблицы. И получается ошибка, что они задублированы. Каким образом это можно обойти ?

переписать их инит скрипт в образе

переписать их инит скрипт в образе

В официальном образе ? Не сталкивался с этим раньше. Что на что переписать ?Убрать создание а добавить что ?

мопед не мой, я просто разместил объяву

Всем привет! Мне необходимо постороить несколько микросервисов с такой архитектурой: api-gateway |---service1 |---service2 |---service3 ... Ранее с докером не работал, приходится осваивать. Доступ из вне только на api-gateway и между собой сервисы общаются только через него. На каждый сервис приходится минимум по 3 контейнера (nginx, php-fpm, workspace) Контейнеры собираю в docker-compose.yml тут все почти гуд и почти понятно. Подскажите пожалйста следующие вещи: 1) Если на каждый сервис будут дублироватся контейнеры (nginx, php-fpm, workspace), то может быть правильнее каким то образом сделать их общими для сервисов чтобы избежать дубликатов. Если это так, то направте меня на правильный путь в этом направлении? 2) Как мне собрать микросервисы в готовый стек сервисов, где, какими инструментами и как примерно это делается? 3) База будет postgres и будет крутится вне докера на виртуалке, в связи с этим непонятно как подключить базу из вне для каждого контейнера.

1) Если на каждый сервис будут дублироватся контейнеры (nginx, php-fpm, workspace), то может быть правильнее каким то образом сделать их общими для сервисов чтобы избежать дубликатов. Если это так, то направте меня на правильный путь в этом направлении? 2) Как мне собрать микросервисы в готовый стек сервисов, где, какими инструментами и как примерно это делается? не совсем понятны вопросы

3) База будет postgres и будет крутится вне докера на виртуалке, в связи с этим непонятно как подключить базу из вне для каждого контейнера. В чем проблема ходить в нее по сети?

в драйвере указываешь хост db.host.example и все, если сеть нормально настроена, то ему ничего не помешает пойти куда угодно

Ну и может быть стоит базу тоже в сервис таки вынести (если нет каких-то принципиальных причин этого не делать?)

Вроде не советуют базы данных хранить в контейнерах, якобы она возвращается в исходное состояние, при каких то манипуляциях, нет?

все что делается в контейнере удаляется после перезапуска, но есть volume который можно подключить

для development/staging/CI крутить базы в докере приемлимо а вот прод - особого смысла нет

Вроде не советуют базы данных хранить в контейнерах, якобы она возвращается в исходное состояние, при каких то манипуляциях, нет?

Кто не советует?

интернет)

*если поискать выше тот тут уже обсуждалась эта тема, раза 3 на моей памяти

не верьте им

они обманывают

Верю вам)

держите все в докере, докер в виртуалке, виртуалку в амазоне, амазон в датацентре, датацентр в малайзии, малайзию в жепе.

Все чаще Некст клоуд

Зачем

Что все вдруг подсели на эту моду клоуд, у вас что многомиллиардные корпорации

у меня две. вам не надо?

так для корпораций облака очень дорогие

Сайт какого нить колхоза с 3 мя униками а они кластеры городят

тогда заберу у вас.

самсунг вон в прошлом году купил жойент

потому что амазон стал очень дорогой

Сам одних знаю, магазин сантехники, посещаемость 1000 уников в день кластер за 3000 евро в месяц

Я хозяину так и сказал у тебя че золотые унитазы

такое ощущение, что сижу на сходке виндоадминов в твери, с самым дешевым пивом)

1) Если на каждый сервис будут дублироватся контейнеры (nginx, php-fpm, workspace), то может быть правильнее каким то образом сделать их общими для сервисов чтобы избежать дубликатов. Если это так, то направте меня на правильный путь в этом направлении? 2) Как мне собрать микросервисы в готовый стек сервисов, где, какими инструментами и как примерно это делается? не совсем понятны вопросы

1)например есть service1 в нем контейнеры nginx, php-fpm, workspace есть сервис service2 в нем тоже крутятся точно такие же контейнеры, тоесть дубликаты, отличие только в кодовой части саомого приложения и если я правильно понял, то образ у них будет один и тот же, а запущенные контейнеры разные, можно ли как то чтобы один контейнер, например nginx был общим для этих сервисов и вообще правильно ли это? 2) вот запустил я compose одного микросервиса, другого. все это вручную, это же явно что то не то. в идеале бы хотелось понять как запустить одной коммандой весь стек микросервисов PS: сорян за нубство, но я тупой(((

Что все вдруг подсели на эту моду клоуд, у вас что многомиллиардные корпорации

Ну не все тут занимаются интернет магазинчиками на коленке 😂

Ну и может быть стоит базу тоже в сервис таки вынести (если нет каких-то принципиальных причин этого не делать?)

для develop так сгодится, но для production что то не нравится мне эта идея в volume

вот бы кто-то аргументы привёл

ну поищите выше

мы с час копья ломали

если кратко то докер не добавляет ценности к субд

ну было бы странно, если б было иначе

реплики в бд и так есть из коробки

и тем более добавляя сущность в систему вы не увеличиваете ее надежность а скорее наоборот

1)например есть service1 в нем контейнеры nginx, php-fpm, workspace есть сервис service2 в нем тоже крутятся точно такие же контейнеры, тоесть дубликаты, отличие только в кодовой части саомого приложения и если я правильно понял, то образ у них будет один и тот же, а запущенные контейнеры разные, можно ли как то чтобы один контейнер, например nginx был общим для этих сервисов и вообще правильно ли это? 2) вот запустил я compose одного микросервиса, другого. все это вручную, это же явно что то не то. в идеале бы хотелось понять как запустить одной коммандой весь стек микросервисов PS: сорян за нубство, но я тупой(((

1) держи раздельно, там nginx к примеру будет одинаковый, а конфиг разный. Можешь просто сделать общий nginx для обоих сервисов к примеру и в конфиге настроить обращения к обоим 2) ansible и тому подобное

вот бы кто-то аргументы привёл

Aufs и overlay до сих пор имеют некоторые баги и иногда могут просто уйти в read-only, иногда это вообще решается только сносом /var/lib/docker/$fs где лежат все волюмы и тогда все данные идут к херам

Достаточный аргумент?

кроме слов "некоторые" и "иногда" – да

бэкапы наше все

Хотя зачем хранить бд в волюмах вопрос такой

Основное - зачем

Если делать волюмы, то только с распределенного хранилища, тогда смысл в бд в докере, если бд и так можно развернуть этим хранилищем

Вот и мне непонятны плюсы бд в докере в проде

ну я вижу плюс только в удобном initial setup всего подряд

бритва Оккама и докер... ))

dev/test - да, в проде не нужон

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

внутренний нетворк, внутренний днс, вот это всё

То есть "а хули бы и нет"?)

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

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

Да потому что нет плюсов и только больше факторов риска недостаточный аргумент?)

Или кубернетс растянут географически и это обеспечит то, что бд будет в той же локации

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

А не там, откуда отклик 50мс

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

очень смешно, да

Или кубернетс растянут географически и это обеспечит то, что бд будет в той же локации

Для этого не нужно в контейнере вертеть в сервис с внешней бд можно и без этого завести там.

очень смешно, да

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

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

у кого-нибудь была проблема с запущенным через docker-compose контейнером: при убийстве встает еще один с префиксом в виде container id

1) держи раздельно, там nginx к примеру будет одинаковый, а конфиг разный. Можешь просто сделать общий nginx для обоих сервисов к примеру и в конфиге настроить обращения к обоим 2) ansible и тому подобное

Спасибо большущее! /me благодарен

/me