Привет, Хабр! Меня зовут Андрей, я новый Android-разработчик в команде онлайн-кинотеатра PREMIER.
Когда я только пришел на работу в проект, мне поставили задачу внедрить измерение билдов для того, чтобы видеть, как с течением времени у нас меняется время сборки проекта на разных билд-машинах.
Решение задачи
После проведенного анализа я выявил два варианта решения
Всем привет меня зовут Максим, я SRE инженер в группе компаний Тинькофф.
Но сегодня я здесь по другой причине.
Я уже давно собираю и публикую подборки видео, от которых есть толк, с разных каналов SRE направленности в телеграмм канале https://t.me/sre_pub и спасибо им большое за то что позволяют мне это делать.
Но я не видел подобных подборок на хабре и для меня до сих пор загадка почему.
Лично для меня Хабр является основной площадкой для получения информации.
Вы можете это понять по 1500+ моих закладок в профиле.
Так вот я просмотрел все доклады с SREcon23 составил для вас подборку из докладов вырезав все доклады в которых было больше болтовни или рекламы чем пользы.
Ctrl-F + репозиторий и лампа джина из пещеры Чудес будет не нужна.
Спойлер: джины все же рассказывают секреты.
Во времена популярности микросервисной архитектуры появляется все больше потребности в платформах и решениях для автоматизации сложных или нереализуемых вручную процессов. Например, когда нам нужно работать с высоконагруженными приложениями, имеющими свои крутые пики и просадки посещаемости, было бы очень сложно построить архитектуру без использования Docker-контейнеров (виртуальных машин), которые позволяют разбивать приложение на части, взаимодействующие друг с другом. Однако задача становится еще более сложной, если мы работаем с приложением, которое делится на другие приложения, которые в свою очередь разделены на контейнеры, и вся эта система обрабатывает миллионы запросов пользователей и хранит невообразимый объем информации.
Яркие примеры таких приложений: YouTube или Google. Естественно, на одной машине такие сервисы не развернуть, поэтому в архитектуре используются тысячи компьютеров, именуемых Нодами (worker node). Однако эти Ноды, как части общего механизма, могут выходить из строя, и тогда их нужно заново поднимать, более того, хорошо бы вообще постоянно мониторить каждый Нод и считывать его состояние. Выполнять такие задачи становится очень сложно вручную. И, возможно, именно для этих площадок, а может быть и нет, но Google разработала технологию Kubernetes, которая выполняет роль оркестрации контейнеров. Kubernetes следит за Нодами и поднимает те, что выходят из строя, но это не единственная ее задача. Технология также может отключать неиспользуемые Ноды, оптимизируя расход ресурсов.
В мире, где Kubernetes доминирует в управлении контейнеризированными приложениями, один вопрос часто встаёт перед теми, кто стремится понять его внутренние механизмы: 'Как на самом деле работает k8s scheduler?' Эта статья предназначена для развенчания мифов и предоставления чёткого объяснения работы Kubernetes планировщика. Мы исследуем ключевые моменты этого процесса, начиная от того, назначает ли планировщик модули узлам один за другим в очереди или выполняет эту задачу параллельно, и заканчивая более сложными аспектами его работы. Погрузитесь в детали этой сложной, но увлекательной темы вместе с нами, чтобы лучше понять, как Kubernetes оптимизирует размещение подов в вашем кластере
Привет, Хабр! Я Степан, DevOps‑инженер, занимаюсь созданием CI/CD процессов с учётом проверки кода на безопасность, поддержкой и разверткой новых кластеров Kubernetes, соблюдением требований безопасности и созданием системы мониторинга и логирования — все это в рамках одной команды. Хочу рассказать об одной незадокументированной особенности Istio, с которой мне довелось столкнуться при внедрении Service Mesh.
Об Istio на Хабре написано уже немало (например, тут и тут, может пригодиться новичкам в этой теме), но вот разбора конкретных примеров не хватает. И когда у нас в ОТП Банке возникла проблема с «Истио», решать её нашей команде пришлось самостоятельно.
Быть может, наш опыт пригодится тому, кто позже наступит на те же грабли. Даже лучше будет, если кто‑то прочитает и уже не наступит. Конкретно наши грабли пригодятся при использовании Istio для маршрутизации в рамках одного кластера. Ещё наш кейс можно проецировать на другие задачи с маршрутизацией. И использовать как пример того, как в нестандартных ситуациях искать качественное решение.
Как и статьи по ссылкам выше, этот текст в основном для начинающих. Эксперты, вероятно, и без того в курсе (возможно, даже подскажут более эффективное решение). С экспертизой и более глубокой работой с istio + может быть с envoy данное решение будет найти не так сложно. Под катом — подробности проблемы, схема нашего конфига с решением и код.
Привет, Хабр! На связи автор статьи двухлетней давности «Пожалуйста, прекратите называть админов девопсами». В ней, если помните, я ловил пескарей в процессе поиска работы офигевал от несоответствия реального мира и моих онтологических ожиданий. С тех золотых денёчков изменилось примерно всё — и вот, с учётом полученного за прошедшее время опыта я хотел бы оглянуться, посмотреть назад и понять, выдержали ли мои прошлые соображения проверку временем.
Дмитрий Зайцев — CTO в компании Flocktory. А ещё директор программного комитета конференции «Онтико» DevOps Conf. Конференция 2023 года уже завершилась и сейчас во всю идёт подготовка к следующей 2024. Ведь работа над мероприятием идёт почти целый год. Мы расспросили у Дмитрия, зачем ходить на конференции в качестве гостя и спикера, кто их аудитория и какие интересные темы ожидают нас в новом сезоне.
Привет!
Я Давид Бадалян, работаю в Исследовательском центре доверенного искуственного интеллекта ИСП РАН. В статье я хочу поговорить об Ansible – одной из самых популярных систем по автоматизации развёртывания.
Стоит запустить Ansible программно, и он становится черным ящиком – нет никакого контроля над его выполнением, нет информации о тасках. Эту проблему мы обнаружили, разрабатывая оркестратор Michman для сервисов уровня PaaS. В результате мы создали cotea и gocotea: инструменты для программного исполнения Ansible-плейбуков из языков Python и Go.
Про cotea, её архитектуру и кейсы применения я расскажу подробно под катом. Если вы DevOps-инженер и хотите узнать, как можно гибко использовать Ansible – статья точно для вас.
Бывало у вас так, что некоторые аналитики запрашивают побольше вычислительных ядер и оперативной памяти для своих Jupyter-ноутбуков, а у вас в это время ничего не работает? У меня бывало, ведь недостаточно уметь разрабатывать код на Spark — еще нужно уметь его настраивать, правильно инициализировать сеансы работы и эффективно управлять доступом к вычислительным ресурсам. Если отдать настройку на волю случая, Spark может (и будет) потреблять ресурсы всего кластера, а другие приложения будут стоять в очереди.
Меня зовут Владислав, я работаю Дата инженером в Альфа-Банке, и в этой статье мы поговорим о том, как правильно подобрать необходимое количество параметров и не положить кластер на коленочки.
Мы с радостью объявляем о релизе GitLab 16.5 с отчётами о соблюдении стандартов соответствия требованиям, правилами задания целевой ветки мерж-реквеста, возможностью завершать обсуждения по тикету, ускорением цепочек мерж-реквестов для полулинейной истории коммитов и многими другими фичами!
Не для кого не секрет, что некоторые типичные действия на компьютере проще быстрее и эффективнее выполнить из-под командной строки.
В этом тексте я хотел бы поделиться командами, которые мне очень часто помогают в работе.
Вносить изменения в код приложения и тут же автоматически получать задеплоенные изменения, чтобы быстро тестировать его, — мечта разработчика. В этой статье мы посмотрим, как реализовать такой подход для небольшого приложения с фронтендом и бэкендом: организуем два варианта локального стенда на базе minikube или Docker с автоматическим развертыванием всех изменений или только закоммиченых в Git.
Бэкенд приложения напишем на Go, а фронтенд — на Vue.js. Все это позволит быстро запускать проект для тестирования прямо во время разработки, что, несомненно, повысит удобство работы с приложением.
Привет! Меня зовут Петр и мы в компании Nixys очень любим Redis. Эта база используется, если не на каждом нашем проекте, то на подавляющем большинстве. Мы работали как с разными инсталляциями Redis, так и с разными версиями, вплоть до самых дремучих, вроде 2.2. Несмотря на то, что в Интернете очень много статей и докладов по этой БД, мы в своей практике достаточно часто встречаемся с непониманием некоторых основных концепций Redis и со стороны разработчиков, и со стороны системных администраторов.
В серии статей я попытаюсь осветить неочевидные нюансы при работе с Redis и сегодня начну с основных концепций и понятий. А еще в конце статьи приведу небольшой чек-лист, который может помочь вам в оптимизации этого NoSQL решения.
Привет, меня зовут Максим Качинский, я ведущий DevOps-инженер в компании RocketData. Более 6 лет мы развиваем одноимённую платформу для управления репутацией — за это время она выросла с монолитного MVP на единственном сервере до 15+ микросервисов с пятью разными видами баз данных. И всё это в гибридной инфраструктуре.
Чем больше рос проект, тем сложнее нам было его поддерживать. Чтобы облегчить жизнь DevOps-инженерам, мы начали постепенно переходить на managed-решения. Но этот путь не был идеально прямым, и нам пришлось пересмотреть многие привычные рабочие инструменты.
В этом посте поделюсь нашим опытом: покажу, как мы используем Terraform, и расскажу, что стоит учесть при масштабировании гибридной инфраструктуры и переезде в облако.
Можно ли сделать классный и удобный мониторинг не для галочки, а с пользой для всех участников разработки? Инженерный опыт подсказывает, что Observability как процесс идеально построить не получится. Но стремиться к этому стоит.
Статья подготовлена на основе доклада Владимира Дроздецкого о вопросах, методах, практиках и в целом подходе к Observability для инфраструктурной платформы Magnit Online Services. Внутри — о том, как пришли к идее нового процесса, о настройке мониторинга от helm upgrade до gitops-подхода, опыте интеграций с Grafana в работе с визуализацией и метриками и политике алертов, которая не пропускает критичные угрозы.
Статья будет полезна инженерам платформенных команд и эксплуатации, а также всем, кто внедряет у себя DevOps-практики.
Как убедиться в том, что коммиты в продуктовых репозиториях «настоящие»? То есть отправлены тем человеком, имя которого указано в коммите. Мы с коллегами из команды DevOps задались целью построить процесс, который будет давать нам полностью прозрачную картинку, и у нас это получилось. Эта статья довольно практическая, и решение, о котором я, Рамазан Ибрагимов, вместе с моим коллегой Александром Паздниковым пишу в этом материале, — лишь часть большой схемы по обеспечению безопасности. В качестве хранилища кода будем опираться на инстанс GitLab On-Premise внутри компании — вендора ПО.
Привет, это Максим Павлов из KTS. Мы создаём IT-продукты для бизнеса.
Все твердят про важность Time To Market — времени от появлении идеи фичи до её релиза для пользователей. При этом почему-то тестируют все фичи на одном сервере. В статье рассказываю, как ускорить Time To Market одним простым способом.
Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про сервисный подход в DevOps. В прошлой статье мы подробно описали сам подход, этапы его внедрения и обозначили ряд проблем, которые нам предстоит решить. Теперь давайте перейдём к этим проблемам.
Первая проблема, с которой мы начнём - это тушение пожара в инфраструктуре.
