Что такое — вертикальное масштабирование? Подозреваю, что это покупка более дорогой редакции. Если, да — то нет, не помогло.
Лапшекод не способен быстро работать в принципе
Работаю в крупной компании, которая начинала с Битрикса, и ушла от него. Причина банальная — дикие тормоза. По мере роста приложения. Когда число клиентов стало исчисляться десятками тысяч — Битрикс лёг. И это всё что надо о нем знать.
Кирилл, ты умничка, каких мало. Не ирония. Как ястреба видать по полету, так умного квалифицированного человека видно по его ответам на неожиданные вопросы. Ты отвечал четко, эрудированно, грамотно. Мне до твоего уровня очень далеко.
Но, умный, квалифицированный чел !== квалифицированный докладчик. Без, обид, пожалуйста. Это тебе в плане на будущее. Акцентируйся, не пытайся объять необъятное.
Не умею нормальные концовки делать
Кирилл, вот хоть режь меня, не поверю, что тебе незнакомо понятие Резюме
Вот ответы на вопросы, это единственное, что было интересно послушать.
В докладе будут разбираться типовые проблемы «оверинжинеринга» и «велосипедостроения».
Технологии, которые в одних задачах аргументированы, а в других — только навредят.
Как выбрать тот путь, который подходит под задачу и как развивать свой опыт разработчика.
…
Митап будет полезен разработчикам… всем, для кого программирование является частью жизни.
Где здесь light? Вполне себе интересные, дискуссионные вопросы. Это было первое.
Второе: любой доклад, любое выступление, любая статья должны завершаться кратким резюме, в котором автор подводит итоги, и еще раз четко формулирует свой позыв, который он хотел донести до аудитории. А не так: всё — конец :(
Но, это моё, сугубо личное мнение, которое я никому не навязываю.
Ребята, митап был ни о чем. От слова совсем. Вам, как организаторам огромный респект, спикеру минус в карму. То, что я услышал, возможно было бы мне интересно в начале изучения php. Но, на митап пришли, в основном, люди, судя по вопросам, которые в теме. И, откровения спикера, о том, что надо читать документацию, и что есть общепринятые заблуждения были ни о чем.
В Linux xdebug.remote_connect_back чудесно работает! Не нужно ничего отдельно резолвить.
Все так, но не в консоли. Если не нужно дебажить консольные скрипты, то при включенной директиве xdebug.remote_connect_back, директива xdebug.remote_host будет проигнорирована
Конкретно в вашем случае: php-cli работает от рута. Вы заходите и делаете Composer update, например. Он начнет ругаться, и правильно, с моей точки зрения, что композер под рутом запускать крайне не рекомендуется. Это первое.
Второе: вы заходите в php-cli контейнер, и создаете из консоли, какой-либо файл, например, файл миграции. Кто будет его владельцем? Суперпользователь root.
Сможете вы с этим файлом просто так работать, когда вернетесь на машину хоста? Нет. Вам придется делать лишние движения
Digital Ocean один из лучших, с этим не поспоришь. Но, есть одно маленькое но — часть его ip адресов находится в черном списке Роскомнадзора. И с первого раза может не повезти. Страшного в этом ничего нет. Удаляем дроплет, создаем по новой, и так до тех пор, пока сервер не начнет откликаться. Проблема в другом: вступил в действие, как писали, здесь, на хабре, т.н. закон Яровой, и будет ли у нас завтра доступ к зарубежным серверам, богу весть.
Отличный и очень познавательный пример. Очень. Спасибо огромное. Может тогда подскажешь (убедительно прошу: давай перейдем на ты) — как оптимально масштабировать твой пример на несколько проектов? С твоей точки зрения? У меня пока просто тупая мысль — прописывать отдельно php-fpm, и php-cli для каждого проекта.
Поигрался я с вашим рецептом, в принципе всё написано верно. Но, давайте конкретизируем задачу, о которой речь идет в статье.
Для контейнеров на образе php-fpm необходимо изменить права доступа таким образом, чтобы мы могли заходить в эти контейнеры, и создавать файлы с правами, которые должны совпадать с правами текущего пользователя.
Важно: в таком контейнере уже есть пользователь www-data, от имени которого и работает демон php-fpm.
Что произойдет, если использовать ваш рецепт в данном конкретном случае? Контейнер запустится от имени суперпользователя root, после запуска отработает docker-php-entrypoint, будет создан пользователь hostuser c нужными правами, и php-fpm попытается запуститься от имени этого пользователя, и вылетит с ошибкой. Данный процесс, php-fpm, может запустить только пользователь www-data. Можно конечно как-то подшаманить, но зачем?
Проще просто передать uid и gid текущего пользователя в докерфайл, и использовать RUN usermod -u ${USER_ID} www-data && groupmod -g ${GROUP_ID} www-data при сборке. Т.е. не жестко приколачивать гвоздями uid и gid в докерфайле, как у меня, сейчас в статье, а передать их извне.
Спасибо за развернутый ответ. У нас немного разные задачи, и разные, соответственно, подходы. В нашей компании, на сейчас, 6 боевых проектов, и их никогда не будет много. И нам проще делать так, как написано в статье. Но, у вас очень интересный подход. Спасибо еще раз. Для полного ответа мне не хватает квалификации. Буду думать, учиться.
Огромное спасибо за комментарий, обязательно покручу ваше решение.
А чем 777 на ассеты и кеш не устраивают? По моему это хуже чем когда владельцем файлов с кодом является пользователь для запуска веб-сервера. Это гораздо более опасно. Из каталогов с ассетами и кешем просто выполнение php запретить и всё.
Почему не устраивает. Все устраивает кроме одного: вот мы зашли в контейнер, и создали миграцию, или иной файл, находясь в контейнере. И от того, что на нужные папки у нас стоят права 777, нам легче не станет. Если не шаманить с правами, то владельцем этого файла будет суперпользователь root, и когда мы вернемся на машину хоста, то нам придется совершать определенные действия, чтобы работать с такими файлами.
Спасибо за комментарий. Сколько людей, столько и мнений. Нашу команду, пока всё устраивает в плане удобства. А по правам доступа — я же честно написал в статье, что это костыль. Можно вообще с ними не заморачиваться, дать 777 на файлы с кешем, папку assets и т.д.
И все будет читаться и писаться.
Но композер, например, ругается на работу под рутом. Все миграции, или иные файлы, которые вы создадите, когда зайдете в контейнер, будут принадлежать не вам, что очень неудобно. Так, что я пока работаю с костылем для решения проблемы прав доступа.
Спасибо за комментарий. Есть только одно маленькое но: наши контейнеры ничего не знают о пользователе от имени которого мы их пытаемся запустить. И также мне, лично, не надо запускать все контейнеры от имени текущего пользователя. Мне нужно запустить только контейнеры с php-fpm
Лапшекод не способен быстро работать в принципе
Но, умный, квалифицированный чел !== квалифицированный докладчик. Без, обид, пожалуйста. Это тебе в плане на будущее. Акцентируйся, не пытайся объять необъятное.
Кирилл, вот хоть режь меня, не поверю, что тебе незнакомо понятие Резюме
Где здесь light? Вполне себе интересные, дискуссионные вопросы. Это было первое.
Второе: любой доклад, любое выступление, любая статья должны завершаться кратким резюме, в котором автор подводит итоги, и еще раз четко формулирует свой позыв, который он хотел донести до аудитории. А не так: всё — конец :(
Но, это моё, сугубо личное мнение, которое я никому не навязываю.
Все так, но не в консоли. Если не нужно дебажить консольные скрипты, то при включенной директиве xdebug.remote_connect_back, директива xdebug.remote_host будет проигнорирована
Второе: вы заходите в php-cli контейнер, и создаете из консоли, какой-либо файл, например, файл миграции. Кто будет его владельцем? Суперпользователь root.
Сможете вы с этим файлом просто так работать, когда вернетесь на машину хоста? Нет. Вам придется делать лишние движения
Чем не устраивает простое
У меня баш ругался на нее. Хотя и работал.
Для контейнеров на образе php-fpm необходимо изменить права доступа таким образом, чтобы мы могли заходить в эти контейнеры, и создавать файлы с правами, которые должны совпадать с правами текущего пользователя.
Важно: в таком контейнере уже есть пользователь www-data, от имени которого и работает демон php-fpm.
Что произойдет, если использовать ваш рецепт в данном конкретном случае? Контейнер запустится от имени суперпользователя root, после запуска отработает docker-php-entrypoint, будет создан пользователь hostuser c нужными правами, и php-fpm попытается запуститься от имени этого пользователя, и вылетит с ошибкой. Данный процесс, php-fpm, может запустить только пользователь www-data. Можно конечно как-то подшаманить, но зачем?
Проще просто передать uid и gid текущего пользователя в докерфайл, и использовать
RUN usermod -u ${USER_ID} www-data && groupmod -g ${GROUP_ID} www-dataпри сборке. Т.е. не жестко приколачивать гвоздями uid и gid в докерфайле, как у меня, сейчас в статье, а передать их извне.Почему не устраивает. Все устраивает кроме одного: вот мы зашли в контейнер, и создали миграцию, или иной файл, находясь в контейнере. И от того, что на нужные папки у нас стоят права 777, нам легче не станет. Если не шаманить с правами, то владельцем этого файла будет суперпользователь root, и когда мы вернемся на машину хоста, то нам придется совершать определенные действия, чтобы работать с такими файлами.
И все будет читаться и писаться.
Но композер, например, ругается на работу под рутом. Все миграции, или иные файлы, которые вы создадите, когда зайдете в контейнер, будут принадлежать не вам, что очень неудобно. Так, что я пока работаю с костылем для решения проблемы прав доступа.