Эта статья — развернутый ответ на вопрос, который нам периодически задают: чем werf отличается от Helm? На первый взгляд можно предположить, что задача у них примерно одинаковая: автоматизировать деплой приложений в Kubernetes. Но всё, конечно, немного сложнее ...

Практический пример по организации CI в Jenkins и Bitbucket.

Для запуска тестов (и других утилит для анализа кода) есть два подхода: непосредственно в кластере Kubernetes или вне его (например, на сервере сборки/деплоя или локально). В статье рассказывается про их запуск вне K8s на примере SonarQube-тестов в рамках пайплайна, построенного на базе GitLab CI/CD с использованием werf.

Практическая статья, автор которой делится своим опытом решения инфраструктурной задачи по сбору логов с помощью fluentd в «домашнем» Kubernetes-кластере (MicroK8s). Он использует werf для сборки и доставки образа (с fluentd), Docker Hub для его хранения и GitHub Actions для запуска своего пайплайна.

В статье рассмотрена проблематика очистки образов, которые накапливаются в реестрах контейнеров (Docker Registry и его аналогах) в реалиях современных CI/CD-пайплайнов для cloud native-приложений, доставляемых в Kubernetes. Приведены основные критерии актуальности образов и вытекающие из них сложности при автоматизации очистки, сохранения места и удовлетворения потребностям команд. Наконец, на примере нашего Open Source-проекта werf мы расскажем, как эти сложности можно преодолеть.

Сегодня мы с радостью сообщаем, что werf научилась работать в распределенном режиме, начиная с версии v1.1.10 (доступна в каналах v1.1 alpha, beta, ea и stable). Для его подключения требуется минимум усилий...

Все популярные реализации реестров для образов контейнеров поддерживают Docker Registry HTTP API и позволяют использовать одни и те же инструменты для работы с ними. Тем не менее, часть реализаций имеет свои особенности и ограничения, а значит — если вам нужно их поддерживать в своем инструментарии для CI/CD, — с этой спецификой необходимо считаться. Так у нас и случилось в процессе работы над GitOps-утилитой werf, когда мы захотели улучшить в ней то, как обеспечивается жизненный цикл образов.

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

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

Мы уже не раз рассказывали про свой GitOps-инструмент werf, а в этот раз хотели бы поделиться опытом сборки сайта с документацией самого проекта — werf.io (его русскоязычная версия — ru.werf.io). Это обычный статический сайт, однако его сборка интересна тем, что построена с использованием динамического количества артефактов.

В этой приуроченной к релизу статье мы подробнее рассмотрим, что предоставляет и не предоставляет данная версия, а также наши планы на будущие версии. Но начнём мы с того, что разберёмся в понимании термина «GitOps» и роли werf в процессах непрерывной интеграции и доставки приложений (CI/CD).

В своей практике мы часто сталкиваемся с задачей адаптации клиентских приложений для запуска в Kubernetes. При проведении данных работ возникает ряд типовых проблем. Одну из них мы недавно осветили в статье Локальные файлы при переносе приложения в Kubernetes, а о другой, связанной уже с процессами CI/CD, — расскажем в этом материале.

Что такое 3-way-merge-патчи, как люди пришли к подходу с их генерацией и почему они важны в CI/CD-процессах с инфраструктурой на базе Kubernetes? Что представляет собой 3-way-merge в werf, какие режимы используются по умолчанию и как этим управлять.

Раннее мы публиковали статью «Сборка проектов с GitLab CI: один .gitlab-ci.yml для сотни приложений», а теперь расскажем о решении схожей задачи сегодня. Новый материал — о том, как можно построить CI/CD-процессы для большого количества однотипных приложений с появлением include в .gitlab-ci.yml и приходом werf на замену dapp.

Статья посвящена новым командам для работы с зависимостями чарта и чарт-репозиториями.

Лучше поздно, чем никогда. Или как мы чуть не допустили серьёзную ошибку, не имея поддержки обычных Dockerfiles для сборки образов приложения.

27 мая в главном зале конференции DevOpsConf 2019, проходящей в рамках фестиваля РИТ++ 2019, в рамках секции «Непрерывная поставка», прозвучал доклад «werf — наш инструмент для CI/CD в Kubernetes». В нём рассказывается о тех проблемах и вызовах, с которыми сталкивается каждый при деплое в Kubernetes, а также о нюансах, которые могут быть заметны не сразу. Разбирая возможные пути решения, мы показываем, как это реализовано в Open Source-инструменте werf.

Так случилось, что ваша программа написана на скриптовом языке — например, на Ruby — и встала необходимость переписать ее на Golang.

Этот материал продолжает цикл о сборке Docker-образов для приложений на различных языках программирования с помощью утилиты werf (dapp). Поговорим о приложениях на JavaScript. Для начала это будет frontend-приложение, а в следующей части планируется рассказать о сборке backend'а и запуске всего в Kubernetes.

В качестве иллюстрации будут использованы приложения nodejs-pool и poolui. Да-да, подготовим к запуску в Kubernetes свой майнинг-пул с блокчейном и выплатами!

Доклад Дмитрия Столярова, технического директора компании «Флант», на конференции RootConf 2018 в рамках фестиваля РИТ++ (28 мая 2018). Рассказывается об опыте настройки мониторинга с Prometheus, который был получен в результате эксплуатации десятков проектов на Kubernetes в production.

В статье представлен (и продемонстрирован в коротких видеороликах) инструментарий, облегчающий разработку и отладку конфигураций с werf (dapp) — Open Source-утилитой, которую мы ежедневно используем при построении и сопровождении процессов CI/CD.

Сборка образов для Docker на основе базового образа, как правило, предполагает вызов команд в окружении этого базового образа. Например — вызов команды apt-get, которая есть в базовом образе, для установки новых пакетов.

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

Проблема известная: одним из путей её решения может быть сборка вспомогательного образа и перенос файлов из вспомогательного образа в результирующий. Для этого появились Docker multi-stage builds или образы-артефакты в dapp. И данный подход идеально решает проблему подобную переносу результатов компиляции исходных кодов в итоговый образ. Однако он не решает все возможные проблемы…

В начале этого года мы посчитали, что наша Open Source-утилита для сопровождения процессов CI/CD — werf (dapp) версии 0.25 — обладает достаточным набором функций и была начата работа над нововведениями. В версии 0.26 появился синтаксис YAML, а Ruby DSL был объявлен классическим (далее перестанет поддерживаться вовсе). В следующей версии, 0.27, основным нововведением можно считать появление сборщика с Ansible. Пришло время рассказать об этих новинках подробнее.

Эта статья — начало цикла о сборке werf'ом (dapp) приложений на различных языках, платформах, технологических стеках. Предыдущие статьи про dapp были больше обзорными, описывали возможности dapp. Теперь же пора поговорить более предметно и поделиться конкретным опытом работы с проектами. В связи с недавним релизом dapp 0.26.2 я заодно покажу, как описывать сборку в YAML-файле.

Описывать сборку буду на примере приложения из репозитория dockersamples — atsea-sample-shop-app. Это прототип небольшого магазина, построенный на React (фронт) и Java Spring Boot (бэкенд). В качестве БД используется PostgreSQL. Для большей похожести на рабочий проект добавлены реверсивный прокси на nginx и шлюз платежей в виде простого скрипта.

Чем werf (dapp) помогает в процессах CI/CD?

Доклад Дмитрия Столярова, технического директора компании «Флант», на конференции HighLoad++ 2017 (7 ноября 2017). Рассказывается о выстраивании процессов непрерывной интеграции и доставки (CI/CD) на базе GitLab CI и специфики их интеграции с инфраструктурой, управляемой Kubernetes.

Демонстрация работы werf (dapp) с кластером Kubernetes.

Эта статья — ознакомительное руководство по сборке Docker-образов приложений с помощью нашей Open Source-утилиты werf (dapp) (подробнее о ней читайте в анонсе). На примере двух простых приложений (с одним образом) рассмотрим, как могут быть задействованы некоторые из основных возможностей dapp и какой результат они дают.

dapp — написанный на Ruby инструмент, созданный в компании «Флант» как Open Source-проект для реализации и сопровождения процессов CI/CD. Что он позволяет?

Доклад Дмитрия Столярова, технического директора компании «Флант», на конференции RootConf, проходившей в рамках фестиваля РИТ++ 2017 (6 июня 2017 г.). Посвящён устройству и основным возможностями Kubernetes и практике использования этой контейнерной системы в небольших проектах.

Доклад Дмитрия Столярова, технического директора компании «Флант», с конференции Highload++ 2016 (8 ноября 2016 г.). Посвящен сборке Docker-образов в контексте CI/CD (Continuous Integration, Continuous Delivery) и обзору основных возможностей Open Source-утилиты werf (dapp).

Доклад Дмитрия Столярова, технического директора компании «Флант» с конференции RootConf 2016 (31 мая 2016 г.). В нём были обобщены и систематизированы лучшие практики построения процесса Continuous Delivery (CD) с использованием Docker и других Open Source-продуктов.