Jenkins pipeline Lock 사용법

배경

젠킨스 CI/CD 파이프라인을 구성하는 과정에서, 설정파일들이 변경되는 경우가 있었는데, 특히 application.yml 파일이 그러했다.

이는 프로젝트 git에는 올라가지 않기 때문에 수동으로 관리해주어야 했는데, 호스트 EC2에서 직접 관리하지 않고 application.yml, Dockerfile, docker-compose.yml 파일 등의 설정파일을 별도의 private git에 두어 이들이 변경점이 생기면 자동으로 pull 해오고 back 컨테이너에 한해서 다시 이미지를 민들어 컨테이너를 재가동하는 파이프라인을 만들었다.

그런데!

만약 application.yml 파일을 수정했는데 동시에 누가 back 브랜치를 push해서 동시에 back 컨테이너에 접근하면?🤔 이미 없는 컨테이너를 삭제하려고 하거나 동시에 2개의 컨테이너를 만들려다가 오류가 터질 수도 있다.

따라서 여러 파이프라인이 동시에 docker container에 안하게 컨테이너를 재시작하는 코드에 Lock을 걸어두었다.

🔒 Lock 사용법

Lockable Resources 플러그인 설치

Lockable Resources jenkins plugin을 설치해준다!

파이프라인 적용

steps 내부에 배타적 Lock을 사용할 수 있다. 즉, 해당 파이프라인만이 락을 소유하여 다른 파이프라인이 동시에 해당 락이 필요한 작업을 수행할 수 없고 락을 반환할 때까지 기다려야 한다.

Lock 이름은 사용자가 지정할 수 있으며, 전역적으로 jenkins에서 관리됨으로 동일한 이름을 가진 lock으로 파이프라인간 데이터 배타성을 보장할 수 있다.

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                lock('my-lock') {
                    // 실행할 작업 내용
                    sh 'echo "이 동작은 락이 걸려 다른 파이프라인에서 동시에 소유할 수 없습니다"
                }
            }
        }
    }
}

결과

• 해당 파이프라인을 동시에 2번 눌러서 돌아가게 하자 Lock을 걸어둔 stage는 동시에 진행되지 않고 먼저 락을 취득한 프로세스가 끝나기를 기다리는 것을 볼 수 있다.
• Lock을 남용하면 Deadlock이 발생하기도 하며 성능에 있어 좋은 방향은 아니다. 그리고 사진에서 볼 수 있듯 아무도 해당 Lock을 맨 처음에 사용할 때도 작지만 Lock을 보유하고 있는지 확인, 취득, 반납하는 과정에서 비용이 있으니 반드시 필요한 부분에만 사용하도록 하자🙌 (paused for 16ms)