07 CI/CD

data_hamster·2023년 5월 21일

학습주제
배포부터 서비스 구성까지
CI/CD 구성

학습내용
백엔트 스프링부트로 만들었던 소스를 직접 CI/CD에 연동해서 붙여보도록 한다
코드 파이프라인을 이용
가지고 있는 소스는 깃허브에 있다고 가정
코드 빌드를 사용
코드 디플로이를 이용해 배포
VPC 내에 퍼블릭, 프라이빗 나눠져 있음. 프라이빗 안에 빈스톡이 설치되어 있음

우선 파이프라인을 만들어본다
CodePipeline으로 와서
파이프라인을 생성한다

소스는 깃허브2에서 가져온다고 가정한다

인텔리제이에서 만들었던 프로젝트를 깃허브의 aws-jongwook와 연결하고 push하였다.

현재 브랜치는 main이나 개발 중이면 dev, feature 등을 끌어오면 된다.
만일 운영, 개발 서버가 따로 있으면 각각의 파이프라인을 따로 파줘야함.

파이프라인은 1개의 브랜치에 꼽을 수 있음

빌드는 aws codebuild를 이용

기존의 빌드를 이용한다

이게 중요함
그래들로 빌드할것이기 때문

이 뜻은 모든 파일을 보낸다는 뜻

이제 배포를 할 때 퍼블릭에 있다고 하면 빈스톡을 바로 끌고 오면 된다. 아주 손쉬운 배포가 됨.
그러나 우리는 프라이빗 안에 있는 것을 연동할 것임.
코드 디플로이를 하나 만든 뒤
ELB에 묶어서 배포할 것임.

프라이빗 서브넷에 위치한 인스턴스에 직접 배포하려면 인터넷을 통한 접근이 필요한데, 이는 보안상 좋지 않을 수 있습니다. 그래서 일반적으로 프라이빗 서브넷에 배포하는 경우에는 CodeDeploy 같은 서비스를 사용합니다.
CodeDeploy는 내부적으로 AWS에서 관리하는 서비스이므로, AWS의 내부 네트워크를 통해 프라이빗 서브넷에 있는 인스턴스에 접근할 수 있습니다. 따라서 프라이빗 서브넷에 있는 인스턴스에 배포하려면 CodeDeploy를 사용하는 것이 좋습니다.
또한, ELB는 프라이빗 서브넷과 퍼블릭 서브넷 간에 트래픽을 라우팅하는 데 사용됩니다. 사용자의 요청은 퍼블릭 서브넷에 있는 ELB로 먼저 도달하고, ELB는 이 요청을 프라이빗 서브넷에 있는 애플리케이션 인스턴스로 라우팅합니다. 따라서 사용자는 프라이빗 서브넷에 있는 애플리케이션에 안전하게 접근할 수 있습니다.

배포 그룹을 먼저 생성해줘야함

일전에 빈스톡을 만들었으면 ELB가 있었을 것임
그게 아니라면 별도의 ELB를 만들어줘야함
ELB를 통해 프라이빗 인스턴스를 연결해줘야함

전에 만들었던 ELB는 기본 VPC에 적용됨 다시 만들어줘야함

대상그룹 citron-service-target을 만들어준다

대상그룹 생성함
로드밸런서 생성
Application Load Balancer로 만듦

AWS의 Elastic Load Balancer (ELB)를 설정할 때 서브넷을 선택하는 것은 흔히 헷갈리는 부분 중 하나입니다.
ELB를 생성할 때는 퍼블릭 서브넷을 선택해야 합니다. ELB는 인터넷 트래픽을 받아서 EC2 인스턴스 등의 대상에 분배하는 역할을 하기 때문에, 인터넷에 연결할 수 있는 퍼블릭 서브넷에 위치해야 합니다.
그런 다음 ELB는 프라이빗 서브넷에 위치한 EC2 인스턴스로 트래픽을 라우팅합니다. 이렇게 하면, 사용자의 요청은 인터넷을 통해 퍼블릭 서브넷의 ELB로 들어오고, 그 후 ELB는 요청을 프라이빗 서브넷의 인스턴스로 안전하게 라우팅하는 구조가 됩니다.

로드밸런서를 생성했다

코드 디플로이 만든게 있어서, 배포그룹과 함께 설정했다
정확히는 모르지만 배포를 어떻게 할지에 대한 설정인 것 같다. 만일 실패할경우 이부분을 다시 파야한다.

아 코드 디플로이에서 어덯게 배포할지 설정하고
배포 그룹에서 - 로드 밸런서를 연결해서 프라이빗 서브넷에 배포할 수 있게한다.

이는 빈스톡을 위한 ELB이다

최종적으로 파이프라인을 생성했다

소스는 금방 가져온다
성공했다
현재 빌드 진행중

만일 실패했을경우

나는 빌드에서 실패했다

코드 디플로이를 사용할 때는 스프링부트 안에 appspec.yml이라는 파일을 하나 넣어주어야 함.

이 파일이 어디로 배포가될지 정해줘야함. 빈스톡이라면 다른 경로겠지만, ec2 기준이라면 저 경로를 설정해줘야함. (근데 빈스톡에 프로젝트를 넣어놓지 않았나??)

깃으로 깃허브에 업로드 하고, 다시 파이프라인을 가동해본다

변경사항이 바로 소스로 공급되는 것을 확인함.
현재 빌드 진행 중.
실패함

그렇다고 한다

CodeBuild의 프로젝트 빌드로 넘어가

version: 0.2

phases:
  build:
    commands:
      - chmod +x ./gradlew
      - ./gradlew build

한줄 추가했다

그리고 파이프라인을 돌리기 전에, 빌드만 따로 돌려본다
실패함. -소스를 받아야 하는 거같음
파이프라인에서 다시 재실행함

경과 나오면 다시 적기로 하고 강의를 진행
appspec.yml은
이벤트, 보안적인 요소의 속성이 필요하게 되면 aws 가이드를 읽고 yml문서를 완성시키면 된다.

기본틀은 루트 자리에 appspec.yml를 추가한다
그래야 코드 디플로이가 문제없이 돌아감

오!!!

빌드 성공

코드 디플로이
빈스톡에 잘 되고 있는지 로그까지 보기로 한다
콘솔 창을 띄운다
일전에 빈스톡에 들어가려면
baston에 들어가서 그다음 빈스톡 접속함

접속. baston에 이미 mykey 이식해놨으니 이제 빈스톡으로 접속 프라이빗 아이피로 접속

실패함. 마찬가지로 .ssh 폴더로 들어가 키를 사용해야함
뭐지 실패함 sudo su -로 시도함

보니까 mykey.pem이 날라가있음 혹시모르니까 메모장에 저장해놓자

와.. 여러번 실패하니까 키를 막아버렸다. 물어보니까 그건 아니라고 한다
chmod 400 mykey.pem
로 소유자 읽기전용으로 만들어야 한다

접속 성공

일단 코드 디플로이 실패함
코드 디플로이 에이전트를 설치해야 할수도 있음
직접 로그를 보기 위해선 코드 디플로이가 설치되어야한다

자동적으로 설치해주는 옵션을 선택해도 설치가 안되는 경우가 있음

wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
뭔가 다운로드됨

chmod +x ./install
이걸로 설치
sudo ./install auto
했는데
루비를 설치하지 않아 발생한 문제인 것 같다고 한다
정상적으로 실행됨

정상적으로 작동함
start로 실행시킴

코드 디플로이가 에러가 났다고 하면 로그를 보면 된다
less /var/log/aws/codedeploy-agent/codedeploy-agent.log
!을 눌러서 나갈 수 있다

bastonhost가 에러가 난다. 빼준다

네, Bastion 호스트는 필요에 따라 사용할 수 있습니다. Bastion 호스트는 일반적으로 인터넷에서 직접 액세스할 수 없는 private subnet 내의 인스턴스에 접근하기 위한 "게이트웨이" 역할을 합니다.
그러나 AWS Elastic Load Balancer (ELB)를 사용하는 경우, ELB가 public subnet에 위치하고 뒷단의 대상 그룹에 있는 인스턴스들 (여기서는 빈스톡)에 트래픽을 분배하게 됩니다. 이러한 구성에서 ELB는 private subnet에 있는 인스턴스들에게 인터넷 트래픽을 전달하는 역할을 하므로, 굳이 Bastion 호스트를 대상 그룹에 포함시킬 필요는 없습니다.
따라서 배포 대상이 빈스톡 인스턴스이고, Bastion 호스트가 배포에 직접적으로 관여하지 않는다면, 대상 그룹에서 Bastion 호스트를 제거해도 됩니다. 그러나 만약 SSH와 같은 수동 인터벤션이 필요한 경우에는 Bastion 호스트가 여전히 필요할 수 있습니다. 그러나 이 경우에도 일반적으로 Bastion 호스트를 배포 프로세스의 일부로 포함시키지는 않습니다.

bastonhost를 제거하고 다시 디플로이를 돌린다
실패함 - 빈스톡에 연결이 안됨

'Access Denied'라는 메시지는 AWS CodeDeploy가 S3 버킷에 있는 빌드 아티팩트를 다운로드하려고 할 때 S3 버킷에 대한 적절한 접근 권한이 없을 때 발생합니다. 이 문제를 해결하기 위해서는 다음과 같은 단계를 따르실 수 있습니다:
S3 버킷의 권한 설정을 확인하세요: AWS CodeDeploy가 필요한 파일에 접근할 수 있도록 S3 버킷에 대한 적절한 접근 권한이 설정되어 있는지 확인해야 합니다.
AWS CodeDeploy 서비스 역할 확인: AWS CodeDeploy는 S3 버킷에 있는 빌드 아티팩트에 접근하려면 적절한 IAM 역할을 가지고 있어야 합니다. AWS CodeDeploy 서비스에 연결된 IAM 역할이 S3에 대한 적절한 권한을 가지고 있는지 확인하세요.
배포 그룹 설정 확인: 배포 그룹이 올바르게 설정되었는지 확인하십시오. 특히, 배포 구성이 적절한지 확인하십시오.
S3 버킷의 지역 확인: AWS 서비스는 지역별로 분리되어 있습니다. 따라서 CodeDeploy와 S3 버킷이 동일한 지역에 위치해야 합니다. CodeDeploy와 S3 버킷의 지역을 확인해 보세요.