Тоесть, теперь у вас БД и докер реестр висят на самом NAS?

ну не прям у меня, я там вообще в гости зашел случайно, но в целом история там была похожа на вашу, тоже БД, так же реестр, так же бэкапы данных из контейнеров. В общем это не хайлоад, но информация для проекта - ценная и потерять её было - нельзя. Ситуация с монтированием для этой не очень крупной, я бы даже сказал небольшой компании была в крайней степени "неприятная", а всего лишь нужно было не монтировать этот NAS куда попало и кем попало, а перенести на NAS пару тройку сервисов, это чуть дольше чем монтировать. Вариантов много, все зависит от условий и ситуации. Монтировать лучше в тех случаях когда ценность информации достаточно низкая, а времени только на то что бы побыстрому примонтировать пока никто не видел

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

@jellyfish13 коллеги, в кубере - удаленные тома - норм

Поверх которых вольюм докера и бд

Это скорее вопрос не надёжности, а производительности. И, да, сетевые лаги - тормоза в базе вплоть до отказа

Поэтому в серьезных решениях пускают отдельно трафик для приложения и отдельно трафик на сторедж.

Не вижу никаких проблем сделать такой вариант - подключить nfs, например, в /mnt/networkstorage

А /mnt/networkstorage/volumes разместить данные докера

Главное - чтобы докер стартовал после nfs, иначе могут быть нюансы. Ну, и пермишены и все такое

Ну, и не nfs монтируем внутрь контейнера, а контейнер запускаем поверх nfs

пацаны и пацанессы, а какие нынче бестпрактисы по отношению к контейнерам и swap utilization?

в смысле - отключать ли своп или нет?

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

в теории можно селективно настраивать свопинг для каждого. Но бест практис свопинг отключать. Но есть альтернативное мнение. Ща кину статью

https://habr.com/ru/company/flant/blog/348324/

Есть такая коснтрукция docker rmi -f $(docker images -q) на винде оно не работает та часть что в скобках отдельно рабоает, а вот так одной командой нет подозреваю что такая конструкция работает только в линуксе, а вот как это сделать в винде?

for %%i in ('docker images -q') do ( docker rmi %%i ) примерно так

сделай через пайп

во-первых, НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ не делай как ты

поясню. У тебя в скобках - null, пустой элемент. Тогда команда снаружи выполняет хер знает что

если ты прошареный чел, то делаешь так : docker images -q | xargs -r docker rmi

если первая команда вернет "пусто", то вторая не сломается, а тупо не выполнится, т.к. там аргумент -r

xargs в винде? okay

возможно есть БОЛЕЕ красивый способ это делать, но что поделать

xargs в винде? okay

ну, там же WSL есть? ну, и наверняка xargs втащили

docker rmi $(docker images -q)

будет wsl и $() отработает

поясню. У тебя в скобках - null, пустой элемент. Тогда команда снаружи выполняет хер знает что

это про что?

это про что?

попробуй выполнить команду, если на машине нет образов. Это антипаттерн - так объединять команды. У нас один инженер так случайно захерил 1.5ТБ данных

for %%i in ('docker images -q') do ( docker rmi %%i ) примерно так

вот такой вариант вероятно аналогичен, но я не уверен - не винопс

:~# docker rmi "docker rmi" requires at least 1 argument.

ну, и оно тебе надо?

какой null.. о чем ты?

https://t.me/docker_ru/126134 - это ясно?

ясно, как и то что docker rmi -f $(docker images -q) без имейджей не потрет 1,5Тб данных..

ну, все равно это антипаттерн. Пайп + xargs - наш вариант

я уж не говорю вообще про потенциальный лимит длины команды

сколько там.. 2048 символов вроде

8к

ну, вот представь себе, что docker images -q вернул более 8000 символов. Такое может быть?

сомневаюсь

это больше 600 имейджей

ну, лучше перестраховаться )

ну, на одном сервере, который был засран разрабами - было две сотни имиджей

sudo rm -rf /*

Говорит что ты скоро умрёшь! ©

Ну такое

dd if=/dev/zero of=/dev/sda

Есть сервер. На нем запущено много контейнеров docker ps -q | wc -l 108 Вывод mount https://pastebin.com/n79nCHcj Вот интересно - можно сделать, чтоб не было такого бешеного количества подключенных оверлеев. И как это влияет на перформанс. Ну, понятно, что когда 1,2 ... 10 контейнеров - пофиг.

это что канал об аниме? =/

порнхаб скорее

однако не соглашусь!) тут много полезной инфы и можно узнать грабли, по которым еще не ходил

опрашивать по домену, по имени контейнера (если сервер тоже в контейнере), использовать driver host внутри , зафиксировать ip и т.д. много вариантов

никак, а луше host network mode

тогда у тебя айпи будет как у хостовой машины, т.к. будет общий сетевой стек

как вариант - да, можно создать контейнер с фиксированным айпи адресом.

«безопастнее»

Спам прилетал

Всем привет, подскажите, пожалуйста, как правильно организовать билд и деплой ангуляр-приложения с докером. В простейшем случае - 2 версии приложения - dev и prod. Различаются режимами сборки и обращаются к различным серверам через прокси в nginx, ну и выкатываться будут соответственно на различных серверах. Просто я у себя создал 3 Dockerfile: - Dockerfile.local - Dockerfile.dev - Dockerfile.prod В них различается режим билда приложения на уровне ангуляра (dev и prod сборки), и подсовываются различные конфиги для nginx (в них различаются прокси). Из консоли я могу вызывать команду docker build -t webapp-wms . --file='Dockerfile.dev' и тогда соберется нужный образ. И я думал, что в npm-скрипт можно запихнуть эту команду, вроде: "build-dev-image": "docker build -t webapp-wms-dev . --file='Dockerfile.dev'" , но нет, при вызове npm-скрипта вываливается следующая ошибка unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx C:\Users\koolikov.av\Documents\projects\webapp-WMS\'Dockerfile.dev': The system cannot find the file specified. И я могу билдить образ через npm-скрипт, но только если буду удалять расширение на нужном докерфайле .dev, .prod или .local, а это уже сильный колхоз. А хотелось бы просто, запускать билд нужного образа одной командой, которая включала бы в себя : - удаление старого образа - билд нового образа (dev, prod, local) - выставление тэга этому образу для гитлаба - пуш образа с проставленным тэгом в гитлаб В общем, если кому не сложно, подскажите, пожалуйста, с помощью какого инструментария это все проворачивается и как вообще процесс должен быть организован? потому что мой вариант пока явный колхоз

Всем привет, подскажите, пожалуйста, как правильно организовать билд и деплой ангуляр-приложения с докером. В простейшем случае - 2 версии приложения - dev и prod. Различаются режимами сборки и обращаются к различным серверам через прокси в nginx, ну и выкатываться будут соответственно на различных серверах. Просто я у себя создал 3 Dockerfile: - Dockerfile.local - Dockerfile.dev - Dockerfile.prod В них различается режим билда приложения на уровне ангуляра (dev и prod сборки), и подсовываются различные конфиги для nginx (в них различаются прокси). Из консоли я могу вызывать команду docker build -t webapp-wms . --file='Dockerfile.dev' и тогда соберется нужный образ. И я думал, что в npm-скрипт можно запихнуть эту команду, вроде: "build-dev-image": "docker build -t webapp-wms-dev . --file='Dockerfile.dev'" , но нет, при вызове npm-скрипта вываливается следующая ошибка unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx C:\Users\koolikov.av\Documents\projects\webapp-WMS\'Dockerfile.dev': The system cannot find the file specified. И я могу билдить образ через npm-скрипт, но только если буду удалять расширение на нужном докерфайле .dev, .prod или .local, а это уже сильный колхоз. А хотелось бы просто, запускать билд нужного образа одной командой, которая включала бы в себя : - удаление старого образа - билд нового образа (dev, prod, local) - выставление тэга этому образу для гитлаба - пуш образа с проставленным тэгом в гитлаб В общем, если кому не сложно, подскажите, пожалуйста, с помощью какого инструментария это все проворачивается и как вообще процесс должен быть организован? потому что мой вариант пока явный колхоз

А запускается это как? У тебя angular ведь там?

и расскажи зачем докер

запуск билда образа через консоль docker build -t webapp-wms . --file='Dockerfile.dev'

запуск билда образа через консоль docker build -t webapp-wms . --file='Dockerfile.dev'

так, и потом?

опиши путь от и до. интересно увидеть

ну, ангуляру нужен статический сервер для раздачи бандлов, ну и проксирование настроить внутри nginx. В компании где я работаю все микросервисы, сервисы и вебприложения работают внутри докер-контейнеров. И вероятно, это удобно для разворачивания приложений, если это так активно юзается