DevOps *

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

Итак, каковы основные причины неудачных миграций в облака, и как снизить риски?

Всем привет! Я Максим, бэкенд-разработчик команды MSB (корпоративная сервисная шина), занимаюсь интеграциями систем для внутренних нужд компании Tele2, и в этом посте хочу поделиться опытом интеграции с “КриптоПро DSS” поверх ГОСТ TLS.

В компаниях с большим количеством проектов часто возникает ситуация, когда при разработке пайплайнов мы начинаем повторять себя, добавляя в разные сервисы одинаковые конструкции. Это противоречит основному принципу программирования DRY (Don’t Repeat Yourself), а ещё усложняет внесение изменений в код. Справиться с описанными проблемами помогает Jenkins Shared Library.

Мы пообщались с Кириллом Борисовым, Infrastructure Engineer технологического центра Deutsche Bank, и узнали, какие задачи решает Jenkins Shared Library и что её внедрение даёт компании. А ещё рассмотрели кейс разработки и тестирования с примерами кода.

Какие задачи пользователю нужно выполнять в рамках CI-пайплайна или при локальной разработке? Среди них может быть что угодно, но самое очевидное — это, наверное, запуск линтеров, всевозможных unit-тестов и получение покрытия и других отчетов по результатам выполнения команды. Также при разработке и отладке может быть полезен интерактивный режим, который позволит быстрее разобраться в проблеме или проверить гипотезу.

В статье разбираемся, зачем компании Site Reliability Engineering (SRE) и когда его применять. Также здесь расписаны шаги, которые помогут обычному инженеру или разработчику внедрить SRE в своей компании.

Для деплоя приложений в Kubernetes существует огромное количество различных инструментов. Если посмотреть на соответствующий раздел в CNCF Landscape, то можно потеряться в разнообразии. Поэтому иногда хорошо иметь в своем арсенале «серебряную пулю», которая подойдет для большинства задач. Helmwave вполне может стать именно таким инструментом.

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

Привет! Меня зовут Юра, я работаю в компании Кристалл Сервис Интеграция, занимаюсь доставкой софта нашим клиентам и пишу плейбуки. Я расскажу, почему мы используем модель On-Premise, какие инструменты применяем и с какими проблемами сталкиваемся. Моей целью не будет детальное описание наших методов и предоставление точных рецептов (это я оставлю на потом, тем более, что мы и сами находимся в постоянном поиске и оптимизации). Думаю, коллеги ДевОпсы (да, да, я знаю, что ДевОпс — не человек, а пароход) захотят технических подробностей, а каких конкретно — надеюсь выяснить по результатам, чтобы в дальнейшем удовлетворить их интерес. 

В тексте написано кокой путь проходят сорцы с момента написания до исполнения на микроконтроллере. Также про то как настроить ToolChain из бесплатных утилит. Показано на что стоит обратить внимание при запуске первого проекта на Cortex-M чипах. Этот текст, в сущности, пояснение того, что происходит под капотом большинства IDE.

Мы в облачном провайдере T1 Cloud уделяем серьезное внимание защищенности клиентских сервисов, поэтому решили подготовить серию материалов о разработке приложений в облаке. Начнем с вводных и расскажем, что собой представляет процесс безопасной разработки программного обеспечения (Secure SDLC) и на какие нюансы стоит обратить внимание в этом контексте.

Привет! Меня зовут Григорий, я техлид в Cloud Infrastructure Team в Сравни. Моя команда отвечает за observability системы и облачную инфраструктуру. Не так давно мы полностью обновили наш стек мониторинга. Хочу рассказать, как у нас организовано хранение long-term метрик без использования Object Storage.

Мы в Сравни долгое время использовали связку Prometheus + Thanos для мониторинга и хранения данных. Для Thanos мы использовали схему с sidecar’ом. Эта схема работала довольно неплохо, но с ростом проекта — росло и потребление ресурсов. Со временем задачи по scrape samples уже потребляли значительные ресурсы. Когда только на Prometheus стало уходить больше 30 ядер vCPU и 100 гигабайт RAM, мы начали искать способы оптимизации потребления ресурсов. 

Первым делом определили требования, которые необходимы для системы мониторинга:
- должно поддерживаться развертывание в Kubernetes;
- система должна быть способна переезжать из одного Kubernetes-кластера в другой без потери данных;
- нужна поддержка downsampling;
- возможность построить high availability систему;
- в идеале, чтобы система требовала очень мало внимания на обслуживание ;)

Мы поизучали варианты, и сперва показалось, что будет хорошей идеей взять стек VMAgent + Thanos receiver. Как несложно угадать из названия статьи, этого у нас не получилось. Недавно я увидел в одном профессиональном чате, что коллеги захотели использовать такой же стек и по тем же причинам, что и мы. Поэтому решил поделиться нашим опытом и рассказать, к чему мы в итоге пришли.

В продолжение наших статей про Chaos Engineering расскажу про недавний опыт проверки на прочность приложений в кластере Kubernetes с помощью Open Source-оператора Chaos Mesh.

Использование того или иного продукта в проекте - это всегда попытка найти лучшее решение, балансируя между ограниченным бюджетом, возможностями роста практически по любому сценарию и высотой "порога входа". Существует много продуктов, которые связаны с контейнерами, что выбрать подходящий инструмент становится всё сложнее и сложенее, а community с "промытыми мозгами" и мышлением "ёжиков жрущих кактус" только добавляет сложности (хотя в противовес оным есть хейтеры, которые наоборот обгадят решение, просто потому что в своё время оно им не подошло).

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

Как правило, при создании desktop-приложений на платформе Qt не возникает проблем, связанных с медленностью работы GUI. Qt – платформа достаточно надежная, неплохо вылизанная по всем параметрам, в том числе и по скорости работы. Однако всё же иногда бывают ситуации, когда из-за обилия виджетов графический интерфейс немного притормаживает, и это печально). В этой статье я приведу один частный пример простого графического интерфейса и покажу, как за два шага можно сначала ускорить его в 11 раз, а потом и в целых 34 раза. Вдобавок к этому, я постараюсь немного осветить механизм принятия решения для таких оптимизационных задач, постараюсь показать направление мыслей для правильного решения. Поехали!

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

В главных ролях: Minio, Kubernetes, Minio Operator, TLS и старина curl.

Компании-разработчики программного обеспечения уже давно полагаются на DevOps-подход с целью повышения уровня гибкости и качества коллабораций при поставке программного обеспечения. Пайплайны CI/CD автоматизируют процессы в жизненном цикле разработки программного обеспечения (SDLC), осуществляя плавную интеграцию и поставку новых функций. Совершенствование программного обеспечения за счет преобразования процессов  автоматизации и гибкости предполагает интеграцию многочисленных инструментов и сервисов, что может привести к возникновению пробелов в защите. Их выявление и устранение является ключом к обеспечению безопасности CI/CD. В данной статье рассмотрим, как защитить ваш пайплайн CI/CD. 

Привет, меня зовут Андрей Голяков, я руководитель бэкенд разработки компании Бимейстер.

Хочу поделиться опытом быстрого подсвечивания возможных проблемных зон объёмного и малознакомого кода.

Этот материал для тех, к кому когда-то подошли и сказали: «Некогда объяснять, ты теперь тимлид (или начальник отдела)». Может быть, теперь вы уже профессионал своего дела, знаете кучу различных инструментов для решения своих задачи. Но давайте посмотрим чуть-чуть с другой стороны и разберем, как вы управляете потоком своих задач. Как справляетесь с работой, которая к вам приходит. Возможно, это поможет немного ее пересмотреть.

Меня зовут Алексей Пименов, я сертифицированный инструктор альянса  ICAgile, аккредитованный тренер и консультант Kanban University. Пионер Kanban-метода в России.  Моя цель — развить и поднять уровень менеджмента. Kanban многие сопоставляют с DevOps-культурой и практиками DevOps, но это всего лишь один из инструментов, который должен быть в вашем менеджерском ящике.

В данной статье рассмотрены в общих чертах процесс создания резервных копий кластера Kubernetes и более детально процесс создания копий PV с помощью Velero.

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