Спасибо! Расскажите, пожалуйста, подробнее о реализации на PHP: какую библиотеку выбрали и почему, наблюдали ли просадки по производительности, возможно есть пример трейсинга для PHP?
Скажите пожалуйста, а Вы не рассматривали возможность агрегации логов? Думаю Вам и Вашей команде было бы намного удобнее работать в браузере, через какой-нибудь ELK.
Скажите пожалуйста, а вы не рассматривали возможность агрегации логов? Думаю Вам и Вашей команде было бы намного удобнее работать в браузере, через какой-нибудь ELK.
Статья неоднозначна с первого взгляда — автор вызывает достаточно сомнительные впечатления, описывая вещи, которые уже давно приняты в мире Go с огромным негодованием.
Конечно, у языка, как и у любого другого есть свои проблемы.
Но я бы хотел обратить внимание на бизнес ценности. Язык — это только инструмент.
Golang дает достаточно высокую скорость разработки, отличную скорость работы и кросс-платформенную компиляцию. В комплекте с огромной стандартной библиотекой и большим комьюнити с екстеншенами — почти ничего не нужно писать с самого начала. Это тоже влияет на скорость разработки.
Резюмирую, как это все работает в моем маленьком мире:
1) Если нужно закрыть проблему бизнеса вот прямо сейчас, и мне не важна производительность — я выбираю Python.
2) Если есть долгоиграющая проблема, с кучей серверов и потребляемых мощностей, и есть немного времени — я выбираю Go.
Go — это скорее про микросервисы, чем про полноценный большой ентерпрайз бекенд.
Пример использования чаще всего выглядит так:
1) Микросервис на Go пакуется в Docker (который на Go написан)
2) Контейнер скейлится в парке из Kubernetes (который тоже на Go написан)
В конце хотелось бы сказать, что выбор инструмента — это не первоочередная проблема. Главное — это решить проблему бизнеса, желательно побыстрее и не дорого. Golang в этом — отличный помощник.
В целом инструмент достаточно понятен и прост — это очень хорошая тулза для систематизации и автоматизации действий на рабочей машине.
Например, задача — переключить окружение разработчика с php 7.0 на php 7.1. Это можно делать по старинке — написать bash скрипт, положите его в $PATH, и вызывать конкретно его. Или написать таску в bake.
Если задача одна — все хорошо. Если их несколько — появляются проблемы, например:
— как запомнить название всех баш скриптов
— как дистрибьютить и версионировать много баш скриптов
— как заморозить или откатить текущий набор баш скриптов
Все эти задачи успешно решает bake.
Еще примеры использования:
— пересборка проекта (grunt, composer, phinx)
— переключение окружений
— перезапуск чего-угодно (nginx, fpm, tomcat)
— кастомная автоматизация того, что вы используете
1. На github.com есть отличные примеры открытый ролей, где проводится тестирование конечного результата. Следует понимать, что универсальных решений не существует, то что подходит всем — может не подходить вам. Именно поэтому и была написана статья — оцените, что должна делать Ваша роль или плейбук — и протестируйте результат.
2. У нас построен глубокий CI для написания Configuration management, и тулзы которые Вы указали — там есть.
3. Конечно используем, т.к. мы деплоимся достаточно часто, и декларируем хорошее качество — у нас каждую ночь проходят глубокие регресионные тесты, с кастомными интеграциями типа: упал тест -> создается тикет в Jira.
4. Для Ansible мы используем Testinfra, для Chef — Inspec.
Самый минимальный тест — это unit, набор всех юнит тестов (порядка нескольких тысяч) выполняется секунды. Дальше по времени выполнения идут интеграционные и системные (их тоже много), выполняются около минуты.
Смоки делятся на 2 категории: Тестирование сборки и Приемочные тесты. У нас это выглядит как последовательный автоматизированный набор тест-кейсов, которые проходят примерно 30 минут. Если все ок — дальше заходят manual QA и нажимают кнопочки, прорабатывая не автоматизированные кейсы.
Самые длинные — это регресионные тесты (порядка нескольких часов). Это детальное тестирование всего, что должно работать в принципе.
Такой подход позволяет нам быть уверенными в релизе, и деливерить максимально качественный продукт за минимальные сроки :)
В недалеком прошлом приходилось работать с Windows стеком, программисты писали на C#, и автоматизация тоже была на PoweShell.
Правда это были не голые PowerShell скрипты — мы их использовали с PowerShell DRS:
https://blogs.technet.microsoft.com/privatecloud/2013/08/30/introducing-powershell-desired-state-configuration-dsc/
Если не ошибаюсь, PowerShell DRS работает через WinRM, наблюдали ли Вы там подобные проблемы?
Постараюсь ответить на Ваши вопросы:
1) К сожалению, метрику по количеству запросов в секунду мы не снимали, но могу сказать, что это сотни конекшнов (в зависимости от нагрузки), которые постоянно что-то пишут, или читают, или слушают канал. По идее, чтобы упереться в ограничение, связанное с IO, необходимо специально начудить (по делофту, если Redis is busy, он скипает операцию записи, и продолжает писать/читать).
2) Абсолютно правильно.
3) Используем форкнутый и допиленный Jedis — https://github.com/xetorthio/jedis
Реализация всех клиентов к кластеру Redis очень похожа: задается массив IP (у нас это Consul, который знает где какие редиски), и клиент загребает всю инфу про кластер с первой по списку рабочей ноды. И дальше, соответсвенно, работает уже со своей информацией о кластере.
На запрос существует таймаут (as you wish), а на нашем наборе данных (гигабайты в кластере) пересборка и промутинг занимает примерно 2 секунды.
Само собой, если это аффектит клиента — это маленький таймаут и ошибка типа «Ooops! Internal server error», если это процесс в бэкграунде — таймаут больше, и рестарт в случае таймаута.
Конечно.
Инициализируете переменную, в которую сохраняете значение хеша от команды 'CLUSTER SLOTS'.
Суть в том, чтобы на стороне апликейшна дождаться, когда пересоберется кластер (поменяется слотмапа), и продолжить работу, как ни в чем не бывало.
Если есть деньги, то Вы очень правильно выбрали. Aerospike — это очень хорошее продакшн решение.
Кстати, у них есть community edition — 1 инстанс Aerospike.
Отличная идея! Но есть нюанс: к примеру, из кластера вылетел мастер, а слейв (тот, который флашит на диск) стал мастером, и теперь он тормозит весь кластер :/
У редиса есть один юз кейс, про который очень часто забывают - в нем нельзя хранить мега важную инфу, потеря которой чревата (деньги, балансы, файлы, сообщения которые должны быть доставлены).
В нашем случае, если упадет один мастер и его реплика — у нас останется 66,6% данных, и самое худшее, что произойдет — юзера внезапно разлогинит. Кеши и разные другие штуки мы нагенерим, процессы перезапустим.
И еще момент — если у нас балансировка между ДЦ, мы наверное с ними подписывали контракты и гарантии SLA, и если оба ДЦ падают в одно время — наверное ничего работать не будет, не только редиски.
Абсолютно согласен, это было отличное решение в свое время. Нам не подошло из-за одного нюанса — латенси на чтении.
Если мы идем в редиску через прокси, или балансер — то теряем очень много времени на доступе по сети (сотни миллисекунд), это при том, что сам редис вычитывает у себя значение из мема за единицы миллисекунд.
Второй момент — на балансер переносится Single point of failure. Т.е. раньше было — падает редиска и ничего не работает, теперь стало — падает балансер и ничего не работает.
Получается, нужно докручивать дополнительную логику (keepalived, lvs etc.) — и опять же, учить клиентов.
В общем — получается очень дорого.
Тут новости:
t.me/devopsengineer
Тут работа 5к+:
t.me/devopsengineerwork
www.terraform.io/docs/providers/google/r/container_cluster.html
А вот кейс с описаниями примитивов k8s — очень спорное решение.
Конечно, у языка, как и у любого другого есть свои проблемы.
Но я бы хотел обратить внимание на бизнес ценности. Язык — это только инструмент.
Golang дает достаточно высокую скорость разработки, отличную скорость работы и кросс-платформенную компиляцию. В комплекте с огромной стандартной библиотекой и большим комьюнити с екстеншенами — почти ничего не нужно писать с самого начала. Это тоже влияет на скорость разработки.
Резюмирую, как это все работает в моем маленьком мире:
1) Если нужно закрыть проблему бизнеса вот прямо сейчас, и мне не важна производительность — я выбираю Python.
2) Если есть долгоиграющая проблема, с кучей серверов и потребляемых мощностей, и есть немного времени — я выбираю Go.
Go — это скорее про микросервисы, чем про полноценный большой ентерпрайз бекенд.
Пример использования чаще всего выглядит так:
1) Микросервис на Go пакуется в Docker (который на Go написан)
2) Контейнер скейлится в парке из Kubernetes (который тоже на Go написан)
В конце хотелось бы сказать, что выбор инструмента — это не первоочередная проблема. Главное — это решить проблему бизнеса, желательно побыстрее и не дорого. Golang в этом — отличный помощник.
Например, задача — переключить окружение разработчика с php 7.0 на php 7.1. Это можно делать по старинке — написать bash скрипт, положите его в $PATH, и вызывать конкретно его. Или написать таску в bake.
Если задача одна — все хорошо. Если их несколько — появляются проблемы, например:
— как запомнить название всех баш скриптов
— как дистрибьютить и версионировать много баш скриптов
— как заморозить или откатить текущий набор баш скриптов
Все эти задачи успешно решает bake.
Еще примеры использования:
— пересборка проекта (grunt, composer, phinx)
— переключение окружений
— перезапуск чего-угодно (nginx, fpm, tomcat)
— кастомная автоматизация того, что вы используете
В общем, спасибо за отличный инструмент!
2. У нас построен глубокий CI для написания Configuration management, и тулзы которые Вы указали — там есть.
3. Конечно используем, т.к. мы деплоимся достаточно часто, и декларируем хорошее качество — у нас каждую ночь проходят глубокие регресионные тесты, с кастомными интеграциями типа: упал тест -> создается тикет в Jira.
4. Для Ansible мы используем Testinfra, для Chef — Inspec.
Смоки делятся на 2 категории: Тестирование сборки и Приемочные тесты. У нас это выглядит как последовательный автоматизированный набор тест-кейсов, которые проходят примерно 30 минут. Если все ок — дальше заходят manual QA и нажимают кнопочки, прорабатывая не автоматизированные кейсы.
Самые длинные — это регресионные тесты (порядка нескольких часов). Это детальное тестирование всего, что должно работать в принципе.
Такой подход позволяет нам быть уверенными в релизе, и деливерить максимально качественный продукт за минимальные сроки :)
Правда это были не голые PowerShell скрипты — мы их использовали с PowerShell DRS:
https://blogs.technet.microsoft.com/privatecloud/2013/08/30/introducing-powershell-desired-state-configuration-dsc/
Если не ошибаюсь, PowerShell DRS работает через WinRM, наблюдали ли Вы там подобные проблемы?
1) К сожалению, метрику по количеству запросов в секунду мы не снимали, но могу сказать, что это сотни конекшнов (в зависимости от нагрузки), которые постоянно что-то пишут, или читают, или слушают канал. По идее, чтобы упереться в ограничение, связанное с IO, необходимо специально начудить (по делофту, если Redis is busy, он скипает операцию записи, и продолжает писать/читать).
2) Абсолютно правильно.
3) Используем форкнутый и допиленный Jedis — https://github.com/xetorthio/jedis
Реализация всех клиентов к кластеру Redis очень похожа: задается массив IP (у нас это Consul, который знает где какие редиски), и клиент загребает всю инфу про кластер с первой по списку рабочей ноды. И дальше, соответсвенно, работает уже со своей информацией о кластере.
Само собой, если это аффектит клиента — это маленький таймаут и ошибка типа «Ooops! Internal server error», если это процесс в бэкграунде — таймаут больше, и рестарт в случае таймаута.
Инициализируете переменную, в которую сохраняете значение хеша от команды 'CLUSTER SLOTS'.
Суть в том, чтобы на стороне апликейшна дождаться, когда пересоберется кластер (поменяется слотмапа), и продолжить работу, как ни в чем не бывало.
Кстати, у них есть community edition — 1 инстанс Aerospike.
У редиса есть один юз кейс, про который очень часто забывают - в нем нельзя хранить мега важную инфу, потеря которой чревата (деньги, балансы, файлы, сообщения которые должны быть доставлены).
В нашем случае, если упадет один мастер и его реплика — у нас останется 66,6% данных, и самое худшее, что произойдет — юзера внезапно разлогинит. Кеши и разные другие штуки мы нагенерим, процессы перезапустим.
И еще момент — если у нас балансировка между ДЦ, мы наверное с ними подписывали контракты и гарантии SLA, и если оба ДЦ падают в одно время — наверное ничего работать не будет, не только редиски.
Если мы идем в редиску через прокси, или балансер — то теряем очень много времени на доступе по сети (сотни миллисекунд), это при том, что сам редис вычитывает у себя значение из мема за единицы миллисекунд.
Второй момент — на балансер переносится Single point of failure. Т.е. раньше было — падает редиска и ничего не работает, теперь стало — падает балансер и ничего не работает.
Получается, нужно докручивать дополнительную логику (keepalived, lvs etc.) — и опять же, учить клиентов.
В общем — получается очень дорого.