Ну приходите к нам работать )), мы как раз помогаем сделать так, чтобы всем было что кушать (Центр развития финансовых технологий РСХБ). Можно прямо из деревни, главное, чтобы интернет был.
В теории все должно работать, особенно если не устраивать конфликты с одновременным редактированием файла в разных местах. Приложения работают на уровне файловой системы, скорее всего через хуки. Но лично не пробовал, если кто пробовал, напишите.
Насчет github/gitlab решайте сами, пока они решили ничего не делать с нами. Видел комментарий от разработчика из Крыма, в 2014 github блокировал учетки при заходе с крымcких ip-адресов.
Товарищ iig выше предлагает nagios. А что Вы по этому поводу думаете? ))
Если серьёзно, отсутствие мук выбора системы мониторинга — одна из причин.
Минимальное и полностью контролируемое решение — вторая.
Полдня, потраченные на скрипт, я бы потратил и разбираясь с nagios/zabbix.
Если умеете в zabbix — наверное, проще использовать его.
Я не ратую за это решение vs полноценные системы мониторинга, у каждого есть своя ниша.
Имелась в виду, конечно, папка на сервере, где будет работать скрипт. Поправил текст статьи. Если права на файловой системе нормально настроены, то это более-менее безопасно. Или переменные окружения имеют какое-то преимущество?
Насчет внешних хранилищ — есть встроенные типа gnome keyring, но там требуется мастер-пароль, который тоже нужно где-то хранить…
Скорее, самокат ). Статья про то, как сделать мониторинг «на коленке» — быстро и минимальными средствами. Я не позиционирую это как альтернативу Zabbix/Nagios. ))
Если использовать для мониторинга сайтов, то да. У нас основной кейс был мониторинг сервиса — то есть отправить эталонный json, сравнить ответ c ожидаемым.
Чтобы проверять только код ответа, можно задать в google.ini:
Да, но одно другое не заменяет: контрактные тесты проверяют договорённости между командами, а интеграционные — реализацию этих договорённостей. И в этом смысле интеграционные тесты действительно «лучше» — так как они проверяют реализацию.
Посмотрите в статье из ссылок — Хэм Фокке. Пирамида тестов на практике: прямо над разделом «Контрактные тесты» идёт абзац про проблемы интеграционных тестов.
Если кратко — интеграционные тесты сложнее и дороже проводить, поэтому их запускают после контрактных.
Минимизация time-to-market означает, что мы должны иметь релизный цикл с короткими итерациями и возможность выпускать отдельные фичи независимо друг от друга. Т.е.:
— Быстро тестировать.
— Быстро выкатывать новые версии.
— Быстро обнаруживать и исправлять проблемы после выкатки.
— Разделить систему на много независимо поставляемых приложений.
Мы движемся в направлении микросервисной архитектуры, которая и позволяет реализовать все эти задачи.
Она хорошо подходит при масштабах Сбербанка. Только над фронт-офисными приложениями у нас работают сотни команд.
По микросервисам рекомендую изучить статью Фаулера: martinfowler.com/articles/microservices.html или ее перевод: habr.com/post/249183
Микросервисный подход отлично ложится и на новую организационную структуру, построенную на принципах agile.
В частности, этим летом централизованную эксплуатацию разнесли по agile-командам.
Тем самым, созданы предпосылки для построения devops-культуры, которая необходима для успешной эксплуатации микросервисов.
Важными моментами для независимого выпуска фич являются:
— Обратная совместимость на уровне API. Обеспечить ее помогают такие шаблоны проектирования, как Consumer Driven Contracts martinfowler.com/articles/consumerDrivenContracts.html
и Tolerant Reader martinfowler.com/bliki/TolerantReader.html
— Возможность включения/выключения отдельных фич (или старой и новой версий фичи) в рамках одного приложения. Тут помогает шаблон Feature Toggle (https://martinfowler.com/bliki/FeatureToggle.html).
Разумеется, помимо этого, есть огромный пласт работ, которые сделаны или делаются для обеспечения эксплуатации микросервисов:
— Внедрение контейнеризации. Сейчас пилотируется OpenShift.
— Devops pipelines.
— Автотесты, в том числе тесты API на совместимость.
— Разрабатывается собственный API gateway на основе nginx.
— Централизованное логирование с возможность находить логи в рамках одного запроса по correlation token.
— Различные механизмы защиты от отказов, например, квотирование в разрезе потребителей сервиса. Другой пример — аналог hystrix для защиты от каскадных отказов. По hystrix рекомендую почитать medium.com/netflix-techblog/fault-tolerance-in-a-high-volume-distributed-system-91ab4faae74a
— Многое-многое другое…
Спасибо, поправил
У нас есть redmine, он, конечно, похуже jira. В статье я привел в основном облачные сервисы, так как для on-premise пока что все проще.
Пробовал. Не совсем аналог - непривычный интерфейс, не похож на Trello.
Ну приходите к нам работать )), мы как раз помогаем сделать так, чтобы всем было что кушать (Центр развития финансовых технологий РСХБ). Можно прямо из деревни, главное, чтобы интернет был.
В теории все должно работать, особенно если не устраивать конфликты с одновременным редактированием файла в разных местах. Приложения работают на уровне файловой системы, скорее всего через хуки. Но лично не пробовал, если кто пробовал, напишите.
Насчет github/gitlab решайте сами, пока они решили ничего не делать с нами. Видел комментарий от разработчика из Крыма, в 2014 github блокировал учетки при заходе с крымcких ip-адресов.
Предложите свои альтернативы, я пишу все.
Согласен, у многих есть такие потребности. Но это тема для отдельной статьи, сейчас не готов за нее взяться.
Не нашел подтверждения по youtrack, есть пруф?
Если серьёзно, отсутствие мук выбора системы мониторинга — одна из причин.
Минимальное и полностью контролируемое решение — вторая.
Полдня, потраченные на скрипт, я бы потратил и разбираясь с nagios/zabbix.
Если умеете в zabbix — наверное, проще использовать его.
Я не ратую за это решение vs полноценные системы мониторинга, у каждого есть своя ниша.
Насчет внешних хранилищ — есть встроенные типа gnome keyring, но там требуется мастер-пароль, который тоже нужно где-то хранить…
Чтобы проверять только код ответа, можно задать в google.ini:
Посмотрите в статье из ссылок — Хэм Фокке. Пирамида тестов на практике: прямо над разделом «Контрактные тесты» идёт абзац про проблемы интеграционных тестов.
Если кратко — интеграционные тесты сложнее и дороже проводить, поэтому их запускают после контрактных.
Минимизация time-to-market означает, что мы должны иметь релизный цикл с короткими итерациями и возможность выпускать отдельные фичи независимо друг от друга. Т.е.:
— Быстро тестировать.
— Быстро выкатывать новые версии.
— Быстро обнаруживать и исправлять проблемы после выкатки.
— Разделить систему на много независимо поставляемых приложений.
Мы движемся в направлении микросервисной архитектуры, которая и позволяет реализовать все эти задачи.
Она хорошо подходит при масштабах Сбербанка. Только над фронт-офисными приложениями у нас работают сотни команд.
По микросервисам рекомендую изучить статью Фаулера: martinfowler.com/articles/microservices.html или ее перевод: habr.com/post/249183
Микросервисный подход отлично ложится и на новую организационную структуру, построенную на принципах agile.
В частности, этим летом централизованную эксплуатацию разнесли по agile-командам.
Тем самым, созданы предпосылки для построения devops-культуры, которая необходима для успешной эксплуатации микросервисов.
Важными моментами для независимого выпуска фич являются:
— Обратная совместимость на уровне API. Обеспечить ее помогают такие шаблоны проектирования, как Consumer Driven Contracts martinfowler.com/articles/consumerDrivenContracts.html
и Tolerant Reader martinfowler.com/bliki/TolerantReader.html
— Возможность включения/выключения отдельных фич (или старой и новой версий фичи) в рамках одного приложения. Тут помогает шаблон Feature Toggle (https://martinfowler.com/bliki/FeatureToggle.html).
Разумеется, помимо этого, есть огромный пласт работ, которые сделаны или делаются для обеспечения эксплуатации микросервисов:
— Внедрение контейнеризации. Сейчас пилотируется OpenShift.
— Devops pipelines.
— Автотесты, в том числе тесты API на совместимость.
— Разрабатывается собственный API gateway на основе nginx.
— Централизованное логирование с возможность находить логи в рамках одного запроса по correlation token.
— Различные механизмы защиты от отказов, например, квотирование в разрезе потребителей сервиса. Другой пример — аналог hystrix для защиты от каскадных отказов. По hystrix рекомендую почитать medium.com/netflix-techblog/fault-tolerance-in-a-high-volume-distributed-system-91ab4faae74a
— Многое-многое другое…