Email or username:

Password:

Forgot your password?
Top-level
Andrey Pechorin

@bifik хотя бы не делайте авто, делайте по триггеру на событие. Мердж в мастер вызывает деплой. В таком духе.

17 comments
BiFiK

@pechorin docker-compose использую, со своими Dockerfile инструкциями для установки всего необходимого (меньше Run, больше минимализма).

Локально всё работает, а вот с деплоем - master ветка и обязательно тегирование версии и в git и в composer файле. Без этого не рассматриваю "автоматическое обновление до последней версии".

BiFiK

@pechorin хотя, можно еще будет продумать схему, при которой от master ветки необходимо будет создать стабильную версию release и только её разворачивать (как вариант). Так и master можно без труда обновлять для каких-то "бета версий прода"

Andrey Pechorin

@bifik честно говоря это все ты решаешь сам, если освоишь любой ci/cd продукт типа github actions, там выбираешь после какого события что случается (on: push /on: release). Думаю так оно в любой continuous integration / continuous delivery системе работает. Главное не уходить в каменный век, с git pull'ом и rebuild'ом на серваке по крону. Так можно и до заливки по ftp дойти. (точнее откатиться)

BiFiK

@pechorin ну обновлять 20+ файлов, загружая их по FTP (или SFTP) я уже подустал, поэтому и задумался о том, что бы централизовано подходить к обновлению своих проектов. Решение "для чего-то, что нельзя сделать на хостинге с php - буду думать про сборки и централизованное хранение образов с разворотом". Но мой принцип "выжимать из языка максимум, без подключений Reddis, Mongo, Rabbit или других ПО" - заставляет и учиться и пытаться максимально изучить язык.

Iron Bug
rsync это делает проще, но надо быть аккуратным с правами доступа и юзерами. иногда надо переписывать GID:PID для другой машины, чтобы не вышло криво и не появились уязвимости.
Andrey Pechorin

@iron_bug @bifik Человек дошел до того, чтобы как-то организовать нормальный процесс доставки и деплоя, а вы ему rsync советуете. Спасибо, не надо.

BiFiK

@pechorin @iron_bug не стоит ссориться. Я ищу "дешевые варианты", а потом, если не нашел их - ищу варианты дороже.

Настраивать CI\CD для проекта, где 1-10 пользователей, а так же туда добавлять Reddis или Memcache для кеширования - ну ок, могу. "есть ли в этом толк ?".

BiFiK

@pechorin @iron_bug можно сказать, что я понял ряд "дешевых вариантов", которые можно "реализовать уже сейчас", но так же понял несколько подходов, по которым мне стоит будет почитать документацию и изучить вопрос более точно. Ну и так же найти варианты применения для максимального уровня "производительности, удобства и простоты".

Andrey Pechorin

@bifik @iron_bug redis с одной d пишется, вы уж извините.

Iron Bug
испоьзование кэша, БД и прочего зависит от того, что твой софт делает и как он это делает, а не от количества пользователей. и да, на начальном этапе может быть 1-10 юзеров, а потом вдруг софт станет популярен и их могут стать миллионы. практичеки весь опенсорц писали "для себя", а теперь от некоторых библиотек или утилит зависит практическески всё.
а в вебе БД - это обычное дело. для мелких задач это обычно мускуль (сейчас он Maria DB в формате СПО). вопрос выбора инструментов для PHP чаще связан с софтом на хостингах. люди редко берут выделенный сервер, чтобы хостить там сайт/приложение на PHP. обычно это веб-хостинги. и обычно веб-хостинг предлагает готовый суповой набор софта: несколько версий PHP и БД в виде мускуля. есть даже аббревиатруа LAMP - Linux, Apache, MySQL, PHP. потому что это самая типичная конфигурация и её многие используют. для небольших задач с малой нагрузкой она вполне работает.
с Редисом есть вопросы, потому что они недавно поменяли лицензию и теперь от них многие отказываются. вопрос вкуса, конечно, но теперь это уже не СПО, а что-то ближе к проприетарщине. но, в принципе, разных NoSQL баз довольно много и все они однотипные. хотя они довольно редко нужны в вебе из-за своей специфики.
разные MQ - это уже не базы, это совсем другая вещь - очереди сообщений. но очереди тоже бывают нужны, правда, в вебе я их как-то не встречала. хотя в обычном сетевом софте они встречаются периодически.
что касается PHP, при грамотном использовании он самый быстрый и производительный, если сравнивать языки, на которых пишут веб. но надо уметь на нём писать. потому что наговнокодить на PHP можно ещё как, и будет работать стрёмно и жрать ресурсы. честно говоря, я гораздо чаще видела тех, кто на нём писать не умел :)
Memcache и вообще кэши - вещь хорошая, когда уже есть софт, какой-то workflow и надо его немного оптимизировать под существующую нагрузку. БД тоже имеют свои настраиваемые кэши для этой цели, там кроме кэша есть разные средства для структуризации хранения самих данных по времени и географии (сегменты, разделы, кластеры и прочее), можно грубоко погружаться. собственно БД решают задачу извлечения данных по запросу и там многое сделано для того, чтобы это работало быстро и оптимально. но для маленьких сайтов и небольшой нагрузки это из пушки по воробьям. зависит от объёмов данных, конечно. я много работала с high load и когда у тебя миллионы юзеров и огромные данные, приходится оптимизировать каждый чих, вплоть до системных вызовов и спинлоков. вот этим я и занимаюсь, чаще всего. но в маленьких приложениях это было бы преждевременной оптимизацией. хотя никто не мешает стремиться к идеалу и улучшать качество софта. я даже маленькие утилиты пищу оптимально. мало ли где и в каком количестве они могут использоваться. в вебе неплохо экономить работу сервера (за счёт кэша, например) и стараться уменьшать трафик. современный плохо написанный софт в вебе создаёт колоссальные нагрузки на сеть и серверы.
испоьзование кэша, БД и прочего зависит от того, что твой софт делает и как он это делает, а не от количества пользователей. и да, на начальном этапе может быть 1-10 юзеров, а потом вдруг софт станет популярен и их могут стать миллионы. практичеки весь опенсорц писали "для себя", а теперь от некоторых библиотек или утилит зависит практическески всё.
Iron Bug
пардон, и чем же "плох" rsync? используется повсеместно, никаких проблем с ним нет. не жирен, не жрёт лишние ресурсы. это стандартная утилита, можно сказать.
да, люди придумали много ненужных костылей, которые жрут ресурсы и требуют кучу времени. но нормальые простые инструменты вполне есть и они работают.
Andrey Pechorin

@bifik Имхо: кругозор надо расширять и понимать где и когда какое решение использовать, а убеждения аля

> "выжимать из языка максимум, без подключений Redis, Mongo, Rabbit или других ПО"

Это какие-то замашки того, кто не разобрался, либо задач не имел, где оно нужно. Ну так и не надо жить с ложными установками.

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

Но чем вам redis не угодил - вообще понять не могу, и как php его заменит тоже не понятно. Вроде в мире php все юзают memcache. Ну redis схож.
Или промежуточный кеш в файлах будете хранить? Да пожалуйста :) Так тоже можно. А если это не кеш, а что-то более?

Короче, хочу сказать, что ваше заявление про "мне ничего кроме php не нужно" — это конечно мощно, но тогда и от базы данных откажитесь, лишнее ПО жеж. Но вы его в списке не упомянули, и думаю не просто так.

А файлы по ftp - это 2000-ые. Надо двигаться дальше было, еще лет 10 назад.

@bifik Имхо: кругозор надо расширять и понимать где и когда какое решение использовать, а убеждения аля

> "выжимать из языка максимум, без подключений Redis, Mongo, Rabbit или других ПО"

Это какие-то замашки того, кто не разобрался, либо задач не имел, где оно нужно. Ну так и не надо жить с ложными установками.

BiFiK

@pechorin с разными Reddis, Rabbit, Memcache, MySQL, MongoDB я работал. Всегда смотрю на прототип и его ценность. Если не получается оптимизировать логику "кеша" и всё равно "глючит", то ищу способы вначале локально, а потом думаю про подключение Reddis или Memcache.

Сталкиваю по работе с ситуациями, когда не хотят "изучать проблему", а "перекрывают проблему добавлением нового компонента".

Iron Bug
да, часто люди не хотят думать головой и решают микроскопические задачки какими-то совершенно не предназначенными для этого средствами. добавление нового софта на прод - это всегда расширение горизонта уязвимостей и усложнение поддержки, это лишний расход ресурсов сервера, а также усложнение разработки, потому что она становится зависимой от кучи внешних факторов, которые не имеют никакой связи с бизнес-процессами, но требуют от разработчиков и админов время и постоянную работу из-за апдейтов левого софта. только ты выпустил стабильный релиз, как уже протухли все зависимости и "мы обновили наши API и они стали несовместимыми с предыдущими версиями, перепишите весь ваш софт заново, потому что мы такие прогрессивные". поэтому чем меньше всякого УГ втащено в проект - тем легче его поддерживать и деплоить.
опять же, про деплой: не все и не всегда могут/хотят себе позволить ставить к себе на сервер разный непонятный и потенциально небезопасный софт. поэтому увеличение количества лишних зависимостей уменьшает возможное количество пользователей/клиентов. тоже вещь, которую нужно иметь в виду. чем меньше твой софт требует - тем проще его установить и с ним работать. также не надо гнаться за самым модным и современным, потому что на серверы никто не ставит новый софт. все ждут, когда там найдут и устранят все баги и уяззвимости. поэтому отсутствие жёстких зависимостей от каких-то версий софта - тоже хорошее свойство. и особенно это важно для PHP, в котором версии самого пыха на серверах могут быть довольно древними. потому что у людей есть легаси софт и просто некогда всё обновлять.
да, часто люди не хотят думать головой и решают микроскопические задачки какими-то совершенно не предназначенными для этого средствами. добавление нового софта на прод - это всегда расширение горизонта уязвимостей и усложнение поддержки, это лишний расход ресурсов сервера, а также усложнение разработки, потому что она становится зависимой от кучи внешних факторов, которые не имеют никакой связи с бизнес-процессами, но требуют от разработчиков и админов время и постоянную работу из-за апдейтов левого...
Iron Bug
насчёт "надо двигаться дальше" - скажу, что это не так, в общем случае.
если инструмент тебя устраивает, если он работает и работает достаточно эффективно, никуда "двигаться" не нужно.
современная чесотка обновляторства пока привела к тому, что самые простейшие задачи, которые можно решить rsync'ом или через стандартные cgroups, решаются каким-то монстрозным левым софтом, который жрёт ресурсы и плодит уязвимости.
не надо тащить ничего лишнего в прод. не надо без необходимости плодить сушности - бритва Оккама.
насчёт "надо двигаться дальше" - скажу, что это не так, в общем случае.
если инструмент тебя устраивает, если он работает и работает достаточно эффективно, никуда "двигаться" не нужно.
современная чесотка обновляторства пока привела к тому, что самые простейшие задачи, которые можно решить rsync'ом или через стандартные cgroups, решаются каким-то монстрозным левым софтом, который жрёт ресурсы и плодит уязвимости.
Iron Bug
насчёт "кругозора" тут тоже всё непросто.
часто за "кругозор" выдают зашоренность мозгов маркетинговым шлаком. а заодно прикрывают банальное неумение пользоваться простыми консольными утилитами.
крупные копрорасты создают монстрозный софт для своего внутреннего использования. с миллионами серверов это может быть оправданно. а может, и нет, кстати. потом этот софт попадает в общий доступ. маганеры кричат "мы - за передовые технологии, посмотрите, как решает задачи гугл!". обезьянки ведутся и ставят к себе на сервер монстозный софт от гугла, для управления своим сайтиком на полторы странички. сервер делает "кряк". всё тормозит, юзеры недовольны. а потом и вовсе случается какой-нибудь внезапный политический абзац и копрорасты перекрывают доступ к своим сервисам/софту и всё встаёт раком. мы это наблюдали массово в последние годы. зато "передовые техологии", ага.
плюсы софта десяти-, а то двадцатилетней давности в том, что он просто работает. вот работает и всё, ему ничего не нужно. никакие апдейты, никакие сомнительные "улучшения". он уже давно оптимизирован и отлажен. такой софт есть и это очень хорошо. нет ничего плохого в том, что софт не обновляется, если это не нужно. важно это понимать. а вот если софт постоянно обновляется и меняется - с большой вероятностью, это очень плохой софт и у него глупые, непутёвые разработчики, которые не знают, чего хотят, и не могут написать нормально с одного раза. поэтому в нём полно багов и уязвимостей и он нуждается в постоянных правках и дописках.
насчёт "кругозора" тут тоже всё непросто.
часто за "кругозор" выдают зашоренность мозгов маркетинговым шлаком. а заодно прикрывают банальное неумение пользоваться простыми консольными утилитами.
крупные копрорасты создают монстрозный софт для своего внутреннего использования. с миллионами серверов это может быть оправданно. а может, и нет, кстати. потом этот софт попадает в общий доступ. маганеры...
Iron Bug
деплой - это вопрос пользователя. можно уведомить пользователя, что вышла новая версия, с такими-то фичами/багфиксами. но решать вопрос, когда апдейтиться, должен админ того сервера, на котором развёрнут софт. сверху и само по себе ничего апдейтиться не должно. это плохая практика.
Go Up