말은 쉽지, 코드를 보여줘!

조직 내부에서 사용되는 라이브러리는 SNAPSHOT 버전으로 만들어서 내부 Nexus 에 저장해서 사용하곤 한다. 빌드툴에서는 기본적으로 버전이 변경될 경우에만 원격저장소와 로컬저장소의 의존성을 비교해서 더 최근버전일 경우 로컬저장소로 다운로드해서 빌드에 활용한다. 하지만 내부에서 사용해서 수정이 잦은 라이브러리의 경우 매번 버저닝을 하기도 번거롭고 이를 사용하는 곳도 버저닝을 적용해야 하는 번거로움 때문에 버저닝 없이도 원격저장소와 로컬저장소를 비교하게 하고 싶을 수 있다. 이를 위한 pom.xml 설정이 아래와 같다. ... ... ... true always true always updatePolicy 가 언제 원격저장소와 로컬저장소를 비교할지에 대한 설정인데 SNAPSHOT 버전은 이렇게 지정하지..

Jenkins 에서는 Kubernetes 환경을 위한 플러그인을 제공한다. Jenkins 에서는 마스터노드에서 전체 잡을 관리하지만 실제 잡 수행은 슬레이브 노드에서 하도록 하는 것이 일반적인데 이 경우 슬레이브 노드가 실제로 아무일도 하지 않는 유휴시간 동안에도 자원을 차지한다는 단점이 있다. 이에 Kubernetes 일 경우 슬레이브 노드 대신 컨테이너에서 잡을 수행하도록 하고 작업이 끝나면 해당 컨테이너도 종료하는 방식이다. 그림으로 표현하자만 대략 아래와 같다. 이를 위해서는 일단 마스터노드에서 Kubernetes 클러스터를 연동해야 하는데 자꾸 헷갈려서 그 방식을 기록해둔다. 사용한 Jenkins 버전은 Jenkins 2.361.4 이다. 아래 메뉴에서 연동할 클러스터 정보를 입력할 수 있다. ..

gradle 에서 특정 플러그인의 버전을 올리면 아래와 같은 에러가 뜨면서 의존성 갱신이 안되는 경우가 있다. Plugin [id: 'org.jetbrains.kotlin.jvm', version: '1.7.20'] was not found in any of the following sources: * Try: > Run with --info or --debug option to get more log output. > Run with --scan to get full insights. * Exception is: org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'org.jetbrains.kotlin.jvm', version: '1.7.20'] w..

https://proandroiddev.com/dependencies-versions-in-gradle-kotlin-dsl-a8db15cedee2 Dependencies versions in Gradle Kotlin DSL Common places for defining dependencies version proandroiddev.com

pom/project 빌드 : ${project.build.directory} = ${pom.build.directory} = ‘target’; 빌드 : ${project.build.outputDirectory} = ‘target/classes’; 프로젝트 이름 : ${project.name} = ${pom.name} = / 엘리먼트 설정 값; 프로젝트 버전 : ${project.version} = ${pom.version} = ${version} = / 엘리먼트 설정 값; 최종 파일 이름 : ${project.build.finalName}= // 엘리먼트 설정 값 settings 로컬 저장소 경로 : ${settings.localRepository} environment variable 시스템 PATH..

잘 사용하던 Jenkins 에서 위와 같은 메시지를 출력하며 신규 잡 생성이 안된다. 기존 잡 동작은 정상이다. Jenkins 관리 > System Log 로 이동해서 로그 화면을 열어 위에 명시된 Logging ID 로 조회해보니 아래와 같은 에러가 확인됐다. job 관련 디렉토리가 생성되었는데 이게 read-only 라는 거 같다. 응? 기존에는 잘 생성되었는데 왜 갑자기? 더 신기한 것은 젠킨스는 이외에도 많이 있고 모두 k8s 환경에 helm 으로 구축했다. 관련 yaml 파일을 확인해보니 딱히 다른 게 발견되지 않았다.. 그런데 실제 위 Jenkins 컨테이너에 접속해서 /var/jenkins_home/jobs 디렉토리에 mkdir 로 아무 디렉토리나 생성해보려고 했는데 진짜 아래와 같은 에러를..

Maven 이든 Gradle 이든 최근에 Wrapper 만 사용하다보니 별도 구축된 빌드툴을 활용한 젠킨스 잡 구성이 잘 기억나지 않아 작업내역을 기록해 놓는다. Wrapper 를 사용하는 것과 일부 겹치기도 한다. 여기에서는 Jenkins Pipeline 를 이용해서 잡을 만들 예정이며 Scripted Pipeline 를 사용할 예정이다. 그리고 젠킨스 내 잡에 스크립트를 포함하지 않고 각 프로젝트에 Jenkinsfile 이라는 파일에 포함하는 방식을 사용한다. 참고로 Pipeline 작성방법은 Scripted Pipeline, Declarative Pipeline 두가지가 존재하는데 Declarative Pipeline 이 더 나중에 도입되었고 Jenkins Community 에서도 지향하는 방식이라..

plugin을 정의할 때 태그를 추가로 정의하는 경우를 볼 수 있다. 이는 해당 플러그인의 goal을 특정 phase 에 연결해서 실행되게 하는 설정이다. maven-compiler-plugin 3.8.0 package compile 예를 들어 위와 같이 지정했다면 mvn package 명령 수행시 아래와 같은 package phase에 해당하는 작업이 모두 수행된 뒤에 위에서 지정한 compile goal이 추가로 수행된다.

SSH 방식 https://wiki.kicco.com/pages/viewpage.action?pageId=9732396 JNLP 방식 https://wiki.kicco.com/pages/viewpage.action?pageId=9732892 실제 Jenkins가 설치된 서버를 Master라 칭하고 이곳에서 모든 CI/CD를 담당할 경우 부하가 심해질 수 있으므로 Master에서는 전체적인 Job에 대한 관리만 하고 실제 CI/CD는 별도 Slave 서버에서 수행되도록 부하분산 처리를 할 수 있다. 이때 Slave 서버는 일반적으로 실제 서비스가 배포되어야 할 서버가 된다. 이 경우 Master 와 Slave 연동이 필요하게 되고 일반적으로 SSH 방식을 많이 사용하고 Master 에서 Slave 로 접근..

Jenkins Kubernetes Plagin 는 전통적인 마스터/슬레이브 구조 중 슬레이브를 Kubernetes Pod으로 구성하는 방식이다. 이는 일회성 컨테이너로 사용되고 잡 수행이 완료되면 자동으로 종료된다. 즉, 아래와 같은 구조가 된다. 구성 방법은 서칭하면 많이 나오니 생략하고 여기에서는 트러블 슈팅에 대해 이야기 하려고 한다. 일단 슬레이브는 무조건 k8s 컨테이너로 생성되어야 하기 때문에 이를 위한 쿠버네티스 클러스터가 필요하고 마스터는 해당 클러스터에 구축해도 되고 별도 클러스터에 구축해도 되고 아예 별도로 PM환경에 구축해도 된다. 여기에서 마스터를 슬레이브와 동일한 클러스터에 구성한다면 별도의 트러블을 경험하지 못하고 쉽게 구축할 수 있을 것이다. 다른 클러스터에 구축하거나 별도 P..