728x90
반응형

프로메테우스란?

  • 프로메테우스는 사운드 클라우드에서 처음 제작한 모니터링 & 알람에 초점이 맞춰진 모니터링 오픈소스 툴이다.
  • 요청 발생 수, DB 연결 수 등의 숫자로 치환될 수 있는 시계열 데이터를 메트릭스(Metrics) 라 하는데, 이를 시계열 데이터로 저장 및 수집하는 툴이다.

특징

  • 다차원 시계열 데이터를 메트릭스 명과 key-value 쌍으로 관리한다.
  • PromQL 이라는 쿼리 언어로 차원들을 관리한다.
  • 다른 저장소에 종속되지 않는다.

데이터 수집 방법

  • 엔드포인트에 HTTP 요청을 통해 데이터를 스크레이핑 한다.
  • exporter를 배포해 해당 exporter의 엔드포인트를 통해 데이터를 스크레이핑한다.

시스템 메트릭 수집

  • 프로메테우스가 서버의 시스템 메트릭스(Load Average, CPU Usage 등)을 수집하는 방법은 node-exporter를 사용하는 것이다.
    • node-exporter는 시스템 정보를 수집하는 툴이라고 생각하면 편하다.

Node Exporter 실행

  • 컨테이너로 이를 시행시킬 수 있다.
  • 아래처럼 설정한다. 이렇게 했을 때, exporter의 엔드포인트로 접근해 데이터를 수집할 수 있다.
services:
    exporter:
        image: prom/node-exporter:v1.8.2
        container_name: exporter
        expose: 9100
        command:
          - '--path.procfs=/host/proc'
          - '--path.rootfs=/rootfs'
          - '--path.sysfs=/host/sys'
          - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
        volumes:
            - /proc:/host/proc:ro
            - /sys:/host/sys:ro
            - /:/rootfs:ro
        networks:
            - proxy
  • path.roofts 설정
    • 호스트 전체 모니터링을 위한 설정
    • 루트 디렉토리에 대해 바인딩 시켜, Exporter가 호스트 FileSystem에 접근하게 해 주는 옵션
    • 이후 루트 디렉토리를 볼륨으로 넣음
    • 일반 디렉토리면 그냥 넣어주면 된다.

프로메테우스 실행

설정

  • 프로메테우스 설정
    • prometheus.yml 파일로 해야 인식한다. 물론 볼륨으로 넣을 때, 명칭을 바꿔주는 것도 가능하다.
    • 수집할 대상의 엔드포인트를 정의한다.
    • 이는 scrape_configs 에 그 타겟 대상과 라벨링이 가능하다.
global:
    scrape_interval: 15s
    evaluation_interval: 15s

# Set the scrape interval to every 15 seconds. Default is every 1 minute.

rule_files:
    - alert.rules.yml
      alerting:
        alertmanagers:
            - static_configs:
            - targets: ["host.docker.internal:9093"]

scrape_configs:
    - job_name: 'System Server'
      static_configs:
        - targets: ['node:9100']

    - job_name: 'cAdvisor'
      static_configs:
        - targets: ['cadvisor:8080']
  • 설정 옵션 관련 내용
    • global: 전체적인 데이터 수집에 대한 전역 설정
    • scrape_configs: 수집 작업에 대한 정의
    • remote_write: 수집된 메트릭을 원격 엔드포인트로 전달하기 위한 설정

컨테이너 설정

  • prometheus.yml 파일 이외에도 alert.rules (장애 알람 규칙) 등 다른 설정들도 먹일 수 있다.
  • 해당 설정들은 /etc/prometheus 경로에 넣어주면 된다.
services:
    prometheus:
        image: prometheus:v2.54.1
        volumes:
            - ./prom-config/prometheus.yml:/etc/prometheus/prometheus.yml
            - ./prom-config/alert.rules.yml:/etc/prometheus/alert.rules.ym
            - prometheus_data:/prometheus
        command:
            - '--config.file=/etc/prometheus/prometheus.yml'
            - '--storage.tsdb.path=/prometheus'
            - '--web.console.libraries=/etc/prometheus/console_libraries'
            - '--web.console.templates=/etc/prometheus/consoles'
            - '--web.enable-lifecycle'
        networks:
            - proxy
        restart: unless-stopped
        ports:
            - 9090:9090

GUI

  • 이제 http://localhost:9090으로 접근해 보면 아래와 같이 확인할 수 있다.
  • 아래 랜딩페이지 화면에서 PromQL을 통해 데이터를 쿼리해 볼 수 있다.

'

  • 또한 현재 데이터를 수집하고 있는 대상을 확인하는 방법은 Status - Target으로 확인할 수 있다.
    • 여기서 현재 정상적으로 데이터가 수집되고 있는지도 확인할 수 있다.

728x90
반응형

'데브옵스 devOps > Monitoring' 카테고리의 다른 글

[CNCF] OpenTelemetry(OTel)란?  (0) 2024.11.22
728x90
반응형

CI / CD

  • CI (Continuous Integration): 지속적 통합
    • 코드에 대한 통합
    • 다수의 개발자들의 코드 베이스를 계속해서 통합한다는 의미
    • 즉 여러 개발자들의 코드를 빠르게 배포함을 의미
  • CD (Continuous Deployment): 지속적 배포
    • 코드 베이스를 사용자가 사용하는 환경에 코드 베이스 배포를 자동화하는 것
  • 즉 CI/CD는 여러명의 개발자들이 개발 환경을 통합하여 사용자가 사용하는 환경에 전달하는 모든 일련의 과정들을 자동화하는 것
    • 여기에는 코드 빌드, 테스트, 배포가 포함됨

젠킨스?

  • Java Runtime Environment에서 동작
    • 플러그인 사용하여 자동화 작업 파이프라인을 설계
    • 파이프라인 마저도 플러그인의 일부
  • Credentials 플러그인을 사용해서 민감정보를 보관

젠킨스 파이프라인

  • Section - 가장 큰 개념
    • Agent Section
      • 오케스트레이션 처럼 slave node에 일 처리 지정
    • Post Section
      • 스테이지가 끝난 이후의 결과에 따른 후속 조치
      • 즉 작업 결과에 따른 행동 조치
    • Stage Section - 카테고리
      • 어떠한 일을 처리할 것인지 stage를 정의
      • Dockerfile의 스테이지를 정의하는 것과 같음
    • Step Section - 카테고리 내부의 동작들
      • 한 스테이지 안에서의 단계
      • 여러 작업들 실행 가능

Declaratives

  • Environment, Stage, Options, Parameters, Triggers, When
  • 각 Stage 안에서 어떠한 일을 할 것인지 정의
  • Environment
    • 환경변수들 정의
  • Parameter
    • 파이프라인 실행시 파라미터를 받음
  • Triggers
    • 파이프라인이 실행되는 트리거 정의
    • 예시: 특정 브랜치에 머지가 감지되었을 때
  • When
    • 수행되는 조건문
    • 예시: 환경변수 BUILD_BRANCH가 dev일 때

예시

  • 깃허브 특정 레포 dev(개발)/main(운영) 브랜치에 머지 인식
    • 미리 Credentials에 등록해 둔 각각 환경에 따라 다른 환경 변수 로드
    • 각각 환경에 따른 이미지 명으로 도커 이미지 빌드
    • 개인 도커 레지스트리에 이미지 푸시
    • 각각 개발/운영 서버에 배포할 서비스 경로 생성
      • docker-compose.yml 파일 복사
      • 빌드하여 푸시한 이미지 가져와서 컨테이너 구동
// 브랜치별 배포 위치

def getDeployTargets(envName) {

targets = [:]



// dev 브랜치

targets['prod'] = [[

    COMPOSE_ENV: 'dev',

    SSH_MODE: 'KEYONLY',

    SSH_IP: '<Server IP>',

    SSH_KEY_ID: 'Key Id From Jenkins Credentials',

    COPY_DIR: '도커 컴포즈 파일 배포할 서버 상의 경로'

]]

    return targets[envName]
}



// 브랜치별 환경 정보

def getBuildBranch(branchName) {
    branches = [
        'origin/main': 'prod',
    ]

    return branches[branchName]
}



pipeline {
    agent any

    //환경변수
    environment {

        //브랜치 선택

        BUILD_BRANCH = getBuildBranch(env.GIT_BRANCH)

        // 도커 설정
        DOCKER_IMAGE = ''
        DOCKER_IMAGE_NAME = '빌드 할 도커 이미지 명'

        // Git, Docker private 레지스트리 로그인 정보 설정    
        GIT_KEY_ID = '깃허브 인증 SSH 키 ID - Credentials에서 관리;'
        REGISTRY_LOGIN_INFO_ID = 'donghquinn_registry'
    }



                        stages {

                            stage('체크아웃') {
                                steps {
                                    echo "작업 브랜치: ${env.GIT_BRANCH}"

                                    git branch: BUILD_BRANCH, credentialsId: GIT_KEY_ID, url: 'git@github.com:donghquinn/<레포 명>.git'

                            }

                        }



                        stage('도커 이미지 빌드') {
                            steps {
                                script {

                                    // 브랜치에 따라 이미지 이름 변경
                                    DOCKER_IMAGE = docker.build(DOCKER_IMAGE_NAME + '-' + BUILD_BRANCH)

                                }

                                echo "Built: ${DOCKER_IMAGE_NAME}-${BUILD_BRANCH}"

                            }
                        }



                        stage('도커 이미지 Push') {
                            steps {
                                script {
                                    // 개발서버 내부 Docker private 레지스트리에 업로드
                                    docker.withRegistry('https://registry.donghyuns.com', REGISTRY_LOGIN_INFO_ID) {

                                    DOCKER_IMAGE.push(env.BUILD_NUMBER)
                                    DOCKER_IMAGE.push('latest')
                                }

                            }
                            echo "Pushed: ${DOCKER_IMAGE_NAME}-${BUILD_BRANCH}:${env.BUILD_NUMBER}"

                            }

                        }



                        stage('도커 컨테이너 배포') {

                        steps {

                            script {

                                def deployTargets = getDeployTargets(BUILD_BRANCH)

                                def deployments = [:]



                                // 배포 타깃별로 병렬 배포

                                for (item in deployTargets) {

                                def target = item



                                deployments["TARGET-${BUILD_BRANCH}"] = {

                                def remote = [:]
                                remote.name = target.SSH_IP
                                remote.host = target.SSH_IP
                                remote.allowAnyHosts = true

                                if (target.SSH_MODE == 'KEYONLY') {

                                    withCredentials([

                                    // DOTENV 파일과 SSH KEY를 가져옴
                                    sshUserPrivateKey(credentialsId: target.SSH_KEY_ID, keyFileVariable: 'SSH_PRIVATE_KEY', usernameVariable: 'USERNAME')
                                    ]) {

                                    // 가져온 키로 ssh 정보 설정
                                    remote.user = USERNAME

                                    remote.identityFile = SSH_PRIVATE_KEY

                                    sshCommand remote: remote, command: """
                                        mkdir -p ${target.COPY_DIR}-${BUILD_BRANCH}/
                                    """

                                    // docker compose 파일 전송
                                    sshPut remote: remote, from: "docker-compose.${BUILD_BRANCH}.yml", into: "${target.COPY_DIR}-${BUILD_BRANCH}/docker-compose.yml", failOnError: 'true'

                                    // 각 상황에 맞는 .env.* 파일 전송

                                   // 각 상황에 맞는 .env.* 파일 전송
                                  sshPut remote: remote, from: DOTENV, into: "${target.COPY_DIR}/.env", failOnError: 'true'

                                    // 도커 이미지 Pull 및 재시작
                                    sshCommand remote: remote, command: """
                                        cd ${target.COPY_DIR}-${BUILD_BRANCH}/
                                        BUILD_BRANCH=${BUILD_BRANCH} docker compose pull
                                        BUILD_BRANCH=${BUILD_BRANCH} docker compose up -d
                                    """
                                }
                            }
                        }

                        parallel deployments

                    }

                }

            }

        }

    }

}
728x90
반응형
728x90
반응형

무중단 배포 전략이란 무엇일까? 각 전략에 대해 개인적 명칭을 붙여봤다.

무중단 배포란?

무중단 배포란 서비스의 중단 없이 새로운 버전을 배포하는 것을 의미한다. 이용자의 서비스 이용에 지장을 주지 않는 것과 동시에 새로운 버전을 배포하는 것이 핵심인 것이다.

이를 위해선 로드 밸런서와 두 대 이상의 서버가 필요하다.

Blue/Green 배포 - 단순 배포 전략?

이전 버전 서버와 새로운 버전 서버를 두고,
공통 로드 밸런서를 통해 새로운 버전을 배포하는 전략이다.

  • Blue 서버: 이전 환경 서버
  • Green 서버: 새로운 배포 환경

Blue/Green 전략

장점

트래픽을 새로운 버전쪽으로 옮기기 때문에 호환성 문제가 발생하지 않는다.

단점

실제 운영에 필요한 리소스보다 2배의 리소스를 확보해야 한다.(서버가 두 대이고, 일질적인 트래픽이 통하는 서버는 이전 환경이기 때문)

Rolling 전략 - 순차 배포 전략?

운영중인 복수개의 인스턴스들을 하나씩 돌아가며(Rolling) 로드 밸런서로부터 트래픽을 끊고 새로운 버전 배포를 하는 전략이다.
즉, 새로운 버전 배포가 완료가 되면 다시 로드 밸런서에 연결을 하고, 그 다음 인스턴스를 로드 밸런서로부터 끊고 새로운 버전을 배포하는 것을 반복하는 것이다.

장점

  • 많은 서버 자원을 배포하지 않아도 무중단 배포 가능
  • 인스턴스마다 차례로 돌아가며 배포를 진행하므로, 배포로 인한 위험이 줄어든다.

단점

  • 새 버전을 배포할 때마다 서비스 중인 인스턴스의 개수가 줄어, 서버 부담이 증가한다.
  • 배포가 진행되는 동안 새로운 버전과 이전 버전의 호환성 문제가 발생할 수 있다.

Canary 배포 - 위험 감지 전략?


Canary 전략

이전 버전과 새로운 버전이 동시에 가동되는 방식으로, 새 버전 인스턴스는 일부 사용자에게만 서비스 하는 방식이다.
새 버전이 정상적으로 작동함을 확인하면, 전체 트래픽을 새 버전으로 전환한다.
오류가 발생한다면, 일부 사용자에게만 발생하므로 오류 방지에 효과적이다.

참고 (개인적 의견)

Canary 전략이라는 이름이 붙은 이유는 탄광에서 위험 감지용으로 데려가던 것에서 유래한 것 같다.

장점

  • 사용자 테스트와 무중단 배포가 동시에 가능함
  • 새로운 버전으로 인한 위험을 감소시킬 수 있다.

단점

  • Rolling 전략과 마찬가지로 이전과 새로운 버전이 동시에 존재하므로 호환성 문제가 발생 가능하다.

참고 링크

728x90
반응형

'데브옵스 devOps > Server' 카테고리의 다른 글

[STANDALONE] Standalone 프로그램이란?  (1) 2024.12.26
[파일전송] Rsync  (0) 2024.12.11
728x90
반응형

계기

컨테이너를 구동하였을 때,
해당 컨테이너가 정상적으로 올라간 것으로 보였지만 로그를 확인하거나 exec 명령어로 컨테이너 내부에 접근하고자 했을 때 문제가 발생하고 있는 것을 확인한 적이 여러번 있었다.

때문에 컨테이너의 정상 여부(Health) 를 주기적으로 체크하며 모니터링 할 필요가 있다.

healthcheck 옵션

  • docker compose 설정
    • healthcheck 라는 설정을 함으로써 가능하다.
      • test: 헬스체크 시도 시에 실행할 동작을 정의한다. 단순 curl/wget 으로 요청을 날려볼 수 있고, CLI를 넣을 수도 있으며, 함수를 실행시킬 수도 있다.
      • interval: 말 그대로 체크 실행 주기를 의미한다.
      • timeout: 실행된 헬스체크 동작에 대한 리턴을 기다리는 시간(timeout)을 의미한다.
      • retries: 타임아웃이 걸려 체크 실패 시 재시도 횟수를 의미한다. 재시도까지 전부 실패하면 unhealthy 상태가 된다.
      • start_period: 컨테이너 구동을 기준으로, 헬스체크를 시작할 때까지의 시간을 의미한다. 처음 구동 시, 초기 세팅에 시간이 많이 걸리는 경우가 있기 때문
    • 상태값
      • 0 : healthy. 즉 건강한 상태이다.
      • 1 혹은 다른 숫자: unhealthy. 비정상적인 문제가 발생하고 있다.
services:
    app:
        expose:
            - ${APP_PORT}
        healthcheck:  
            // 헬스체크를 위해 실행할 함수
            test: curl --fail http://localhost:5000/ || exit 1  

            // REDIS 체크의 경우
            test: [ "CMD", "redis-cli", "--raw", "incr", "ping" ]

            // 체크 실행 주기
            interval: 40s 
            // 타임아웃 
            timeout: 30s  
            retries: 3  
            // 컨테이너 구동 후 체크 시작할 시점
            start_period: 60s
  • DockerFile 설정

    • 도커 파일 설정은 Dockerfile의 이미지 빌드 과정에 입력된다.
    • 이외 헬스 체크 주기 등의 옵션은 컨테이너 구동 시 입력한다.
    FROM asdcasdcas
    # ... 빌드 내용
    
    # 컨테이너에서 구동하는 어플리케이션의 /health 엔드포인트에 요청을 날리는 것이 헬스체크 방식이다.
    HEALTHCHECK CMD curl --fail http://localhost/health
    docker container run -d -p 8080:80 --health-interval 5s app_image/stable/latest

    결과

    • 헬스체크가 완료되면 아래처럼 보이게 된다.

주기 설정에 관하여

  • healthcheck 는 어찌 되었건 cpu 등 서버 리소스를 사용하기 때문에 적당한 주기(interval)로 실행시켜야 한다.
  • 또한 실제로 헬스체크 동작을 실행시켰을 때 받아올 수 있는 정도의 주기로 실행해야 한다.
    • 만약 헬스체크 대상 어플리케이션의 특정 함수 동작 주기가 1분인데, 10초마다 헬스체크를 한다면, 이는 자원 낭비일 것이다.
728x90
반응형
728x90
반응형

 

본 과정은 Ubuntu 20.04 를 기준으로 작성되었습니다.

도커 설치

 

운영체제 패키지 업데이트

 

sudo apt-get update

 

 

필수 요소 설치

 

sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg \
  lsb-release -y

 

 

도커 GPG 키 설치

 

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

 

 

Stable 버전 도커 설치

 

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

 

 

도커 엔진 설치

 

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io -y

 

 

버전 확인

 

docker version

 

 

도커 컴포즈는 뭔데?

 

도커 컴포즈는 컨테이너 이미지를 빌드하고, 컨테이너 설정을 미리 할 수 있는 설계도이다.

빌드할 도커 파일을 설정하고, 컨테이너 이름 및 공개할 포트 번호, 네트워크 등을 미리 설정할 수 있다.

 

도커 컴포즈 설치

 

sudo curl -L "https://github.com/docker/compose/releases/download/v2.9.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

 

 

실행 권한 부여

 

sudo chmod +x /usr/local/bin/docker-compose

 

 

버전 확인

 

docker-compose --version

 

728x90
반응형

'데브옵스 devOps > Docker' 카테고리의 다른 글

[DOCKER] 도커 port / expose 에 대해  (1) 2024.10.21
[DOCKER] 도커 네트워크에 관하여  (0) 2024.10.18
[DOCKER] 헬스체크  (2) 2024.10.03
[Docker] 도커란?  (1) 2024.09.25
[Docker] Private 도커 허브와 크레덴셜  (7) 2024.09.24
728x90
반응형

 

도커는 리눅스의 격리 기술을 활용한 기술이다.

 

프로세스란?

프로세스? 프로세스가 무엇인가. 여기서 시작해야 도커에 대한 설명을 할 수 있겠다. 우리가 주로 컴퓨터에 설치하는 것들을 ‘프로그램‘이라고 한다. 카카오톡, 알약, 팟플레이어 등… 모든것이 프로그램이라고 할 수 있다. 하지만 프로그램은 설치되었다고 해서 실행되는 것이 아니다. 실행을 시켜야 그 프로그램을 사용할 수 있다. 정말 러프하게 설명하자면 ‘실행되고 있는 프로그램을 프로세스‘라고 한다. 조금 전문적으로 설명하자면 CPU가 작업을 처리하기 위해 ‘메모리에 올라가 있는 프로그램‘이라고 말할 수 있겠다.

 

그래서 프로세스가 도커랑 뭐?

자 이제 프로세스가 도커와 무슨 상관일까? 도커를 러프하게 설명하자면, 프로세스를 구동하고 있는 가상 머신이다. 오.. 그렇구나. 그런데 가상머신 VM과 도커랑 무슨 차이가 있길래 구별을 하는거냐? 이것 역시 러프하게 얘기하자면, VM은 모든 가상 머신에 각각 OS가 설치되어있다. 내 컴퓨터에 가상 머신이 4개가 돌아가고 있다 가정한다면, 4개의 컴퓨터가 하나의 컴퓨터 안에서 돌아가고 있다고 생각해도 무방하다. 때문에 무겁다. 하지만 도커는 호스트의 OS를 공유하기 때문에 가상머신에 비해 비교적 빠르고 가볍다.

 

도커의 구성 요소?

자 이제 그러면 도커를 구성하는 요소들에 대해 설명하겠다. 도커는 크게 호스트, 컨테이너로 구성된다. 호스트란 가상 머신을 지칭하는 거로, OS가 구동된다. 컨테이너는 이 호스트에서 하나 이상의 프로세스를 구동하고 있는 단위이다. 우리의 컴퓨터랑 똑같이 생각하면 이해가 빠를 것이다. 컴퓨터를 켜서 배경화면에 와서(호스트 접속) 프로그램을 실행하면(컨테이너 구동) 프로그램을 사용할 수 있다. 물론 이 예시에서 클라이언트는 빠졌지만.

 

도커를 이용하는 방법

그렇다면 도커 컨테이너를 구동시키기 위하여 어떻게 해야 할 것인가? 우선 도커 컨테이너는 이미지라는 것을 가져와 프로세스를 구동시킨다. 방법은 두가지가 있다. 첫번째는 Dockerfile을 통해 현재 로컬 호스트의 소스코드와 구동 환경들을 정적으로 이미지 빌드하여 사용하는 것이다. 이 경우 커스텀한 이미지를 만들어 사용할 수 있다는 장점이 있다. 두번째는 레지스트리에서 가져오는 것이다. 레지스트리가 무엇인가? 쉽게 말하자면 이미지를 온라인상에 업로드 한 저장창고 라고 생각하면 쉽다. 가장 대표적으로 도커 공식 레지스트리 docker hub가 있다.

728x90
반응형
728x90
반응형

 

본 글은 Ubuntu 20.04 를 기준으로 작성되었습니다.

 

도커 이미지 허브

도커 이미지는 빌드되어 정적인 상태로 관리된다. 때문에 저장장치에 이미지를 업로드하여 url을 통해 내려 받아 와 사용할 수 있다. 이른바 CI/CD 의 일종으로 볼 수 있을 것 같다. 그런데 개인적인 프로젝트나, 회사 내부 프로젝트일 경우 이미지는 내부에서 관리되어야 하고 유출되면 곤란하다. 때문에 도커 이미지 레지스트리 관리 오픈소스 툴인 harbor 를 이용해 이미지를 관리해 왔다.

 

보안

이미지를 업로드한 저장소에 접근하기 위해선 저장소 접근 권한을 통해 로그인을 해야 한다. 그런데 리눅스 기반의 운영체제에서 (다른 운영체제는 잘 모르겠다) docker login 명령어를 통해 접근하려고 하면, 로컬에 해당 민감정보가 저장되어 버린다는 끔찍한 문제점이 존재한다. 때문에 도커에서도 공식적으로 이러한 방식이 아닌 credential을 이용해 접근하라고 권고하고 있다.

 

Docker Credential

- [공식 레포지토리](https://github.com/docker/docker-credential-helpers

Credential은 로컬에 그대로 저장하는 것이 아닌, 암호화 시키고 사용할 때 인증을 해서 접근 권한을 가져와 사용할 수 있게 해 준다. 어떤 능력자 분이 설치하는 스크립트를 공유해 주셔서 이를 공유해본다.

 

- [스크립트 원문](https://geoffhudik.com/tech/2020/09/15/docker-pass-credential-helper-on-ubuntu/)

#!/bin/sh
# Sets up a docker credential helper so docker login credentials are not stored encoded in base64 plain text.
# Uses the pass secret service as the credentials store.
#
# If previously logged in w/o cred helper, docker logout <registry> under each user or remove ~/.docker/config.json.
#
# For Swarm use just run once on a manager.
# Script written for use on Ubuntu.
# Run elevated logged in as the target user.
# To remove cred helper:
#   - delete /usr/local/bin/docker-credential-pass
#   - remove '{ "credsStore": "pass" }' from ~/.docker/config.json
# Ensure executable in git:
# git update-index --chmod=+x path/docker-credentials.sh
if ! [ $(id -u) = 0 ]; then
   echo "This script must be run as root"
   exit 1
fi
# Install dependencies - jq more optional for existing varying configuration in ~/.docker/config.json.
apt update && apt-get -y install gnupg2 pass rng-tools jq
# Check for later releases at https://github.com/docker/docker-credential-helpers/releases
version="v0.6.3"
archive="docker-credential-pass-$version-amd64.tar.gz"
url="https://github.com/docker/docker-credential-helpers/releases/download/$version/$archive"
# Download cred helper, unpack, make executable, move it where it'll be found
wget $url \
    && tar -xf $archive \
    && chmod +x docker-credential-pass \
    && mv -f docker-credential-pass /usr/local/bin/
# Done with the archive
rm -f $archive
config_path=~/.docker
config_filename=$config_path/config.json
# Could assume config.json isn't there or overwrite regardless and not use jq (or sed etc.)
# echo '{ "credsStore": "pass" }' > $config_filename
if [ ! -f $config_filename ]
then
    if [ ! -d $config_path ]
    then
        mkdir -p $config_path
    fi
    # Create default docker config file if it doesn't exist (never logged in etc.). Empty is fine currently.
    cat > $config_filename <<EOL
{
}
EOL
    echo "$config_filename created with defaults"
else
    echo "$config_filename already exists"
fi
# Whether config is new or existing, read into variable for easier file redirection (cat > truncate timing)
config_json=`cat $config_filename`
if [ -z "$config_json" ]; then
    # Empty file will prevent jq from working
    $config_json="{}"
fi
# Update Docker config to set the credential store. Used sed before but messy / edge cases.
echo "$config_json" | jq --arg credsStore pass '. + {credsStore: $credsStore}' > $config_filename
# Output / verify contents
echo "$config_filename:"
cat $config_filename | jq
# Help with entropy to prevent gpg2 full key generation hang
# Feeds data from a random number generator to the kernel's random number entropy pool
rngd -r /dev/urandom
# To cleanup extras from multiple runs: gpg --delete-secret-key <key-id>; gpg --delete-key <key-id>
echo "Generating GPG key, accept defaults but consider key size to 2048, supply user info"
gpg2 --full-generate-key
echo "Adjusting permissions"
sudo chown -R $USER:$USER ~/.gnupg
sudo find ~/.gnupg -type d -exec chmod 700 {} \;
sudo find ~/.gnupg -type f -exec chmod 600 {} \;
# List keys
gpg2 -k
# Grab target key
key=$(gpg2 --list-secret-keys | grep uid -B 1 | head -n 1 | sed 's/^ *//g')
echo "Initializing pass with key $key"
pass init $key
# Image can't be found when Swarm attempts to pull later if a pass phrase is here.
echo "Do not set a passphrase for this step (*IMPORTANT*)"
pass insert docker-credential-helpers/docker-pass-initialized-check
# Optionally show password but mask ***
# pass show docker-credential-helpers/docker-pass-initialized-check | sed -e 's/\(.\)/\*/g'
echo "Docker credential password list (empty initially):"
docker-credential-pass list
echo "Done. Ready to test. Run: docker login <registry>"
echo "After login run: docker-credential-pass list; cat ~/.docker/config.json; pass show"

 

도메인 등록

도커 로그인을 진행해서 도메인을 등록한다.

sudo docker login <docker hub | registry address>
>>username:
>>password:
>> succeed

 

리스트 업

sudo docker-credential-pass list
>> {"example.com":"username"}

 

활성화

아래 명령어를 입력하면 위에서 인증 키를 생성할 때 입력한 패스워드를 입력할 수 있는 창이 뜰 것이다. 이후에 저장소에 접근하면 정상적으로 가능해진다.

sudo pass ls docker-credential-helpers/docker-pass-initialized-check
728x90
반응형

'데브옵스 devOps > Docker' 카테고리의 다른 글

[DOCKER] 도커 port / expose 에 대해  (1) 2024.10.21
[DOCKER] 도커 네트워크에 관하여  (0) 2024.10.18
[DOCKER] 헬스체크  (2) 2024.10.03
[Docker] 도커 및 도커 컴포즈 설치  (0) 2024.09.25
[Docker] 도커란?  (1) 2024.09.25

+ Recent posts