AWS IAM, S3, CI/CD, 종합실습 - TIL230517

📚 KDT WEEK 7 DAY 3 TIL

• IAM
• S3
• CI/CD

 

---

🟥 IAM

Amazon Identity and Access Management

AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스

리소스를 사용할 수 있는 로그인 인증 및 권한 부여 대상을 제어할 수 있다. ex) 루트 사용자 로그인

※ 일상적인 작업에는 루트 사용자가 아니라 별도의 사용자 계정을 사용하는 것을 권장함

 

• 리소스 별, 권한(읽기/쓰기) 별로 지정도 가능
• 많은 AWS 서비스와의 통합가능
• 일부를 제외하고 기본적으로 무료 사용
• 역할, 정책, 사용자 등에 대한 정의

 

IAM 정책

테스크를 수행하기 위해 방법과 관계없이 작업에 대한 권한을 정의하는 것

사용하는 곳에 알맞는 역할과 정책을 추가하거나 지정해줘야 한다.

ex) 권한의 유무로 S3에 엑세스할 수 있는지를 따질 수 있다.

 

AWS의 IAM 사용자 추가 화면

사용자 추가 외에도 그룹을 생성하여 그룹에 포함시킬 수 있으며, 권한도 부여할 수 있다.

추가된 사용자는 액세스 키, 비밀 엑세스 키, 비밀번호 등을 고유적으로 부여받아 갖게 된다.

 

---

 

🟦 S3

Amazon Simple Storage Service(Amazon S3)

데이터 가용성 및 확장성 보안 및 성능을 갖춘 객체 스토리지 서비스

특정 비즈니스나 조직에 맞게 데이터에 대한 액세스를 최적화, 구조화 및 구성할 수 있는 관리 기능을 제공

ex) 일반적인 영상 및 이미지, 빅데이터 등등.

 

S3를 사용하여 정적 웹 사이트를 별도의 서버없이 호스팅할 수도 있음

 

• 버킷 : 저장된 객체에 대한 컨테이너(윈도우의 폴더)
• 객체 : S3에 저장되는 기본 개체 / 객체 데이터와 메타 데이터가 있음
• 키 : 객체를 판별할 수 있는 식별자

 

S3에서 버킷(폴더)를 만들어 객체(파일)를 담아두는 모습

 

버킷의 속성에서 정적 웹 사이트 호스팅 편집이 가능하다.

정적 웹 사이트 호스팅을 활성화하면 url을 받아 접속할 수도 있다.

(버킷 권한 정책에서 퍼블릭 액세스 차단을 풀어줘야 접속이 가능하다.)

 

---

 

🟩 CI / CD

 

• Continuous Integration (CI)
  • 코드를 커밋하고 병합하는 과정
• Continuous Delivery (CD)
  • 개발팀이 지속적인 짧은 주기로 SW를 개발하고 배포하는 것

▶ CI + CD = 개발한 내용을 빌드하고 배포하는 과정을 자동화

 

AWS내에서의 CI / CD

 

AWS CodeCommit

클라우드에 소스 코드나 바이너리 파일 등의 자산을 비공개로 저장하여 관리할 수 있게 한다. 깃허브와 비슷하다.

 

• 코드 공동작업이 가능하고 안전하게 저장할 수 있음
• AWS가 아닌 다른 서비스와도 호환되며, git에서도 가져올 수 있음
• git의 대부분의 기능 및 명령어도 제공

CodeCommit에서 임의의 Repo를 생성한 모습. git clone도 가능하다.

 

AWS CodeBuild

클라우드상에의 완전관리형 빌드 서비스

코드가 올라오면 자동으로 빌드하고 넘겨준다.

 

• 자체 빌드 서버 필요없이 소스 코드 컴파일 및 단위 테스트 실행, 빌드까지 가능
• Gradle 등 많이 사용되는 빌드 도구에 맞게 빌드 환경을 제공함

 

CodeBuild에서 빌드 프로젝트를 생성하는 중 '소스' 옵션

 

아까 만들었던 CodeCommit의 firstRepo를 가져올 수 있는 것은 물론이고,

Github의 OAuth 인증만 하면 내 깃허브의 Repo도 모두 가져올 수 있다!

 

 

AWS CodeDeploy

CodeBuild에서 넘어온 코드를 자동적으로 배포할 수 있도록 서비스

코드, AWS Lambda, 웹 파일, 패키지, 스크립트 등등 배포 가능하다.

 

AWS CodePipeline

CI/CD 전과정을 자동화시키는 서비스

개발 서버, 운영 서버, 스테이징 서버 등 각 서버마다 하나씩 필요하다.

CodeCommit, CodeBuild, CodePipeline 서비스를 한번에 엮는다.

 

---

 

🟧 종합 실습으로 처음부터 배포해보기

 

AWS 웹서버 아키텍처

 

 

0. 백엔드 모듈 구성

 

1. VPC 구성

추가로 NAT Gateway도 넣어야 한다..

2. Elastic Beanstalk 구성

다음으로 만들었던 앱을 넣을 Elastic Beanstalk 환경을 구성한다.

환경을 구성한 다음에 VPC를 넣으려면 어렵기 때문에, 구성하면서 아래처럼 VPC 설정을 완료해주면 좋다.

 

Private 영역에 Elastic Beanstalk을 넣어준다.

데이터베이스도 똑같이 Private 영역에 넣어주었다.

 

3. Bastion host 생성 > EC2

bastion host 역할을 할 EC2를 하나 만들어준다.

역시 아까 만들었던 VPC를 설정해준다. bastion host는 퍼블릭에 들어가야 한다.

 

bastion host 인스턴스 생성 중 VPC를 설정한 모습

 

4. 콘솔로 Private subnet의 ElasticBeanstalk 접속하기

 

Private에 퍼블릭ID를 통해 콘솔로 접속하려고 시도하면 당연히 접속되지 않는다.

Private에 접속하려면 public에 등록한 bastion host를 통해 접속해야한다.

 

1. 터미널에서 bastion host에 접속하여 .ssh 폴더에 사용하던 pem 키를 복사 (chmod 400도 필요)

2. 사용하려는 ElasticBeanstalk 구성에서 보안 수정 > EC2 키페어에 pem 키 등록

3. 설정이 되면 사용하려는 ElasticBeanstalk 환경의 Private IP를 통해 터미널로 접속

 

Public의 bastion host를 통해 Private의 ElasticBeanstalk에 접속되는 것을 확인할 수 있다.

 

---

 

5. RDS 설치

사전에 서브넷 그룹을 먼저 생성해준다.

AWS RDS > 서브넷 그룹 생성 > VPC Private subnet에 등록

 

DB를 생성합니다.

RDS > 데이터베이스 생성 ➡️ 방금 생성한 서브넷 그룹 적용, 그 외에는 기본 설정 적용

 

생성 후 파라미터 그룹에서 DB의 여러 설정을 바꿔줄 수 있다.

MySQL을 설정했다면 포트로 3306이 들어갔는지 확인하면 좋다. (없으면 접속불가)

 

DB가 생성되면 MySQL WorkBench 등을 통해 테스트 커넥션을 해볼 수 있다.

> Host : 생성된 엔드포인트

> Port : 3306

> User, Password : DB 생성시 등록한 유저와 비밀번호 입력

 

※ Public subnet에 DB가 들어있으므로 SSH 설정도 따로 넣어줘야 정상적으로 접속이 가능하다.

> SSH Configurations 탭에서 추가 설정필요

> Host : bastion host 퍼블릭 IP

> User name : ec2-user(기본)

> Authentication type : Key pair

> Private key file : 사용하는 pem 파일 등록

 

 

---

 

6. Front 관리

 

S3 버킷에 Front 리소스들을 관리하기 위해 새로 생성합니다.

버킷 이름을 사용할 도메인 이름으로 새로 생성하고, 정적 웹 사이트 호스팅을 활성화합니다.

 

간단한 Front 작업이 된 파일이 있다면 버킷에 올려 테스트합니다.

테스트를 위해 버킷의 퍼블릭 액세스 차단 해제와 버킷 권한 설정이 필요합니다.

 

설정이 완료되었다면 버킷의 정적 웹 사이트 호스팅 설정에 나타난 엔드 포인트를 통해 접속이 가능하다.

 

---

 

7. CI/CD 연동

CodePipeline 서비스를 연동하여 CI/CD를 구현한다.

 

1. 코드 파이프라인을 깃허브와 연동이 가능하도록 생성 (OAuth 인증필요)

• 브랜치의 경우 개발 상황에 따라 브랜치의 수 만큼 파이프라인 구성이 필요하다.

2. CodeBuild 생성의 경우 사용할 환경에 맞게 생성해여 파이프라인에 넣어야한다.

• 해당 코드빌드의 Buildspec 편집을 통해 build:와 artifact: 추가가 필요하다.

phases:
	build:
    		commands:
        		- ./gradlew build # gradlew 로 빌드
artifacts:
	files:
    	- '**/*' # 모든 파일을 보냄

 

3. 배포 스테이지 추가의 경우 BeanStalk이 Public에 있다면 바로 BeanStalk 적용이 가능하지만, Private에 존재하기 때문에 CodeDeploy와 ELB를 사용한다.

• CodeDeploy를 EC2 Auto Scaling 설정을 On하여 새로 생성한다.
• 생성 마지막에 로드 밸런서 추가의 경우 EC2만 사용하냐, BeanStalk을 사용했냐로 갈린다.
  • EC2만 사용하는 경우 별도의 EC2 로드밸런서가 필요하다.
  • 나는 BeanStalk을 따로 생성하여 관리하므로 BeanStalk 로드밸런서를 사용한다.
• Private Subnet을 연결하는 ELB를 통해 배포가 가능해진다.

4. 생성된 CodeDeploy를 코드파이프라인에 추가한다.

 

※ CodeDeploy를 사용할 때는 Front 루트 폴더에 appspec.yml 파일을 추가해야한다. 아래 링크 참고.

https://velog.io/@wngud4950/AWS-EC2-CodeDeploy-Appspec.yml%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC

[AWS] EC2-CodeDeploy Appspec.yml에 대하여

그래야 깃허브에서 소스를 가져올 때 CodeDeploy가 Appspec.yml 파일을 읽어 정상적으로 가져올 수 있다.

 

CI/CD가 제대로 구동하는지 확인하려면 터미널에서 beanstalk에 접속하고,

CodeDeploy Agent를 먼저 설치해줘야 한다.

 

wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent status # codedeploy 동작확인
# 위 status에서 codedeploy가 동작하지 않고 있다면
# sudo service codedeploy-agent start # codedeploy 동작

참고 링크 : https://sangchul.kr/entry/aws-codedeploy-%EC%97%90%EC%9D%B4%EC%A0%84%ED%8A%B8-%EC%84%A4%EC%B9%98codedeploy-agent-install

 

이후 깃허브로 push를 명령하면 코드 파이프라인이 자동적으로 빌드되는 것을 확인할 수 있다.

 

---

 

8. Route53 설정

도메인을 Route53을 통해 도메인을 구매하는 경우 > Route53 의 도메인 등록을 통해 도메인 구매

다른 곳에서 도메인을 구해온 경우 > 호스팅 영역 생성에서 구매했던 도메인을 넣어 NameServer 발급받아 교체해주기

 

CloudFront를 통해 배포하기(CDN)

 

CloudFront 생성

• 만들었던 S3 등록
• HTTP 사용 등 원하는 세팅 설정
• 인증서의 경우 AWS Certificate Manager 의 퍼블릭 인증서 요청을 통해 SSL인증서 발급가능 (도메인으로 발급)

 

Route53에서 레코드생성 > 값/ 트래픽 라우팅 대상에 CDN이나 S3 등 방법에 따라 라우팅 설정

 

---

 

🤔 공부하면서 어려웠던 내용

AWS가 제공하는 서비스가 정~말 많은 것 같다.

기능을 하나하나 외우는 것도 어렵지만, 처음보는 용어가 많아서 더 어려운 것 같다..😭

모르는 용어 하나를 검색하면 새로운 용어 몇 개를 또 봐야하는.. 딜레마에 빠진다.

AWS 공부하면서 내가 기초가 정말 부족하다는 생각도 많이 들었다..