03.12.2017 09:30
23derevo 12 2200 Источник


В понедельник, 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, организует митапы в Питере и других городах.

Регистрация


Участие бесплатное, регистрация тут.

Комментарии (12)


  1. Gadget
    03.12.2017 16:04
    #10549376

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


    1. acmnu
      04.12.2017 10:11
      #10550150

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


    1. red5
      04.12.2017 11:40
      #10550348

      А еще лучше возможность просмотреть в записи!


      1. 23derevo Автор
        04.12.2017 11:45
        #10550356

        Трансляции не будет. Видеозапись будет через пару дней на нашем Youtube-канале.


        1. Gadget
          04.12.2017 16:51
          #10551096

          Алексей, спасибо за приятную новость.

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

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

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

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

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


          1. 23derevo Автор
            05.12.2017 02:02
            #10551866

            Отвечает oleg-nenashev


            1. oleg-nenashev
              06.12.2017 03:59
              #10553728
              +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, но на этом интеграции без хаков заканчиваются. Написать плагины можно (даже отладчик), были бы контрибьюторы.


              1. Gadget
                06.12.2017 04:43
                #10553738

                Олег, спасибо за развернутый ответ!

                С библиотеками пробовали руководствоваться этой статьей:
                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)
                ...
                }


                1. oleg-nenashev
                  06.12.2017 13:53
                  #10554308

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


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

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


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

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


                  1. Gadget
                    06.12.2017 14:04
                    #10554322

                    А можно попросить ссылочку на пример с использованием folder level libraries? :)


                    1. oleg-nenashev
                      06.12.2017 20:45
                      #10555178

                      Ответил мимо треда внизу :(


  1. oleg-nenashev
    06.12.2017 20:44
    #10555176

    Вот тут есть пример, как через Groovy Boot Hook у меня для папки инициализируются несколько Pipeline Library. В UI всё примерно так же выглядит, просто ещё одна секция в конфиге.