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️⃣ CI/CD (Jenkins & GitHub Actions)

도구개인기업
GitHub Actions ✅ 퍼블릭 무제한, 프라이빗 월 2,000분 무료 ❌ 프라이빗 무료 없음
Jenkins ✅ 무료 (서버 필요) ✅ 무료 (서버 필요)

기업에서도 GitHub Actions을 무료로 쓰려면 퍼블릭 리포지토리를 사용하거나 Self-hosted Runner 활용
Jenkins는 개인/기업 모두 무료지만, 직접 서버를 운영해야 함


2️⃣ 정적 코드 분석 (SAST)

도구개인기업
SonarQube (Community Edition) ✅ 무료 ✅ 무료 (기본 기능만 가능)
Semgrep ✅ 무료 ✅ 무료 (기본 기능)

SonarQube는 Community Edition 무료, 기업용은 Advanced 기능 유료
Semgrep도 기본 기능은 무료지만, 대형 코드베이스 분석 시 유료


3️⃣ 동적 분석 (DAST - 웹 취약점 스캐너)

도구개인기업
OWASP ZAP ✅ 완전 무료 ✅ 완전 무료
Burp Suite Community ✅ 무료 (기본 기능) ❌ 기업용은 유료

OWASP ZAP은 개인/기업 모두 무료
Burp Suite Community 버전은 기업에서는 기능 부족 (전문 기능은 유료)


4️⃣ 컨테이너 보안 (Trivy, Clair)

도구개인기업
Trivy (Aqua Security) ✅ 무료 ✅ 무료
Clair ✅ 무료 ✅ 무료

Trivy, Clair 모두 개인/기업 무료 사용 가능
기업에서도 Docker 이미지 취약점 분석 무료로 가능


5️⃣ 로그 모니터링 (ELK, Grafana)

도구개인기업
ELK Stack (Elasticsearch, Logstash, Kibana) ✅ 무료 (기본 버전) ✅ 무료 (기본 버전)
Grafana + Loki ✅ 무료 ✅ 무료

ELK Stack 기본 버전은 개인/기업 무료, 기업에서는 유료 기능(보안, 클러스터링) 추가 가능
Grafana + Loki는 개인/기업 무료 사용 가능


 결론: 개인 & 기업 무료 사용 전략

기능개인 무료 사용기업 무료 사용
CI/CD GitHub Actions (퍼블릭) Jenkins 또는 Self-hosted GitHub Actions
SAST SonarQube (Community) 또는 Semgrep SonarQube (Community) 또는 Semgrep
DAST OWASP ZAP OWASP ZAP
컨테이너 보안 Trivy Trivy
로그 모니터링 ELK (기본) 또는 Grafana+Loki ELK (기본) 또는 Grafana+Loki

기업에서도 완전히 무료로 사용하려면

  • GitHub Actions 대신 Jenkins 또는 Self-hosted Runner 사용
  • SAST, DAST, 컨테이너 보안은 무료 도구 활용 가능
  • 로그 모니터링은 ELK 대신 Grafana + Loki가 가벼움

'DevSecOps' 카테고리의 다른 글

DevSecOps 정의  (0) 2025.03.16

DevSecOps는 "Development(개발) + Security(보안) + Operations(운영)"의 합성어로, 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 보안을 자동화하고 통합하는 방법론이다.

🔹 DevSecOps의 개념

기존에는 개발(Dev) → 운영(Ops) → 보안(Security) 순으로 각 단계가 따로 적용되었지만, DevSecOps는 개발 초기부터 보안을 포함하여 애플리케이션을 안전하게 만들고 운영하는 것을 목표로 한다.
즉, 보안을 개발 프로세스의 일부로 자동화하여, 코드가 배포되기 전에 취약점을 찾아 해결하는 방식이다.


🔹 DevSecOps의 핵심 원칙

  1. Shift Left(왼쪽으로 이동)
    • 보안 검사를 배포 단계가 아니라 개발 초기 단계부터 수행하여, 문제가 커지기 전에 해결
    • 개발-운영이 진행될수록 수정 비용이 증가하는 문제를 방지
  2. 자동화(Automation)
    • CI/CD 파이프라인에서 보안 검사를 자동화하여 개발 속도 저하 없이 보안을 유지
    • 예: 정적 코드 분석(SAST), 동적 애플리케이션 보안 테스트(DAST), 컨테이너 이미지 스캔
  3. 지속적인 모니터링(Continuous Monitoring)
    • 배포 이후에도 로그 및 보안 이벤트를 실시간으로 분석하여 이상 징후 탐지
  4. 책임 공유(Shared Responsibility)
    • 개발팀, 운영팀, 보안팀이 협업하여 보안 책임을 공동으로 관리
    • 기존의 "보안팀만 보안을 담당"하는 방식에서 벗어나, 개발자가 직접 보안을 고려

🔹 DevSecOps 도입 시 이점

보안 강화: 코드 배포 전에 취약점을 미리 제거하여 보안 사고 방지
빠른 개발 속도 유지: 보안 검사를 자동화하여 개발 속도를 저하시키지 않음
비용 절감: 배포 후 수정보다 개발 단계에서 문제를 해결하는 것이 비용이 적게 듦
규정 준수(Compliance): 금융, 헬스케어 등 규제가 엄격한 산업에서 보안 정책 준수 용이


🔹 DevSecOps 도입을 위한 주요 도구

카테고리도구 예시

 

카테고리 도구 예시
CI/CD Jenkins, GitHub Actions, GitLab CI/CD
정적 분석(SAST) SonarQube, Checkmarx, Semgrep
동적 분석(DAST) OWASP ZAP, Burp Suite
컨테이너 보안 Trivy, Clair, Anchore
비밀 관리 HashiCorp Vault, AWS Secrets Manager
보안 모니터링 Splunk, ELK Stack, Datadog Security

🔹 실무에서 DevSecOps 적용 예시

1️⃣ 개발자가 코드를 GitHub에 푸시하면 자동으로 보안 검사가 실행
2️⃣ CI/CD 파이프라인에서 정적 분석(SAST) 및 종속성 검사 수행
3️⃣ 취약점이 발견되면 자동으로 PR을 차단하고 개발자에게 경고
4️⃣ 컨테이너 이미지 스캔을 통해 배포 전에 보안 취약점 확인
5️⃣ 배포 후에도 로그 모니터링 및 공격 탐지 수행


DevSecOps는 단순히 보안 툴을 추가하는 것이 아니라, 조직 문화와 프로세스를 변화시켜 개발과 보안이 함께 움직이도록 만드는 것이 핵심이다. DevOps에 관심이 있다면 DevSecOps도 꼭 익혀두면 좋을 개념이다

'DevSecOps' 카테고리의 다른 글

DevSecOps 도구별 무료 사용 가능 범위  (0) 2025.03.16

개발을 하다 보면 GitHub에 저장된 코드를 자동으로 가져와 빌드하고 실행해야 하는 경우가 많습니다.

이를 위해 Flask와 GitPython을 활용하여 간단한 자동 빌드 시스템을 구축하는 방법을 소개합니다.

1. 개요

이 프로젝트에서는 Flask 웹 서버를 구축하여 다음 기능을 수행하도록 합니다:

  • GitHub에서 지정된 프로젝트를 클론 또는 업데이트
  • 프로젝트 빌드 실행
  • API 호출을 통해 빌드 결과를 확인

2. Ubuntu에서 필요한 패키지 설치

먼저, Python과 필요한 패키지를 설치해야 합니다.

sudo apt update
sudo apt install python3 python3-pip python3-flask python3-git -y

설치 후 Python과 pip 버전을 확인합니다.

python3 --version
pip3 --version

이후 pip를 최신 버전으로 업데이트합니다.

python3 -m pip install --upgrade pip

3. Flask 애플리케이션 코드 작성

아래는 app.py 파일을 생성하고, GitHub에서 소스를 가져와 빌드하는 Flask 애플리케이션 코드입니다.

import os
import subprocess
from flask import Flask, jsonify
import git

app = Flask(__name__)

# GitHub Repository 정보
REPO_URL = "https://github.com/********/my-project-001.git"
CLONE_DIR = "./my-project-001"
BRANCH = "develop"

# 빌드 명령어 (필요에 따라 변경)
BUILD_COMMAND = ["make"]  # 예시: make 사용, 프로젝트에 따라 변경 필요

def clone_or_pull_repo():
    """GitHub에서 소스를 가져오거나 업데이트"""
    if os.path.exists(CLONE_DIR):
        repo = git.Repo(CLONE_DIR)
        repo.git.checkout(BRANCH)  # 브랜치 변경
        repo.remotes.origin.pull()
        return f"Repository updated to {BRANCH} branch"
    else:
        repo = git.Repo.clone_from(REPO_URL, CLONE_DIR, branch=BRANCH)
        return f"Repository cloned with {BRANCH} branch"

@app.route('/update', methods=['GET'])
def update_repo():
    """소스 업데이트"""
    message = clone_or_pull_repo()
    return jsonify({"message": message})

if __name__ == '__main__':
    app.run(debug=True, host='0.0.0.0', port=5000)

4. 백그라운드 실행 방법

Flask 서버가 실행된 후 터미널이 종료되면 프로세스도 함께 종료됩니다. 이를 방지하고 백그라운드에서 실행하려면 아래 방법을 사용할 수 있습니다.

1) nohup 명령어 사용

nohup python3 app.py > flask.log 2>&1 &

이렇게 실행하면 app.py가 백그라운드에서 실행되며, 로그는 flask.log 파일에 기록됩니다.

5. API 사용 방법

>소스 업데이트:

curl http://127.0.0.1:5000/update

1. 개요

웹 애플리케이션 배포를 자동화하는 과정에서 rsync를 활용하면 빠르고 효율적인 동기화가 가능합니다. 특히 GitLab CI/CD, Jenkins 등의 자동화 도구와 연계하면, 코드 변경이 발생했을 때 자동으로 웹 서버에 배포할 수 있습니다. 본 글에서는 GitLab에서 Webhook을 트리거로 사용하여 rsync를 통한 자동 동기화 배포 환경을 구축하는 방법을 다룹니다.

2. rsync를 활용한 배포 자동화 개념

rsync는 증분 전송 방식을 사용하여 변경된 파일만 업데이트할 수 있는 강력한 동기화 도구입니다. 이를 CI/CD 파이프라인에 연계하면 코드가 푸시될 때마다 자동으로 웹 서버에 반영되도록 설정할 수 있습니다.

3. GitLab Webhook + rsync 연계

3.1 GitLab Webhook 설정

GitLab의 Webhook을 활용하여 새로운 코드가 푸시될 때 서버에서 자동으로 배포 스크립트를 실행하도록 설정합니다.

  1. GitLab 프로젝트 설정 → Settings → Webhooks
  2. URL 입력: Webhook을 실행할 서버의 URL (예: http://[your-server-ip]:5000/webhook)
  3. Trigger 선택: Push events 선택
  4. Secret Token 설정 (선택 사항)
  5. Save Webhook 클릭

3.2 Webhook 처리 서버 구성

GitLab Webhook 요청을 받아 rsync를 실행하는 간단한 웹 서버를 Python으로 작성합니다.

from flask import Flask, request
import subprocess

app = Flask(__name__)

@app.route('/webhook', methods=['POST'])
def webhook():
    data = request.json
    if data.get('event_name') == 'push':
        subprocess.run(['bash', '/data/devops/deploy.sh'])
        return 'Deployment started', 200
    return 'Ignored', 400

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

3.3 배포 스크립트 (deploy.sh)

GitLab Webhook이 실행되면 rsync를 이용해 최신 코드를 배포합니다.

#!/bin/bash
GIT_REPO_PATH="/home/user/myproject"
WEB_SERVER_PATH="/var/www/html"

cd $GIT_REPO_PATH
git pull origin main
rsync -avz --delete $GIT_REPO_PATH/ user@webserver:$WEB_SERVER_PATH/

4. GitLab CI/CD와 rsync 연계

GitLab CI/CD를 활용하여 코드가 푸시될 때 rsync를 실행하는 방법도 가능합니다.

4.1 .gitlab-ci.yml 설정

GitLab CI/CD에서 rsync를 실행하는 파이프라인을 설정합니다.

stages:
  - deploy

deploy:
  stage: deploy
  script:
    - rsync -avz --delete ./ user@webserver:/var/www/html/
  only:
    - main

 

1. 개요

파일 전송을 위해 자주 사용되는 rsync, scp, sftp의 성능을 비교하고, 어떤 상황에서 어떤 도구를 선택해야 하는지 살펴봅니다. 이를 위해 실험 및 벤치마크를 수행하여 속도를 비교합니다.

2. 각 도구의 특징

2.1 rsync

  • 특징
    • 증분 전송 방식 (변경된 부분만 전송)
    • SSH를 이용한 보안 전송 가능
    • 압축 옵션 제공으로 네트워크 트래픽 감소 가능
    • 파일 동기화 및 백업에 적합
  • 사용 예시
  • rsync -avz /local/path/ user@remote:/remote/path/

2.2 SCP (Secure Copy Protocol)

  • 특징
    • SSH를 기반으로 한 단순한 파일 복사
    • 전체 파일을 전송 (증분 전송 없음)
    • 다중 파일 전송 시 속도가 느려질 수 있음
    • 설정이 간편하며 보안성이 높음
  • 사용 예시
  • scp -r /local/path/ user@remote:/remote/path/

2.3 SFTP (SSH File Transfer Protocol)

  • 특징
    • SSH를 이용한 파일 전송
    • 상호작용 가능한 인터페이스 제공
    • 다중 파일 전송 시 성능이 우수할 수도 있음
    • FTP보다 보안성이 뛰어나며 원격 파일 관리 가능
  • 사용 예시
  • sftp user@remote sftp> put localfile.txt /remote/path/

3. 성능 비교 실험

3.1 실험 환경

  • 서버 환경: Ubuntu 22.04 LTS, 4 vCPU, 8GB RAM, 1Gbps 네트워크 대역폭
  • 테스트 파일: 1GB 단일 파일, 100MB x 10개 파일, 10KB x 10,000개 파일
  • 네트워크 환경: 로컬 네트워크 및 원격 서버 환경

3.2 벤치마크 결과

파일 유형 RSync SCP SFTP
1GB 단일 파일 빠름 (압축 가능) 중간 느림
100MB x 10개 빠름 (병렬 처리 가능) 중간 느림
10KB x 10,000개 매우 빠름 (변경된 파일만 전송) 느림 빠름 (대량 처리 최적화)

4. 선택 기준

4.1 rsync를 선택해야 할 경우

  • 대량의 파일을 동기화해야 할 때
  • 네트워크 트래픽을 최소화하고 싶을 때
  • 변경된 파일만 업데이트하고 싶을 때

4.2 SCP를 선택해야 할 경우

  • 단순한 파일 복사가 필요할 때
  • 추가적인 설정 없이 빠르게 파일을 전송해야 할 때
  • 보안이 중요한 경우 (SSH 기반)

4.3 SFTP를 선택해야 할 경우

  • GUI 기반의 파일 전송이 필요할 때
  • 원격 서버에서 파일을 관리해야 할 때
  • 대량의 작은 파일을 한 번에 전송해야 할 때

5. 결론

  • 빠른 동기화가 필요하다면 rsync
  • 단순한 파일 전송이 필요하다면 scp
  • 원격 파일 관리 및 대량의 작은 파일 전송이 필요하다면 sftp

각 도구의 특성과 사용 환경을 고려하여 적절한 방식을 선택하는 것이 중요합니다.

1. rsync란?

rsync는 파일 및 디렉터리를 로컬 및 원격 서버 간에 동기화하는 강력한 유틸리티입니다. SSH를 활용한 보안 연결이 가능하며, 증분 전송 방식으로 속도가 빠르고 효율적입니다.

2. rsync 기본 사용법

rsync 명령어의 기본적인 사용법은 다음과 같습니다.

rsync [옵션] 원본 경로 대상 경로

예제:

rsync -avz /local/path/ user@remote:/remote/path/
  • -a : 아카이브 모드(파일 속성 유지 및 하위 디렉터리 포함)
  • -v : 상세 출력
  • -z : 전송 데이터 압축

3. 로컬 디렉터리 간 동기화

같은 서버 내에서 파일을 동기화할 때 사용할 수 있습니다.

rsync -av /source/directory/ /destination/directory/

4. 원격 서버와의 동기화

4.1 로컬 → 원격 서버 동기화

rsync -avz /local/path/ user@remote:/remote/path/

4.2 원격 서버 → 로컬 동기화

rsync -avz user@remote:/remote/path/ /local/path/

4.3 SSH를 통한 보안 전송

기본적으로 rsync는 SSH를 사용하여 원격 서버에 연결합니다.

rsync -avz -e ssh /local/path/ user@remote:/remote/path/

5. 특정 파일 또는 디렉터리 제외하기

--exclude 옵션을 사용하여 특정 파일 또는 디렉터리를 제외할 수 있습니다.

rsync -avz --exclude 'node_modules' /local/path/ user@remote:/remote/path/

여러 개를 제외하려면:

rsync -avz --exclude={'node_modules','*.log'} /local/path/ user@remote:/remote/path/

6. 주기적인 동기화 자동화 (crontab 활용)

6.1 crontab 설정

주기적인 동기화를 위해 crontab을 활용할 수 있습니다.

crontab -e

아래와 같이 입력하면 매일 새벽 2시에 자동으로 동기화가 실행됩니다.

0 2 * * * rsync -avz /local/path/ user@remote:/remote/path/ >> /var/log/rsync.log 2>&1

7. SSH 키 기반 인증을 통한 비밀번호 없는 동기화

비밀번호 입력 없이 rsync를 실행하려면 SSH 키를 설정해야 합니다.

ssh-keygen -t rsa
ssh-copy-id user@remote

이후 rsync 명령어 실행 시 비밀번호 입력 없이 동작합니다.

8. 결론

rsync는 파일 동기화 및 백업을 자동화하는 데 매우 유용한 도구입니다. SSH 키 인증과 crontab을 함께 활용하면 원격 서버와의 파일 동기화를 간편하게 자동화할 수 있습니다.

1. rsync란?

rsync는 파일 및 디렉터리를 효율적으로 동기화하는 강력한 도구입니다.

파일의 변경된 부분만 전송하는 차등 전송(differential transfer) 방식을 사용하여 네트워크 대역폭을 절약하고 빠르게 동기화할 수 있습니다.


2. rsync 기본 사용법

rsync의 기본적인 실행 형식은 다음과 같습니다.

rsync [옵션] 원본 경로 대상 경로

예를 들어, 로컬 디렉터리를 다른 위치로 복사할 때:

rsync -av /home/user/data /backup/

또는 원격 서버에 전송할 때:

rsync -av /home/user/data user@remote:/backup/

3. rsync 주요 옵션 정리

1) 파일 속성을 유지하는 -a (아카이브 모드)

rsync -a source/ destination/
  • 디렉터리 구조, 심볼릭 링크, 권한, 타임스탬프 등을 유지하며 동기화
  • cp -r보다 강력한 파일 복사 기능 제공

2) 전송 진행 상황을 출력하는 -v (verbose)

rsync -av source/ destination/
  • 전송 중인 파일 목록과 진행 사항을 출력
  • 로그 기록용으로 유용

3) 파일 크기를 줄이기 위한 -z (압축)

rsync -az source/ destination/
  • 전송 시 파일을 압축하여 속도를 향상
  • 네트워크 속도를 절약하는 데 효과적

4) 삭제 동기화: --delete

rsync -av --delete source/ destination/
  • 원본에서 삭제된 파일을 대상에서도 삭제하여 정확한 복제 유지
  • 주의: 잘못 사용하면 데이터 손실 가능성이 있음

5) 파일 비교 기준 변경: -u (업데이트된 파일만 복사)

rsync -avu source/ destination/
  • 대상 파일이 이미 최신 버전이라면 덮어쓰지 않음
  • 불필요한 덮어쓰기 방지로 성능 최적화 가능

6) 부분적으로 전송된 파일 유지: --partial

rsync -av --partial source/ destination/
  • 전송 중 중단된 파일을 다시 이어서 복사할 수 있도록 보존
  • 대용량 파일 전송 시 유용

7) 전송 속도 제한: --bwlimit=KBPS

rsync -av --bwlimit=5000 source/ destination/
  • 초당 전송 속도를 제한하여 네트워크 부담 완화
  • 원격 서버가 트래픽 제한이 있는 경우 유용

8) SSH를 통한 원격 전송: -e ssh

rsync -av -e ssh source/ user@remote:/destination/
  • SSH 프로토콜을 사용하여 보안이 강화된 파일 전송
  • SSH 기본 포트가 아닌 경우:
  • rsync -av -e "ssh -p 2222" source/ user@remote:/destination/

9) 특정 파일 제외: --exclude

rsync -av --exclude="*.log" source/ destination/
  • 특정 패턴의 파일을 동기화에서 제외
  • 여러 개 제외 가능:
  • rsync -av --exclude={"*.log","temp/"} source/ destination/

10) 동기화 중 변경된 파일 제외: --ignore-existing

rsync -av --ignore-existing source/ destination/
  • 대상 폴더에 이미 존재하는 파일은 건너뜀

4. rsync 실전 예제

✅ 로컬 폴더를 원격 서버로 백업

rsync -azv --delete /home/user/data user@remote:/backup/
  • 압축(-z), 아카이브(-a), 자세한 로그(-v) 활성화
  • 원본에서 삭제된 파일을 대상에서도 삭제(--delete)

✅ 여러 개의 폴더를 동기화하면서 특정 파일 제외

rsync -av --exclude={"*.log","node_modules/"} /project/ /backup/
  • .log 파일과 node_modules/ 디렉터리는 제외하고 복사

✅ 대역폭 제한을 걸고, 중단된 파일 이어서 복사

rsync -av --bwlimit=2000 --partial source/ destination/
  • 초당 2MB로 속도를 제한하고(--bwlimit=2000), 부분 전송 지원(--partial)

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>

+ Recent posts