Привет! На связи Василий Мармер, DevOps-тимлид компании «Флант». Сегодня мы поговорим об Atlas — еще одной утилите, которая делает работу DevOps-инженера более комфортной. Atlas увидел мир в ноябре 2021 года, а сейчас у него более 3,3 тысячи звёзд на GitHub. Язык программирования — Go.
Рассматриваемая утилита служит для управления схемами миграций баз данных и позволяет задействовать современные паттерны DevOps. Разработчики Atlas воспринимают свой инструмент как универсальный способ визуализировать, планировать и выстраивать миграции схем баз данных в соответствии с CI.
Weave Scope — Open Source-утилита для контроля за микросервисными приложениями, развернутыми в Docker и Kubernetes. Утилита визуализирует топологию приложения на уровне контейнеров, помогает находить проблемы и оптимизировать архитектуру. Управление организовано через простой веб-интерфейс; командная строка нужна только для установки и запуска приложения.
Weave Scope можно использовать бесплатно на локальном сервере. Также есть платная SaaS-версия. Создатели Weave Scope — компания Weaveworks, которая известна и другими популярными cloud native-решениями (например, Cortex и Flux).
Чтобы продемонстрировать возможности Weave Scope, развернем утилиту на хосте, потом в кластере Kubernetes, после чего попробуем подключить один из готовых плагинов, который расширяет базовую функциональность Weave Scope.
Это вторая и заключительная часть знакомства с доступными сегодня Open Source-утилитами для организации хаос-инжиниринга в Kubernetes-кластерах. В первой статье было вкратце рассказано о появлении самой дисциплины — chaos engineering, — а также рассмотрены kube-monkey, chaoskube и Chaos Mesh. Теперь этот список пополнится обзором Litmus Chaos, Chaos Toolkit, мини-подборкой из хаос-игр и перечислением пяти других вариантов, заслуживающих внимания инженеров, заинтересованных в разовой или постоянной проверке своей инфраструктуры на устойчивость.
Хаос-инжиниринг для Kubernetes становится всё популярнее, и это закономерно: ведь такая инфраструктура создавалась быть готовой к тому, чтобы в любой момент что-нибудь «отстрелило». А значит — это замечательное свойство надо проверять в реальных проектах.
Благо, уже сегодня можно найти не одно Open Source-решение, помогающее в подобных экспериментах. Представляем вашему вниманию их обзор. Он получился весьма объёмным, поэтому был разбит на две части: в этой мы рассмотрим три популярных проекта.
Что будет, если использовать всем известное in-memory-хранилище ключей и значений в качестве персистентной базы данных, не используя TTL? А если оно запущено с помощью надёжного, казалось бы, оператора в Kubernetes? А если в процессе увеличения реплик Redis мы внесём ещё одно маленькое и безобидное изменение?.. Отвечая на эти вопросы в данной статье, мы попутно расскажем, какие утилиты помогут найти пути к оптимизации размеров большой БД в Redis.
Проблемный кейс
Redis у нас используется внутри кластера Kubernetes в разных проектах. Для удобства управления и применения единых практик в рамках компании мы остановились на операторе от Spotahome. По нашему опыту, это наиболее стабильный вариант, хотя и у него есть свои проблемы, некоторые из которых будут затронуты далее в статье.
Представитель нашего клиента, стек приложений которого обитает в облаке от Microsoft (Azure), обратился с проблемой: с недавнего времени часть запросов некоторых клиентов из Европы стала завершаться ошибкой 400 (Bad Request). Все приложения написаны на .NET, развёрнуты в Kubernetes…
Бывают попадаются задачи, когда надо что-то сделать из-под Linux-а на машине, на которой установлен Windows, но не через RDP или VNC. Или например, как в моём случае, основная машина на Linux и необходимо управлять группой серверов. И для простых задач, например простого запроса типа dsquery group -name "Группа" | dsget group -members | dsget user, который выдаст полный список членов группы в Active Directory со всеми полями — не запускать же ради такого сеанс RDP.
Простого и удобного инструментария я, если честно, не нашёл. За исключением двух утилит: wmic и winexe, которые входят в комплекты Zenoss и OpenVAS. Вернее входили в Zenoss. Не суть, отдельно их я не нашёл, поэтому далее предлагаю свой вариант, большей частью для конкретного дистрибутива (Xubuntu 13.04), но при должной сноровке — всё можно сделать и в любом другом.
В преддверии 1 июля, дня когда произойдёт отключение самой удобной, на мой взгляд, читалки rss-фидов, я озадачился выбором альтернативы. И учитывая привычку Google отключать сервисы, которые казалось бы пользуются успехом, мой выбор лежал скорее в стороне относительно независимых решений. Доверить хранение кучи своих фидов кому-либо кроме гугла я уже не хотел, мало ли что придёт в голову какому-нибудь эффективному интернет-менеджеру. Кроме того, мне очень хотелось ещё и помочь друзьям, которые тоже пользовались google reader и так же как я настороженно ждут его конца. Не буду останавливаться на вариантах, которые возникли передо мной — об этом уже достаточно написано другими.
Мой выбор пал на Tiny Tiny RSS — tt-rss.org/redmine/projects/tt-rss/wiki.
