Jenkins

1. 공부 내용

사용 툴: Jenkins

  • CI/CD 작업을 처리하는 데 최적화된 도구입니다.
    • Java 어플리케이션뿐만 아니라 다양한 프로그래밍 언어의 어플리케이션 배포에도 사용 가능합니다.
    • Tomcat, Docker, Kubernetes 등과의 연동 방법도 다룹니다.
    • Infrastructure as Code(IaC)와의 연동도 포함됩니다.

공부 내용

  1. 섹션 1: DevOps와 CI/CD 이해

    • DevOps와 CI/CD의 개념과 중요성에 대해 학습합니다.

  2. 섹션 2: Jenkins를 이용한 CI/CD 사용

    • Jenkins를 설치하고 기본적인 CI/CD 작업을 설정하는 방법을 배웁니다.

  3. 섹션 3: Jenkins와 Infrastructure-as-Code 연동

    • Jenkins와 IaC 도구들을 연동하여 효율적인 배포 환경을 구성하는 방법을 학습합니다.

  4. 섹션 4: Jenkins와 Ansible, Kubernetes 연동

    • Ansible과 Kubernetes를 이용하여 Jenkins와의 연동을 통해 배포 작업을 자동화하는 방법을 다룹니다.

  5. 섹션 5: Jenkins의 고급 기능 활용

    • Jenkins 파이프라인을 이용해 작업들을 일관된 흐름으로 구성하는 고급 기능을 배웁니다.

  6. 섹션 6: 상용 클라우드 배포

    • 로컬에서 사용한 결과물을 AWS, 네이버 클라우드 플랫폼(NCP) 등의 상용 클라우드에 배포하는 방법을 설명합니다.

부록

  • 공부할 때 사용한 환경 설정 및 소프트웨어 설치 방법을 윈도우즈와 맥OS 환경별로 설명합니다.
  • 공부를 시작하기 전에 부록을 참조하여 필요한 환경 설정을 체크해보세요.

2. DevOps와 CI/CD의 이해

Waterfall vs Agile

  • DevOps와 CI/CD의 이해

    • 전통적인 개발 방법론: 워터폴

      • 워터폴 방식:
        • 프로젝트의 각 단계를 구분하여 순차적으로 진행합니다.
        • 단계: 요구사항 > 분석 > 설계 > 구현 > 테스트 > 운영
        • 한 번 완료된 단계는 이전 단계로 돌아가기 어렵습니다.
        • 고객의 요구사항을 바로 반영하기 어렵고, 비용과 시간이 많이 소요됩니다.
        • 특정 프로젝트나 조직의 규모에 따라서는 여전히 유효한 방법론입니다.

    • 최신 개발 방법론: 애자일

      • 애자일 방법론:
        • 변화하는 고객 요구사항을 빠르게 반영할 수 있습니다.
        • 반복적이고 점진적인 개발을 통해 소프트웨어를 진화시킵니다.
        • 애자일 선언문:
          • 개인과 상호작용을 중요시
          • 작동하는 소프트웨어를 강조
          • 고객과의 협력을 중시
          • 변화에 대한 대응을 중요시
        • 애자일 방법론의 주요 형태:
          • 익스트림 프로그래밍 (XP)
          • 페어 프로그래밍
          • 테스트 주도 개발 (TDD)
          • 스크럼

  • IT 시스템의 역사와 변화

    1. 워터폴 방식과 모노리스:
      • 물리적 하드웨어 중심
      • 인하우스 데이터 센터 구축
    2. 2000년대 초반: 애자일 도입:
      • 분산 시스템과 가상 환경의 도입
    3. 최근: DevOps와 클라우드 네이티브 아키텍처:
      • DevOps, 마이크로 서비스 아키텍처 (MSA), 컨테이너 가상화, 클라우드 기반
      • 클라우드 네이티브 아키텍처: 클라우드 환경에서 애플리케이션과 서비스를 최적의 상태로 운영하는 아키텍처
      • CNCF (Cloud Native Computing Foundation)에서 관련 기술과 스펙을 정의

  • 클라우드 네이티브 아키텍처

    • 클라우드 인프라 환경에서 최적의 상태로 애플리케이션과 서비스를 운영
    • 유연하고 확장 가능한 시스템을 구축

  • 앞으로 다룰 내용

    1. DevOps와 CI/CD의 개요:
      • DevOps: 개발과 운영의 협업을 통해 소프트웨어 개발과 배포를 자동화하는 방법론
      • CI (Continuous Integration): 지속적인 통합으로 코드 변경 시마다 자동으로 빌드하고 테스트
      • CD (Continuous Delivery/Deployment): 지속적인 배포로 변경 사항을 자동으로 배포
    2. Jenkins 설치:
      • Jenkins는 CI/CD 도구로 다양한 플랫폼에서 설치 가능
      • 여러분의 PC 환경에 맞춰 적절한 버전을 선택해 설치
    3. 간단한 애플리케이션 배포 실습:
      • Jenkins를 사용해 간단한 애플리케이션을 배포하는 실습 진행

  • 마무리

    • 이번 섹션에서는 전통적인 개발 방법론과 최신 개발 방법론을 비교하면서 DevOps와 CI/CD의 중요성을 이해했습니다.
      다음 섹션에서는 Jenkins 설치와 간단한 실습을 통해 CI/CD를 직접 경험해보겠습니다.
      이번 공부를 통해 DevOps와 CI/CD를 효과적으로 활용합시다.

Cloud Native Application의 구성요소

클라우드 네이티브 애플리케이션은 클라우드 환경에서 최적의 상태로 운영되도록 설계된 애플리케이션입니다.
CNCF(Cloud Native Computing Foundation)와 Pivotal에서 정의한 클라우드 네이티브 애플리케이션의 주요 구성 요소는 다음과 같습니다:

  1. 마이크로서비스:

    • 애플리케이션을 작은 서비스들로 분리하여 각각 독립적으로 개발, 배포, 운영할 수 있습니다.

  2. 컨테이너 가상화:

    • 마이크로서비스를 클라우드 환경에 배포하고 운영하기 위해 컨테이너 가상화 기술을 사용합니다.
      이는 자원을 효율적으로 사용하고, 독립적으로 서비스를 실행할 수 있게 합니다.

  3. DevOps:

    • 개발과 운영 조직 간의 협력을 통해 지속적으로 서비스를 개선합니다.
      이는 빠른 문제 해결과 업데이트를 가능하게 합니다.

  4. CI/CD 자동화 파이프라인:

    • 자동화된 통합, 빌드, 테스트, 배포 과정을 통해 안정적인 운영 상태를 유지합니다.

  • 마이크로서비스 아키텍처

    • 마이크로서비스 아키텍처는 애플리케이션을 여러 작은 서비스로 나누어 개발합니다.
      이는 다음과 같은 두 가지 주요 구조로 나뉩니다:
      1. 이너 아키텍처:
        • 비즈니스 로직을 포함한 주요 서비스들로 구성됩니다.
      2. 아우터 아키텍처:
        • 서비스들을 지원하고 운영하는 시스템들로 구성됩니다.
          예를 들어, API 게이트웨이, 서비스 메쉬, 환경 설정 관리, 런타임 플랫폼 등이 포함됩니다.

  • 컨테이너 가상화

    • 컨테이너 가상화는 리소스를 효율적으로 사용하면서 애플리케이션을 독립적으로 실행할 수 있게 합니다.
      대표적인 도구는 Docker입니다.
      Docker는 다음과 같은 방식으로 동작합니다:
      1. Docker 파일:
        • 이미지 생성을 위한 설정 파일입니다.
      2. 이미지:
        • Docker 파일을 기반으로 생성된 실행 가능한 파일입니다.
      3. 컨테이너:
        • 이미지를 실행한 인스턴스입니다.

  • DevOps

    • DevOps는 개발(Development)과 운영(Operations)을 결합한 방법론으로, 다음과 같은 특징을 가집니다:
      1. 빠른 피드백:
        • 고객의 요구사항을 빠르게 반영합니다.
      2. 자동화:
        • 코드 통합, 빌드, 테스트, 배포 과정을 자동화합니다.
      3. 협력:
        • 개발과 운영 팀이 긴밀하게 협력하여 문제를 해결합니다.
  • DevOps 도입을 위해 다양한 도구들이 사용됩니다. 예를 들어:
    • 코드 관리: Git, SVN
    • 빌드 도구: Maven, Gradle
    • 테스트 도구: JUnit, Selenium
    • 통합 도구: Jenkins
    • 배포 도구: Docker, Kubernetes, Ansible
    • 모니터링 도구: Nagios, FluentD
  • 클라우드 네이티브 아키텍처와 DevOps의 결합
    • 클라우드 네이티브 아키텍처는 마이크로서비스, 컨테이너 가상화, DevOps, CI/CD 자동화 파이프라인의 결합으로 이루어집니다.
      이를 통해 애플리케이션의 개발, 배포, 운영이 효율적으로 이루어지며, 변화하는 요구사항에 빠르게 대응할 수 있습니다.
    • 이번 공부에서는 이러한 기술들을 사용하여 실제로 CI/CD 파이프라인을 구축해 볼 예정입니다.
      Docker, Kubernetes, Jenkins, Ansible 등의 도구를 활용하여 전체 자동화 과정을 실습해 보겠습니다.
      이 과정에서 각 도구의 사용법과 역할을 이해하고, 클라우드 네이티브 애플리케이션을 효과적으로 관리하는 방법을 배울 것입니다.

CI/CD 자동화 도구의 이해

CI/CD는 소프트웨어 개발에서 중요한 프로세스로, 지속적인 통합(CI)과 지속적인 배포(CD)를 의미합니다.
이제 CI/CD의 개념과 역할, 그리고 이를 구현하는 방법을 자세히 살펴보겠습니다.

  • CI/CD란 무엇인가?

    1. 지속적인 통합 (CI, Continuous Integration):
      • 여러 개발자가 작업한 코드를 자주 병합하고 테스트하는 프로세스입니다.
      • 주기적으로 코드를 통합함으로써 병합 충돌을 줄이고 코드의 품질을 높입니다.
      • 빌드, 테스트, 머지 등의 단계를 자동화하여 개발 생산성을 향상시킵니다.
    2. 지속적인 배포 (CD, Continuous Deployment/Delivery):
      • CI 과정을 거친 후, 패키징된 코드를 다양한 서버(개발 서버, 테스트 서버, 운영 서버)에 배포하는 과정입니다.
      • Continuous Delivery: 수동으로 최종 배포를 진행합니다.
      • Continuous Deployment: 자동으로 최종 배포까지 진행합니다.

  • CI/CD의 중요성

    • 자동화: 코드 통합, 빌드, 테스트, 배포 과정을 자동화하여 개발 시간을 절약하고 오류를 줄입니다.
    • 빠른 피드백: 문제를 빠르게 발견하고 수정할 수 있습니다.
    • 높은 코드 품질: 단위 테스트와 코드 검증을 통해 코드의 품질을 향상시킵니다.
    • 효율적인 협업: 여러 개발자가 동시에 작업할 때 발생하는 충돌을 최소화합니다.

  • CI/CD 도구: Jenkins

    • Jenkins: CI/CD 도구로서, 소스 코드의 빌드, 테스트, 패키징, 배포 과정을 자동화합니다.
      • 빌드: 소스 코드를 컴파일하고 패키징합니다.
      • 테스트: 단위 테스트를 실행하여 코드의 품질을 검증합니다.
      • 배포: 패키징된 코드를 운영 서버나 테스트 서버에 배포합니다.

  • CI/CD의 단계

    1. 소스 코드 관리 (SCM, Source Code Management):
      • 개발자들이 작성한 코드를 형상 관리 시스템(SCM) 또는 버전 관리 시스템(VCS)에 업로드합니다.
      • Git, GitHub, GitLab, BitBucket 등이 대표적인 도구입니다.
    2. 코드 통합:
      • Jenkins가 SCM에서 코드를 불러와 빌드, 테스트, 패키징 작업을 수행합니다.
      • 단위 테스트를 통해 코드의 품질을 검증하고, 문제가 없으면 다음 단계로 넘어갑니다.
    3. 배포:
      • CI 과정을 거친 패키지된 코드를 운영 서버나 테스트 서버에 배포합니다.
      • 수동으로 배포하는 Continuous Delivery와 자동으로 배포하는 Continuous Deployment로 구분됩니다.

  • 마이크로서비스 아키텍처와 CI/CD

    • 마이크로서비스 아키텍처는 애플리케이션을 작은 서비스 단위로 나누어 각각 독립적으로 개발, 배포, 운영합니다.
      각 서비스는 분리된 서버에서 실행되므로, 많은 서버에 배포하는 과정이 필요합니다.
      이때 CI/CD를 통해 자동화된 배포를 구현하면 다음과 같은 이점이 있습니다:
      • 효율성: 수작업을 줄이고 자동화된 배포로 시간을 절약합니다.
      • 유지보수: 빠른 업데이트와 문제 해결이 가능합니다.
      • 확장성: 필요한 서버와 서비스의 수를 쉽게 늘릴 수 있습니다.

  • 결론

    • CI/CD는 클라우드 네이티브 애플리케이션의 필수 구성 요소입니다.
      Jenkins와 같은 도구를 사용하여 CI/CD 파이프라인을 구축하면, 개발과 배포 과정을 자동화하고 효율성을 높일 수 있습니다.
      이번 공부에서는 이러한 CI/CD의 개념을 이해하고, 실제로 CI/CD 파이프라인을 구축하여 마이크로서비스 애플리케이션을 효과적으로 관리하는 방법을 배울 것입니다.
      다음 섹션에서는 Jenkins 설치와 함께 간단한 CI/CD 실습을 진행하겠습니다.

CI/CD Work flow

이번에는 실습에서 사용할 전체 CI/CD 구성도와 워크플로우에 대해 알아보겠습니다.
이 과정에서는 Jenkins를 중심으로 다양한 도구를 사용하여 CI/CD 파이프라인을 구축할 것입니다.

  • CI/CD 구성도 개요

    • 먼저, CI/CD 구성도에서 사용하는 주요 도구들과 그 역할을 살펴보겠습니다.

  • CI 도구

    • Jenkins: 오픈소스 CI 도구로서, 소스 코드의 빌드, 테스트, 패키징, 배포 과정을 자동화합니다.
    • 다른 CI 도구: Travis CI, Circle CI, TeamCity 등 다양한 CI 도구가 있지만, 우리는 Jenkins를 선택했습니다.

  • 빌드 도구

    • Maven: Java 기반 프로젝트의 빌드 도구로, 프로젝트의 빌드와 의존성 관리를 돕습니다.
    • Gradle: Maven과 유사하지만 더 유연한 빌드 도구로, 복잡한 빌드 설정에 유리합니다. 우리는 Maven을 사용할 것입니다.

  • 컨테이너 가상화

    • Docker: 애플리케이션을 컨테이너로 실행하여 가상화하는 도구입니다. 컨테이너는 애플리케이션과 그 환경을 포함하는 패키지입니다.
    • 대안 도구: Cri-o, containerd 등 다양한 컨테이너 런타임이 있지만, Docker를 사용할 것입니다.

  • 오케스트레이션 도구

    • Kubernetes: 여러 컨테이너의 배포, 확장, 운영을 자동화하는 도구입니다.
      CNCF에서 졸업한 첫 번째 프로젝트로, 표준 오케스트레이션 도구로 자리 잡았습니다.

  • 인프라스트럭처 관리

    • Ansible, Terraform: Infrastructure as Code(IaC) 도구로, 서버와 인프라를 코드로 관리합니다.
      Jenkins와 함께 사용하여 배포 작업을 자동화합니다.

  • CI/CD 워크플로우

    1. 소스 코드 관리:
      • 개발자들이 GitHub, GitLab, BitBucket 등 SCM 시스템에 소스 코드를 업로드합니다.
      • 코드 변경 사항은 커밋(commit)하고, 버전 관리를 통해 충돌을 방지합니다.
    2. 코드 통합 (CI):
      • Jenkins가 SCM에서 코드를 불러와 빌드, 테스트, 패키징 작업을 수행합니다.
      • 테스트를 통과한 코드만 다음 단계로 넘어갑니다.
    3. 배포 (CD):
      • 패키징된 코드를 운영 서버, 테스트 서버, 또는 컨테이너 환경에 배포합니다.
      • Docker를 사용해 컨테이너 이미지를 생성하고, Kubernetes를 통해 컨테이너를 배포하고 관리합니다.

  • Jenkins와의 연동

    • Jenkins와 SCM 연동:
      • Jenkins가 Git과 같은 SCM에서 소스 코드를 불러옵니다.
      • 소스 코드 변경 사항을 자동으로 감지하고 빌드 작업을 시작합니다.
    • Jenkins와 빌드 도구 연동:
      • Maven을 사용해 소스 코드를 빌드하고 패키징합니다.
      • 빌드가 성공하면 패키징된 파일(WAR 파일 등)을 생성합니다.
    • Jenkins와 Docker 연동:
      • Docker를 사용해 빌드된 애플리케이션을 컨테이너 이미지로 생성합니다.
      • 생성된 이미지를 Docker 레지스트리에 저장합니다.
    • Jenkins와 Kubernetes 연동:
      • Kubernetes를 통해 Docker 이미지를 사용해 컨테이너를 배포합니다.
      • Kubernetes 클러스터에서 애플리케이션을 스케줄링하고 관리합니다.
    • Jenkins와 Ansible/Terraform 연동:
      • Ansible 또는 Terraform을 사용해 인프라를 코드로 관리하고, 필요한 환경을 자동으로 설정합니다.
      • Jenkins가 패키징된 결과물을 적절한 환경에 배포합니다.

Jenkins 소개

이번에는 Jenkins 도구를 소개하고 간단한 배포 작업을 진행하겠습니다.
Jenkins는 CI/CD 작업에서 시스템의 자동화 파이프라인 또는 워크플로우를 설계하는 데 사용되는 도구입니다.
지속적인 통합(CI)과 지속적인 배포(CD)를 통해 소프트웨어 개발과 배포 과정을 자동화할 수 있습니다.

Jenkins란 무엇인가?

Jenkins는 Java로 개발된 오픈소스 CI/CD 도구입니다.
원래 선 마이크로시스템즈에서 Hudson이라는 프로젝트로 시작되었고, 이후 Oracle에 인수되면서 Jenkins로 이름이 변경되었습니다.
Jenkins는 다음과 같은 장점을 가지고 있습니다:

  • 오픈소스: 무료로 사용할 수 있으며, 다양한 레퍼런스와 풍부한 플러그인이 제공됩니다.
  • 유연성: 다양한 빌드 도구(Maven, Gradle 등)와 형상 관리 시스템(Git, SVN 등)과 연동 가능합니다.
  • 확장성: 수많은 플러그인을 통해 기능을 확장할 수 있습니다.

Jenkins의 주요 기능

  • 빌드 자동화: 소스 코드를 컴파일하고, 단위 테스트를 실행하며, 패키징 작업을 자동으로 수행합니다.
  • 테스트 자동화: 빌드된 코드를 테스트하고, 결과를 피드백합니다.
  • 배포 자동화: 패키징된 코드를 운영 서버나 테스트 서버에 배포합니다.

Jenkins 설치

Jenkins를 설치하려면 다음 단계를 따르세요:

  1. Jenkins 다운로드:

    • Jenkins 공식 사이트에서 각 운영체제에 맞는 버전을 다운로드할 수 있습니다.

  2. Docker를 사용한 설치:

    • Docker를 사용해 Jenkins를 설치할 수도 있습니다. Docker를 사용하면 설치가 간편하고, 다양한 환경에서 동일한 설정을 사용할 수 있습니다.
    • 먼저 Docker Desktop을 설치해야 합니다. 이는 윈도우와 맥OS에서 모두 사용할 수 있습니다.

Jenkins 설치 및 설정

# 도커 이미지 목록
docker images

# 도커 컨테이너 목록
docker container ls

  • jenkins/jenkins

    • 앞에 있는 jenkins는 우리가 만들고자 하는 계정
    • 뒤에 있는 jenkins는 레파지토리 이름
    • 즉, jenkins/jenkins는 jenkins 계정의 jenkins 레파지토리를 사용한다는 의미
    • 레파지토리는 일종의 자료가 저장되는 공간을 의미

  • 먼저 도커 이미지를 다운로드 받는게 필요

    # 도커 이미지 다운로드
# jenkins 라는 계정에서 jenkins 라는 레파지토리를 다운로드 받겠다는 의미
docker pull jenkins/jenkins

  • 현재 페이지에서 두번째 Tags 메뉴를 클릭해보면 레이티스트 버전이 있고 윈도우 서버 코어 버전이 여러가지 형태로 있음
  • 태그는 정확하게 버전이라고 말할 수는 없지만 버전을 나타내는 경우가 대부분임
  • 버전이라던가 실행 환경이라던가 해당하는 서비스가 베이스가 되고 있는 이 라이브러리가 어떤 것인지를 나타낼 때 보통 이 태그를 활용하고 있기 때문에 이 라이브러리가 어떤 것인지를 나타낼 때 보통 이 태그를 확인해보면 됨 (태그를 보면서 어떤 형태의 Jenkins인지 확인해볼 수 있음)
  • 아무것도 입력하지 않으면 최신 버전을 쓰게됨
docker pull jenkins/jenkins

# run: docker 에서 이미지를 생성할 때 사용되는 커맨드
# -p: publish 옵션, 컨테이너 내부에 있는 포트를 컨테이너 바깥쪽에 있는 환경에서 어떻게 접속해서 사용할 것인지를 나타내는 설정
# 8080:8080 컨테이너 바깥쪽에서 8080이라는 포트를 사용하게 되면 컨테이너 내부로 8080 포트로 접속됩
# 50000:50000 컨테이너 외부에서 50000번으로 호출하게되면 컨테이너 내부의 50000번으로 응답하겠다는 뜻
# --restart=on-failure: 컨테이너가 실패하면 다시 실행하겠다는 의미
# jenkins/jenkins: jenkins 계정 / jenkins 레파지토리
# :lts-jdk17: lts jdk 17 버전을 사용하겠다는 의미
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17

# -v: volume 옵션, jenkins_home 이라는 폴더를 만들어서 jenkins 라는 컨테이너 내부의 폴더와 연결시키겠다는 의미
#   즉, -v 옵션은 여러분이 쓰고 있는 도커의 실행 환경 도커가 설치되어 있는 PC(windows, macos)에서 어떠한 디렉토리하고
#   도커 내부에 있는 디렉토리하고 마운트, 즉 연결 작업을 할 건지에 대한 설정임
# 마운트 작업이 왜 필요할까?
#   마운트 작업을 하지 않았을 경우에 도커 내부에서 발생되어진 데이터는 도커 내부에 저장된 것이기 때문에 도커가 삭제되게 되면 해당 데이터가 같이 없어진다.
#   그래서 도커 내부에 저장된 데이터 값을 없어지지 않게 하기 위해서 어딘가에 그 데이터를 보관시켜놔야됨
#   이 보관하는 방법 중에서 도커가 실행되고 있는 외부에 해당하는 폴더의 위치를 지정해 연결해서 링크를 잡아놓은 다음에 저장하는 방법을 마운트라고함
#   마운트를 하기 위해서 -v (볼륨) 옵션을 사용함
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17

# --name jenkins-server: 컨테이너의 이름을 jenkins-server로 지정
# --name: 만들고자하는 컨테이너에다가 이름을 부여하는 옵션
#   이름을 부여하지 않으면 docker가 랜덤하게 이름을 만들어 생성하게됨
#   랜덤한 이름을 만든다는 얘기는 그 이름만 놓고 봤을 때, 해당하는 컨테이너가 뭔지 알 수 없다는 뜻
#   이름은 가능한한 꼭 부여하는게 좋음
docker run -p 8080:8080 -p 50000:50000 --name jenkins-server --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17

# -d: detach 옵션, 백그라운드에서 실행하겠다는 의미
#   현재 우리가 실행하고 있는 콘솔과 터미널과 분리한 상태에서 실행하겠다는 뜻
#   다시 말해 백그라운드 또는 데몬 형태로 기동하겠다는 뜻
#   우리는 이 콘솔과 터미널을 계속 사용해야 되기 때문에 -d 옵션을 사용할거임
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17

실습

# docker 이미지 생성
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure --name jenkins-server jenkins/jenkins:lts-jdk17

  • -d 옵션을 부여했기 때문에 컨테이너 id만 출력됨
  • 기타 로그는 별도의 다른 커맨드를 이용해야 볼 수 있음
# 프로세스가 정상적으로 작동됐는지 확인
docker ps

  • STATUS: UP: 현재 도커의 상태(STATUS)가 UP 상태인걸 확인할 수 있음
  • PORTS: 0.0.0.0:8080->8080/tcp: 0.0.0.0:8080 요청을 내부의 8080 포트로 전달하겠다는 의미
  • PORTS: 0.0.0.0:50000->50000/tcp: 0.0.0.0:50000 요청을 내부의 컨테이너 50000번이 처리하겠다는 의미

  • 시간이 지나도 STATUS가 UP 상태로 유지되고 있어야됨

    • STATUS 부분이 created라던지 exit로 되어있다면 실행이 안되고 중지된 것
    • 그땐 로그 파일을 확인해 원인을 파악하는게 필요함

  • docker 설정작업

# jenkins 컨테이너 로그 확인
#   jenkins 초기 비밀번호를 확인하기 위함
docker logs jenkins-server

  • localhost:8080으로 접속

  • Install suggested plugins: 기본적인 모든 플러그인 설치
  • Select plugins to install: 원하는 플러그인만 선택해서 설치

Install suggested plugins 이거 선택

  • 실행 화면
    • 아직은 아이템을 만들지 않았기 때문에 비어있는 화면이 노출됨
    • 만약에 아이템을 추가로 만들어서 빌드를 해본다면 마지막에 그 아이템의 실행 상태(언제 실행되었는지, 상태가 어땠었는지)를 확인해볼 수 있음
    • 아이템이라는 것은 jenkins에서 사용하고 있는 작업의 최소 단위라고 보면됨
    • 빌드를 할 때, 배포를 할 때 아이템이라는 걸 만들어서 어떤 작업과정을 거칠 것인지 기술을 해줄 것임
    • '젠킨스 관리' 메뉴에서 jdk 설정이라던지 maven 설정을 진행하도록 하겠음

  • 그리고 JDK 설정을 제일 먼저 해볼건데 만약 실행환경이 맥os 라던가 윈도우즈 환경에서 Jenkins를 별도로 설치했다고 하면 당연히 JDK의 홈 디렉토리 위치를 별도로 지정해주시는게 필요함
  • JDK가 존재하지 않으면 jenkins 자체가 기동이 안될거임
  • 그래서 사전에 JDK가 설치되어 있어야 하고 그 설치되어 있는 JDK의 위치 정보를 정확하게 명시해주어야함
  • 만약 이를 잘못 설정할 경우 jenkins 자체가 정상 작동되지 않을 것임
  • 그런데 우리가 사용하고 있는 jenkins 환경은 docker 컨테이너 기반으로 작동되고 있음
  • docker에서 컨테이너를 만들기 위해서 우리는 이미지라는 것을 하나 가지고와서 생성해야 되는데 조금 전에 이미지를 다운로드받아 봤음
  • 해당 이미지는 jdk가 포함된 이미지이기 때문에, 쉽게 말해서 docker 상태로 jenkins를 기동할 때는 그 jenkins 안에 jdk가 정확하게 명시되어있는 상태다 라는걸 기억하면 됨.
    따라서 해당하는 폴더만 잘 설정해주면 됨.
    • 예를 들어, opt/java/openjdk 이런식으로 jdk 위치를 지정해주면 됨

위와 같이 Install automatically를 체크하면, 하단 메뉴가 나오는데, 하단 메뉴에서 해주는 작업은 jdk가 설치가 안되어있다라고 가정을 했을 때 자동으로 jdk를 설치해주는 메뉴임

  • 이 메뉴에선 오라클 계정을 필요로 한다는데, 지금도 그런지 확인해봐야됨

이렇게 jdk 설정까지 끝나면 샘플 어플리케이션을 만들기 위한 기본적인 jenkins 설정이 다 끝난 것이기 때문에 다음부턴 jenkins 프로젝트를 실행해보도록 하겠음

실습 1-1) docker 컨테이너로 jenkins 설치하기

  • 위와 같이 jenkins가 실행됐다는 것 자체가 jdk가 정상적으로 설치되어있고 설정되었다는 것을 의미함
  • 만약 필요하다면 위의 add jdk 버튼을 눌러서 필요한 jdk 정보를 입력할 수 있음

실습 1-2) 첫번째 Item(Project) 생성

우리가 만들고 있는 이 jenkins 자체가 어디에 설치됐냐면 docker에 설치가 되어있음.
docker는 기본적으로 운영되고 있는 운영체제를 linux로 사용하고 있기 때문에 다시 말해서 우리가 사용하고 있는 jenkins는 linux에 설치가 되어있다라고 볼 수 있음.
그래서 위의 Execute Shell에서 실행하는 Shell script 환경은 linux의 shell script라고 보면됨.
간단하게 echo 문장을 한번 출력해 보도록 하겠음.

실행 안되는줄 알고 '지금 빌드' 버튼 여러번 클릭함.
여튼 위와 같이 잘 빌드됨을 확인할 수 있음.
fail됐다고 하면 붉은색의 아이콘으로 보임.
위 표시는 빌드가 성공한 것을 나타냄.

위 빌드 기록의 시간을 보면 5월 20일 오전 1시 24분이라고 되어있는데, 실제 실습을 진행한 시간은 오전 10시 40분임.
이는 리눅스가 실행되고 있는 타임스탬프하고 현재 내가 사용하고 있는 환경이 다르기 때문에 시간이 다르게 표시된 것.

현재 jenkins에서 사용하고 있는 jdk 버전을 체크해보자.

# jdk 버전 확인
javac -version

위와 같이 워크스페이스도 확인해볼 수 있음.
이는 도커의 터널링을 이용해서 확인해볼 수 있음.

# 프로세스가 정상적으로 작동됐는지 확인
# docker 프로제스 확인
docker ps

# 현재 기동되고 있는 jenkins 에 우리가 터널링해서 입속하려면
# docker exec -it [container-id or container-name] [사용할 쉘 스크립트]
docker exec -it jenkins-server bash

위와 같이 도커 컨테이너 내부에 접속하면, 터미널창 화면이 위와 같이 나오게됨.
보면 컨테이너 id가 호스트 네임으로 쓰이고있고, 계정명도 표시가 되어있는 것을 볼 수 있음.

# docker 에서 기동되고 있는 젠킨스 내부 파일 목록 보기
ls -al

위와 같이 마지막에 내가 생성한 프로젝트 들어가서 ls -al을 실행하면 어떤 파일 및 폴더도 나오지 않는데, 그 이유는 해당 아이템(My-First-Project)은 패키징을 하지 않기 때문임.

즉, 위와 같이 실행되는 쉘 스크립트에 echo 스크립트하고 javac라는 버전 확인하기 위한 스크립트만있지 어떠한 형태로 패키징, 즉, 압축을 한다던지하는 결과물을 만들고있지는 않음.

2. Jenkins를 이용한 CI/CD 자동화 도구의 사용

CI/CD를 위한 git, maven설정

git 플러그인 설치되어있는지 확인

위와 같이 깃헙 플러그인이 설치되어있는 것을 확인할 수 있음.

git의 이름은 Default, git 커맨드는 그냥 사용하면 됨.
일단 젠킨스가 설치되어 있는 pc에 git이라는 커맨드를 사용할 수 있는가를 확인해보자.

# 프로세스가 정상적으로 작동됐는지 확인
# docker 프로제스 확인
docker ps

# 도커 컨테이너가 기동되어있는 상태에서 추가적인 커맨드로 더 전달하고자 할 때 사용할 수 있는 커맨드
# -it: interactive tty, 즉 해당 젠킨스의 터미널을 통해서 상호작용하겠다는 의미
docker exec -it jenkins-server bash

위와 같이 설정 후 저장.

maven 플러그인 설치

위와 같이 플러그인을 설치하고, maven이 기본적으로 설치되어있는지 확인.

설치 안되어있으므로 다음과 같이 설치.

Maven 프로젝트 생성

☰