DevOps *

Вносить изменения в код приложения и тут же автоматически получать задеплоенные изменения, чтобы быстро тестировать его, — мечта разработчика. В этой статье мы посмотрим, как реализовать такой подход для небольшого приложения с фронтендом и бэкендом: организуем два варианта локального стенда на базе 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. В прошлой статье мы подробно описали сам подход, этапы его внедрения и обозначили ряд проблем, которые нам предстоит решить. Теперь давайте перейдём к этим проблемам.

Первая проблема, с которой мы начнём - это тушение пожара в инфраструктуре.

О сложных системах простыми словами.

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

Возможно, немного другой формат шпаргалки покажется вам более удобным.

System Design (сборник на английском языке).

В этой статье я рассказываю, как настроить уведомления в вашем приложении на Python или в Alertmanager таким образом, чтобы сообщения приходили в определенный Telegram топик.

В этой статье будет дана пошаговая инструкция настройки доменного имени для вашего HTTP Gateway с использованием AWS CDK. Независимо от того, являетесь ли вы опытным пользователем AWS или новичком, это руководство обещает предоставить ценную информацию и практические шаги для улучшения ваших навыков в области облачных сервисов.

С версией 1.19 в Gitea появился собственный Github-подобный CI/CD. Насколько же трудно будет прикрутить к уже работающему Gitea серверу CI/CD. Давайте проверим!

Всем прив :-)

Дочитал недавно книжку «Микросервисы от архитектуры до релиза» (в оригинале наз: «Microservices Up & Running») Вышла она в конце 2020, недавно ее перевели. В издательстве «Питер» периодически делают щедрые скидосы на книжки, и я решил порадовать себя и накупил кучу). Вообще люблю книги в бумажном виде, особенно фундаментальные книги — те, к которым я еще неоднократно возвращаюсь и из которых черпаю идеи. Более хардовые и с кодом я предпочитаю электронные.

«Microservices Up & Running» написали два чувака: Ронни Митра и Иракли Надареишвили. Оба они не понаслышке поели финтех энтерпрайза и имеют очень богатый опыт, занимаются консалтингом и пишут книги. Ронни — соавтор «Continuous API Management», а также вместе с Иракли участвовал в написании «Microservices Architecture». Ронни занимается консалтингом финтех компаний, а Иракли сейчас Banking Platform Managing Director в JPMorgan Chase & Co, а до этого был вице‑президентом по инновациям в Capital One Financial и возглавлял команды, ответственные за создание современной банковской платформы. В общем, это все можно посмотреть в их профиле в Линкедине. Им явно есть чем поделиться.

В целом, книжка мне очень понравилась, поэтому и решил сделать этот обзор. В качестве примера берется создание системы бронирования билетов на самолеты. Если прям очень коротко, то тут поднимаются вопросы:

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

Автоинструментарий упрощает внедрение Observability. С гордостью представляем Grafana Beyla — автоинструментарий eBPF с открытым исходным кодом, который сейчас в стадии публичного тестирования. Beyla сообщает данные о задержках для основных запросов, а также метрики RED (Rate-Errors-Duration) для сервисов Linux HTTP/S и gRPC — и всё это без модификации кода для ручной вставки зондов.

В этой статье мы рассмотрим, как установить и настроить Grafana Beyla с помощью Grafana Cloud для улучшения наблюдаемости приложений. Ещё поделимся планами на будущее.

В этой статье мы рассмотрим, почему API-шлюзы стали ключевым элементом экосистемы современных облачных вычислений и как появление Kubernetes API Gateway упростило и стандартизировало работу с ними. 

Статья составлена на основе сразу двух англоязычных материалов. В первом (его мы поместили в самое начало) авторы на примере профессий объясняют роль различных компонентов облачных приложений, а во втором — проводят глубокий анализ все возрастающей значимости API-шлюзов для экосистемы облачных приложений, их места в рамках концепции «Kubernetes — облачная операционная система» и того, как повлияет на дальнейшее развитие API-шлюзов появление Kubernetes API Gateway. 

Приветствую!

На пути инженера данных часто встречаются задачи связанные с DevOps. Одна из таких - развернуть Airflow в Kubernetes кластере. Если до этого похожего опыта работы не было, то эта задача может показаться нетривиальной. Конечно, можно выполнить несколько команд из официального гайда, но если нужно будет что-то поправить, то без понимания, что происходит внутри, обойтись будет сложно.

Эта статья призвана  облегчить данную задачу. Она поможет тем, кто уже работал с Airflow, но еще не касался технологии Kubernetes. 

Запускаем новую рубрику в блоге beeline cloud — дайджест материалов, в которых авторы и реальные эксперты в одном лице делятся опытом решения различных ИТ-задач. Сегодня в выпуске: как развернуть Kubernetes-кластер в домашних условиях, провести аудит его безопасности, выстроить ИТ-архитектуру и не только.

Бывало ли у вас такое, что вы совершали одни и те же действия из раза в раз и наконец-то решили избавиться от всей этой рутины? Но вы решили отложить это решение на некоторое время, в частности из-за занятости или лени. Но вот вы решаете взять себя в руки и всё изменить! Также было и со мной - и вот в конце концов я решился пойти на оптимизацию развертывания сервисов в Kubernetes при помощи Helm и написать об этом статью!

Я уже успел развернуть несколько приложений в Kubernetes. Но в последнее время взаимодействовать с ресурсами через kubectl становится невыносимо больно. Поэтому я решил осуществить свою давнюю затею - написать свой Helm чарт. Сегодня мы вместе с тобой, Хабрюзер, создадим свой чарт, который можно будет использовать для деплоя собственных приложений!

Привет! Меня зовут Михаил Кажемский, я ведущий DevOps-инженер в ИТ‑интеграторе Hilbert Team. В этой статье я расскажу о различных подходах к созданию унифицированных типовых R&D-окружений: создание динамических окружений в Kubernetes, создание статических окружений с помощью Terraform и Terragrunt и создание окружений с помощью CrossPlane и Argo CD.

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

Прошел ровно год с предыдущего анализа вакансий системных администраторов и снова появилась необходимость в актуальных данных для планирования заработных плат специалистам уже на 2024 год.

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