Многие, наверняка, сталкивались с мемом this is fine, или оригинальным комиксом. Так выглядит типичный день для многих дежурных сотрудников. Оперативные дежурные получают много оповещений, и работа со слишком большим количеством оповещений может привести к усталости от оповещений — чувству истощения, вызванному реагированием на оповещения, которые не имеют приоритета или четких действий. Убедиться в том, что оповещения действенны и точны, а не являются ложными срабатываниями, крайне важно, потому что если дежурные сотрудники постоянно получают ложные уведомления, они могут перестать обращать на них внимание и игнорировать даже важные сообщения. С этой целью в Cloudflare многочисленные команды проводят периодический анализ оповещений, каждая команда разрабатывает свои собственные панели мониторинга для отчетности.

Базовые distroless-образы GoogleContainerTools часто упоминаются как один из способов создания (более) маленьких, (более) быстрых и (более) безопасных контейнеров. Но что на самом деле они собой представляют? Зачем они нужны? В чем разница между контейнером, созданным на distroless-базе, и контейнером, созданным с нуля? Давайте разберёмся.

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

Для написания расширений используется Typescript, который достаточно просто освоить. Однако существенным препятствием является то, что в документации часто нет ответов на вопросы, которые возникают при реальной разработке.

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

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть1, Часть2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Многие компании успешно внедрили практики DevOps в свой инженеринг. Мы в SHARE NOW сделали также. Команды в компании ответственны не только за разработку программ, но и за то как эти программы попадут в продакшен, и как они будут обслуживаться. You build it — you own it.

Остается вопрос — как узнать что мы на правильном пути? Как измерить DevOps? Здесь нам и помогут DORA метрики.

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

Мы очень любим Kubernetes и мечтаем чтобы все современные технологии поскорее начали использовать его замечательные паттерны.

А вы когда-нибудь задумывались о том чтобы построить своё собственное облако? Могу поспорить что да. Но можно ли это сделать используя лишь современные технологии и подходы, не покидая уютной экосистемы Kubernetes? Нам по опыту разработки Cozystack пришлось с ним как следует разобраться.

Да, вы могли бы возразить что Kubernetes для этого не предназначен и почему бы не использовать OpenStack для Bare Metal-серверов а внутри него запускать Kubernetes как положено. Но поступив так, вы просто переложите ответственность с ваших рук на руки OpenStack администраторов. Что добавит как-минимум ещё одну сложную и неповоротливую систему в вашу экосистему.

Зачем так всё усложнять? - ведь на данный момент Kubernetes уже имеет всё необходимое для запуска Kubernetes кластеров.

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

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

Всем привет, меня зовут Александр и я алкоголик бы хотел поделиться личным опытом получения оффера в США, подготовки к получению визы этой страны, собственно, получения визы (ох, и разные это вещи!), переезда, получения гринкарты. Может, что-то получится добавить по результатам осмысления своего положения здесь, в США. Я переехал в начале 2022 года, и примерно через год получил гринкарту.

Почему может быть интересна еще одна статья на подобную тему? Ведь есть уже немало вариантов (это разные ссылки, если что). На мой взгляд, главное отличие - я не пользовался никакими услугами помогаторов, не тратил 100500 денег, и вся информация будет максимально подкреплена ссылками на официальные сайты и подходами, которые сработали в моем случае.

Салют!

Хочу рассказать вам про такие замечательные инструменты как docker compose(быть точнее про новую возможность watch), skaffold, tilt.

Рассказать для чего они полезны, как пользоваться и с примерами.

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

Protobuf, или Protocol Buffers, это бинарный формат сериализации, разработанный в Google для эффективного обмена данными между сервисами. Это как JSON, только компактнее, быстрее и типизированнее. Если JSON был вашим первым крашем в мире сериализации, то Protobuf – это тот, с кем вы хотите серьёзных отношений.

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

Представим ситуацию, что мы деплоим по push-модели. В качестве платформы для запуска деплоя у нас используется Gitlab: в нём настроен пайплайн и джобы, разворачивающие приложения в разные окружения в Kubernetes

Какой бы инструмент мы не использовали (kubectl, helm), для манипуляций с ресурсами API нам в любом случае будет необходимо аутентифицироваться при выполнении запросов к Kubernetes. Для этого в запросе надо передать данные для аутентификации, будь то токен или сертификат. И тут возникает несколько вопросов:

1. Где хранить эти креды?

Хранить креды от кластера можно, например, в Gitlab CI/CD Variables и подставлять в джобу деплоя, но тогда потенциально все пользователи будут деплоить с одними и теми же доступами

2. Как сделать так, чтобы у каждого пользователя были свои данные для доступа в кластер?

Можно было бы вручную запускать джобы деплоя и в параметры каждый раз подставлять свои аутентификационные данные, но, очевидно, такой подход неудобен и подходит далеко не всем

А что если сделать так, чтобы в качестве провайдера аутентификационных данных для Kubernetes выступал сам Gitlab? Тогда не надо было бы нигде хранить креды, и каждый пользователь мог бы аутентифицироваться в кубере под своей учёткой при запуске деплоя

Всем привет! Несколько месяцев назад прошел GrafanaCON 2023, на котором объявили о выходе десятой версии Grafana — инструмента для мониторинга и визуализации данных с аудиторией в 20 миллионов по всему миру.

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

В этой статье мы обсудим нововведения Grafana 10. Кроме того, вы можете сами ознакомиться с новыми функциями: 

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

• PersistentVolumes (PV).
• PersistentVolumeClaims (PVC).
• Storage Classes.

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

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

Перевели туториал об основах контроллеров, операторов и CRD. В качестве практики вы можете создать кастомный оператор ConfigmapSync для синхронизации Configmap между пространствами имен. Рассказываем, как его написать и развернуть его с помощью Kubebuilder.

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

Мы начали использовать геораспределенные кластеры и повысили надежность сервисов. В статье опишем, какими инструментами это делали, какие сложности возникали и какие получили результаты. 

Привет, Хабр, меня зовут Артур Мечетин, и в этой статье мы со Станиславом Столбовым из Byndyusoft расскажем о том, как повысили стабильность приложений в К8s кластерах с высокой критичностью для бизнеса.