Привет Антон :) Именно поэтому и было интересно посмотреть на бенчи указанного в посте решения под соусом RR. Кстати, дополню про "20 до 80 процентов" — это именно на "тяжелых" endpoints, условно-статичные (ping, static view) просто уходят в космос по сравнению с традиционным nginx+fpm.
В сторону Spiral пока лишь присматриваюсь, но и этот проект кажется очень интересным, обязательно что-нибудь на его основе сделаем.
Тоже странно, почему нет RR в сравнении. Используем его в проде уже более полу-года (все php-приложения перевели на работу с ним, забыв про nginx+fpm) — полёт нормальный. Кстати, он довольно легко интегрируется с тем же Laravel, для чего написал и поддерживаю пакет avto-dev/roadrunner-laravel. По нашим тестам буст производительности (очень многое зависит от самих приложений) составил от 20 до 80 процентов.
PHP постоянно развивается, и только что мир увидело их последнее обновление — PHP 7.4.
Предварительная загрузка — одно из самых ярких обновлений. Эта возможность позволяет значительно ускорить выполнение скрипта и делает код чище и быстрее ...
К сожалению, он является дополнительной зависимостью, что должна быть на тачке каждого разработчика, а make с 99% вероятностью уже стоит "по умолчанию".
Но yaml читать многократно удобнее, тут спорить сложно. В сторону таскера посмотрю тоже обязательно, быть может зайдет созданием скрипта с именем ./task с примерным содержанием docker run --rm -v "$(pwd):/rootfs" -w '/rootfs' task:image $@
Начинал тоже с набора скриптов в директории ./bin, но когда их стало больше 10 — начал искать альтернативу, и ей стал как раз Makefile. Надо лишь чуть "въехать" в его синтаксис, и после этого дальнейшую разработку без него представить уже становится сложно.
Один из примеров того как можно его использовать можно найти тут (golang проект-болванка).
Ах да, ещё и документирование поддерживаемых целей возможна таким способом:
.DEFAULT_GOAL : help
# This will output the help for each task. thanks to https://marmelab.com/blog/2016/02/29/auto-documented-makefile.html
help: ## Show this help
@printf "\033[33m%s:\033[0m\n" 'Available commands'
@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {printf " \033[32m%-14s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
Статья написана здорово, читается легко, но её содержимое (мягко говоря) отталкивает. Складывается стойкое убеждение что решаете проблему не с той стороны — не дроблением монолита на сервисы с независимым деплоем каждого по отдельности по мере необходимости на, скажем, k8s, а пытаетесь закостылять то "что есть", выдавая это за некоторое подобие инновации и "мы разработали деплой кит".
Вот бы статейку о том, как молит дробили, да под каждый конкретный сервис подбирали наиболее подходящий язык/службу/идею — вот этому цены бы не было
Из архива берем rclone.exe и кидаем в корень c:\ (сугубо для удобства);
Открываем cmd, выполняем:
cd /d c:\
rclone.exe config
No remotes found - make a new one
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n
name> yandex
client_id>
client_secret>
Remote config
Use auto config?
* Say Y if not sure
* Say N if you are working on a remote or headless machine
y) Yes
n) No
y/n> y
# Открывается окно браузера, в котором вводим логин:пароль от учетки ЯД
Waiting for code...
Got code
--------------------
[yandex]
client_id =
client_secret =
token = {"access_token":"AQA...OuQ","token_type":"bearer","expiry":"2017-07-13T18:27:46.7501402+05:00"}
--------------------
y) Yes this is OK
e) Edit this remote
d) Delete this remote
y/e/d> y
Current remotes:
Name Type
==== ====
yandex yandex
e) Edit existing remote
n) New remote
d) Delete remote
s) Set configuration password
q) Quit config
e/n/d/s/q> q
rclone.exe --help
# Смотрим строку --config string Config file. (default "C:\\Users\\USERNAME/.rclone.conf")
type C:\Users\USERNAME\.rclone.conf
[yandex]
type = yandex
client_id =
client_secret =
token = {"access_token":"AQA...OuQ","token_type":"bearer","expiry":"2017-07-13T18:27:46.750140+05:00"}
Тот самый конфиг, что был выведен крайней командой нежно копируем в буфер, возвращаемся на сервер, на котором выполняем (я делал под рутом):
$ rclone --help 2>&1 | grep -e '--config'
--config string Config file. (default "/root/.rclone.conf")
# создаем конфиг по указанному пути и вставляем в него содержимое конфига с десктопа:
$ nano /root/.rclone.conf
# Проверяем
$ rclone lsd yandex:
# Создаем директорию для бэкапов, например
$ rclone mkdir yandex:backups
# И заливаем в неё (синхронизируем содержимое локального каталога с директорией в облаке):
$ rclone sync /var/backups yandex:backups
Проверяем содержимое в веб-морде ЯД, опционально — ставим крайнюю команду в крон
# Синхронизация файлов на локальной машине и в хранилище
$ rclone sync /home/local/directory selectel:[имя контейнера]
# Синхронизация файлов в хранилище с файлами на локальной машине
$ rclone selectel:[имя контейнера] sync /home/local/directory
Небольшие, но важные поправки:
$ rclone sync selectel:[имя контейнера] /home/local/directory — потрет всё содержимое /home/local/directory, если директория в облаке пустая
Синхронизация локального каталога с облаком выполняется по команде $ rclone sync /home/local/directory selectel:[имя контейнера] — у вас ошибка в порядке аргументов
А он умеет заменять без ручного допила привычный sendmail так, что этого не замечают ни консольные приложения, ни веб-скрипты, да с возможностью использования разных аккаунтов для разных виртуальных серверов без перенастройки оных?
То что нашлось — это DLL injection на уже скомпрометированной машине с авторизованным keepass и MitM во время обновления софтины что, разумеется, не приятно, но врятли можно назвать причиной отказа от использования
Не так давно сам пользуюсь KeepAss, и в качестве хранилища БД использую nginx + webdav (благо он уже умеет его из коробки после простого apt-get install nginx) + ssl + auth basic. В итоге необходимо держать в голове uri + basic login/pass + master pass, но параноик внутри меня чувствует себя спокойнее, и доступ к данным есть отовсюду (благо клиентов полно под все платформы, и даже простой web-access). То, что шарить её при необходимости, а так же ограничивать доступ (с помощью того же auth basic) не составляет проблемы уточнять не приходится. В качестве дополнительных мер можно ограничить доступ по IP и проверять User-Agent (да, keepass умеет выставлять нужный user-agent при подключении).
Дополнительно он всегда есть в бэкапе. Из минусов — сохраняется база в ~15Mb порядка 15 секунд, но это не кажется критичным
На днях решал аналогичную задачу, но столкнулся с одним очень неприятным багом версии 1.4.32 (что на этот момент в репозиторий epel под CentOS 7) — неизменяемое поле Sender — всегда выставлялось MAILER-DAEMON, игнорируя любые указания в конфигах — вот хоть ты тресни. Собрав же ручками его из исходников (1.6.5), всё стало работать как надо. Если кто-то столкнется с аналогичной проблемой — вот тут накидал небольшой пост по его сборке и настройке, как раз — тоже на Яндекс.
Привет Антон :) Именно поэтому и было интересно посмотреть на бенчи указанного в посте решения под соусом RR. Кстати, дополню про "20 до 80 процентов" — это именно на "тяжелых" endpoints, условно-статичные (ping, static view) просто уходят в космос по сравнению с традиционным nginx+fpm.
В сторону Spiral пока лишь присматриваюсь, но и этот проект кажется очень интересным, обязательно что-нибудь на его основе сделаем.
Тоже странно, почему нет RR в сравнении. Используем его в проде уже более полу-года (все php-приложения перевели на работу с ним, забыв про nginx+fpm) — полёт нормальный. Кстати, он довольно легко интегрируется с тем же Laravel, для чего написал и поддерживаю пакет avto-dev/roadrunner-laravel. По нашим тестам буст производительности (очень многое зависит от самих приложений) составил от 20 до 80 процентов.
Чище?
К сожалению, он является дополнительной зависимостью, что должна быть на тачке каждого разработчика, а
makeс 99% вероятностью уже стоит "по умолчанию".Но
yamlчитать многократно удобнее, тут спорить сложно. В сторону таскера посмотрю тоже обязательно, быть может зайдет созданием скрипта с именем./taskс примерным содержаниемdocker run --rm -v "$(pwd):/rootfs" -w '/rootfs' task:image $@Начинал тоже с набора скриптов в директории
./bin, но когда их стало больше 10 — начал искать альтернативу, и ей стал как разMakefile. Надо лишь чуть "въехать" в его синтаксис, и после этого дальнейшую разработку без него представить уже становится сложно.Один из примеров того как можно его использовать можно найти тут (golang проект-болванка).
Ах да, ещё и документирование поддерживаемых целей возможна таким способом:
Статья написана здорово, читается легко, но её содержимое (мягко говоря) отталкивает. Складывается стойкое убеждение что решаете проблему не с той стороны — не дроблением монолита на сервисы с независимым деплоем каждого по отдельности по мере необходимости на, скажем, k8s, а пытаетесь закостылять то "что есть", выдавая это за некоторое подобие инновации и "мы разработали деплой кит".
Вот бы статейку о том, как молит дробили, да под каждый конкретный сервис подбирали наиболее подходящий язык/службу/идею — вот этому цены бы не было
rclone.exeи кидаем в корень c:\ (сугубо для удобства);Небольшие, но важные поправки:
$ rclone sync selectel:[имя контейнера] /home/local/directory— потрет всё содержимое /home/local/directory, если директория в облаке пустая$ rclone sync /home/local/directory selectel:[имя контейнера]— у вас ошибка в порядке аргументовСпасибо за пост, только вот подружить rclone с Yandex.Disk не пытались?
Принято, спасибо!
А он умеет заменять без ручного допила привычный sendmail так, что этого не замечают ни консольные приложения, ни веб-скрипты, да с возможностью использования разных аккаунтов для разных виртуальных серверов без перенастройки оных?
Эвоно как, и кликать на них в поле описания записи, а не вызывать по хоткею? Спасибо!
Одна из самых удобных "фич" — это хоткей
ctrl + uдля открытия уже авторизованного терминала. Как в таком случаете вы используете winscp?То что нашлось — это DLL injection на уже скомпрометированной машине с авторизованным keepass и MitM во время обновления софтины что, разумеется, не приятно, но врятли можно назвать причиной отказа от использования
Можно ли чуть подробнее о взломах и дырах?
Не так давно сам пользуюсь KeepAss, и в качестве хранилища БД использую nginx + webdav (благо он уже умеет его из коробки после простого
apt-get install nginx) + ssl + auth basic. В итоге необходимо держать в голове uri + basic login/pass + master pass, но параноик внутри меня чувствует себя спокойнее, и доступ к данным есть отовсюду (благо клиентов полно под все платформы, и даже простой web-access). То, что шарить её при необходимости, а так же ограничивать доступ (с помощью того же auth basic) не составляет проблемы уточнять не приходится. В качестве дополнительных мер можно ограничить доступ по IP и проверять User-Agent (да, keepass умеет выставлять нужный user-agent при подключении).Дополнительно он всегда есть в бэкапе. Из минусов — сохраняется база в ~15Mb порядка 15 секунд, но это не кажется критичным
На днях решал аналогичную задачу, но столкнулся с одним очень неприятным багом версии 1.4.32 (что на этот момент в репозиторий epel под CentOS 7) — неизменяемое поле Sender — всегда выставлялось
MAILER-DAEMON, игнорируя любые указания в конфигах — вот хоть ты тресни. Собрав же ручками его из исходников (1.6.5), всё стало работать как надо. Если кто-то столкнется с аналогичной проблемой — вот тут накидал небольшой пост по его сборке и настройке, как раз — тоже на Яндекс.msmtp откуда (какой репозиторий) ставили, и какой версии встал? Или ручками собирали?