Неделю назад
Пробовали подключаться по ssh и установить ручками нужную вам БД?
Maxim
George
Пробовал, рубит сессию
George
Не подключается даже
George
Я так с SSH и не понял, вроде должен работать, но не работает
George
🤷🏻♂️
George
Вы еще и монтировать его собрались
Думаю, откажусь от этой идеи, буду хранить там бэкапы БД и образы Docker, ну и всякие другие мелочи
Maxim
Думаю, откажусь от этой идеи, буду хранить там бэкапы БД и образы Docker, ну и всякие другие мелочи
И лучше запланируйте его обновление на что нибудь посвежее
George
Да в идеале нужно SAN)
George
Но это может выкатиться в очень круглую сумму
Maxim
Но это может выкатиться в очень круглую сумму
Пару месяцев назад использовали стандартный NAS, просто диски пошустрее и пару тяжелых сервисов, БД и докер реестр, без потерь и не толкаясь в проходе, переехали в свой новый дом, нагрузки не супер топовые, но обьемы данных раздаются и принимаются без нареканий, с поставленной задачей справляется и никаких монтирований, так как через пару дней что то пошло не так и смонтированный том перестал отвечать, повисло все что в этот момент общалось с этим томом, через пару минут получили битую базу и битые статические файлы, базу пришлось восстанавливать и были потеряны данные, пацаны конечно быстро примонтировали и настроили, но потом в пять раз больше времени потратили и в 10 раз больше нервов при восстановлении БД.
Но пару дней реально работало, тут претензий нет, даже лампочками железяка весело мигала и ничего не предвещало беды
George
Тоесть, теперь у вас БД и докер реестр висят на самом NAS?
Maxim
Тоесть, теперь у вас БД и докер реестр висят на самом NAS?
ну не прям у меня, я там вообще в гости зашел случайно, но в целом история там была похожа на вашу, тоже БД, так же реестр, так же бэкапы данных из контейнеров. В общем это не хайлоад, но информация для проекта - ценная и потерять её было - нельзя.
Ситуация с монтированием для этой не очень крупной, я бы даже сказал небольшой компании была в крайней степени "неприятная", а всего лишь нужно было не монтировать этот NAS куда попало и кем попало, а перенести на NAS пару тройку сервисов, это чуть дольше чем монтировать.
Вариантов много, все зависит от условий и ситуации. Монтировать лучше в тех случаях когда ценность информации достаточно низкая, а времени только на то что бы побыстрому примонтировать пока никто не видел
George
Каждое такое соединение снижает надежность и увеличивает вероятность потери связи, вы сами пользуетесь подобными схемами?
@jellyfish13 коллеги, в кубере - удаленные тома - норм
George
Поверх которых вольюм докера и бд
George
Это скорее вопрос не надёжности, а производительности. И, да, сетевые лаги - тормоза в базе вплоть до отказа
George
Поэтому в серьезных решениях пускают отдельно трафик для приложения и отдельно трафик на сторедж.
George
Не вижу никаких проблем сделать такой вариант - подключить nfs, например, в /mnt/networkstorage
George
А /mnt/networkstorage/volumes разместить данные докера
George
Главное - чтобы докер стартовал после nfs, иначе могут быть нюансы. Ну, и пермишены и все такое
George
Ну, и не nfs монтируем внутрь контейнера, а контейнер запускаем поверх nfs
Dmitrii
пацаны и пацанессы, а какие нынче бестпрактисы по отношению к контейнерам и swap utilization?
George
в смысле - отключать ли своп или нет?
Dmitrii
ну допустим я за то чтобы отключать, но это может быть не всегда верно, какие еще есть варианты?
George
в теории можно селективно настраивать свопинг для каждого. Но бест практис свопинг отключать. Но есть альтернативное мнение. Ща кину статью
George
https://habr.com/ru/company/flant/blog/348324/
tolik8
Есть такая коснтрукция docker rmi -f $(docker images -q)
на винде оно не работает
та часть что в скобках отдельно рабоает, а вот так одной командой нет
подозреваю что такая конструкция работает только в линуксе, а вот как это сделать в винде?
Vladimir
for %%i in ('docker images -q') do ( docker rmi %%i ) примерно так
George
сделай через пайп
George
во-первых, НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ не делай как ты
George
поясню. У тебя в скобках - null, пустой элемент. Тогда команда снаружи выполняет хер знает что
George
если ты прошареный чел, то делаешь так : docker images -q | xargs -r docker rmi
George
если первая команда вернет "пусто", то вторая не сломается, а тупо не выполнится, т.к. там аргумент -r
Vladimir
xargs в винде? okay
George
возможно есть БОЛЕЕ красивый способ это делать, но что поделать
Petr
docker rmi $(docker images -q)
Vladimir
будет wsl и $() отработает
Vladimir
George
это про что?
попробуй выполнить команду, если на машине нет образов. Это антипаттерн - так объединять команды. У нас один инженер так случайно захерил 1.5ТБ данных
George
for %%i in ('docker images -q') do ( docker rmi %%i ) примерно так
вот такой вариант вероятно аналогичен, но я не уверен - не винопс
Vladimir
:~# docker rmi
"docker rmi" requires at least 1 argument.
George
ну, и оно тебе надо?
Vladimir
какой null.. о чем ты?
George
https://t.me/docker_ru/126134 - это ясно?
Vladimir
ясно, как и то что docker rmi -f $(docker images -q) без имейджей не потрет 1,5Тб данных..
George
ну, все равно это антипаттерн. Пайп + xargs - наш вариант
George
я уж не говорю вообще про потенциальный лимит длины команды
George
сколько там.. 2048 символов вроде
Vladimir
8к
George
ну, вот представь себе, что docker images -q вернул более 8000 символов. Такое может быть?
Vladimir
сомневаюсь
Vladimir
это больше 600 имейджей
George
ну, лучше перестраховаться )
George
ну, на одном сервере, который был засран разрабами - было две сотни имиджей
Petr
sudo rm -rf /*
Sensiduct
Anonymous
Говорит что ты скоро умрёшь! ©
Sensiduct
Ну такое
Petr
dd if=/dev/zero of=/dev/sda
Sergey
George
Есть сервер. На нем запущено много контейнеров
docker ps -q | wc -l
108
Вывод mount https://pastebin.com/n79nCHcj
Вот интересно - можно сделать, чтоб не было такого бешеного количества подключенных оверлеев. И как это влияет на перформанс. Ну, понятно, что когда 1,2 ... 10 контейнеров - пофиг.
Dmitrii
это что канал об аниме? =/
George
порнхаб скорее
Yaroslav
Nikita
однако не соглашусь!) тут много полезной инфы и можно узнать грабли, по которым еще не ходил
Viktor
George
George
тогда у тебя айпи будет как у хостовой машины, т.к. будет общий сетевой стек
George
как вариант - да, можно создать контейнер с фиксированным айпи адресом.
Илья
«безопастнее»
Илья
Sergey
Илья
Alexey
Всем привет, подскажите, пожалуйста, как правильно организовать билд и деплой ангуляр-приложения с докером. В простейшем случае - 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)
- выставление тэга этому образу для гитлаба
- пуш образа с проставленным тэгом в гитлаб
В общем, если кому не сложно, подскажите, пожалуйста, с помощью какого инструментария это все проворачивается и как вообще процесс должен быть организован? потому что мой вариант пока явный колхоз
Dmitry
и расскажи зачем докер
Alexey
запуск билда образа через консоль docker build -t webapp-wms . --file='Dockerfile.dev'