Системы сборки *

Мы открываем исходный код фич со стадий Plan, Create, Verify, Package, Release, Configure и Defend.

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

В статье рассказывается об основных особенностях поддерживаемых имплементаций Docker Registry, а также о соответствующих нововведениях в 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.

Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте.

Привет, Хабр!

Это четвертая и заключительная часть серии статей "Учимся разворачивать микросервисы", и сегодня мы настроим Jenkins и создадим пайплайн для микросервисов нашего учебного проекта. Jenkins будет получать файл конфигурации из отдельного репозитория, собирать и тестировать проект в Docker-контейнере, а затем собирать Docker-образ приложения и пушить его в реестр. Последней операцией Jenkins будет обновлять кластер, взаимодействуя с Helm (более подробно о нем в прошлой части).

Новый релиз GitLab 12.8 посвящен подходу «единое место»: для всех ваших логов, пакетов NuGet и контроля за соответствием требованиям. По аналогии с тем, что GitLab — это единое место для всего вашего жизненного цикла DevOps.

Переменные в Gitlab можно задать в нескольких местах:

1. В настройках групп
2. В настройках проекта
3. Внутри .gitlab-ci.yml

При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".

Начнем с простого наследования и будем постепенно усложняться.

С конечным списком уровней приоритетов можно ознакомиться в конце документа.

Здравствуйте, меня зовут Дмитрий Карловский и я… люблю плевать против ветра. Утираться и снова плевать. Хобби у меня такое. И всё, что я создаю, делаю я без оглядки на тенденции, стараясь решать проблемы системно, а не как привычно. Зачастую бывает, что основная сложность даже не в том, чтобы придумать решение, а в том, чтобы объяснить другим, что проблема вообще существует.

Знаю, я всех уже заколебал, но сегодня, хотелось быть рассказать про разработанный мной 4 года назад фреймворк, какой путь он прошёл, где он сейчас, и куда прокладывает новые пути. Пройдёмся мы и по конкурентам, и по крупным игрокам, и даже по мне самому. Так что никто не уйдёт не обиженным. Статья, как обычно, длинная. Мужайтесь.

Привет всем, меня зовут Илья. В ИТ я работаю около 6 лет, последние 2 года — в компании «Яндекс.Деньги» фронтенд-разработчиком. В обязанности входит поддерживать/развивать части приложений, в данный момент проект «Личный кабинет» (и нет, это не просто «в ие неправильные отступы поправить», «кнопке цвет поменять» или «быстро форму сошлепать»).

В отделе разработки у нас есть внутренний проект Challenges — так мы называем задачи, не связанные напрямую с основными продуктами. Это задачки, которые будут общественно полезны, помогут улучшить инфраструктуру, CI/CD и другое. Например, доработать бота, оповещающего о релизах, сделать плагин для IDEA по автогенерации assert по объекту и провести рефакторинг старой UI-библиотеки. Такие «вызовы» можно брать по желанию — они прекрасно подходят для разбавления бизнес-задач.

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

Естественно, итогом стала не просто конкретная реализованная задача, а библиотека с правилами и общими функциями (ядро/core) для реализации любых чекеров (я надеюсь). В процессе решения задачки были набиты шишки, о которых тоже хочется рассказать.

Итак, есть Jenkins, Bitbucket, почта (или Telegram, Slack — что понадобится) и необходимость проверять размер бандла. Надо это всё подружить.

Встречаемся 19 февраля, чтобы обсудить наболевшее – Scala системы сборки. Встреча сообщества состоится в нашем офисе (Старо-Петергофский, 19).

В программе три доклада. Будем говорить про существующие билд тулы для Scala, разберемся, когда Pants лучше других систем сборки и познакомимся с Nix — системой сборки и управления зависимостями.

Под катом — подробнее о докладах, ссылка на регистрацию для участия во встрече и информация о трансляции.

Наверное никому из нас не нравится долго ждать завершения сборки проекта, когда каждая секунда похожа на вечность. И хорошо, если это рабочие часы, и скоротать время можно за кружечкой кофе, обсуждая все недостатки автоматической сборки мусора.

Иногда, определенных успехов можно добиться, выполнив оптимизацию CMake. Рассматриваемый здесь прием основывается на простой идее: две статические библиотеки, использующие функции друг друга, могут собираться одновременно.

Вышел релиз GitLab 12.7 — с улучшениями, которые помогут вашим командам и конвейерам (в русской локализации GitLab «сборочные линии») стать более эффективными и результативными. Настройка автоматизации и конвейеров — основа продуктивной работы команд DevOps, и в 12.7 мы предлагаем множество нововведений, которые сделают вашу работу быстрее и эффективнее. Например, конвейеры Parent-Child, группы ресурсов конвейера и бета-версию общих обработчиков заданий (shared runner) для Windows на GitLab.com.

Alpine Linux — часто рекомендованный как базовый образ для Docker`а. Вам говорят, что использование Alpine сделает ваши билды меньше, а процесс сборки быстрей.

Но если вы используете Alpine Linux для Python приложений, то он:

• Делает ваши билды намного медленней
• Делает ваши образы больше
• Тратит ваше время
• И в итоге может стать причиной ошибок в рантайме

Приглашаем на митап сообщества Load Testing 4 февраля. Будет интересно: узнаем рецепты по программированию с InfluxDB и Grafana, разберем автоматизацию НТ с Jenkins. И ещё case study – deadlock, race condition и memory leak.

Регистрируйтесь и приходите в офис Райффайзенбанка в Нагатино!

Недавно для QtProtobuf я озадачился настройкой босяцкого CI для верификации "запросов на слияние" aka pull requests, ну и конечно для того, чтобы вставить модный бэйдж в README проекта. На выбор были GitHub Actions и Travis CI. Честно скажу, я не задавался целью искать, сравнивать, анализировать, хотелось простоты и быстрого решения совсем несложной задачи. Сначала я разобрался с CI для GitHub Actions, и настроил билд и верификацию юниттестов через docker контейнер. Но ввиду уймы ограничений GitHub Actions оказался попросту непригодным для верификации проекта в Windows. Пришлось обратиться к Travis CI.

КДПВ_not_found.png

Всем привет, на связи Александр Панов, техлид из Pixonic. В компании я отвечаю за межпроектные решения и околопроектную периферию и сегодня хочу поделиться своим опытом и наработками.

Платформы непрерывной разработки и интеграции, или CI/CD, сейчас используются повсеместно в тех отраслях, где решающую роль играет итеративность и отлаженность технических процессов. В этой статье речь пойдёт о CI/CD для реализации наших Unity-проектов для мобильной геймдев-разработки: с какими проблемами мы столкнулись, как их удалось решить, каких улучшений мы добились и как прописан наш пайплайн сборок билдов.

Сразу договоримся, что в качестве сервера CI мы используем TeamCity от JetBrains, в качестве хранилища Git-репозиториев ― GitHub, для хранения артефактов сборки ― Nexus.

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



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

werf — это GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. werf поддерживает сборку образов приложения с помощью Dockerfile или собственного встроенного сборщика (на основе синтаксиса YAML, с поддержкой Ansible и инкрементальной пересборки на базе Git). Для доставки приложения используется формат конфигурации, совместимый с Helm. Код приложения, конфигурация собираемых образов и конфигурация выката приложения хранятся в одном Git-репозитории.

Долгожданный стабильный релиз 1.0 — это законченная по функциям базовая версия утилиты (точный номер версии первого стабильного релиза — это 1.0.6). В базовой версии werf поддерживает полный цикл доставки приложения и его сопровождения. Это включает в себя сборку образов приложения, деплой в Kubernetes, очистку неиспользуемых образов.

Руководителям разработки необходим четкий и понятный обзор состояния безопасности приложения и соответствия требованиям для их проектов. Декабрьский релиз GitLab поможет вам эффективнее отслеживать эти важные параметры.

В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml

Дано

Есть монорепа, в которой:

• 10 Dockerfiles
• 30 описанных деплоев
• 3 окружения: devel, staging и production

Задача

Настроить пайплайн:

• Сборка Docker-образов должна производиться по добавлении git-тэга с версией.
• Каждая операция деплоя должна выполняться при пуше в ветку окружения и только по изменении файлов в конкретной директории
• В каждом окружении установлен свой gitlab-runner с отдельным тэгом, который выполняет деплой только в своём окружении.
• Не все приложения должны быть задеплоены в каждое из окружений, мы должны описать пайплайн так, чтобы иметь возможность делать исключения.
• Некоторые деплойменты используют git submodule и должны запускаться с установленной переменной GIT_SUBMODULE_STRATEGY=normal

Описать это всё может показаться настоящим адом, но мы не отчаиваемся и вооружившись Jsonnet сделаем это легко и непринуждённо.