DevOps *

Как установить оптимальное значение таймаутов в микросервисной архитектуре, чтобы достичь максимальной производительности и отказоустойчивости.

Под катом вы узнаете как установить оптимальные значение connection и request timeout, стоит ли повторять запрос при ошибке или лучше избегать этого.

В конце статьи есть небольшая шпаргалка и куча полезных ссылок. Приятного чтения.

Kafka — это масштабируемая, отказоустойчивая платформа для обмена сообщениями в реальном времени. Она позволяет обрабатывать миллионы сообщений в секунду. Однако некоторые ситуации приводят к потере событий. Например, Kafka требует хорошего стабильного сетевого соединения между клиентами и брокерами; если сеть нестабильна, это может легко привести к потере сообщений. 

Команда разработчиков Trendyol Tech видоизменила архитектуру и решила эту проблему с помощью outbox-шаблона, но столкнулась с другой проблемой — дублированием событий. Приводим перевод статьи о том, как разработчики залезли под капот Kafka и нашли решение этих двух проблем.

Подходы к оптимизации процессов разработки и развертывания хорошо известны и задокументированы: DevOps, SRE, облачные сервисы вроде Containerum Kubernetes или DBaaS for PostgreSQL и т. д.

Однако использование разных подходов еще не гарантирует, что разработчики фактически приблизятся к запуску программного обеспечения. Чтобы решить проблемы, которые могли возникнуть из-за плохого внедрения DevOps или SRE, можно создать платформу для поддержки приложений.

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

Прочитав эту статью до конца вы поймете какими навыками вам нужно обладать для того, что бы стать smart-contract разработчиком!

В конце статьи прикреплен Solidity developer roadmap.

Знакомимся со state-of-the-art инструментом, который используют более половины компаний из списка Fortune 100, с помощью материалов от разработчиков и DevOps-специалистов. Как запустить, оптимизировать и обезопасить свой кластер, плюс — многие другие подробности в подборке по теме от beeline cloud.

Привет! Меня зовут Олег, в IT я около 8 лет, и попал в отрасль тогда, когда начинался хайп вокруг гибких методологий разработки на российском рынке. Так что у меня была возможность своими глазами посмотреть, к чему все это привело в больших компаниях.

Кроме того, гибкие методологии разработки способствовали развитию инженерных практик.

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

Вот, к примеру, набор из уже имеющихся практик и инструментов. Начинает напоминать какой-то зоопарк:

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

Всем привет! Я работаю Dev-Ops инженером в небольшой команде и мы уже 4-ый месяц используем Yandex Cloud для наших сервисов. Так сложилось, что с Kubernetes и облачными вычислениями я столкнулся впервые, поэтому многое приходится изучать на ходу, иногда на "горьком" опыте. На данный момент наши микросервисы развернуты в зональном кластере Kubernetes с одним рабочим узлом, по одной реплике на каждый Deployment. Это означает, что никакой отказоустойчивости и масштабируемости нет и при малейшей нагрузке приложения упадут.

Поэтому, пока нагрузка идет только от команды разработчиков, я решил заранее побеспокоиться об отказоустойчивости наших сервисов, развернутых в Yandex Managed Service for Kubernetes. Сегодня я разверну на своем облаке Kubernetes кластер и покажу как будет вести себя автомасштабируемое приложение под нагрузкой. Для управления инфраструктурой воспользуемся Terraform, для имитирования нагрузки сервисом Yandex Load Testing (в стадии Preview) от Yandex Cloud.

Я Сипатов Максим - DevOps в компании Tourmaline Core. У нас есть небольшая ML-команда, и назревал для этой команды проект, на котором неплохо было бы использовать мощности какой-нибудь видеокарты. Наш выбор пал на Nvidia Tesla a10, и как оказалось, использование таких видеокарт может вызвать некоторые проблемы, если ваш сервер - это просто открытый стенд. В этой статье я расскажу с какими проблемами столкнулся, пытаясь настроить эту видеокарту на сервере, как их решил, и каким образом мы утилизировали ресурсы видеокарты.

Nvidia Tesla a10 – отличное решение для проведения экспериментов небольшой командой, специализирующейся на машинном обучении, если вы не работаете с огромными массивами данных. И в целом иметь свое устройство для задач по искусственному интеллекту (и не только), всегда интереснее, чем арендовать чужое.

Сегодня мы с радостью объявляем о релизе GitLab 16.2 c совершенно новым редактором текста, палитрой команд, поддержкой подписей без ключей с Cosign, новым уровнем настроек для панели аналитики разработки и многими другими фичами!

Это 2-ая часть статьи "Как задеплоить монолитный pet проект на Java с 0 и не сойти с ума". Первую часть вы можете найти по ссылке.

В первой части мы успешно добавили свои наработки в репозиторий GitHub, в этой части мы рассмотрим что такое GitHub Actions и как с помощью них добавить свой образ docker контейнера с приложением в хранилище DockerHub.

Quality Gate — это принудительная мера или метрика, встроенная в Pipeline, которой должно соответствовать программное обеспечение, прежде чем оно сможет перейти к следующему шагу. Quality Gate обеспечивает соблюдение определенных правил, метрик или практик, которым должен следовать код, чтобы предотвратить попадание кода низкого качества в разрабатываемое ПО .

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

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

Но инженер, тем более девопс, на то и инженер. Видишь что-то, что движется - автоматизируй. Не движется? Двигай и автоматизируй!

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

Представляем перевод статьи, где подробно рассматриваются переменные Ansible.

Привет!
Меня зовут Руслан Качмазов, я стажёр-инженер Yandex Cloud Security, занимаюсь детектированием инцидентов. Вместе с коллегами Алибеком Епхиевым и Дмитрием Пикушем, выпускниками Школы ИБ Яндекса 2023 года, мы расскажем о методах защиты от supply-chain-атак, которые реализованы в группе проектов Sigstore. Поговорим о SLSA, Cosign, Fulcio и Rekor — методологии и инструментах, позволяющих снизить риск таких атак, их гарантиях и тонких местах.

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

Перерыв в работе заставил меня задуматься над смыслом выражения "Сапожник без сапог". Будучи Java Backend Developer с 3-ех летним стажем я не имею на руках ни одного pet проекта. Конечно, на GitHub у меня есть какие-то мелкие проектики, но они не доведены до конца и кроме того как просто висеть на доске "почета" они больше ничего и не могут. С этой мыслёй я пошел в интернет гуглить "как мне задеплоить свое приложение?".

Скажу сразу, это статья содержит шаги по развертыванию Java приложения с помощью GitHub Actions на серверах AWS EC2 и это моя интрерпретация тех инструкций, которые я находил в интернете. Собственно это статья содержит для новичков, кто просто не делал никогда деплой своего приложения, но очень хочет в сжатые сроки похвастаться своим результатом.

Привет, Хабр! Универсальность губит уникальность или почему не нужно все сводить к одному.

Каждый человек, который имеет отношение к IT, будь то ПМ, разработчик, Sales или DevOps, рано или поздно за свою карьеру столкнётся с фразой «надо было вчера». К сожалению, при погружении в эту ситуацию можно прийти к выводам, что никто не виноват в причинах ее возникновения.

Какие доклады должны быть на конференции про девопс? Ведь для тех, кто связан с девопсом, важны и культура взаимодействия разных специалистов, и инструменты вроде Kubernetes, и вопросы вроде безопасности, и облака, и много чего ещё… Что из этого освещать на мероприятии?

Наш ответ такой: всё. Поскольку ближайшая конференция DevOops будет аж четырёхдневной, там найдётся время на все эти темы. А поскольку она будет полуофлайновой-полуонлайновой, то это «всё» будет ещё и «везде»: можно хоть лично прийти на московскую площадку, хоть подключиться удалённо.

Сейчас программа уже составлена, и представляем Хабру описания всех докладов.

Как упростить процесс исправления багов и не допустить уязвимый код в релиз? Использовать инструменты контроля качества. Для поиска ошибок и уязвимостей воспользуемся PVS-Studio, а для работы с отчётом — DefectDojo. В статье рассмотрим, как совместно использовать эти инструменты.

В ночь с 15 на 16 августа официально выйдет новая версия Kubernetes — 1.28. Среди главных изменений — оптимизация работы с sidecar-контейнерами и задачами (Job). Клиенты теперь будут переадресовываться на тот сервер API, который способен обработать их запрос, что упростит скользящие обновления. Проект Kubernetes продолжает размежевание с инфраструктурой Google — KEP 1731 описывает ряд шагов, направленных на оптимизацию и упрощение релизного процесса.

Мы подробно разобрали все новые фичи Kubernetes 1.28.