Jenkins 스크립트 파이프 라인 또는 선언적 파이프 라인


95

이전 스타일 프로젝트 기본 워크 플로를 Jenkins 기반 파이프 라인으로 변환하려고합니다. 문서를 살펴 보는 동안 scripted및 이라는 두 가지 구문이 있음을 발견했습니다 declarative. Jenkins 웹 declarative구문 릴리스와 같은 최근 (2016 년 말). 새로운 구문 릴리스가 있지만 Jenkins는 여전히 스크립트 구문도 지원합니다.

이제이 두 유형이 어떤 상황에서 가장 잘 맞는지 잘 모르겠습니다. scripted구문은 곧 지원 중단됩니까? 그렇다면 declarativeJenkins 파이프 라인의 미래가 될까요?

이 두 가지 구문 유형에 대해 몇 가지 생각을 공유 할 수있는 사람.


1
스크립팅이 더 이상 사용되지 않는 것을 보지 못했으며 선언적과 스크립팅 간의 기능 차이를 고려하면 놀라운 일입니다.
Matt Schuchard

답변:


86

Jenkins Pipeline이 처음 만들어 졌을 때 Groovy가 기초로 선택되었습니다. Jenkins는 오랫동안 관리자와 사용자 모두에게 고급 스크립팅 기능을 제공하기 위해 내장 된 Groovy 엔진과 함께 제공되었습니다. 또한 Jenkins Pipeline의 구현자는 Groovy가 현재 "Scripted Pipeline"DSL이라고하는 것을 구축 할 수있는 견고한 기반임을 발견했습니다.

완전한 기능을 갖춘 프로그래밍 환경이기 때문에 Scripted Pipeline은 Jenkins 사용자에게 엄청난 양의 유연성과 확장 성을 제공합니다. Groovy 학습 곡선은 일반적으로 주어진 팀의 모든 구성원에게 바람직하지 않으므로 Jenkins Pipeline을 작성하기 위해 더 간단하고 독단적 인 구문을 제공하기 위해 Declarative Pipeline이 만들어졌습니다.

두 가지 모두 근본적으로 동일한 파이프 라인 하위 시스템입니다. 둘 다 "코드로서의 파이프 라인"의 내구성있는 구현입니다. 둘 다 Pipeline에 내장되거나 플러그인에서 제공하는 단계를 사용할 수 있습니다. 둘 다 공유 라이브러리를 활용할 수 있습니다.

그러나 구문과 유연성이 다른 부분입니다. 선언적은보다 엄격하고 사전 정의 된 구조로 사용자가 사용할 수있는 것을 제한하므로보다 단순한 지속적 배포 파이프 라인에 이상적인 선택입니다. Scripted는 구조 및 구문에 대한 유일한 제한이 파이프 라인 특정 시스템이 아닌 Groovy 자체에 의해 정의되는 경향이있는 한 매우 적은 제한을 제공하므로 고급 사용자와 더 복잡한 요구 사항을 가진 사용자에게 이상적인 선택입니다. 이름에서 알 수 있듯이 Declarative Pipeline은 선언적 프로그래밍 모델을 권장합니다. 스크립팅 된 파이프 라인은보다 명령적인 프로그래밍 모델을 따릅니다.

https://jenkins.io/doc/book/pipeline/syntax/#compare 에서 복사


5
나는 일련의 선언적 파이프 라인 작업을 스크립팅 된 파이프 라인으로 옮기려고했습니다. "파워 유저와 더 복잡한 요구 사항을 가진 사람들에게 이상적인 선택"이었기 때문입니다. 스크립팅 된 파이프 라인에 대한 문서는 거의 없습니다. 없음. 이것처럼 거의 쓸모가 없습니다. 이것은 사람들이 알아야 할 큰 차이입니다.
cauchy

6
@cauchy 스크립팅 된 파이프 라인과 선언적 파이프 라인 모두에 대해 동일한 문서가 있지만 스크립팅은 고급 사용자를위한 것이기 때문에 먼저 표시되는 것은 아니지만 모든 문서에는 스크립팅 된 파이프 라인과 선언적 파이프 라인 문서와 예제가 모두 포함되어 있습니다. 선언적 파이프 라인의 각 문서 예 아래에서 scipted 구문을 토글하기 만하면됩니다
Ilhicas 2018 년

1
@Ilhicas 어디? 사용자 핸드북에는 "토글"이 없습니다. 링크가 있습니까? 스크립팅 된 파이프 라인의 파이프 라인 단계조차도 선언적 파이프 라인 및 선언적 파이프 라인 문서에 대한 링크와 차이가 없다고 말하며 이는 오해의 소지가 있습니다.

3
@cauchy 예제 jenkins.io/doc/book/pipeline , 아래에는 선언적 파이프 라인에 해당하는 스크립트를 확장하는 jenkins.io/doc/book/pipeline/# 로 이동하는 토글이 있습니다
Ilhicas

문제는 "다음은 선언적 파이프 라인 구문을 사용하는 Jenkinsfile의 예입니다. 아래의 스크립트 된 파이프 라인 토글 링크를 클릭하여 해당하는 스크립트 구문에 액세스 할 수 있습니다."문서를 제대로 읽지 않았을 때 발생합니다. 이것은 공식 문서에 있습니다! 읽기, 그러면 그러한 진술을 할 수 있습니다. 그들이 사실이라면 ..
Ilhicas

57

고려해야 할 또 다른 사항은 선언적 파이프 라인에 script () 단계가 있다는 것 입니다. 스크립팅 된 모든 파이프 라인을 실행할 수 있습니다. 따라서 필자는 선언적 파이프 라인을 사용하고 필요한 경우 script()스크립팅 된 파이프 라인을 사용하는 것이 좋습니다 . 따라서 두 세계의 장점을 모두 얻을 수 있습니다.


3
선언적 파이프 라인에서 script () 블록을 사용하는 예가 있습니까? 링크가 없습니다.
user2023861

script선언적 파이프 라인에서 블록을 몇 번 사용하는 경우 스크립트 파이프 라인을 항상 사용하는 것을 고려해야합니다.
Kru

@CodyK가 언급했듯이 스크립팅 된 파이프 라인보다 선언적 파이프 라인을 선호합니다. 예, 스크립팅 된 파이프 라인을 사용할 수있는 몇 가지 복잡한 상황에 동의합니다. 그러나 prope 단순화 된 계획은 항상 복잡성을 줄이고 대부분의 경우보다 단순한 선언적 파이프 라인을 향한 길을 닦을 것입니다.
NIK

18

최근에 kubernetes 에이전트로 스크립팅 된 것에서 선언적으로 전환했습니다. 2018 년 7 월까지 선언적 파이프 라인은 kubernetes pod를 지정할 수있는 완전한 기능이 없었습니다. 그러나 yamlFile단계를 추가 하면 이제 저장소의 yaml 파일에서 포드 템플릿을 읽을 수 있습니다.

그러면 예를 들어 vscode의 훌륭한 kubernetes 플러그인을 사용하여 포드 템플릿의 유효성을 검사 한 다음 Jenkinsfile로 읽어 들여 원하는대로 컨테이너를 사용할 수 있습니다.

pipeline {
  agent {
    kubernetes {
      label 'jenkins-pod'
      yamlFile 'jenkinsPodTemplate.yml'
    }
  }
  stages {
    stage('Checkout code and parse Jenkinsfile.json') {
      steps {
        container('jnlp'){
          script{
            inputFile = readFile('Jenkinsfile.json')
            config = new groovy.json.JsonSlurperClassic().parseText(inputFile)
            containerTag = env.BRANCH_NAME + '-' + env.GIT_COMMIT.substring(0, 7)
            println "pipeline config ==> ${config}"
          } // script
        } // container('jnlp')
      } // steps
    } // stage

위에서 언급했듯이 스크립트 블록을 추가 할 수 있습니다. 사용자 정의 jnlp 및 docker가있는 예제 포드 템플릿.

apiVersion: v1
kind: Pod
metadata:
  name: jenkins-pod
spec:
  containers:
  - name: jnlp
    image: jenkins/jnlp-slave:3.23-1
    imagePullPolicy: IfNotPresent
    tty: true
  - name: rsync
    image: mrsixw/concourse-rsync-resource
    imagePullPolicy: IfNotPresent
    tty: true
    volumeMounts:
      - name: nfs
        mountPath: /dags
  - name: docker
    image: docker:17.03
    imagePullPolicy: IfNotPresent
    command:
    - cat
    tty: true
    volumeMounts:
      - name: docker
        mountPath: /var/run/docker.sock
  volumes:
  - name: docker
    hostPath:
      path: /var/run/docker.sock
  - name: nfs
    nfs:
      server: 10.154.0.3
      path: /airflow/dags

1
이것은 내가 일년 본 것 중 가장 도움이 답입니다 : D 덕분에
트레버 루돌프

14

declarative는 미래에 대비 한 옵션이며 사람들이 권장하는 옵션 인 것으로 보입니다. Visual Pipeline Editor가 지원할 수있는 유일한 것입니다. 유효성 검사를 지원합니다. 대부분의 컨텍스트에서 스크립팅 된 것으로 대체 할 수 있으므로 스크립팅 된 기능의 대부분을 차지하게됩니다. 때때로 누군가가 선언적으로하고 싶은 일을 할 수없는 유스 케이스를 떠올리지 만, 이것은 일반적으로 한동안 스크립트를 사용해온 사람들이며 이러한 기능 격차는 시간이 지나면 사라질 가능성이 높습니다.

더 많은 컨텍스트 : https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/


4
더 미래를 보장하는 것은 없으며 다른 청중과 목적을 제공하며 여기에 여러 다른 답변에서 언급했듯이 둘 다 동일한 기본 시스템을 가지고 있습니다. Declarative는 사용자를 제한하고 스크립트가 너무 많은 자유를 제공하므로 각각을 적용하려면 젠킨스에 대한 다양한 지식 수준에 있어야합니다.
Ilhicas

3
동의합니다. 이 답변은 내가 작성한 당시 최고 였지만 젠킨스 저자가 차이점을 더 잘 문서화하고 스크립트가 곧 사라지지 않는다는 것을 분명히 밝힌 것에 기쁩니다. :)
burnettk

7

Jenkins 문서는 두 유형을 올바르게 설명하고 비교합니다.

인용하자면 : "Scripted Pipeline은 Jenkins 사용자에게 엄청난 양의 유연성과 확장 성을 제공합니다. Groovy 학습 곡선은 일반적으로 주어진 팀의 모든 구성원에게 바람직하지 않으므로 Declarative Pipeline은 Jenkins Pipeline 작성.

둘 다 근본적으로 동일한 파이프 라인 하위 시스템입니다. "

자세한 내용은 https://jenkins.io/doc/book/pipeline/syntax/#compare에서 확인하세요.


1
  1. 선언적 파이프 라인은 'pipeline'이라는 레이블이 붙은 블록 내에서 정의되는 반면 스크립팅 된 파이프 라인은 '노드'내에서 정의됩니다.
  2. 구문-선언적 파이프 라인에는 'Stages', 'Steps'가 있습니다.
  3. 빌드가 실패하면 선언적 옵션이 해당 단계에서 빌드를 다시 시작할 수있는 옵션을 제공합니다. 이는 스크립트 옵션에서 사실이 아닙니다.
  4. 스크립팅에 문제가있는 경우 작업을 빌드하자마자 선언적인 사람이 알려 주지만 scripted의 경우 'Okay'단계를 통과하고 'Not ok'단계에서 오류를 발생시킵니다.

이것을 참조 할 수도 있습니다. 아주 좋은 읽기-> https://e.printstacktrace.blog/jenkins-scripted-pipeline-vs-declarative-pipeline-the-4-practical-differences/ @ Szymon.Stepniak https://stackoverflow.com/users/ 2194470 / szymon-stepniak? tab = profile


0

선언 파이프 라인은 받는 사람보다 훨씬 우수하다 스크립팅 파이프 라인 . 선언적 파이프 라인은 스크립트 단계 를 사용하여 스크립팅 된 파이프 라인이 할 수있는 모든 것을 실행할 수 있으며 많은 추가 기능이 있습니다.

또한 Declarative Pipeline은 Docker 또는 Kubernetes 와 같은 다양한 기술을 지원합니다 ( 여기 참조 ).

선언적 파이프 라인은 또한 미래를 대비합니다. 아직 개발 중이며 새로 도입 된 Matrix 기능 과 같은 새로운 기능이 최근 2019 년 말에 추가되었습니다.

tl; dr-선언적 파이프 라인은 스크립팅 된 파이프 라인이 할 수있는 모든 것을 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.