Ssoon
1주 : Jenkins CI/CD + Docker : 3 본문
CloudNet@ 가시다님이 진행하는 CI/CD 맛보기 스터디
✅ Jenkins 기본 사용 : Job Configuration
🧿 Jenkins Item 생성 : item name(first) - docker 명령 실행 확인
Jenkins의 작업(Job)은 소프트웨어 개발 및 배포를 자동화하기 위해 설정되는 작업 단위입니다
Freestyle Project | 가장 기본적인 작업 유형으로, 단순한 빌드 및 테스트 작업을 수행할 수 있음 | - 단순한 스크립트 실행 - 단일 언어/프레임워크 기반 프로젝트 빌드 - 간단한 테스트 및 배포 |
Pipeline | Jenkinsfile을 사용해 복잡한 CI/CD 파이프라인을 정의하고 실행 | - 멀티 스테이지 빌드 및 배포 - 코드 분기 처리 - 테스트, 빌드, 배포 등 전체 프로세스 자동화 - YAML 형식으로 정의 가능 |
Multibranch Pipeline | 여러 Git 브랜치에 대해 파이프라인을 자동 생성하고 관리 | - 브랜치별 자동화 처리 - Git 관리 브랜치에 따라 자동화된 파이프라인 실행 - Pull Request 이벤트 처리 |
Folder | 여러 작업(Job)을 그룹화하여 관리 | - 관련된 작업을 그룹화해 관리 - 프로젝트별, 팀별 폴더 구성 - 권한 및 설정의 계층적 관리 |
GitHub Organization | GitHub 조직의 모든 리포지토리와 브랜치를 자동으로 탐색하여 멀티브랜치 파이프라인 생성 | - GitHub에 저장된 여러 프로젝트를 한 번에 관리 - 모든 리포지토리와 브랜치의 자동화된 빌드 파이프라인 |
External Job | 외부에서 실행된 작업을 Jenkins에서 추적 | - Jenkins 외부의 빌드 및 테스트 작업 추적 - 외부 스크립트나 서버와의 통합 |
Matrix Project | 여러 파라미터(예: OS, 브라우저) 조합으로 빌드 및 테스트 | - 다양한 환경에서 소프트웨어의 호환성 테스트 - 브라우저별 테스트 - 플랫폼별 빌드 |
Maven Project | Maven 기반 Java 프로젝트를 빌드하고 관리 | - Maven으로 관리되는 Java 프로젝트의 빌드, 테스트, 배포 - Maven 설정을 통한 종속성 관리 |
External Pipeline | 외부 시스템에서 정의된 파이프라인을 Jenkins에 통합 | - 클라우드 빌드/배포 작업 통합 - 기존 CI/CD 도구와의 통합 |
- 새로운 아이템을 생성합니다.
- Jenkins의 Build Steps는 빌드 작업(Job)을 실행하는 동안 수행해야 하는 개별 작업 단계를 설정하는 기능입니다.
- Build Steps는 소프트웨어를 빌드, 테스트, 배포하거나 스크립트를 실행하는 등의 작업을 포함합니다.
Execute Shell Shell 스크립트를 실행 - Linux 환경에서 빌드/테스트 스크립트 실행
- 파일 복사, 컴파일, 테스트 실행
- 커스텀 명령어 실행Execute Windows Batch Command Windows Batch 명령어를 실행 - Windows 환경에서 빌드 스크립트 실행
- cmd 명령어 실행
- Windows 프로그램 빌드 및 배포Invoke Ant Apache Ant를 사용해 빌드 및 테스트 - Java 기반 프로젝트 빌드
- Ant 스크립트를 통한 컴파일 및 테스트Invoke Gradle Script Gradle 스크립트를 실행 - Gradle로 관리되는 프로젝트 빌드 및 테스트
- Java, Kotlin, Android 프로젝트 빌드
- Jenkins의 Console Output은 빌드 실행 중 발생하는 모든 출력 내용을 실시간으로 보여주는 기능입니다.
- Jenkins의 Workspace는 빌드 작업(Job)이 실행되는 동안 필요한 파일과 데이터를 저장하는 작업 전용 디렉터리입니다.
소스 코드 저장 | 버전 관리 시스템(Git, SVN 등)에서 가져온 소스 코드가 저장됩니다. | - Git 리포지토리에서 코드 다운로드 - git clone 명령 실행 후 파일들이 저장됨 |
빌드 파일 생성 | 빌드 중 생성된 파일(컴파일 결과물, 로그 등)이 저장됩니다. | - 컴파일된 바이너리 파일 - 생성된 .jar, .war 파일 |
스크립트 실행 위치 | 빌드 스크립트와 명령어가 실행되는 위치입니다. | - Shell 스크립트 실행 - 빌드 도구(Maven, Gradle) 실행 |
캐시 및 임시 파일 | 빌드에 필요한 임시 파일이나 캐시 데이터가 저장됩니다. | - 테스트 결과 파일 - 설치된 라이브러리 캐시 |
Workspace의 구조
Jenkins의 Workspace는 기본적으로 다음과 같은 디렉터리 구조를 가집니다:
- {JOB_NAME}: 작업 이름에 따라 개별 디렉터리가 생성됩니다.
/var/lib/jenkins/workspace/{JOB_NAME}/
Workspace의 주요 특징
- 빌드별 독립성:
- 각 작업(Job)은 고유한 Workspace를 가지며, 다른 작업의 데이터와 충돌하지 않음.
- 빌드 중 데이터 임시 저장:
- 빌드가 완료되면 필요한 데이터를 아카이브하거나 배포 후 삭제 가능.
- 멀티 브랜치 파이프라인 지원:
- 브랜치별로 독립적인 Workspace가 생성됨.
- 청소 가능:
- 오래된 파일이나 불필요한 데이터를 Workspace Cleanup 플러그인을 통해 삭제 가
[ssoon@localhost dev-app]$ docker compose exec jenkins ls /var/jenkins_home/workspace
first
🧿 Jenkins 에 Gogs Repo 자격증명 설정
Jenkins의 Credential(자격 증명)은 Jenkins가 외부 시스템(예: Git 저장소, 배포 서버, 클라우드 서비스 등)과 안전하게 통신하기 위해 사용하는 인증 정보입니다. Jenkins는 빌드 및 배포 자동화를 지원하기 위해 다양한 외부 리소스와 연결되며, Credential은 이러한 연결에서 필요한 인증을 간단하고 안전하게 관리하도록 도와줍니다.
Credential의 주요 역할
- 외부 서비스 인증
- Git 저장소, Docker 레지스트리, 클라우드 API(GCP, AWS 등) 등에 접근하기 위해 필요한 인증 정보를 저장.
- 보안 강화
- 비밀번호, API 키 등 민감한 정보를 작업 스크립트에 직접 노출하지 않고 안전하게 관리.
- 중앙 집중 관리
- 여러 작업(Job)에서 동일한 자격 증명을 재사용 가능.
Jenkins Credential의 주요 유형
Username with Password | 사용자 이름과 비밀번호를 저장. | - Git 저장소 인증 - SSH 접속 시 사용자 이름과 비밀번호 사용 |
SSH Username with Private Key | SSH 키 인증 정보를 저장. | - Git 저장소에서 SSH 인증 - 원격 서버 접근 시 SSH 키 사용 |
Secret Text | 비밀번호, API 키, 토큰과 같은 단순 텍스트 데이터를 저장. | - 클라우드 서비스 API 키 - Personal Access Token(PAT) |
Secret File | 인증서, JSON 키 파일 등 파일 형태로 제공되는 자격 증명 데이터를 저장. | - Google Cloud Service Account 키 파일 - 보안 인증서 |
Certificate | PKCS#12 형식의 인증서를 저장. | - HTTPS를 사용하는 서비스 인증서 관리 |
Docker Host Certificate Authentication | Docker 데몬에 접근하기 위해 필요한 인증 정보를 저장. | - Docker Swarm, Kubernetes 인증 |
Credential의 저장 위치
- Jenkins는 자격 증명을 Encrypted Secrets Storage에 안전하게 저장하며, 관리자는 Jenkins 관리 페이지에서 이를 설정 및 관리할 수 있습니다.
- Jenkins 관리를 클릭합니다.
- Credentials 를 클릭합니다.
- Add credentials 을 클릭합니다.
- Kind : Username with password
- Username : devops
- Password : <Gogs dev-app 토큰>
- ID : gogs-dev-app
- 생성된 credentials 정보를 확인합니다.
🧿 Jenkins Item 생성 : item name(second) - 소스코드관리(Git) 설정 + 빌드 파라미터
- 새로운 아이템을 생성합니다.
Jenkins의 Parameter는 빌드 작업(Job)을 실행할 때 사용자로부터 입력을 받아 빌드 과정에 반영할 수 있도록 하는 기능입니다. 쉽게 말해, 사용자가 빌드를 실행할 때 설정할 수 있는 변수입니다.
Parameter를 사용하면 같은 작업(Job)이라도 입력 값에 따라 다르게 동작하도록 설정할 수 있습니다.
Parameter의 주요 역할
- 사용자 입력 수집:
- 빌드 실행 시 사용자로부터 특정 값(예: 브랜치 이름, 버전 번호)을 입력받아 사용.
- 빌드 동작 제어:
- 입력받은 값을 빌드 스크립트, 환경 변수 등에서 활용하여 빌드 동작을 변경.
- 재사용성 향상:
- 하나의 Job을 여러 상황에서 재사용 가능.
Parameter 유형과 설명
String Parameter | 문자열 값을 입력받음. | - 브랜치 이름 입력 - 환경 변수 값 설정 |
Boolean Parameter | 참/거짓(True/False) 값을 선택하도록 함. | - 기능 활성화 여부 제어 - 테스트 실행 여부 설정 |
Choice Parameter | 미리 정의된 값 중 하나를 선택. | - 배포 환경 선택(예: dev, staging, production) |
File Parameter | 빌드 시 사용될 파일 업로드. | - 테스트 데이터 업로드 - 설정 파일 교체 |
Password Parameter | 비밀번호나 민감한 정보를 입력받음(화면에 노출되지 않음). | - 데이터베이스 비밀번호, API 키 입력 |
Run Parameter | 특정 Jenkins 빌드 번호를 선택하여 참조. | - 이전 빌드 결과를 사용해야 하는 작업 |
Git Parameter (플러그인) | Git 리포지토리의 브랜치, 태그 등을 선택 가능(플러그인 설치 필요). | - 특정 Git 브랜치를 선택하여 빌드 |
Active Choices Parameter (플러그인) | 스크립트를 기반으로 동적으로 선택 목록 생성(플러그인 설치 필요). | - 현재 Git 태그 목록 가져오기 - 동적 환경 변수 목록 표시 |
Jenkins의 소스 코드 관리(Source Code Management) 기능은 빌드 작업(Job)이 소스 코드 저장소에서 필요한 코드를 자동으로 가져와 빌드를 수행할 수 있도록 설정하는 기능입니다. Jenkins는 다양한 소스 코드 관리 시스템(SCM)과 연동을 지원하며, 이를 통해 코드 변경 사항을 감지하고 빌드 프로세스를 자동화할 수 있습니다.
소스 코드 관리의 주요 역할
- 코드 다운로드:
- Git, Subversion(SVN) 등과 같은 소스 코드 저장소에서 코드를 Jenkins 작업 공간(Workspace)으로 가져옴.
- 자동화 트리거:
- 저장소에서 코드가 변경될 때 이를 감지하여 자동으로 빌드를 실행.
- 코드 버전 관리:
- 특정 브랜치, 태그, 커밋에 따라 코드를 가져와 빌드 수행 가능.
- 소스코드관리에서 Git을 선택하고 설정합니다.
- Repository URL : http://***<mac IP>***:3000/***<Gogs 계정명>***/dev-app ← .git 은 제거
- Credentials +Add 클릭(Jenkins :
- Branches to build (Branch Specifier) : */main
- uild Steps : Execute shell 에 입력합니다.
- Save 후 ‘파라미터와 함께 빌드’ 을 시작합니다.
- Console Output을 확인합니다.
- workspace을 확인합니다.
[ssoon@localhost dev-app]$ docker compose exec jenkins ls /var/jenkins_home/workspace
first second second@tmp
[ssoon@localhost dev-app]$ docker compose exec jenkins tree /var/jenkins_home/workspace/second
/var/jenkins_home/workspace/second
├── Dockerfile
├── README.md
├── VERSION
└── server.py
1 directory, 4 files
[ssoon@localhost dev-app]$ docker compose exec jenkins ls -l /var/jenkins_home/workspace/second
total 16
-rw-r--r--. 1 jenkins jenkins 95 Dec 2 17:20 Dockerfile
-rw-r--r--. 1 jenkins jenkins 11 Dec 2 17:20 README.md
-rw-r--r--. 1 jenkins jenkins 6 Dec 2 17:20 VERSION
-rw-r--r--. 1 jenkins jenkins 755 Dec 2 17:20 server.py
✅ Jenkins 파이프라인
🧿 Jenkins Plugin 설치
Jenkins의 플러그인(Plugin) 은 Jenkins의 기본 기능을 확장하거나 새로운 기능을 추가할 수 있는 소프트웨어 모듈입니다. 플러그인을 사용하면 Jenkins를 특정 요구 사항에 맞게 커스터마이징하고 다양한 도구 및 서비스와 연동할 수 있습니다.
플러그인의 주요 역할
- 기능 확장:
- Jenkins에 기본적으로 없는 새로운 기능 추가.
- 예: Slack 알림, Docker 통합, Kubernetes 배포 등.
- 외부 서비스 통합:
- Git, Maven, Gradle, AWS, GCP 등 다양한 외부 도구 및 서비스와의 연동 지원.
- 자동화 지원:
- 빌드, 테스트, 배포와 같은 작업을 더 효율적으로 수행할 수 있도록 도와줌.
- Pipeline Stage View - Docs
- Docker Pipeline : building, testing, and using Docker images from Jenkins Pipeline - Docs
- Gogs : Webhook Plugin - Docs
🧿 Jenkins 도커 계정/암호 자격 증명 설정
- Username : <도커 계정명>
- Password : <도커 계정 암호>
- ID : dockerhub-credentials ⇒ 자격증명 이름으로, pipeline 사용 예정
🧿 Jenkins Pipeline : Item : First-Pipeline
- 새로운 아이템을 생성합니다.
Jenkins의 Pipeline은 빌드, 테스트, 배포와 같은 소프트웨어 개발 프로세스를 자동화하는 데 사용되는 코드를 기반으로 한 워크플로우입니다.
Pipeline 기본 구조
- Pipeline: 전체 작업의 흐름을 정의.
- Stages: 작업의 주요 단계를 구분.
- Steps: 각 단계에서 실행할 세부 작업을 정의.
pipeline | 파이프라인의 전체 구조를 정의. | pipeline { agent any stages { ... } } |
agent | Pipeline이 실행되는 환경 정의. (예: Docker, any, 특정 노드 등) | agent { docker { image 'node:14' } } |
stages | Pipeline의 주요 단계를 정의. | stages { stage('Build') { steps { ... } } } |
stage | 단일 작업 단계를 나타냄. | stage('Test') { steps { echo 'Running tests...' } } |
steps | 각 단계(stage)에서 실행할 작업들. | steps { sh 'npm install' } |
environment | 빌드에 필요한 환경 변수 설정. | environment { ENV_NAME = 'production' } |
post | 작업 완료 후 실행되는 작업 정의. 성공, 실패 시 별도 작업 실행 가능. | post { success { echo 'Build Successful!' } } |
- Hello World 테스트 → 지금 빌드
Pipeline 동작 흐름
- Agent 선언:
- agent any: Jenkins가 어떤 노드든 작업을 실행하도록 허용.
- Stages 정의:
- Stage 1: Hello
- Jenkins는 "Hello World"라는 메시지를 출력.
- 단순한 로그 출력 작업입니다.
- Stage 2: Deploy
- Jenkins는 "Deployed successfully!"라는 메시지를 출력.
- 실제 배포 작업 없이 성공 메시지만 출력하는 단계입니다.
- Stage 1: Hello
- console output 을 확인합니다.
- 구성을 클릭하고 수정 (환경변수 사용, 문자열 보간) 합니다.
Pipeline 동작 흐름
- 환경 변수 초기화:
- CC는 파이프라인 전체에서 사용 가능.
- AN_ACCESS_KEY는 Example 스테이지에서만 유효.
- Example Stage 실행:
- echo "${CC}" 명령어는 글로벌 환경 변수 CC 값을 Jenkins 콘솔에 출력.
결과: clang - sh 'echo ${AN_ACCESS_KEY}' 명령은 쉘 스크립트에서 현재 stage 환경 변수 AN_ACCESS_KEY 값을 출력.
결과: abcdefg
- echo "${CC}" 명령어는 글로벌 환경 변수 CC 값을 Jenkins 콘솔에 출력.
pipeline {
agent any
environment {
CC = 'clang'
}
stages {
stage('Example') {
environment {
AN_ACCESS_KEY = 'abcdefg'
}
steps {
echo "${CC}";
sh 'echo ${AN_ACCESS_KEY}'
}
}
}
}
- Console Output을 확인합니다.
- 구성을 클릭하고 수정 ( CRON 트리거를 사용 ) 합니다.
Pipeline 동작
- 1분마다 실행:
- 트리거에 따라 Jenkins가 매 1분마다 파이프라인을 실행.
- Example Stage 실행:
- Jenkins는 echo 'Hello World' 명령어를 실행.
- 결과는 콘솔 로그에 출력됩니다.
pipeline {
agent any
triggers {
cron('* * * * *') // 1분마다 실행
}
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
}
- 1분마다 실행되는것을 확인합니다.
- 구성을 클릭하고 수정 ( 파라미터와 함께 빌드 ) 합니다.
Pipeline 동작
- 빌드 시작 시 사용자 입력 요청:
- Jenkins는 빌드를 시작하기 전에 입력 폼을 표시.
- 사용자는 각 매개변수에 값을 입력하거나 기본값을 사용할 수 있음.
- Example Stage 실행:
- 입력받은 매개변수 값이 파이프라인의 각 단계에서 사용됨.
- 예를 들어, echo "Hello ${params.PERSON}"은 PERSON에 입력된 값을 출력.
pipeline {
agent any
parameters {
string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
text(name: 'BIOGRAPHY', defaultValue: 'SSOON', description: 'Enter some information about the person')
booleanParam(name: 'TOGGLE', defaultValue: true, description: 'Toggle this value')
choice(name: 'CHOICE', choices: ['One', 'Two', 'Three'], description: 'Pick something')
password(name: 'PASSWORD', defaultValue: 'SECRET', description: 'Enter a password')
}
stages {
stage('Example') {
steps {
echo "Hello ${params.PERSON}"
echo "Biography: ${params.BIOGRAPHY}"
echo "Toggle: ${params.TOGGLE}"
echo "Choice: ${params.CHOICE}"
echo "Password: ${params.PASSWORD}"
}
}
}
}
- 다시 한번 더 빌드 클릭 (변수 입력 칸 확인)
- 구성을 클릭하고 수정 ( post (빌드 후 조치) ) 합니다.
Jenkins Pipeline의 post 블록은 파이프라인 실행 후에 특정 작업을 정의할 수 있는 부분입니다. 파이프라인이 끝난 후, 성공/실패/중단 여부와 관계없이 후속 작업을 수행하는 데 유용합니다.
always | 빌드가 성공, 실패, 중단 여부와 관계없이 항상 실행됩니다. | echo 'This will always run.' |
success | 빌드가 성공적으로 완료된 경우에만 실행됩니다. | echo 'Build was successful!' |
failure | 빌드가 실패한 경우에만 실행됩니다. | echo 'Build failed! Please check the logs.' |
aborted | 빌드가 중단된 경우에만 실행됩니다. | echo 'Build was aborted!' |
Pipeline 동작
- Example Stage 실행:
- Hello World 메시지를 콘솔에 출력.
- Post 단계 실행:
- 파이프라인이 끝나고 어떤 결과와 관계없이 I will always say Hello again!라는 메시지가 출력됩니다.
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
always {
echo 'I will always say Hello again!'
}
}
}
- Console Output을 확인합니다.
- 구성을 클릭하고 수정 ( 빌드 단계 별 로그 ) 합니다.
- stages 블록은 빌드 파이프라인을 단계별로 나눠서 실행합니다.
- 각 stage 안에 steps 블록을 사용해 수행할 작업들을 정의합니다.
- 이 예제에서는 각 단계에서 echo 명령어로 성공적인 작업을 콘솔에 출력하고 있습니다. 실제 프로젝트에서는 각 스테이지에 해당하는 실제 작업(예: 컴파일, 테스트 실행, 코드 분석, 배포)을 추가할 수 있습니다.
pipeline {
agent any
stages {
stage('Compile') {
steps {
echo "Compiled successfully!";
}
}
stage('JUnit') {
steps {
echo "JUnit passed successfully!";
}
}
stage('Code Analysis') {
steps {
echo "Code Analysis completed successfully!";
}
}
stage('Deploy') {
steps {
echo "Deployed successfully!";
}
}
}
}
- Console Output을 확인합니다.
- 구성을 클릭하고 수정 ( 빌드 성공 실패 등 메시지 출력 ) 합니다.
- stages는 파이프라인의 작업 단계를 정의하고, 각 단계에서 특정 작업을 실행합니다.
- post는 파이프라인이 완료된 후 실행할 후속 작업을 정의합니다.
- always, success, failure, unstable, changed 조건에 따라 실행됩니다.
- post 블록을 활용하면 빌드 성공/실패에 따른 알림, 후처리 작업 등을 자동화할 수 있습니다.
pipeline {
agent any
stages {
stage('Compile') {
steps {
echo "Compiled successfully!";
}
}
stage('JUnit') {
steps {
echo "JUnit passed successfully!";
}
}
stage('Code Analysis') {
steps {
echo "Code Analysis completed successfully!";
}
}
stage('Deploy') {
steps {
echo "Deployed successfully!";
}
}
}
post {
always {
echo "This will always run"
}
success {
echo "This will run when the run finished successfully"
}
failure {
echo "This will run if failed"
}
unstable {
echo "This will run when the run was marked as unstable"
}
changed {
echo "This will run when the state of the pipeline has changed"
}
}
}
- Console Output을 확인합니다.
- 빌드 실행 결과 정보 확인 : 상단에 결과 정보 확인
✅ Jenkins Item 생성(Pipeline) : pipeline-ci
- 새로운 아이템을 생성합니다.
Pipeline 흐름
- Checkout:
- Git에서 main 브랜치를 체크아웃하고, 인증 정보를 사용해 코드를 다운로드합니다.
- Read VERSION:
- VERSION 파일을 읽고 그 내용을 버전으로 설정하여 Docker 이미지 태그로 사용합니다.
- Docker Build and Push:
- Docker 이미지를 빌드하고, Docker Hub에 푸시합니다.
- post 블록:
- 파이프라인 실행 후 성공 또는 실패에 따라 후처리 작업을 실행합니다.
pipeline {
agent any
environment {
DOCKER_IMAGE = 'kschoi728/dev-app' // Docker 이미지 이름
}
stages {
stage('Checkout') {
steps {
git branch: 'main',
url: 'http://192.168.56.105:3000/devops/dev-app.git', // Git에서 코드 체크아웃
credentialsId: 'gogs-dev-app' // Credentials ID
}
}
stage('Read VERSION') {
steps {
script {
// VERSION 파일 읽기
def version = readFile('VERSION').trim()
echo "Version found: ${version}"
// 환경 변수 설정
env.DOCKER_TAG = version
}
}
}
stage('Docker Build and Push') {
steps {
script {
docker.withRegistry('https://index.docker.io/v1/', 'dockerhub-credentials') {
// DOCKER_TAG 사용
def appImage = docker.build("${DOCKER_IMAGE}:${DOCKER_TAG}")
appImage.push()
}
}
}
}
}
post {
success {
echo "Docker image ${DOCKER_IMAGE}:${DOCKER_TAG} has been built and pushed successfully!"
}
failure {
echo "Pipeline failed. Please check the logs."
}
}
}
- 이 Jenkins Pipeline은 Docker 이미지를 빌드하고 Docker Hub에 푸시하는 작업을 자동화하는 흐름을 제공합니다.
- stages 블록에서는 Git 체크아웃, 버전 읽기, Docker 빌드 및 푸시 작업을 순차적으로 처리합니다.
- post 블록에서는 파이프라인 실행 결과에 따라 후속 작업(성공/실패 시의 메시지 출력)을 설정합니다.
- Docker 이미지의 태그는 VERSION 파일에서 읽은 버전 정보로 설정됩니다.
- dockerhub 에 push 된 이미지를 확인합니다.
- vscode 에서 imge 를 확인합니다.
'CICD 맛보기' 카테고리의 다른 글
2주 : GitHub Actions CI/CD : 2 (1) | 2024.12.12 |
---|---|
2주 : GitHub Actions CI/CD : 1 (0) | 2024.12.11 |
1주 : Jenkins CI/CD + Docker : 4 (2) | 2024.12.05 |
1주 : Jenkins CI/CD + Docker : 2 (0) | 2024.12.03 |
1주 : Jenkins CI/CD + Docker : 1 (0) | 2024.12.02 |