도커라이징

• 이전 블로그에서 개발자님이 만드신 테스트코드를 TEST & BUILD 후 java -jar 명령어를 통해 배포하여 브라우저에서 정상적으로 접속되는 것을 확인하였다. 오늘은 이전 작업에이어서 테스트 코드에 대해서 TEST & BUILD 후 배포까지 하는 Dockerfile을 작성 후 빌드해서 이미지화 시킬것이다. 이 과정까지가 도커라이징이다.
• 이후 이미지를 Docker Hub에 Push하고 ArgoCD에서 배포중인 Deployment의 파드에서 이미지를 Docker Hub에 Push된 이미지로 교체할것이다.
• 백엔드 서버를 배포하는 역할을 하는 새로운 이미지로 생성된 컨테이너를 가진 새로운 파드가 Deployment에 의해서 Rolling Update로 배포될것이다.

1 . Dockerfile 작성

FROM gradle:8.0.2-jdk11 AS mbuilder # gradle 8.0.2버전, java 11버전 
COPY . /usr/src/
WORKDIR /usr/src/
RUN ./gradlew build # build/libs디렉터리 생성 및 jar파일 생성 

FROM openjdk:11-jre # java 11버전 
COPY --from=mbuilder /usr/src/build/libs/finalproject-0.0.1-SNAPSHOT.jar /usr/src/
CMD ["java","-jar","/usr/src/finalproject-0.0.1-SNAPSHOT.jar"] # jar파일 배포 

2 . Dockerfile 빌드

docker build -t backend:testv1 . 

• Dockerfile 빌드과정에서 개발자의 코드중 서버를 테스트하는 디렉터리의 서비스와 DB에 오류가 발생하였다.
• 개발자님에게 물어보니 해당 test디렉터리는 필요가없는 부분이여서 생략하고 빌드해도 된다고 하였다.

vi build.gradle # gradle 빌드 설정 파일 접속  

. . .
test.onlyIf {
    !project.hasProperty('test')
}

• 따라서 test 디렉터리에 대해서 무시하는 코드를 빌드 설정 파일 마지막부분에 추가하였다.
• 이후 다시 Dockerfile을 빌드해보니 정상적으로 빌드가 되는 것을 알 수 있다.

3 . Docker Hub에 Push

docker login # id/passwd 입력 
docker tag backend:testv1 suhwan11/backend:testv1 
docker push suhwan11/backend:testv1

• 생성한 이미지를 DockerHub에 Push하기위해서는 일치하는 계정명이 있어야 하기때문에 tag작업을 한다.
  

4 . ArgoCD로 배포

ArgoCD가 연동된 remote Git의 workDIR에 들어가서
Backend Deployment의 yaml파일에서 파드의 image를 위의 이미지로 교체한다.

git add .
git commit -m "change back image to test back image"
git push 

• ArgoCD는 자신과 연동된 Git에 새로운 Push가 들어왔음을 감지하고 새로운 image가 적용된 컨테이너를 가지고 있는 파드를 Deployment에 의해서 Rolling Update로 배포하는 것을 볼 수 있다.

• 기존의 AWS의 Backend ingress로 생성된 ALB의 DNS Name을 브라우저에 입력하면 새로 배포된 백엔드 서버의 테스트 페이지가 나타나는 것을 확인
• 아직 프론트엔드 연결을 하지 않았기 때문에 웹페이지가 나타나지는 않는다

---

< 프론트엔드 도커라이징 >

• 프론트엔드 도커라이징은 다른 팀원들이 진행하였다.

1 . nginx의 환경변수 설정

• vue 로 작성한 파일을 nginx에 올리기위해 nginx의 환경변수를 설정해준다.

2 . Dockerfile 작성

3 . 이미지 생성 및 ArgoCD로 배포

• Backend와 마찬가지로 Dockerfile을 빌드하고 생성된 이미지를 Docker Hub에 Push한다
• ArgoCD와 연동중인 Git에 Frontend Deployment의 yaml파일에서 파드의 image를 Docker Hub에 Push된 이미지로 교체한다.
• 이후 add와 commit, Push를 한다.
• ArgoCD에서 새로운 Push를 감지하고 새로운 이미지가 적용된 컨테이너를 가진 파드를 Deployment에 의해서 Rolling Update로 배포한다.

• AWS콘솔에서 기존의 Frontend Ingress에 의해 생성된 ALB의 DNS Name을 브라우저에 입력하면 정상적으로 Vue로 작성된 웹페이지가 나타나는 것을 확인.

RDS연동

📒 RDS연동 참조

• RDS 생성 및 연동 부분은 데이터베이스 담당인 다른 팀원이 작업하였다.
• 해당 팀원이 RDS관련 작업 후 문서화를 하여 블로그에 업로드하였다. 따라서 RDS관련하여 위의 링크를 참조하면 된다.

Jenkins 설치

• 헬름을 이용하여 젠킨스를 설치할 것이다.

kubectl create namespace jenkins # 젠킨스용 네임스페이스 생성

helm repo add jenkinsci https://charts.jenkins.io
helm repo update # helm으로 설치 

vi jenkins-values.yaml

controller:
  tag: "lts-jdk11" # 젠킨스는 java설치가 필수이다
  serviceType: LoadBalancer # 젠킨스 웹페이지에 접속하기 위해 노출시킨다 
  installPlugins: # 여러 플러그인 설치 (젠킨스 웹페이지 처음 들어가면 설치하는 플러그인들)
  - kubernetes
  - workflow-aggregator
  - git
  - configuration-as-code
  - pipeline-stage-view
  adminPassword: # 패스워드 입력 

persistence:
  storageClass: "efs-sc" # EFS스토리지 사용  

helm install jenkins jenkinsci/jenkins -n jenkins -f jenkins-values.yaml # 젠킨스 설치 완료 

• Jenkins Pod가 배포되고 로드밸런서가 정상적으로 작동하기까지 매우 오래걸렸다. = 에러가 아닐수도 있으니 좀만 더 기다려보자
• 처음에는 yaml파일에 스토리지클래스 항목에 아무생각없이 이전 실습에서 사용한 gp2 스토리지클래스를 지정했다.
• 클러스터배포과정에서 OIDC를 이용해서 EBS CSI Driver를 사용할 수 있는 EBS CSI Controller를 가진 서비스 계정을 생성했었다. 따라서 당연히 스토리지 클래스에 EBS타입인 gp2를 사용해도 EBS를 사용할 수 있는 권한이 있는 서비스 계정이 있기 때문에 문제없다고 생각했다. 하지만 계속해서 파드가 Pending이 되어있었고, PVC는 동적으로 PV를 생성하지 못하였다.
• 확인해보니 EBS-CSI-Controller가 존재하지 않았다. 내 생각으로는 클러스터 배포과정에서 EFS-CSI-Controller를 가지는 서비스계정을 OIDC를 이용해서 생성했었는데 이 과정에서 EBS-CSI-Controller가 생성되지 않았던 것 같다.
• 따라서 OIDC를 이용하지 않고 수동으로 IAM을 생성해서 EBS-CSI-Controller를 가지는 서비스 계정을 만들어 gp2스토리지 클래스를 사용하려 했지만 생각해보니 굳이 gp2를 사용하지 않고 그냥 현재 이용중인 EFS스토리지를 이용해도 되겠다고 생각했다. 따라서 이전에 생성한 EFS스토리지 클래스를 지정했다.