Пахнет спамом

типичные боты

чую щас онлайн три топора скинут

Добрый день я то уж точно не бот.

Пахнет спамом

Уже нет

Всем привет! Кто разворачивал nextcloud в docker -e? Подскажите плз, говорят что при масштабируемости работает фигово, что под масштабируюмостью подразумеваю- например, 1500 пользователей и каждый хочет засунуть по 50-60 гигов файлики! Что лучше использовать centos или ubuntu ? Сам еще не разворачивал, вот сейчас буду начинать, просто хотел спросить совета, можт кто подобные вещи делал? Может еще с какими проблемами сталкивался ?

Всем привет! Кто разворачивал nextcloud в docker -e? Подскажите плз, говорят что при масштабируемости работает фигово, что под масштабируюмостью подразумеваю- например, 1500 пользователей и каждый хочет засунуть по 50-60 гигов файлики! Что лучше использовать centos или ubuntu ? Сам еще не разворачивал, вот сейчас буду начинать, просто хотел спросить совета, можт кто подобные вещи делал? Может еще с какими проблемами сталкивался ?

Центось или убунту - без разницы

Что лучше умеете, то и берите. В целом, центось немного посложнее для новичка, но и более стабильная. Все равно если все упакуете в докер, то фишки убунты со свежими пакетами на хосте - мимо

Это что-то вроде owncloud?

Касательно масштабируемости - вопрос к докеру вообще не имеет отношения. Вам нужно строить федерацию из нектклаудрв, а я хз как они горизонтально скейлятся

Центось или убунту - без разницы

Я читал с ubuntu есть в этом плане некоторые фризы с бекапами, что очень критично, не хотелось бы когда пользователь лил бы файл в 90 гигов, а в это время делался бы бекап, после этого пришлось бы пользователю лить эти 90 гигов заного..

И сторедж лучше взять типа s3

Это что-то вроде owncloud?

Да, ребрендинг, форк

Что лучше умеете, то и берите. В целом, центось немного посложнее для новичка, но и более стабильная. Все равно если все упакуете в докер, то фишки убунты со свежими пакетами на хосте - мимо

Понял, спс!

Я читал с ubuntu есть в этом плане некоторые фризы с бекапами, что очень критично, не хотелось бы когда пользователь лил бы файл в 90 гигов, а в это время делался бы бекап, после этого пришлось бы пользователю лить эти 90 гигов заного..

Какие фризы с бекапами, вы что?

Убунта и центос - тот же хуй в другой руке

Ядро одинаково работает

Какие фризы с бекапами, вы что?

Судя по вопросам, человек знает про линукс только то, что он есть

У вас бекапы вообще на уровне файловой системы должны быть (типа lvm snapshot). База - реплицирована. Иначе реально взорвется.

Ядро одинаково работает

И да, и нет

Кстати рекомендую zfs

Её допилили нормально под линь

И стало вообще хорошо

Вообще для Вашей задачи нужен не нектклауд, а обджект сторедж

Судя по вопросам, человек знает про линукс только то, что он есть

От части, с ubuntu работал, а вот с центось вообще оч мало))

Типа s3 совместимого. А что внутри. Да хоть https://cloudian.com/products/hyperstore/

От части, с ubuntu работал, а вот с центось вообще оч мало))

Тогда берите убунту

Debian, лучше приучать себя к хорошему

Ядро сразу накати только из бэкпортов

Типа s3 совместимого. А что внутри. Да хоть https://cloudian.com/products/hyperstore/

Спс почитаю!

А то из коробки несвежее

Собираю так проект docker-compose up --build . К примеру, если вносятся изменения в код, приходится через ctrl+c завершать и заново запускать docker-compose up --build. Так как я новичек в докере, быть может есть более правильное решение?

Изменения в код вносятся пока текущая версия ещё не добилдилась? Так пишите сразу все и билдите

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

Изменения в код вносятся пока текущая версия ещё не добилдилась? Так пишите сразу все и билдите

сначало пишу код. Далее этот код заливается на сервер, далее control+c и пересборка, сейчас так

Попробуй обернуть компоуз в сервис и рестартить его на каждом коммите, например. Имхо красивее и удобнее.

Попробуй обернуть компоуз в сервис и рестартить его на каждом коммите, например. Имхо красивее и удобнее.

благодарю

Ух ты

Позывные

Да, некоторые сообщества немного перегибают и требуют писать свой позывной в никнейме ;) когда то было обязательно. Менять теперь лениво. Приветствую всех!

Есть у кого опыт сборки перла в докере? Может подскажете лучшие практики? Спасибо.

Есть у кого опыт сборки перла в докере? Может подскажете лучшие практики? Спасибо.

Зачем ? А какие особенности сборки перла? Он же вроде интерпретируемый

И ещё - это что за модуль? Ну, скрипт, cgi или что?

Да, интерпретируемый. Есть несколько способов собирать библиотеки. Через perlbrew cpanm ставить прямо в контейнере или через carton. И если приложение давно уже написано как cgi то так и собирать его внутри одного контейнера apache + perl ?

И ещё - это что за модуль? Ну, скрипт, cgi или что?

cgi с зависимостями из cpan

Да, интерпретируемый. Есть несколько способов собирать библиотеки. Через perlbrew cpanm ставить прямо в контейнере или через carton. И если приложение давно уже написано как cgi то так и собирать его внутри одного контейнера apache + perl ?

Ну, видимо, придется так, да

Я просто не в курсе Апач + cgi ведь по сети не фурыкен?

Т.е. распилить отдельно Апач от перла на разные контейнеры не получится

Да, интерпретируемый. Есть несколько способов собирать библиотеки. Через perlbrew cpanm ставить прямо в контейнере или через carton. И если приложение давно уже написано как cgi то так и собирать его внутри одного контейнера apache + perl ?

What is carton?

спасибо. А я правильно думаю что базу данных лучше нативно в систему ставить? не в контейнере. Производительность лучше.

Ставьте зависимости тем способом, который удобен. Т.е. в Dockerfile вся сборка

Carton - Perl module dependency manager (aka Bundler for Perl)

спасибо. А я правильно думаю что базу данных лучше нативно в систему ставить? не в контейнере. Производительность лучше.

Нет, не важно. Главное, что это должен быть отдельный контейнер

Либо если масштабируетесь, то базы вынести вообще на отдельный узел

Т.е. в контейнере с апачем была ручка для задания "где лежит база"

Спасибо за помощь!

Добрый вечер. Есть связь между 2 контейнерами в 2 композ-файлах через external_link. Волнует вопрос: могу ли я как-то однозначно определить наименование контейнера А для использования его в контейнере Б в external_link?

Добрый вечер. Есть связь между 2 контейнерами в 2 композ-файлах через external_link. Волнует вопрос: могу ли я как-то однозначно определить наименование контейнера А для использования его в контейнере Б в external_link?

Да

Да

Поделитесь?

Ну, дока по докер компоуз

Вариантов три

1. container name 2. Alias 3. Зафиксировать айпи

Да, 3 можно сделать

1. container name 2. Alias 3. Зафиксировать айпи

1 не помог, нетворк у всех общий

1. Значит что-то делаете не так

1 не помог, нетворк у всех общий

Если есть связь между двумя контейнерами в двух разных docker-compose файлах через external_link то данный факт уже говорит о том что есть какой то однозначный способ общения между этими двумя контейнерами. Для однозначного определения имени контейнера используется директива (неожиданно) container_name для четкого указания имени контейнера и дальнейшего его использования в корыстных целях в одугих местах конфигурационного файла, можно попробовать указать его в external_link например, лично не проверял, но уверен что начать поиски лучше всего отсюда

Подскажите, как более правильно собирать контейнер для дев и прод окружения ? Например, в случае PHP, для дев разработки нужно установить xdebug и выключить opcache в конфигах, для прода xdebug не устанавливать и включить opcache Пока на ум приходит : 1. Перенос таких вот вещей в отдельный sh скрипт 2. Это будут совсем разные Dockerfile для прода и дев.

Подскажите, как более правильно собирать контейнер для дев и прод окружения ? Например, в случае PHP, для дев разработки нужно установить xdebug и выключить opcache в конфигах, для прода xdebug не устанавливать и включить opcache Пока на ум приходит : 1. Перенос таких вот вещей в отдельный sh скрипт 2. Это будут совсем разные Dockerfile для прода и дев.

Оба варианта возможны

Почему не сделать два докерфайла для прода и дева и не прописать пути к ним в зависимости от окружения?

Можно завести отдельный дев образ

И в from передавать что нужно

В дев образе есть xdebug и выключен opcache

Остальная-то часть сборки не отличается

Зачем копипастить

Можно один докерфпйл

Через arg передать dev/prod - на выходе два образа, с общими слоями

Не совсем удобно иногда, у тебя может быть 3 проекта на пыхе например

Где dev от prod отличается всегда одинаково

Опкешем и xdebug'ом