본문 바로가기
Devops/GitLab

[GitLab] GitLab Runner + Docker + Ubuntu 환경 구축 (3) - SpringBoot, Next를 동일 Repository에서 사용할 경우

by J4J 2022. 2. 10.
300x250
반응형

안녕하세요. J4J입니다.

 

이번 포스팅은 GitLab Runner + Docker + Ubuntu를 이용한 동일 Repository에 SpringBoot, Next가 존재할 때 환경 구축하는 방법에 대해 적어보는 시간을 가져보려고 합니다.

 

 

 

들어가기에 앞서 다음 글을 참고하시면 좋을 것 같습니다.

 

 

 

반응형

 

 

사전 준비

 

[ 1. GitLab Runner와 GitLab Repository 연결 ]

 

Runner와 Repository를 연결하는 방법은 [GitLab] GitLab Runner 설치하기 (Ubuntu 20.04)를 참고해주시길 바랍니다.

 

또한 참고적으로 Runner와 연결되는 저의 Repository는 다음과 같이 구성되어 있습니다.

 

Repository 구성

 

 

 

해당 폴더들은 링크를 걸어둔 [GitLab] GitLab Runner + Docker + Ubuntu 환경 구축 (1) - SpringBoot[GitLab] GitLab Runner + Docker + Ubuntu 환경 구축 (2) - Next에서 테스트하던 파일들을 하나의 Repository로 합쳐둔 것들입니다.

 

 

 

 

GitLab CI 작성

 

계속해서 링크를 걸어두고 있는 SpringBoot와 Next에 각각 존재하는 .gitlab-ci.yml 파일을 하나의 파일로 합치려고 합니다.

 

그러므로 각 폴더마다 사용되고 있던 .gitlab-ci.yml 파일을 삭제한 뒤 다음과 같이 root경로에 .gitlab-ci.yml 파일을 새롭게 생성해보겠습니다.

 

.gitlab-ci.yml 파일 생성

 

 

 

이제 기존에 .gitlab-ci.yml 파일들에 작성되어 있던 내용들에 의해 실행된 결과들이 동일하게 나올 수 있게 새롭게 생성한 .gitlab-ci.yml에 내용을 작성해줘야 합니다.

 

내용을 입력하기에 앞서 fe와 be가 동일 Repository에 있을 때 자동 배포가 이루어질 수 있도록 .gitlab-ci.yml에 작성해줘야 하는 키워드는 "cd" 명령어라고 생각합니다.

 

왜냐하면 각 stage들 마다 실행되어야 하는 script들을 작성하기 전에 cd 명령어를 이용해 특정 폴더에 이동을 해주면 Repository가 서로 분리되어 있던 상황처럼 환경을 구성할 수 있기 때문입니다.

 

그 결과 기존에 fe, be에서 작성되어 있던 .gitlab-ci.yml 파일을 하나의 파일로 합치게 되면 다음과 같이 작성해줄 수 있었습니다.

 

# 실행될 stage 지정 (위에서 아래로 차례대로 실행)
stages:
  - build
  - test
  - package
  - deploy

fe-build:   # JOB 이름
  # 사용될 이미지 설정
  image: node:12.18.4
  # stage 설정
  stage: build
  # 실행될 script 설정
  script:
    - cd fe
    - npm install
    - npm run build
  # artifacts 설정 (bulld를 통해 생성된 파일을 job artifacts에 보관하여 다음에 수행되는 JOB에서 가져다 활용할 수 있게 도와줌)
  artifacts:
    # 보관이 이루어질 경로 설정
    paths:
      - fe/.next
      - fe/node_modules
    # 유효기간 설정
    expire_in: 1 days
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

be-build:  # JOB 이름
  # 사용될 이미지 설정
  image: maven:3.8.4-jdk-11 
  # stage 설정
  stage: build
  # 실행될 script 설정
  script:
    - cd be
    - mvn clean package -DskipTests
  # artifacts 설정 (bulld를 통해 생성된 파일을 job artifacts에 보관하여 다음에 수행되는 JOB에서 가져다 활용할 수 있게 도와줌)
  artifacts:
    # 보관이 이루어질 경로 설정
    paths:
      - be/target/*.jar
    # 유효기간 설정
    expire_in: 1 days
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

fe-test:   # JOB 이름
  # 사용될 이미지 설정
  image: node:12.18.4
  # stage 설정
  stage: test
  # 실행될 script 설정
  script:
    - cd fe
    - npm run test
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

be-test:  # JOB 이름
  # 사용될 이미지 설정
  image: maven:3.8.4-jdk-11 
  # stage 설정
  stage: test
  # 실행될 script 설정
  script:
    - cd be
    - mvn test
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

# 전역 변수 설정
variables:
  FE_IMAGE_NAME: $CI_REGISTRY_IMAGE/fe:latest   # FE 이미지 이름
  BE_IMAGE_NAME: $CI_REGISTRY_IMAGE/be:latest   # BE 이미지 이름

fe-package:   # JOB 이름
  # 사용될 이미지 설정
  image: docker:latest
  # stage 설정
  stage: package
  # service 설정 (설정한 image가 작업이 이루어지는 동안 실행되는 docker 이미지)
  services:
    - docker:dind
  # script가 실행 전 수행 될 script
  before_script:
    - docker login $CI_REGISTRY -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD   # GitLab Container Registry에 로그인
  # 실행될 script 설정
  script:
    - docker build -t $FE_IMAGE_NAME fe/.   # fe에 있는 Dockerfile로 build
    - docker push $FE_IMAGE_NAME   # Container Registry에 image push
  # script가 실행된 후 수행 될 script
  after_script:
    - docker logout   # GitLab Container Registry 로그아웃
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

be-package:  # JOB 이름
  # 사용될 이미지 설정
  image: docker:latest
  # stage 설정
  stage: package
  # service 설정 (설정한 image가 작업이 이루어지는 동안 실행되는 docker 이미지)
  services:
    - docker:dind
  # script가 실행 전 수행 될 script
  before_script:
    - docker login $CI_REGISTRY -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD   # GitLab Container Registry에 로그인
  # 실행될 script 설정
  script:
    - docker build -t $BE_IMAGE_NAME be/.   # be에 있는 Dockerfile로 build
    - docker push $BE_IMAGE_NAME   # Container Registry에 image push
  # script가 실행된 후 수행 될 script
  after_script:
    - docker logout   # GitLab Container Registry 로그아웃
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

fe-deploy:   # JOB 이름
  # stage 설정
  stage: deploy
  # tag 설정 (수행이 이루어질 GitLab-Runner tag 등록)
  tags:
    - dev-all
  # script가 실행 전 수행 될 script
  before_script:
    - docker login $CI_REGISTRY -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD   # GitLab Container Registry에 로그인
  # 실행될 script 설정
  script:
    - docker rm -f fe-con || true   # 기존에 존재하던 Container 삭제
    - docker rmi $FE_IMAGE_NAME || true   # 기존에 존재하던 이미지 삭제
    - docker pull $FE_IMAGE_NAME   # Container Registry에서 이미지 가져오기
    - docker run --name fe-con -p 8088:8088 -d $FE_IMAGE_NAME   # Container 생성 및 실행
  # script가 실행된 후 수행 될 script
  after_script:
    - docker logout   # GitLab Container Registry 로그아웃
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

be-deploy:   # JOB 이름
  # stage 설정
  stage: deploy
  # tag 설정 (수행이 이루어질 GitLab-Runner tag 등록)
  tags:
    - dev-all
  # script가 실행 전 수행 될 script
  before_script:
    - docker login $CI_REGISTRY -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD   # GitLab Container Registry에 로그인
  # 실행될 script 설정
  script:
    - docker rm -f be-con || true   # 기존에 존재하던 Container 삭제
    - docker rmi $BE_IMAGE_NAME || true   # 기존에 존재하던 이미지 삭제
    - docker pull $BE_IMAGE_NAME   # Container Registry에서 이미지 가져오기
    - docker run --name be-con -p 8080:8080 -d $BE_IMAGE_NAME   # Container 생성 및 실행
  # script가 실행된 후 수행 될 script
  after_script:
    - docker logout   # GitLab Container Registry 로그아웃
  # JOB이 수행될 branch 설정 (설정된 branch에 push가 발생될 시 JOB 수행)
  only:
    - master

 

 

 

 

기존 파일들에 작성되어 있던 내용들과 비교 했을때 변경점은 크게 없고 경로에 대한 부분과 이미지 변수 명에 대한 부분 정도만 추가 수정이 이루어졌습니다.

 

또한 참고적으로 .gitlab-ci.yml 파일 외에 각 폴더마다 가지고 있던 Dockerfile 등은 따로 변경된 사항이 없습니다.

 

 

 

이렇게 .gitlab-ci.yml을 작성한 뒤 commit을 해주고 push까지 해주면 다음과 같이 Pipelines에 trigger가 생성되고 stage마다 fe, be에 해당되는 JOB들이 실행되는 것을 확인할 수 있습니다.

 

trigger 생성

 

 

 

또한 생성된 이미지를 저장하는 Container Registry를 확인해보면 다음과 같이 fe, be의 이미지들이 생성된 것도 확인이 가능합니다.

 

이미지 생성

 

 

 

모두 정상적으로 수행되었다면 Runner가 설치되어 있는 Ubuntu에서도 Repository가 서로 나뉘어진 상태에서 수행된 것처럼 이미지들을 확인할 수 있고 또한 해당 이미지들로 만들어진 Docker Container가 생성 및 실행된 것도 확인할 수 있습니다.

 

 

 

 

 

 

 

 

 

이상으로 GitLab Runner + Docker + Ubuntu를 이용한 동일 Repository에 SpringBoot, Next가 존재할 때 환경 구축하는 방법에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.

 

 

 

728x90
반응형

댓글