Используя Ceph как сетевое хранилище в разных по нагруженности проектах, мы можем столкнуться с различными задачами, которые с первого взгляда не кажутся простыми или тривиальными. Например: миграция данных из старого Ceph в новый с частичным использованием предыдущих серверов в новом кластере; решение проблемы распределения дискового пространства в Ceph. Разбираясь с такими задачами, мы сталкиваемся с необходимостью корректно извлечь OSD без потери данных, что особенно актуально при больших объемах данных. Об этом и пойдет речь в статье. Описанные ниже способы актуальны для любых версий Ceph. Кроме того, будет учтен тот факт, что в Ceph может храниться большой объем данных: для предотвращения потерь данных и других проблем некоторые действия будут «дробиться» на несколько других...

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. В релизе v1.1 была представлена новая возможность в сборщике образов: тегирование образов по содержимому или content-based tagging. До сих пор типичная схема тегирования в werf предполагала тегирование Docker-образов по Git-тегу, Git-ветке или Git-коммиту. Но у всех этих схем есть недостатки, которые полностью решаются новой стратегией тегирования. Подробности о ней и чем она так хороша — под катом...

Привет, Хабр! Вы же помните Чиполлино? Да-да, того самого парня-луковицу из детской сказки. Так вот: он оказался в нашем мире в самый разгар пандемии COVID-19, наивно* полагая, что его защищают природные фитонциды… Путь героя домой, в свою луковую страну, оказался непрост. Его ждёт множество интересных загадок и головоломок, с которыми, мы уверены, Чиполлино с радостью помогут хаброжители, находящиеся на карантине...

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Как и обещали, выход версии v1.0 знаменовал начало добавления в werf новых возможностей и пересмотра привычных подходов. Теперь мы рады представить релиз v1.1, который является большим шагом в развитии и заделом на будущее сборщика werf. Версия доступна на данный момент в канале 1.1 ea. Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте...

У компании «Флант» есть ряд Open Source-разработок, преимущественно для Kubernetes, и loghouse — одна из самых популярных. Это наш инструмент для централизованного логирования в K8s, который был представлен более 2 лет назад. Как мы упоминали в недавней статье про логи, он требовал доработки, и актуальность её со временем только росла. Сегодня мы рады представить новую версию loghouse — v0.3.0. Подробности о ней — под катом...

Прим. перев.: Американский DevOps-инженер Sid Palas, пользуясь недавним анонсом Google Cloud как инфоповодом, провёл сравнение стоимости услуги Managed Kubernetes (в разных конфигурациях) от ведущих мировых облачных провайдеров. Дополнительным плюсом его работы стала публикация соответствующего Jupyter Notebook, позволяющего (при наличии минимальных знаний Python) подкорректировать производимые расчёты под свои нужды. TL;DR: Azure и Digital Ocean не взимают плату за вычислительные ресурсы, используемые для управляющего слоя (control plane), что делает их подходящим выбором для развертывания множества небольших кластеров. Для запуска малого количества крупных кластеров лучше всего подходит GKE. Кроме того, можно серьезно сократить затраты, используя спотовые/вытесняемые/низкоприоритетные узлы или «подписавшись» на длительное использование одних и тех же узлов (это касается всех платформ)...

В эпоху повсеместного CI/CD мы сталкиваемся с большим спектром сопутствующих инструментов, в том числе и CI-систем. Однако именно GitLab стал для нас самым близким, по-настоящему «родным». Заметную популярность он снискал и в индустрии в целом*. Разработчики продукта не отставали от роста интереса к его использованию, регулярно радуя сообщество разработчиков и DevOps-инженеров новыми версиями. Агрегация по месяцам и тегам репозитория GitLab GitLab — тот случай, когда активное развитие приносит множество новых и интересных возможностей. Если для потенциальных пользователей это просто один из факторов выбора инструмента, то для действующих — ситуация такова: если вы не обновляли свою инсталляцию GitLab последний месяц, то с большой вероятностью пропустили что-то интересное. В том числе и регулярно выходящие security updates. О наиболее значимых — т.е. востребованных нашими DevOps-инженерами и клиентами — нововведениях в последних релизах Community-редакции GitLab и пойдет речь в статье...

Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции. Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.). За последние десять лет бесчисленное множество команд пали жертвой этого громкого названия и оказались — не побоюсь этого слова — откровенно облапошены. В своей заметке автор утверждает, что они успешно внедрили эту модель в проекты, но умышленно не раскрывает подробности проектов, которые привели к этой «успешности». И это главная ошибка тех, кто верит данной публикации. Общеизвестен факт, что не все стратегии работают во всех ситуациях, со всеми людьми, во всех контекстах. И я утверждаю, что та же логика применима и к этой модели ветвления. На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне...