company_banner

[Питер] Встреча JUG.ru с Олегом Ненашевым из CloudBees — Groovy DSL в Jenkins и Pipeline. Реализации и подводные грабли



    В понедельник, 4 декабря, в офисе компании Oracle состоится встреча с Олегом Ненашевым, разработчиком в компании CloudBees, которая является одним из основных контрибьюторов Jenkins. Тема встречи — Groovy DSL в Jenkins и Pipeline.

    Несмотря на появление новых средств CI/CD, Jenkins остается одним из наиболее популярных серверов автоматизации. Он фактически является распределенным веб-сервисом и предоставляет различные DSL, в том числе с доступом к JVM и внутренним API. Давать такой доступ нужно аккуратно, а то в продакшне будет мучительно больно: security, UX, performance, и т.д. О предотвращении этой боли и пойдет разговор.

    Олег расскажет:

    • как в Jenkins реализованы Groovy DSL и почему их так много;
    • как в Jenkins Pipeline реализованы Groovy Sandbox, доступ к API Java, Script Security и персистентность контекста при рестарте;
    • какие архитектурные проблемы это вызывает;
    • как можно при всем этом расширять и поддерживать DSL для частных задач.

    Disclaimer: Цель доклада — поговорить об архитектурных особенностях Jenkins, который в своей основе является распределённым Java-приложением. Мы будем говорить о Jenkins Pipeline и его новомодных фичах (Declarative Pipeline, Blue Ocean), но только в контексте реализации.

    Теги: jenkins, groovy, dsl, configuration-as-code.

    О докладчике


    Олег Ненашев — разработчик в CloudBees, состоит в Core Team проекта Jenkins. C 2008 года занимается автоматизацией, инфраструктурой и фреймворкостроением для крупных программно-аппаратных проектов с помощью Jenkins и десятков других тулов. Пишет код, поддерживает ядро и плагины Jenkins, организует митапы в Питере и других городах.

    Регистрация


    Участие бесплатное, регистрация тут.
    JUG Ru Group
    588.97
    Конференции для программистов и сочувствующих. 18+
    Share post

    Comments 12

      0

      Сделайте онлайн трансляцию пожалуйста если есть возможность!

        0

        Тоже поддерживаю. Очень было бы интересно поговорить с людьми, которые делают Groovy Sandbox, ибо вопросов, в том числе матерных очень много.

          0
          А еще лучше возможность просмотреть в записи!
            +1
            Трансляции не будет. Видеозапись будет через пару дней на нашем Youtube-канале.
              0
              Алексей, спасибо за приятную новость.

              Если вдруг будет дефицит вопросов (вряд ли конечно), то вот те, которые интересуют нашу команду:
              — как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода? Интересует как собираются решать текущие трудности с переиспользованием разных элементов (pipeline, stage, step) в нескольких разных пайплайнах. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное.

              — подходит ли Pipeline концепт к мультирепозиторным проектам? Пример — когда модули одного проекта разбросаны по разным Git репозиториям, но при этом у них общий CI и CD. Или же Pipeline концептуально настаивает на монорепозиториях?

              — есть ли планы более плотной интеграции с Gradle? Вопрос в связи с тем, что теперь по сути в репозитории появился еще один build-script файл (jenkins file). Но задача/ответственность по сути близка к скриптам Gradle и Maven.

              — есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?

              Эти вопросы для нас очень важны, так как Pipeline с одной стороны серьезно отличается от традиционного подхода, с другой стороны весьма активно разрабатывается и быстро изменяется, эволюционирует. Знать в каком направлении планируют развивать продукт и решение разработчики — может помочь минимизировать риски выбора неверных дизайнерских решений на данном этапе для тех, кто уже начал миграцию.
                0
                Отвечает oleg-nenashev
                  +1
                  Добрый вечер,

                  Начну с конца. Pipeline сейчас — не единый продукт, а open-source экосистема, которая делается многими компаниями и независимыми разработчиками. В «ядре» Pipeline есть вектор развития на стабилизацию/performance и Declarative, но на периферии все происходит довольно спонтанно. В особенности это касается Pipeline-интеграций в плагинах.

                  По вопросам:

                  как разработчики Declarative Pipeline видят в будущем структуризацию groovy кода?.. Текущее решение, использующее чекаут Git репозитория для подключения библиотек, многими воспринимается как неудобное и усложненное

                  Не берусь ответить за разработчиков Declarative. Есть идеи о поддержке Declarative-блоки внутри библиотек, я бы в ближайшем будущем не ожидал новых движков для шаринга кода. Собственно, а чем Вам неудобны библиотеки? Их не обязательно в Git держать, через другие плагины их можно хоть локально на мастере держать (через alpha-версию Filesystem SCM Plugin)

                  Подходит ли Pipeline концепт к мультирепозиторным проектам?

                  Подходит. В этом случае все равно надо где-то хранить код Pipeline (в самой задаче или в Jenkinsfile в одном из репозиториев), но другие репозитории могут подтягиваться через шаги типа git(). И webhook'и на все репозитории вешать можно. Более сложную логику триггеринга, конечно, будет писать тяжелее.

                  есть ли планы более плотной интеграции с Gradle?

                  AFAIK планов в roadmap нет. Есть висящий pull-request в Gradle Plugin. Он близок к завершению, и любая помощь там приветствуется (ревью/тестирование). Форвардну вопрос тем, кто сейчас разработкой Pipeline занимается.

                  Есть ли планы разработки плагинов для Intellij Idea с полноценной поддержкой Jenkinsfile?

                  Публичных планов, к сожалению, нет. А вот потребность в этом есть. Я на митапе про интеграцию с IDE немного говорил (начало слайдов). Сейчас есть условно-рабочая поддержка автодополнения и документации через GDSL, но на этом интеграции без хаков заканчиваются. Написать плагины можно (даже отладчик), были бы контрибьюторы.
                    0
                    Олег, спасибо за развернутый ответ!

                    С библиотеками пробовали руководствоваться этой статьей:
                    https://jenkins.io/doc/book/pipeline/shared-libraries/

                    Global Shared libraries отпало, т.к. это нарушало саму идею, что весь код хранится целостно в одном месте (получается часть приходит из Git, часть добавлена руками в Jenkins). По поводу Filesystem SCM были не в курсе, в ближайшее время опробуем.

                    Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.

                    На данный момент всю логику стараемся вынести в shell скрипты наподобии:
                    clean-test-package
                    describe-environment
                    deploy-to-cloud

                    В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев — и потом ссылаться на различные стейджи в тех пайплайнах где это необходимо. К примеру так:

                    pipeline {
                    ...
                    stage(describe-environment)
                    stage(clean-test-package)
                    stage(deploy-to-cloud)
                    ...
                    }
                      0
                      Наиболее интересно звучит Folder-level libraries. Но в статье есть лишь упоминание, без конкретики и примеров.


                      Там особо много не расскажешь. Объявления делаются не глобально, а на уровне Folder'ов. Поведение примерно такое же. Но это позволяет управлять наборами библиотек/версий для проектов и при необходимости делать CI/CD для библиотек на том же инстансе. Я у себя глобальных библиотек не держу, только в фолдерах.

                      В идеале в Declarative Pipeline было бы полезно и удобно иметь возможность организовывать набор из стэйджев


                      Сейчас это можно сделать, если стейджи описаны на Scripted Pipeline (например, в той же библиотеке). Будет что-то типа:

                      stage("my stage") {
                        steps {
                          describe-environment()
                        }
                      }
                      

                        0
                        А можно попросить ссылочку на пример с использованием folder level libraries? :)
                          0
                          Ответил мимо треда внизу :(
          0
          Вот тут есть пример, как через Groovy Boot Hook у меня для папки инициализируются несколько Pipeline Library. В UI всё примерно так же выглядит, просто ещё одна секция в конфиге.

          Only users with full accounts can post comments. Log in, please.