Jenkins는 오픈소스 CI/CD(Continuous Integration & Continuous Deployment) 자동화 서버로, 소프트웨어 개발 과정에서 코드 빌드, 테스트, 배포를 자동화하는 데 사용됩니다. 특히 DevOps 및 DevSecOps 환경에서 필수적인 도구로 자리 잡고 있습니다.

1. Jenkins의 주요 기능

1.1 CI/CD 구축

Jenkins는 소프트웨어 개발 파이프라인을 자동화하는 데 핵심적인 역할을 합니다. 코드 변경이 감지되면 자동으로 빌드, 테스트, 배포를 실행하여 개발 속도를 높이고 품질을 유지할 수 있습니다.

1.2 정적 코드 분석 (SAST)

SonarQube, Semgrep과 같은 정적 코드 분석 도구와 연동하여 보안 취약점을 자동으로 검출할 수 있습니다.

1.3 동적 애플리케이션 보안 테스트 (DAST)

OWASP ZAP을 사용하여 애플리케이션을 배포한 후 동적 보안 테스트를 수행할 수 있습니다.

1.4 컨테이너 보안 및 배포

Docker 및 Kubernetes와 연동하여 컨테이너화된 애플리케이션의 보안 점검(Trivy 등)을 수행하고, 배포 프로세스를 자동화할 수 있습니다.

1.5 서버 및 인프라 자동화

Ansible, Terraform과 같은 인프라 자동화 도구와 통합하여 서버 프로비저닝을 자동화할 수 있습니다.

1.6 로그 모니터링 및 알림

Elasticsearch, Grafana, Prometheus와 같은 모니터링 도구와 연동하여 시스템 로그 및 성능 지표를 분석하고 알림을 설정할 수 있습니다.

2. Jenkins 설치 및 설정

2.1 설치 방법

Jenkins는 다양한 플랫폼에서 실행할 수 있으며, 다음과 같은 방법으로 설치할 수 있습니다.

  • Linux(Ubuntu/Debian)
sudo apt update
sudo apt install openjdk-11-jdk
wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt update
sudo apt install jenkins
sudo systemctl start jenkins
  • Docker 컨테이너에서 실행
docker run -p 8080:8080 -p 50000:50000 --name jenkins -d jenkins/jenkins:lts

2.2 초기 설정

설치 후 브라우저에서 http://localhost:8080으로 접속하여 초기 설정을 진행할 수 있습니다.

  1. /var/lib/jenkins/secrets/initialAdminPassword에 저장된 초기 비밀번호 입력
  2. 기본 플러그인 설치 또는 원하는 플러그인 선택하여 설치
  3. 관리자 계정 생성 후 Jenkins 대시보드 접속

3. Jenkins 플러그인 및 확장성

Jenkins는 플러그인을 통해 기능을 확장할 수 있습니다. 주요 플러그인은 다음과 같습니다.

  • Git 플러그인: GitHub, GitLab 등과 연동하여 코드 변경 감지
  • Pipeline 플러그인: Jenkinsfile을 사용한 코드 기반 CI/CD 파이프라인 구축
  • SonarQube 플러그인: 코드 품질 및 보안 분석 자동화
  • Docker 플러그인: 컨테이너 빌드 및 배포 자동화
  • Slack 플러그인: 빌드 결과 알림을 Slack으로 전송

4. Jenkins를 활용한 DevSecOps 자동화 실습

4.1 CI/CD 파이프라인 구축

Jenkinsfile을 사용하여 코드 변경 시 자동 빌드 및 배포를 설정할 수 있습니다.

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/example/repo.git'
            }
        }
        stage('Build') {
            steps {
                sh './gradlew build'
            }
        }
        stage('Test') {
            steps {
                sh './gradlew test'
            }
        }
        stage('Deploy') {
            steps {
                sh './deploy.sh'
            }
        }
    }
}

4.2 보안 자동화 (SAST + DAST + 컨테이너 보안)

pipeline {
    agent any
    stages {
        stage('SAST Analysis') {
            steps {
                sh 'semgrep --config=auto'
            }
        }
        stage('DAST Analysis') {
            steps {
                sh 'zap-baseline.py -t http://example.com'
            }
        }
        stage('Container Security Scan') {
            steps {
                sh 'trivy image example/app:latest'
            }
        }
    }
}

5. Jenkins vs GitHub Actions 비교

기능 Jenkins GitHub Actions
설치 방식 직접 서버 설치 필요 GitHub 제공, 설치 불필요
확장성 플러그인으로 확장 가능 GitHub 네이티브 기능 활용
비용 무료 (자체 호스팅) 퍼블릭 무료, 프라이빗 제한
CI/CD 속도 자체 서버 리소스 사용 GitHub 서버에서 실행
DevSecOps 활용 모든 보안 도구 연동 가능 일부 도구 제한

6. 결론

Jenkins는 강력한 CI/CD 및 DevSecOps 자동화 도구로, 지속적인 배포와 보안 강화를 동시에 수행할 수 있습니다. GitHub Actions에 비해 확장성과 유연성이 뛰어나며, 기업 환경에서도 비용 부담 없이 활용할 수 있습니다. 따라서 CI/CD와 DevSecOps를 함께 고려하는 경우, Jenkins를 활용한 자동화 파이프라인을 구축하는 것이 좋은 선택이 될 수 있습니다.

1️⃣ 개요

GitLab을 인터넷이 차단된 내부망에서 Docker를 활용하여 CPU와 메모리를 제한한 상태로 설치하는 방법을 정리합니다.
또한, GitLab 데이터를 /data/gitlab 경로 아래에 저장하고, HTTPS(SSL) 설정을 적용하여 보안성을 강화합니다.


2️⃣ 사전 준비

GitLab을 설치할 내부망 서버에는 Docker 및 Docker Compose가 필요합니다.

✅ 인터넷이 없는 환경이므로, 외부망에서 필요한 파일을 다운로드 후 내부망으로 옮겨야 합니다.


3️⃣ 내부망에서 Docker 설치

내부망 서버에 Docker가 설치되지 않은 경우, 외부망에서 패키지를 다운로드 후 내부망으로 이동하여 설치합니다.

(1) 외부망에서 Docker 패키지 다운로드

wget https://download.docker.com/linux/ubuntu/dists/jammy/pool/stable/amd64/containerd.io_1.6.27-1_amd64.deb
wget https://download.docker.com/linux/ubuntu/dists/jammy/pool/stable/amd64/docker-ce_25.0.2-1~ubuntu.22.04~jammy_amd64.deb
wget https://download.docker.com/linux/ubuntu/dists/jammy/pool/stable/amd64/docker-ce-cli_25.0.2-1~ubuntu.22.04~jammy_amd64.deb
wget https://download.docker.com/linux/ubuntu/dists/jammy/pool/stable/amd64/docker-compose-plugin_2.24.5-1~ubuntu.22.04~jammy_amd64.deb

(2) 내부망 서버로 패키지 전송

scp containerd.io_1.6.27-1_amd64.deb user@internal-server:/home/user/
scp docker-ce_25.0.2-1~ubuntu.22.04~jammy_amd64.deb user@internal-server:/home/user/
scp docker-ce-cli_25.0.2-1~ubuntu.22.04~jammy_amd64.deb user@internal-server:/home/user/
scp docker-compose-plugin_2.24.5-1~ubuntu.22.04~jammy_amd64.deb user@internal-server:/home/user/

(3) 내부망 서버에서 Docker 설치

sudo dpkg -i containerd.io_1.6.27-1_amd64.deb
sudo dpkg -i docker-ce-cli_25.0.2-1~ubuntu.22.04~jammy_amd64.deb
sudo dpkg -i docker-ce_25.0.2-1~ubuntu.22.04~jammy_amd64.deb
sudo dpkg -i docker-compose-plugin_2.24.5-1~ubuntu.22.04~jammy_amd64.deb

설치 확인:

docker --version
docker-compose version

4️⃣ 외부망에서 GitLab Docker 이미지 다운로드

외부에서 GitLab Docker 이미지를 미리 다운로드한 후 내부망으로 전송합니다.

(1) 외부망에서 GitLab EE 이미지 다운로드

docker pull gitlab/gitlab-ee:latest

(2) 다운로드한 이미지 저장

docker save -o gitlab-ee.tar gitlab/gitlab-ee:latest

(3) 내부망 서버로 전송

scp gitlab-ee.tar user@internal-server:/home/user/

5️⃣ 내부망에서 GitLab 실행 (리소스 제한 적용)

(1) 내부망에서 GitLab 이미지 로드

docker load -i gitlab-ee.tar

(2) /data/gitlab 디렉토리 생성

sudo mkdir -p /data/gitlab/config
sudo mkdir -p /data/gitlab/logs
sudo mkdir -p /data/gitlab/data
sudo chown -R 1000:1000 /data/gitlab

(3) Docker Compose 파일 작성 (docker-compose.yml)

version: '3.7'
services:
  gitlab:
    image: gitlab/gitlab-ee:latest
    restart: always
    hostname: 'gitlab.local'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.local'
        letsencrypt['enable'] = false
        nginx['redirect_http_to_https'] = true
        nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.crt"
        nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.key"
    ports:
      - "80:80"
      - "443:443"
      - "22:22"
    volumes:
      - /data/gitlab/config:/etc/gitlab
      - /data/gitlab/logs:/var/log/gitlab
      - /data/gitlab/data:/var/opt/gitlab
      - /data/gitlab/ssl:/etc/gitlab/ssl
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: "4GB"

(4) GitLab 컨테이너 실행

cd /data/gitlab
docker-compose up -d

6️⃣ GitLab 초기 설정 및 HTTPS 인증서 생성

mkdir -p /data/gitlab/ssl
cd /data/gitlab/ssl

openssl req -newkey rsa:4096 -nodes -keyout gitlab.key -x509 -days 365 -out gitlab.crt \
-subj "/C=KR/ST=Seoul/L=Seoul/O=InternalGitLab/OU=IT/CN=gitlab.local"

chmod 600 gitlab.*

 

 1. initialAdminPassword 파일 확인

젠킨스를 처음 설치할 때 생성된 initialAdminPassword 파일이 있을 수 있습니다. 이 파일에는 초기 관리자 비밀번호가 저장되어 있습니다.
 파일 위치는 일반적으로 /var/lib/jenkins/secrets/initialAdminPassword 또는 ~/.jenkins/secrets/initialAdminPassword에 위치합니다.
파일 내용을 확인하여 초기 관리자 비밀번호를 알아낼 수 있습니다.
해당 파일이 없는 경우, 비밀번호가 이미 변경된 상태입니다.

 

2. config.xml 수정(보안 설정 해제)

젠킨스가 설치된 서버에 접속하여 config.xml 파일을 찾습니다. 
파일 위치는 일반적으로 /var/lib/jenkins/config.xml 또는 ~/.jenkins/config.xml에 위치합니다.
config.xml 파일에서 <useSecurity>true</useSecurity> 부분을 찾아 false로 변경합니다.
젠킨스를 재시작합니다.
젠킨스에 접속하면 로그인 화면 없이 바로 접속됩니다.

 


3. 비밀번호 변경 혹은 새로운 사용자 추가

 

1️⃣ 보안 설정 확인

  • Security 메뉴에서 "Jenkins' own user database" 선택

2️⃣ 관리자 계정  확인

  • Users → (관리자 계정 선택) → 비밀번호 변경

4. 보안 설정 다시 활성화

config.xml 파일 수정
<useSecurity>true</useSecurity>

클라우드 환경에서 DevOps를 구현하는 방법은 다양합니다. 특히 CI/CD 파이프라인을 구축할 때 Azure DevOps, AWS DevOps, GCP DevOps와 같은 클라우드 네이티브 서비스를 사용할 수 있으며, GitLab Self-Managed와 같은 온프레미스 솔루션도 고려할 수 있습니다.

본 글에서는 각 클라우드 CI/CD 서비스의 특징과 온프레미스 GitLab 설치형 대비 장단점을 분석하고, 멀티 클라우드 전략을 선택할 경우 고려해야 할 사항에 대해 살펴보겠습니다. 또한, 아키텍트 관점에서 어떤 전략이 적절한지 논의합니다.

 

1. 클라우드 CI/CD 서비스 비교

(1) Azure DevOps

Microsoft의 Azure DevOps는 CI/CD, 코드 저장소, 프로젝트 관리, 빌드 및 배포 자동화를 통합 제공하는 서비스입니다.

특징:

  • Azure Pipelines를 통한 강력한 CI/CD 기능
  • Azure Repos (Git 저장소) 및 Azure Artifacts 제공
  • Azure Boards를 활용한 프로젝트 및 애자일 관리
  • 다양한 언어 및 환경 지원 (Windows, Linux, macOS, Kubernetes 등)
  • GitHub 및 외부 리포지토리 연동 가능
  • 온프레미스 환경에서도 Azure DevOps Server 활용 가능

⏩ 추천 대상: Azure 환경을 기반으로 DevOps를 구축하는 기업 및 조직


(2) AWS DevOps (Code Suite)

AWS는 개별 DevOps 서비스를 조합하여 CI/CD를 구성해야 합니다.

특징:

  • AWS CodePipeline: CI/CD 파이프라인 자동화
  • AWS CodeCommit: Git 기반 코드 저장소 (Azure Repos와 유사)
  • AWS CodeBuild: 빌드 자동화 (Azure Pipelines와 유사)
  • AWS CodeDeploy: EC2, Lambda, ECS 등 AWS 환경으로 배포 가능
  • AWS IAM(Identity & Access Management)과 강력한 보안 연계

⏩ 추천 대상: AWS 환경에서 DevOps를 최적화하고자 하는 기업


(3) GCP DevOps

GCP는 컨테이너 중심의 CI/CD 솔루션이 강점입니다.

특징:

  • Cloud Build: CI/CD 빌드 및 배포 자동화 (Jenkins 대체 가능)
  • Cloud Deploy: Kubernetes 기반 애플리케이션 배포
  • Artifact Registry: 컨테이너 이미지 및 패키지 저장소
  • Cloud Source Repositories: Git 기반 저장소 (Azure Repos, AWS CodeCommit과 유사)
  • Google Kubernetes Engine(GKE) 및 Anthos와 최적의 연동 제공

⏩ 추천 대상: Kubernetes 및 GCP 기반 마이크로서비스를 운영하는 기업


(4) GitLab Self-Managed (온프레미스)

GitLab은 Git 저장소뿐만 아니라 CI/CD, 패키지 관리, 보안 검사까지 올인원 DevOps 플랫폼을 제공합니다.

특징:

  • 온프레미스 환경에서 GitLab 서버를 운영 가능 (폐쇄망에서도 사용 가능)
  • GitLab CI/CD를 활용하여 빌드, 테스트, 배포 자동화 가능
  • GitHub Actions, Azure Pipelines 없이 자체 CI/CD 제공
  • GitLab Runner를 통해 개별 인프라에서 CI/CD 실행 가능
  • 보안 및 접근 제어 기능 강화 (RBAC, SAML, LDAP 지원)

⏩ 추천 대상: 폐쇄망 환경에서 DevOps가 필요한 기업 및 자체 관리형 Git 솔루션을 원하는 조직


2. 멀티 클라우드 전략을 고려할 경우

멀티 클라우드 환경에서는 한 가지 클라우드 플랫폼에 종속되지 않고, 다양한 클라우드 서비스를 조합하여 사용합니다. 이를 위한 DevOps 전략도 변화해야 합니다.

✅ 멀티 클라우드 DevOps 구축 시 고려할 점

  1. CI/CD 파이프라인의 일관성 유지
    • 각 클라우드 서비스의 CI/CD를 개별적으로 운영하면 관리가 어려워질 수 있음
    • GitLab CI/CD 또는 Jenkins 같은 클라우드 독립적인 CI/CD 솔루션을 고려해야 함
  2. 공통 코드 저장소 활용
    • GitHub, GitLab.com 같은 중앙화된 리포지토리를 사용하면 멀티 클라우드 환경에서도 일관된 소스 코드 관리 가능
  3. 보안 및 네트워크 정책 검토
    • 온프레미스 환경과 클라우드 간 데이터 이동 시 보안 정책 고려 필요
    • CI/CD 실행 환경을 폐쇄망과 연계할 경우, GitLab Self-Managed 같은 솔루션이 적합할 수 있음
  4. 배포 환경 최적화
    • AWS, Azure, GCP의 배포 방식이 다르므로 Kubernetes, Terraform 등을 활용하여 인프라를 자동화하는 것이 필요

3. 결론 및 추천 전략

🚀 선택 기준 정리

선택 기준추천 플랫폼

Azure 중심의 DevOps ✅ Azure DevOps
AWS 중심의 DevOps ✅ AWS CodePipeline + CodeBuild
GCP 기반 Kubernetes 운영 ✅ Cloud Build + Cloud Deploy
폐쇄망에서 DevOps 운영 필요 ✅ GitLab Self-Managed
멀티 클라우드 DevOps 구축 ✅ GitHub Actions, GitLab CI/CD, Jenkins

💡 멀티 클라우드 환경에서는 특정 클라우드에 종속되지 않는 GitLab CI/CD, Jenkins, ArgoCD 같은 범용 DevOps 툴을 고려하는 것이 유리하다.

아키텍트 입장에서 각 클라우드별 CI/CD를 활용할지, GitLab Self-Managed와 같은 독립적인 솔루션을 선택할지를 결정하는 것은 보안, 확장성, 관리 편의성을 기준으로 최적의 방법을 찾아야 합니다.

1. 서론

로컬에서 개발한 프로젝트를 GitHub에 올려서 원격 저장소에서 관리하는 방법을 알아봅니다. GitHub는 버전 관리와 협업을 위한 중요한 도구로, 프로젝트를 원격에서 안전하게 관리할 수 있게 해줍니다. 이 글에서는 로컬 Git 저장소를 GitHub에 연결하고, 소스 코드를 푸시하는 방법을 단계별로 안내합니다.


2. Git 설치 확인하기

GitHub에 프로젝트를 올리기 전에, 먼저 Git이 로컬에 설치되어 있는지 확인해야 합니다. 터미널 또는 명령 프롬프트에서 아래 명령어를 입력하여 Git이 설치되어 있는지 확인할 수 있습니다.

git --version
 

설치된 Git 버전이 출력되면, Git이 정상적으로 설치된 것입니다. 만약 "command not found" 또는 유사한 메시지가 나타난다면, (https://git-scm.com/)에서 Git을 설치한 후 다시 시도하세요.


3. 로컬 Git 저장소 초기화하기

GitHub에 프로젝트를 푸시하려면, 먼저 로컬 프로젝트에서 Git 저장소를 초기화해야 합니다. 프로젝트 디렉토리에서 다음 명령어를 실행합니다.

git init
 

이 명령어는 해당 폴더를 Git 저장소로 설정합니다. 이제 로컬 저장소에서 Git을 사용할 준비가 되었습니다.


4. GitHub에서 Repository 생성하기

GitHub에서 새 저장소를 만들어야 합니다. GitHub에 로그인한 후, + 버튼을 클릭하고 **"New repository"**를 선택합니다. 이후 Repository name을 입력하고 Create repository를 클릭합니다. 새로 생성된 GitHub 저장소의 HTTPS URL을 복사합니다.


5. 원격 저장소 연결하기

로컬 Git 저장소와 GitHub 저장소를 연결하려면, GitHub에서 복사한 원격 저장소 URL을 사용합니다. 터미널에서 아래 명령어를 실행하세요:

 

이제 로컬 저장소는 GitHub의 원격 저장소와 연결되었습니다.


6. 변경 사항 추가 및 커밋하기

로컬에서 변경한 파일을 Git에 추가하고 커밋합니다. 변경된 파일을 모두 추가하려면 git add . 명령어를 사용하고, 커밋 메시지를 입력하여 커밋을 완료합니다.

 
git add . git commit -m "Initial commit"

7. GitHub에 푸시하기

로컬 저장소의 내용을 GitHub에 푸시하려면, 아래 명령어를 실행하여 원격 저장소에 파일을 업로드합니다.

git push -u origin master

 

1. 서론

GitHub에 프로젝트를 올릴 때, 임시 파일이나 빌드 파일 등 불필요한 파일들이 함께 올라가는 경우가 많습니다. 이런 파일들은 프로젝트에 필요하지 않으며, GitHub의 저장소 공간을 차지할 뿐만 아니라 협업 시 불필요한 혼란을 초래할 수 있습니다. 이 문제를 해결하는 방법은 바로 .gitignore 파일을 활용하는 것입니다.


2. .gitignore란?

.gitignore 파일은 Git에게 어떤 파일을 추적하지 않을지 지정하는 설정 파일입니다. 이 파일을 사용하면, 특정 폴더나 파일을 Git의 버전 관리에서 제외시킬 수 있습니다. 이를 통해 프로젝트에 불필요한 파일이 GitHub에 올라가지 않도록 할 수 있습니다.


3. .gitignore 파일 생성하기

프로젝트 루트 디렉토리에서 .gitignore 파일을 생성한 후, 제외할 파일들을 지정합니다. 예를 들어, Gradle을 사용하는 경우 build/나 .gradle/ 같은 파일들이 불필요하게 포함될 수 있습니다. 이를 .gitignore에 추가하려면 다음과 같은 내용으로 파일을 작성하면 됩니다.

# Gradle 관련 파일 제외
.gradle/
build/
gradle-wrapper.jar
gradle-wrapper.properties

 


4. 이미 Git에 추가된 파일 제거하기

.gitignore 파일을 추가하더라도 이미 Git에 추가된 파일들은 계속 추적될 수 있습니다. 이 경우, git rm --cached 명령어로 Git에서 해당 파일들을 제거해야 합니다.

 
git rm -r --cached .gradle
git rm -r --cached build

5. 변경 사항 커밋하고 푸시하기

이제 .gitignore 파일을 추가하고 불필요한 파일을 제거한 후, 변경 사항을 커밋하고 GitHub에 푸시하면 됩니다.

 
git add .gitignore
git commit -m "Add .gitignore to exclude Gradle files"
git push origin master

6. 결론

.gitignore 파일은 Git과 GitHub에서 효율적인 버전 관리를 위해 꼭 필요한 도구입니다. 프로젝트의 불필요한 파일들을 제외시킴으로써, 저장소가 깔끔해지고 협업이 원활해집니다. 이제 GitHub에 파일을 푸시할 때마다 .gitignore를 활용하여, 필요한 파일만 관리할 수 있게 되었습니다.

+ Recent posts