Всем привет! В этой статье я хочу рассказать вам о направлении DevOps (акроним от англ. development & operations) в текущих реалиях России. В первую очередь, как я это вижу для себя с позиции начинающего специалиста. Эта тема для меня особенно близка — я изучаю её в рамках своего диплома и также вливаюсь сам в эту сферу.
В данной статье мы будем рассматривать российский рынок за 2024 год, опираясь также на четвертое исследование команды Экспресс 42 — State of DevOps Russia 2024.
Привет! Меня зовут Игорь Латкин, я управляющий партнер и системный архитектор в KTS. Сегодня расскажу, как мы в компании выстраивали процессы деплоя приложений так, чтобы разработчики могли делать это самостоятельно.
Финансирование разработки Kubernetes крупнейшими спонсорами на GitHub за последние десять лет, источник
Эти компании сначала при помощи сообщества разрабатывают опенсорсный софт или берут готовый, строят на нём прибыльный бизнес, зарабатывают миллионы. А потом меняют лицензию, оставляя контрибуторов, пользователей и партнёров в недоумении, что им делать. Такова бизнес-модель некоторых современных компаний вроде Redis Labs.
Но ещё хуже поступают крупные облачные провайдеры. Они просто используют готовые решения, вообще не занимаясь разработкой и убивая бизнес «паразитов», описанных выше. Здесь вообще паразиты в квадрате.
И весь этот террариум кормится опенсорсом.
Читать полностью »
3 апреля на сайте InfoWorld вышла статья известного публициста на тему Open Source и юриста Matt Asay под названием «OpenTofu, возможно, демонстрирует нам, как не надо делать форк». Лидер-абзац в статье довольно жёсткий:
Не согласны с лицензией? Просто сделайте форк проекта, но не выкидывайте его код — говорите, что он всегда был доступен публично. Сравните код и лицензию HashiCorp с версией OpenTofu.
Когда-нибудь в твоей стране запретят IaC и ты вспомнишь про мои бэкапы…
© Джейсон Стетхем
Не так давно мы в компании столкнулись с маленькой проблемкой - RabbitMQ Читать полностью »
Дисклаймер: Я написал такую статью, какую сам хотел бы прочитать полгода-год назад, когда мы стартовали миграцию в облако. Мне бы она здорово помогла сэкономить силы, время и нервы – надеюсь, теперь поможет кому-то ещё. Здесь нет исчерпывающей экспертизы, только немного моего опыта для конкретных условий и наработанные мною решения и инструменты.
Критика и дополнения приветствуются.
Предыстория: выбирали сертифицированное облако для всякой там сертифицированной жизни. Остановились на кое-каком B2B-колоссе, руководство заключило договор, и отделу SRE пришлось работать с облаком на основе VMware vCloud Director. И, как подобает секте свидетелей Infrastructure as Code, хотелось поменьше сидеть в веб-морде облака и больше -- в конфигурациях какого-нибудь Ansible и Terraform.
Эта статья - плод нескольких вечеров девопсера и бог знает скольких дней и ночей CTO. По горячим следам, поэтому, возможно, она несколько скомканная. Тем не менее, если вы столкнулись с облаком на основе vCloud - будет интересно.
Рассказываем про наш опыт импорта и адаптации конфигураций инфраструктуры, ранее развернутой вручную в AWS, в формат Terraform. Зачем? Причин может быть много: и отказоустойчивость, и упрощение горизонтального и вертикального масштабирования, и многие другие. С них и начнем эту статью.
Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.
