И снова привет, Хабр! Продолжаю рассказывать, как мы с коллегами решали небольшую задачу по автоматизации управления списками доступов на пограничных маршрутизаторах. В предыдущей части речь шла о концепции хранения и представления данных. Теперь же погрузимся в пучину кода, который отвечает за проверку и отправку политик на сетевые устройства.
Это небольшой туториал о том, как ускорить pull и push тяжелых Docker образов, которые вы собираете локально, но их запуск возможен только в удаленной среде. Например, потому что контейнер использует специфическое окружение, приложения или ресурсы, которые трудно или невозможно воспроизвести локально.
Решение “в лоб” состоит в том, чтобы запушить собранный образ в Dockerhub. А там, где вы будете его использовать, просто указать ссылку на образ. Очевидно, что у этого простого способа есть недостатки.
Найденное решение оказалось без этих недостатков, простым, работающим и весьма изящным. Вот 3 шага, которые нужно сделать:
Поделюсь с коллегами практикой создания Docker-сборок на базе Spark разных версий, которые могут запускаться как Spark Kubernetes Executors для параллельного выполнения Spark-задач в кластере.
В нашем конкретном случае сборки включают Pyspark и Cassandra Connector, однако вы можете использовать этот материал как набор практических примеров, чтобы сконструировать собственные Docker-сборки для Spark на другом стеке или с другими приложениями.
В рамках поставленной задачи мне понадобилось подготовить, как минимум, пару Docker-сборок: одну для поддержки легаси кода и другую вполне современную для последующей миграции. Ниже я расскажу об этапах создания таких Docker-сборок, погружаясь в детали по ходу дела.
Привет, Хабр! Сегодня поделюсь, как я с коллегами решал небольшую задачу по автоматизации управления списками доступов на пограничных маршрутизаторах. Исходные данные просты: 100+ маршрутизаторов, на которых необходимо поддерживать в актуальном состоянии правила NAT. Звучит несложно, но, как водится, есть свои нюансы.
TL;DR: Статья раскрывает опыт создания плагина для IntelliJ IDEA без глубокого погружения в технические подробности. Описан полный цикл разработки — от мотивации и идеи до публикации плагина.
Привет! В этой статье я хочу поделиться своим опытом создания плагина для среды разработки от JetBrains — Infrastructure as Code Security Linter. Плагин позволяет находить проблемы в Dockerfile и docker-compose файлах, как Hadolint, только делает это на лету и интегрирован в IDE.
Мониторинг – это не только сбор информации о состоянии, а помощник для всех. И именно поэтому он такой разный. Ведь чтобы помочь пользователям, разработчикам, провайдерам, мониторингу приходится решать очень разные задачи на разных уровнях. Например, пользователям важно, чтобы сервис был доступен именно в тот момент, когда он им потребуется. Провайдеру – чтобы ресурсы работали максимально эффективно.
На первый взгляд кажется, что главное для мониторинга – это выбрать ключевые метрики, учесть особенности инфраструктуры и настроить сбор данных, триггеры и алерты. Несомненно, это очень важно для инструмента наблюдения. Но всё же главное в мониторинге — сделать его источником информации для развития и оптимизации.
Привет, Хабр! Я — Андрей Камардин, SRE-инженер одной из российских облачных компаний, старший преподаватель в МАИ и эксперт Skillbox по DevOps. Веду канал «Записки про IT». Для закрытого комьюнити Skillbox IT Experts рассказал, как мы настраивали мониторинг инфраструктуры для принятия решений.
Помню в детстве, перед началом летних каникул, казалось, что лето никогда не кончится - 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. И сегодня хочу рассказать, как мы прошли путь от «кустарного производства» пайплайнов к промышленным масштабам, не потеряв по дороге ни одного девопса и не спалив продакшен.
