Рубрика «devops» - 23

Обзор инструментов для chaos engineering в Kubernetes. Часть 2: Litmus Chaos, Chaos Toolkit, KubeInvaders и другие - 1

Это вторая и заключительная часть знакомства с доступными сегодня Open Source-утилитами для организации хаос-инжиниринга в Kubernetes-кластерах. В первой статье было вкратце рассказано о появлении самой дисциплины — chaos engineering, — а также рассмотрены kube-monkey, chaoskube и Chaos Mesh. Теперь этот список пополнится обзором Litmus Chaos, Chaos Toolkit, мини-подборкой из хаос-игр и перечислением пяти других вариантов, заслуживающих внимания инженеров, заинтересованных в разовой или постоянной проверке своей инфраструктуры на устойчивость.Читать полностью »

Разработка должна ориентироваться на продакшен, всё остальное — чушь - 1

За мою карьеру у меня выработались определённые мнения. Некоторые из них оставили особенно глубокий след, подкреплённый годами опыта. Я попытался сформулировать, что же у них есть общего. Общее заключается в мысли о том, что единственное, что важно — это код в продакшене. Обкатка не важна, код на твоём ноутбуке не важен, QA не важен, важен только продакшен. Всё остальное — это технический долг.

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

Эта мысль, а также все связанные с ней подразумеваемые действия, может показаться контринтуитивной или спорной, поэтому я хочу раскрыть её немного глубже. Ниже представлен перечень практик и принципов, которые я считаю правильными, исходя из моего мнения о том, что единственное, что важно — это код в продакшене.
Читать полностью »

Обзор инструментов для chaos engineering в Kubernetes. Часть 1: kube-monkey, chaoskube, Chaos Mesh - 1

Хаос-инжиниринг для Kubernetes становится всё популярнее, и это закономерно: ведь такая инфраструктура создавалась быть готовой к тому, чтобы в любой момент что-нибудь «отстрелило». А значит — это замечательное свойство надо проверять в реальных проектах.

Благо, уже сегодня можно найти не одно Open Source-решение, помогающее в подобных экспериментах. Представляем вашему вниманию их обзор. Он получился весьма объёмным, поэтому был разбит на две части: в этой мы рассмотрим три популярных проекта.Читать полностью »

CrowdSec — современная альтернатива Fail2Ban и коллективный иммунитет для Интернета - 1
CrowdSec

Инструмент Fail2Ban хорошо известен админам. Программа анализирует логи на сервере и подсчитывает количество попыток доступа с конкретных IP-адресов по указанным протоколам. В случае нарушения правила данный IP-адрес блокируется на заданный отрезок времени. Например, джейл для авторизации по SSH включён с дефолтными настройками 5 попыток авторизации за 10 минут, после чего происходит бан IP-адреса на 10 минут. Отличный способ отфильтровать мусорный трафик от разных сканеров и защита от DDoS.

Fail2Ban и SSHGuard — лучшие инструменты в своей области. Однако новый опенсорсный проект CrowdSec представляется интересной альтернативой. Это локальная замена Fail2Ban, а потенциально нечто большее — глобальная база репутации IP-адресов типа иммунной системы интернета.
Читать полностью »

Обзор операторов PostgreSQL для Kubernetes. Часть 2: дополнения и итоговое сравнение - 1

На прошлую статью, где мы рассмотрели три оператора PostgreSQL для Kubernetes (Stolon, Crunchy Data и Zalando), поделились своим выбором и опытом эксплуатации, — поступила отличная обратная связь от сообщества*.

Продолжая эту тему, мы добавили в обзор два других решения, на которые нам указали в комментариях: StackGres и KubeDB, — и сделали сводную таблицу сравнения. Также за время эксплуатации оператора от Zalando у нас появились новые интересные кейсы — спешим поделиться и ими.Читать полностью »

Ультимативный гайд по собеседованию DevOps-инженеров — что спрашивать и к чему готовиться - 1

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

Это когда никакого четкого алгоритма нет. Ты просто разговариваешь с человеком и что-то для себя понимаешь. Спрашиваешь, что кандидат делал на прошлой работе, цепляешься за тему — и вот вы уже просто обсуждаете инженерные темы, примерно на том же уровне, что и с коллегами. Если беседа клеится и человек нравится, то все хорошо.

Такой интуиции вряд ли научишься по книгам и текстам, она приходит сама с опытом. Вместе с ней в мышление просачиваются фразы вроде «мне не так важны конкретные знания, как общий кругозор, способность искать информацию, понимание, сработаемся ли» и все такое.

Но иногда, чтобы не терять хватку, надо все же напоминать себе, какими знаниями должен обладать инженер и какими вопросами можно максимально объективно оценить человека, которого видишь впервые в жизни.Читать полностью »

Запускаем тесты на GitLab Runner с werf — на примере SonarQube - 1

Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD:

  • непосредственно в кластере K8s — с помощью отдельных Job или Helm hooks;
  • «снаружи» K8s — например, на сервере сборки/деплоя или локально у разработчиков.

Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье «Как мы выносили СУБД (и не только) из review-окружений в статическое». В этой статье рассмотрен более простой путь — запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf.Читать полностью »

Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).

Читать полностью »

Чуть больше года назад я столкнулся с тем, что на внутреннем проекте совсем не айтишной компании вырос целый отдел веб-разработки, которым мне и довелось руководить. Рабочий процесс вроде как устаканился и всех устраивал, но оставались проблемы:

  • Проверка каждой ветки проходила локально. Приходилось откатывать базу от изменений с предыдущей проверки, билдить фронт. Когда несколько разработчиков вот-вот закончат работы и осталось проверить каждую по мелочи — это превращалось в ад;
  • Различались окружения на проде и между разработчиками, что приводило к ошибкам: “у меня всё работает”.

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

  • Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
  • Гарантию защищённости от ошибок из-за различий в окружении приложения;
  • Можем организовать эффективное взаимодействие с заказчиком:
    • демонстрировать каждую feature-ветку;
    • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

  • начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
  • хотите обновить свой устаревший процесс разработки (workflow);
  • ищете лучшие практики и хотите посмотреть, как у других;
  • часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

  • типовой рабочий процесс от постановки задач до релиза;
  • инфраструктурное решение для построения любого современного процесса разработки с использованием минимального количества инструментов;
  • пример для часто встречающегося кейса: разработка веб-приложения;
  • видеозапись доклада, где вживую показывается результат.

Веб-разработка с нуля: руководство для молодых команд по созданию инфраструктуры CI-CD и процесса разработки - 1

Читать полностью »

Наш опыт с графовой базой данных Dgraph в Kubernetes - 1

Недавно перед нами встала задача развернуть Dgraph в кластере Kubernetes. В этой статье я поделюсь полученным опытом: с чем мы столкнулись во время деплоя и последующего использования этого приложения в различных окружениях, от dev до production.

Что вообще такое Dgraph? Это горизонтально масштабируемая графовая (GraphQL) база данных с открытым кодом, созданная в стартапе Dgraph Labs. Краткое сравнение её основных возможностей с другими подобными решениями приведено здесь. В целом же не буду подробно останавливаться на описании Dgraph, т.к. на хабре уже была подробная статья о причинах появления проекта и особенностях реализации. Для желающих начать практическое знакомство с Dgraph также рекомендую официальную документацию.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js