DevOps *

Помню в детстве, перед началом летних каникул, казалось, что лето никогда не кончится - 3 месяца где-то рядом с бесконечностью. А сейчас... Оказывается мы уже больше года разрабатываем RMON, первый коммит в Github был 15 марта 2024 года. Вжух и один год жизни пролетел. Ладно, хватит разговаривать на скуфском - это было маленькое вступление для подведения небольшого итога года работы. Вперед!

В современном мире тема ИИ возникает чуть ли не везде. Что уж говорить про ИТ‑сервисы, которые стремятся бежать впереди паровоза и пихают модную технологию где надо и где не надо. Меня это с самого начала стало раздражать, поскольку к теме ИИ отношусь с изрядной долей критического подхода и даже скепсиса. Я не вижу, что в нужных мне приложениях ИИ приносит хоть какую‑то ощутимую пользу.

Больше всего меня досадует то, что на волне увлечения ИИ как‑то стали забывать про естественные потребности человека, вернее отодвигать их на вторые и третьи позиции в списке приоритетов. Искусственно раздутый хайп вокруг искусственного же интеллекта мешает развитию обычных привычных технологий, практик, интерфейсов, юзабилити и т. д. и т. п. Везде на видное место засовывают этих бесполезных помощников, они везде на первой кнопке, лезут в виде плашек отовсюду, всплывающие окна, помимо запроса на никому не сдавшиеся печеньки на сайтах теперь ещё и предлагают ничем не полезные «интеллектуальные сервисы» в виде помощников. Везде, всюду, на всех сайтах, даже тех, которые совсем далеки не только от ИИ, но и от ИТ вообще. И это мракобесие уже превращается в какое умопомрачение.

Я принципиально сейчас не пользуюсь никакими помощниками. Я понимаю, что на текущей стадии это всё больше хайп, рабоает оно всё через пень‑колоду, раз через десять получаются более‑менее приемлемые результаты. т. е. если вы фанат ИИ (а я на самом деле фанат, но не такого паттерно‑натасканного ИИ, а традиционного, реально интеллектуального) — то можете тестировать и обчать этих ботов на себе. Но зачем вы портите жизнь другим людям, зачем вы втюхиваете тухлые продукты тем, кто предпочитает здоровое питание?

В проектах STM Labs нам нужно было получить подробные логи при обновлениях развёртываний и перейти на Helm 3. Мы попробовали несколько подходов к решению задачи и остановили свой выбор на werf — Open Source-утилите «Фланта» для упрощения организации жизненного цикла CI/CD в Kubernetes. В статье рассмотрим возможности утилиты, а также решения, которые можно использовать в рамках werf или отдельно от неё.

Привет, меня зовут Владислав Феофилактов, я разработчик команды интеграции продукта PT Application Inspector. В этой статье вместе с коллегой Даниилом Бакиным мы расскажем о безопасной разработке приложений, подходе shift left и о том, как сделать жизнь разработчиков и AppSec-специалистов проще, а продукты — более защищенными.

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

В статье описывается новый подход к настройке аутентификации для нескольких доменов с помощью DexAuthenticator в Deckhouse Kubernetes Platform. Узнайте, как одно решение заменяет сотни объектов, экономит ресурсы и делает управление безопасностью проще.

Многие разработчики стремятся протестировать свои изменения перед развертыванием в стабильные среды: prod, dev или staging. Первое, что приходит на ум — написание тестов. Однако, как показывает практика, времени на создание качественных тестов часто не хватает. В таких случаях логичное решение — настройка деплоя для отдельных веток. Хотя эта идея кажется простой, ее реализация связана с рядом сложностей:

Привет, Хабр! Меня зовут Максим Рогоза, и последние 7 лет я работаю корпоративным архитектором в крупнейших компаниях России. В настоящее время я занимаюсь стратегическим IT‑консалтингом в компании Аксеникс, где помогаю крупным организациям выстраивать эффективную IT‑архитектуру.

Недавно я рассказывал вам о подходе Architecture as Code с использованием PlantUML. Сегодня хочу поделиться опытом хранения моделей ArchiMate в системе контроля версий Git и автоматизации рабочих процессов для совместной работы над архитектурой предприятия.

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

Если ты начинающий разработчик, то эта статья точно тебе пригодится. А если у тебя огромный опыт и ты думаешь, что тебя уже ничем не удивить, то… Не будем торопиться… Давай проверим?

Когда‑то давно общался с коллегой на тему всякого разного и в ходе беседы, он как‑то вскользь сказал, «А в линуксе же кроме дефолтного STP ничего не поддерживается, ну вот я и...».

Дальше уже ничего слышно не было.

Как это не поддерживается? GENEVE мы умеем, а MST нет?... на что получил положительный ответ и примечание, что по крайней мере такое было в какой-то относительно свежей версии Debian.

Короче, решил покопаться сам, почему-то мне казалось, что это де-факто стандарт и такое должно там быть.

Ну и покопался, вот мои копания в виде статейки.

Добро пожаловать под кат.

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

Меня зовут Кристина Демидович, я DevOps‑инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. Я расскажу о нашем подходе к обновлению СУБД Pangolin, который позволил нам превратить часть мажорных обновлений в обновление данных системного каталога — что проще, удобнее и занимает вдвое меньше времени.

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

Этот кейс будет полезен всем, кто занимается подготовкой и поддержкой учебных устройств в образовательных учреждениях и EdTech проектах. Если в вашей организации сотни компьютеров и планшетов Apple, которые нужно оперативно настраивать, готовить к учебному процессу, обновлять и очищать, автоматизация этих процессов становится критически важной. Мы расскажем, как один корпоративный университет упростил администрирование своего парка устройств с помощью Ринго MDM.

Немного о клиенте

Это корпоративный университет. Назвать его не можем, поэтому обозначим его Университет N.

Всем привет! Я — Java-разработчик с пятилетним опытом в финтехе, и сегодня я расскажу, как настроить CI/CD для деплоя Spring Boot приложения из Bitbucket через Jenkins в MicroK8s. Это не просто теория — я поделюсь реальным кейсом, разберу ошибки, с которыми столкнулся, и дам рабочий код. Если вы хотите автоматизировать деплой и не наступать на грабли — поехали!

Представьте: у вас есть микросервис на Spring Boot, который нужно быстро и без ошибок доставить в продакшен. Ручной деплой отнимает время, а команда требует стабильности. Я решил эту задачу с помощью Bitbucket, Jenkins и MicroK8s, но путь оказался не таким гладким, как хотелось бы. Проблемы с аутентификацией, конфликты портов и настройка окружения заставили меня попотеть. Как я справился? Об этом — в статье.

CI/CD (Continuous Integration/Continuous Deployment) — это must-have для современных разработчиков. Автоматизация сборки, тестирования и деплоя приложений экономит время, снижает вероятность ошибок и ускоряет доставку кода до продакшена. В этой статье мы разберем, как настроить полноценный CI/CD-пайплайн для Spring Boot приложения, используя связку Bitbucket, Jenkins и MicroK8s.

Привет, Хабр! С вами Максим Коровенков, DevSecOps Lead в Купер.техе. Продолжаем цикл статей про построение DevSecOps с нуля. Это большой гайд from zero to, надеюсь, hero.

Привет, Хабр! Меня зовут Максим Бочкарев, в IT я с 2005 года и сейчас руковожу devops-направлением в компании ЕВРАЗ. За эти годы я успел повидать множество граблей, на которые мы наступали, пытаясь построить нормальную систему CI/CD. И сегодня хочу рассказать, как мы прошли путь от «кустарного производства» пайплайнов к промышленным масштабам, не потеряв по дороге ни одного девопса и не спалив продакшен.

Современное производство программного обеспечения — сложный процесс, от разработчика требуется не только писать код, но и справляться с целым комплексом сопутствующих задач: отслеживать изменения, проводить тестирование, соблюдать стилистические правила и внутренние стандарты, учитывать безопасность и применять best practices по обеспечению ИБ уже во время написания кода.

Но есть и хорошие новости. Разработчику доступно большое число инструментов, которые упрощают труд: от линтеров до анализаторов и систем автоматизированного тестирования — все они встраиваются в среду разработки и помогают решать сложные задачи, не отвлекаясь от творческой части работы. В этой статье я, Евгений Иляхин, архитектор процессов безопасной разработки в Positive Technologies, как раз расскажу о крайне полезных инструментах, которые автоматизируют рутину и повышают качество кода, позволяя программисту сосредоточиться на разработке новой фичи или поиске оптимального решения.

Привет, Хабр! Меня зовут Георг Гаал, я член ПК DevOpsConf. Я энтузиаст информационных технологий со школьной скамьи. Меня эта тема очень зажгла, когда я в первый раз сел за компьютер и осознал, что вообще не понимаю, как он функционирует. Сегодня я попытаюсь на примерах из своего опыта рассказать про эволюцию DevOps, актуальных трендах и о том, как оставаться востребованным в профессии.

Защита DNS при помощи TLS позволяет скрыть состав DNS-трафика, который обычно передаётся в открытом виде. Соединения DNS-over-TLS не так распространены, как DNS-over-HTTPS, но зато могут прозрачно применяться не только для доступа к резолверам, но и на авторитативных серверах. Посмотрим, вооружившись консольными утилитами, как всё это работает на практике.

Ansible — мощный инструмент автоматизации, но его push-модель не всегда удобна. Когда требуется централизованный контроль большого числа серверов, могут возникнуть проблемы:

📌 Нестабильные сети → клиент может быть недоступен во время обновления.

📌 Сложности с NAT → серверы находятся в закрытых "серых" сетях.

📌 Перемещаемые устройства → подключаются к сети только время от времени.

Разбираемся, как ansible-pull решает эти проблемы на стенде, а также настраиваем CI/CD для тестирования и совместной разработки Ansible-ролей

Кто бы мог подумать, что внедрение корпоративного ИТ-мониторинга может быть таким… скажем так, «интересным»? Вы начинаете с благих намерений, а заканчиваете в окружении мигающих экранов и тысячи алертов. Большинство проектов могли бы проходить гораздо быстрее, если бы не хаотичный подход. Особенно «весело» дела обстоят с legacy-системами, где документация — это древний свиток, а знания разбросаны, как пазл, потерявший половину деталей. Мы собрали 9 правил, которые помогут избежать хаоса и внедрить мониторинг без боли.

О том, «Что делать?» (без «Кто виноват?») — читайте в нашей статье.

Меня зовут Дима Синявский, я SRE-инженер в Ви.Tech — это IT-дочка ВсеИнструменты.ру

За полгода до этой статьи я рассказал вам в материале Vector.dev: как упростить подсчет метрик по логам как мы сделали удобный для нас подсчет метрик по логам.

И вот недавно мы поняли — что-то не так. Метрик иногда становилось много и появились те, которых быть не должно. Нас это удивило. Оказалось, мы себе оставили грабли в огороде, но удача нам улыбалась и мы их обходили.

Удивительно, что решение почти 2 года нас устраивало и прекрасно решало наши задачи!

Время рассказать вам о граблях: как и где ОНИ нас нашли, каким образом нам удалось от них избавиться.