С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься?

Мы в Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента, а теперь делимся с Хабром опытом: и про архитектуру, и про подводные камни.

Данная статья представляет подход к решению задачи сбора и агрегации метрик от Ingress Nginx Controller для извлечения геоданных с помощью GeoIP2 и их визуализации в Elasticsearch.

Собираем кроссплатформенное (server-client, static-client, gh-pages, Android, iOS, macOS, Linux, Windows, Chrome extension, Docker, Kubernetes, ...) React приложение. В этой статье я почти не затрону Deep backend, только чуть-чуть в конце. Но рассмотрю Open Source шаблон/заготовку для сборки кроссплатформенных React приложений который мы используем в Deep.Foundation.

Приветствую! Меня зовут Ксения, и я — DevOps инженер компании Smartex. 

Я люблю создавать инфраструктуру и процессы, которые помогают разработчикам и операционной команде быть более эффективными и продуктивными. 

Если ваша повседневная рутина связана с множеством однотипных микросервисов и разнообразными средами, данная информация может быть для вас полезна. Материал рассчитан на Junior+ и Middle DevOps специалистов.

Хотя MicroK8s разработан как сверхлегкая реализация Kubernetes, создание кластера MicroK8s все же возможно и полезно. В этой статье я расскажу о том, как добавлять и удалять узлы и что требуется для обеспечения высокой доступности кластера.

Меня зовут Александр Гирев, я Android-разработчик и технический интервьюер. В одной компании я выполнял роль interview expert: следил за качеством собеседований, готовил рекомендации и матрицы вопросов, обучал начинающих интервьюеров.

Однажды на интервью я спросил кандидата, был ли у него опыт проведения технических собеседований. Кандидат спросил: «Что за опыт — задать пару технических вопросов?». Услышав это, я слегка подвис, ведь я считал интервью серьёзным навыком, почти искусством.

В основе статьи лежит мой опыт проведения собеседований. Расскажу про важные качества технического интервьюера, хорошие и плохие примеры фидбека и про то, как быть, если на собеседовании случился форс-мажор.

Всем привет! Случались ли у вас ситуации, когда количество DAG’ов в вашем Airflow переваливает за 800 и увеличивается на 10-20 DAG’ов в неделю? Согласен, звучит страшно, чувствуешь себя тем героем из Subway Surfers… А теперь представьте, что эта платформа является единой точкой входа для всех аналитиков из различных команд и DAG’и пишут более 50 различных специалистов. Подкосились ноги, холодный пот и желание уйти из IT?

Не спешите паниковать, под катом я расскажу о том, как контролировать потребление ресурсов DAG’ов Airflow для предупреждения неоптимально написанных DAG’ов и борьбы с ними.

Меня зовут Давид Хоперия, я Data Engineer в департаменте данных Ozon.Fintech и моим основным инструментом является Apache Airflow, поэтому настало время углубиться в детали его работы.

Всем привет. На этот раз хотел бы поделиться материалом, связанным непосредственно с devops работой. Недавно возникла потребность раскатить kafka кластер в kubernetes. В ходе развертывания возникло очень много сложностей, встречено множество подводных камней, и, естественно, в большинстве случаев рецепта в интернете найдено не было, поэтому приходилось искать решения самостоятельно методом проб и ошибок. Все, что здесь будет описано это сугубо личный опыт на одном из проектов. Сегодня я расскажу как с нуля раскатить dev контур bitnami/kafka кластера с помощью helm чартов, как обезопасить ваш кластер kafka и какие сложности могут вам встретиться.

Поскольку блокировки интернета в РФ в последние недели и месяцы многократно активизировались, а маразм все крепчает и крепчает, стоит еще раз поднять тему обхода этих самых блокировок (и делаем ставки, через сколько дней на эту статью доброжелатели напишут донос в РКН чтобы ограничить к ней доступ на территории страны).

Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.

В первую очередь материал рассчитан на разработчиков, которым ещё не приходилось погружаться в тонкости работы с RabbitMQ или использовать его вообще. Более опытным читателям статья может пригодиться в качестве компактной и упорядоченной выжимки из уже знакомых статей, вебинаров и многочисленных страниц документации.

Привет, Хабр!

Jenkins позволяет автоматизировать всё, от сборки и тестирования кода до деплоя на продакшн. Jenkins работает по принципу пайплайнов, которые можно настраивать под любые нужды проекта.

Инфраструктурный пайплайн – это серия автоматизированных шагов, которые преобразуют ваш код в готовое к использованию на продакшне программное обеспечение. Главная цель всего этого – сделать процесс доставки ПО как можно более быстрым.

Привет, Хабр!

Packer — это open-source инструмент для создания идентичных машинных образов для множества платформ из одного исходного файла конфигурации. Т.е с пакером можно автоматизировать создание образов для Amazon EC2, VMware, Docker и т.д, используя единый процесс сборки.

Рассмотрим его возможности мультисборки, пост-процессоров и пользовательских плагинов.

Добрый день!

Helm - это менеджер пакетов для Kubernetes. Этот инструмент позволяет нам обернуть Kubernetes приложения в удобные пакеты, называемые чартами, которые можно легко развертывать, обновлять и управлять ими в любой момент времени.

Чарты – это пакеты, которые могут включать в себя все для запуска приложения в Kubernetes, от deployments до services. Все это дает возможность работать с приложениями как с единой сущностью, а не как с набором отдельных ресурсов, которые еще и в ручную нужно настраивать...

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

К тому же можно с легкостью откатиться к предыдущей версии нашего приложения.

Тема, которая будет сегодня освещена, рассказывается от лица backend разработчика. На нашем проекте нет devops'а, который бы мог подсказать, направить. Поэтому нам пришлось выходить из зоны комфорта.

При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.

В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер работает под управлением Deckhouse Kubernetes Platform, а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.

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

Основные виды задач

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

По степени важности и срочности для бизнеса выделяют четыре уровня приоритетности:

• A — важные и срочные;
• B — важные, но несрочные;
• C — срочные, но неважные;
• D — несрочные и неважные.

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

Кстати, вот как выглядит матрица Эйзенхауэра:

Главная рекомендация - отказаться от лимитов!

А теперь подробнее.

Когда у вас много пользователей используют один кластер Kubernetes, возникает вопрос - как задать квоты, чтобы и приложениям хватало ресурса, и не случилось ситуации, когда из-за одного прожорливого соседа страдают все поды на ноде? 

Начну с того, что самым распространенным способом является задание request и limit по CPU и RAM. С оперативной памятью все достаточно просто - при превышении потребления, OMM-Killer остановит процесс. А вот с CPU есть целый ряд нюансов и возможностей наступить на грабли.

Это происходит из-за того, что ресурс процессора делится не долями, а по времени. 

Это можно представить так

За свою карьеру руководителя разработки я успешно перевел на рельсы TBD 5 команд общей численностью 20 человек. Когда я общаюсь с коллегами из других компаний на тему TBD, то часто слышу про негативный опыт. Эта статья - мой личный опыт и разбор типовых ошибок других компаний.