Как стать автором
Обновить

Комментарии 27

Упустили еще одно, пожалуй, главное преимущество докерфайлов – разработчики обычно работают с теми же образами через docker-compose.
Держать две конфигурации смысла нет.

Планируем плотно развивать тему локальной разработки с использованием werf. Это возможно включает и поддержку docker-compose. Сейчас работаем над стабилизацией версии 1.0. Где-то в конце этого года можно ждать подвижек.

Тимофей, у меня к вам еще вопрос:
Я видел драму в issue helm'a c интеграцией поддержки kubedog в нем.
Можно расчитывать, что вы не оставите надежду интегрировать этот функционал в Helm 3?

Не оставим, но в любом случае, когда выйдет стабильный helm 3 и будет способ мигрировать старые инсталляции на новый хельм — мы перейдем на кодовую базу helm 3 и будем использовать и развивать kubedog для слежения за ресурсами в werf.


Короче советую переходить на werf ;)

Использование werf'a в GitLab где и так есть CI это overhead, теряется гибкость и информативность.
Вы рассматривали возможность использования helper image в раннере вместо использования тулзы as is в одном джобе?

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

Пока нет, не смотрели, выглядит как немного не то.


Но интеграция с самим gitlab у нас есть и достаточно плотная:



Например werf автоматом использует токены, которые выдает gitlab для логина в docker-registry, который также задает gitlab. Werf автоматом использует gitlab-environment если он определен.


Так-то по возможности стараемся лишнего не делать, если это можно переложить на внешнюю CI-систему.


Какой в gitlab есть ci конкретно для деплоя в кубы, где верф будет избыточен, можно подробнее на примере? Везде где используется kubectl apply или helm upgrade можно использовать и werf deploy — тут никаких ограничений не вносится, даже наоборот werf deploy проще использовать из-за наличия интеграции с гитлабом.

Чего хотелось бы еще от werf, по небольшому опыту применения
* Сборка образов на машине разработчика (для тестирования и отладки инструкций) без лишних приседаний, включая работу под Win, как, собственно, можно делать с Dockerfile.
* Параллельная сборка независимых stages. Это сделало бы werf реально мощнее того, что может сейчас предложить многоконтейнерный Dockerfile.
В двух словах зачем эти велосипеды нужны, когда есть встроенный docker swarm?
Что за биомусор минусует в карму на ровном месте?

Werf ориентирован на kubernetes. И чтобы деплоить приложения туда. И в дальнейшем чтобы собирать образы используя runner-ы работающие в самом kubernetes.

НЛО прилетело и опубликовало эту надпись здесь
«Всегда возникает вопрос можно ли положиться на новую технологию, если это разработка одного человека, где гарантии что она будет поддерживаться и развиваться?» — технология не так уж нова, проекту не один год. Разрабатывается он не одним человеком, а хотя бы «одной компанией» (насколько эта формулировка корректно для Open Source-проекта, конечно же, принимающего и сторонние коммиты/контрибьюторов). Посмотрите за историей развития, например, по коммитам, чтобы понять, сколько мы в нее вкладываем — это по-настоящему огромная и решающая многое инвестиция для нас как компании, помогающей организовать другим DevOps и сопутствующее обслуживание.

Риск, конечно, всегда есть, но это ещё и Open Source, что при достаточном сообществе + использовании стандартных для экосистемы технологий (речь и про сам язык, и про применяемые внутри технологии вроде Helm) по меньшей мере даёт куда большие шансы на жизнь в будущем, чем в иных ситуациях.

Этот пост (и сама фича, про которую он) — хорошая иллюстрация того, как мы стремимся развивать сообщество вокруг проекта. Заходите ещё в tg-канал (werf_ru), чтобы увидеть, как активно там люди («сторонние», т.е. вне «Фланта») пользуются и им помогают, вплоть до оперативных патчей, решающих их проблемы.

О преимуществах werf в сравнении с использованием родных средств Kubernetes (и не только) хорошо рассказано в недавнем докладе (по ссылке краткий его обзор и там же полное видео). Там как раз о проблемах, которые в принципе возникают при построении Continuous Delivery на базе K8s, и как они решены конкретно в werf.
НЛО прилетело и опубликовало эту надпись здесь

target из Докер файла можно указать?


Экспериментальный синтаксис с buildkit поддерживается? Все эти RUN --mount=…


И только для сборки можно использовать? А то сегодня полдня писал build.sh — грустно как то…

Target можно:


configVersion: 1
project: myproj
---
image: backend
dockerfile: ./Dockerfile
target: backend
---
image: frontend
dockerfile: ./Dockerfile
target: frontend

Поддерживается любой синтаксис стандартного Dockerfile, т.к. для билда используется docker server (который может использовать buildkit).


После того как образы описаны в werf.yaml, собраны и опубликованы (через werf build-and-publish), их можно использовать для деплоя в кубы. Для этого надо описать chart. В описанном чарте можно ссылаться на имена образов из werf.yaml, в нашем случае например так:


apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: backend
spec:
  template:
    metadata:
      labels:
        service: backend
    spec:
      containers:
      - name: main
        command: [ ... ]
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
        env:
{{ tuple "backend" . | include "werf_container_env" | indent 8 }}

Имелось в виду, можно ли использовать исключительно для сборки, возможностями деплоя не пользуясь. Только закончил описывать собственно деплой на helm 3, перешёл к написанию build.sh "универсального", намучался с "конфигом" на баш массивах, а тут ваш пост. :)

Поддерживается любой синтаксис стандартного Dockerfile, т.к. для билда используется docker server (который может использовать buildkit).

Поигрался сегодня, не смог заставить интерпретировать директиву syntax, создал issue https://github.com/flant/werf/issues/1767 — оно и не должно работать? Или нужно в схему werf.yaml добавлять какой-то buildkit: true, чтобы эмулировать что-то вроде DOCKER_BUILDKIT=1 werf build --stages-storage :local?

Зачем вообще упоминать команду ADD? Мое мнение, что ее нужно выжигать калёным железом в пользу COPY. Докеровцы реально "молодцы", что сделали такой комбайн как ADD — который и ссылки скачает, и архивы распакует, что делает прогноз того, что произойдет весьма нетривиальным. Поэтому мой выбор — вполне ясная директива COPY для копирования файлов внутрь образа.

На самом деле хочу сказать:
Ребята! Вы — молодцы. Похоже, что несмотря на весь мой скепсис — werf взлетит. Как говорится, одна картинка — лучше тысячи слов (отсылаю к скриншоту о сборке Dockerfile из статьи). Но не помешало бы описать больше юзкейсов, если вы действительно заинтересованы в популяризации утилиты и снадбить их видосиками в ASCII формате (забыл как этот чудесный сайт называется, который позволяет такие штуки)...


Интересно вообще как пойдет развитие технологий, но пока видится, что чтобы собрать какой-либо софт — нужно тащить целый стек разных штуковин. А хочется что-то типа самораспаковывающейся коробки — установить кубер, ввести команду "поехали!" и чтобы он сам из исходников все скомпилировал и внутрь себя задеплоил (влажные мечты опса). Работа в этом направлении, насколько мне известно, ведется, но как-то не особо видно результаты. Это отсылка к Argo-CI и Tekton.

Это https://asciinema.org/ скорее всего, делали ролики когда-то для статей про dapp. Жалко, что хабр не умеет делать для них embed, можно только ссылку с картинкой.

ну, так давайте убедим редакцию включить возможность включения embed asciinema )

Отправил «Гениальную идею» через форму обратной связи с редакцией Хабра. Почему-то был уверен, что уже просил их об этом когда-то давно, но не нашёл в своей почте тому подтверждений.
Пообщались с поддержкой хабра:

Для встраивания стороннего контента мы используем API сервиса iframely.com
К сожалению, нам не известно планирует ли этот сервис добавить поддержку указанного вами ресурса.

Спасибо за ответ! Если вставка должна выглядеть просто так: <oembed>https://asciinema.org/a/168763</oembed> — то это не работает, т.к. браузер показывает URL без каких-либо картинок. Однако проверка вставки URL'а через сам iframely показывает другой результат. На чьей стороне проблема?

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

А можно использовать werf только для сборки и хранения образов? Например, мой проект пока не требует k8s, хватает докер-композа. Но удобный ci/cd и чистый registry хочется).

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.