[TIL] 7주차_Day28: AWS 클라우드 실습 (3)

💡Today I Learned

• AWS 클라우드 실습에 대한 세 번째 수업을 진행했습니다.
• IAM, S3, CI/CD 파이프라인 구축, 종합 실습 (백엔드 모듈_Springboost, Elastic bs 생성, baston host 생성, VPC 구성)

---

 

1. AWS Identity and Access Management (IAM)

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

: 리소스 사용 시 인증(로그인) 및 권한 부여된 대상을 제어함

: 자격 증명 = AWS 계정 루트 사용자 → 계정 생성할 때 사용한 이메일, 암호로 로그인

: 루트 사용자 = 해당 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 로그인 ID

→ 일상적인 작업에는 루트 사용자를 사용하지 않을 것 (권장)

 

- 엑세스 키 공유하지 않고도 AWS의 리소스 사용 권한을 다른 사용자에게 부여 가능

- 리소스에 따라 여러 사용자에게 다양한 권한 부여 가능

- EC2 인스턴스에서 실행되는 application을 위한 보안

- ID 페더레이션 (임시 액세스 권한 부여 관련 기능)

- PCI DSS 준수 (국제적 신용카드 데이터 처리 관련)

- 많은 AWS 서비스와의 통합

- 기본적으로 무료로 사용 (일부 기능 제외)

 

- IAM 정책

: 어떤 리소스에 액세스 가능한지 관련 정책

: 단일 사용자 or 사용자들의 그룹에 [정책]을 부여

: 여러 정책들을 묶어서 특정 [역할]에 매핑 → 각각의 서비스에 대한 접근 제어를 적용

(단일 사용자 or 사용자 그룹의 역할에 따라 부여된 정책이 다름)

 

- 서비스 이용 전

Q. 나한테 이 서비스를 이용할 수 있는 정책이 부여됐는지?

Q. 내가 속한 그룹에 이 서비스 이용 정책이 부여됐는지?

Q. 내가 위임된 역할에 이 서비스 이용 정책이 부여됐는지?

→ 모두 아닐 경우 권한 없음, 리소스 접근 불가

 

- IAM 생성하기 (실습)

: 사용자 생성 _ AWS Management Console에 대한 사용자 액세스 권한 제공

• 콘솔 암호(자동생성) → 생성한 사용자가 로그인 시 직접 비밀번호 바꿀 수 있도록
• 액세스 키 생성 → CLI (AWS CLI를 사용하여 AWS 계정에 액세스할 수 있도록 이 액세스 키를 사용)

: 사용자 그룹 생성

: 정책 생성

*) 처음 서비스, 인스턴스 생성할 때 관련 역할이나 정책이 없을 경우 에러 발생 → IAM에서 필요한 역할, 정책 만들어주면 됨

 

2. Amazon Simple Storage Service (S3)

: 확장성, 데이터 가용성, 보안, 성능 제공하는 객체 스토리지 서비스

: 파일, 객체를 저장해서 활용할 수 있는 스토리지

: 이미지, 스트리밍 파일 ~ 빅데이터, 모바일, 웹사이트 ... 다양한 사용 사례에서 원하는 양의 데이터를 저장/보호

 

- 액세스 관리: public/private

- 저장되는 데이터에 대해 분석/인사이트

 

- S3를 이용한 정적 웹 사이트 호스팅

: 정적 웹 사이트에서 개별 웹 페이지는 정적 콘텐츠를 포함함

: 클라이언트 측 스크립트를 포함할 수도 있음 (별도의 서버 없이)

*) 동적 웹사이트는 PHP, JSP, ASP .NET 등 서버 측 스크립트를 포함 → 서버 측 처리에 의존함

 

- 버킷

: S3에 저장된 객체에 대한 컨테이너

: 모든 객체는 어떤 버킷에 포함됨

: 윈도우에서의 '폴더'

 

- 객체

: S3에 저장되는 기본 개체

: 객체 = 객체 데이터 + 메타 데이터

 

- 키

: 버킷 내 객체의 고유한 식별자

: 버킷 내 모든 객체는 하나의 키를 가짐

: 버킷 + 키 + 버전 ID 의 조합 → 각 객체를 고유하게 식별

 

- S3 버킷 생성 (실습)

: 버킷 생성

: 업로드 - index.html (테스트 파일)

: 버킷 > 속성 > 정적 웹 사이트 호스팅 > 활성화 > 인덱스 문서 (업로드 한 index.html) > 생성된 URL로 접속 시 403 forbidden

: (버킷에 대한 권한 정책 열어주기) 버킷 > 권한 > 퍼블릭 엑세스 차단 편집(버킷 설정) > 차단 해제

: 버킷 > 권한 > 버킷 정책 > 정책 생성기 > S3 Bucket policy > Actions > All Actions(v) (모든 액션에 대한 권한 허용) > 버킷 ARN 복붙 + '/*' → 안에 있는 모든 파일에 대해 액세스 가능 > Add statement > Generate Policy > JSON 파일 복붙해서 정책 등록

 

3. CI/CD(CodeCommit, CodeBuild, CodeDeploy, CodePipeline)

: 자동으로 빌드 & 배포

: DevOps의 중추적인 역할

 

- CI

: 지속적 통합

: 모든 개발자가 개발한 코드를 공유 repository에 코드를 커밋, 병합

 

- CD

: 지속적 배포

: 개발팀이 짧은 주기로 sw를 개발하고 언제든지 운영 환경으로 안정적으로 배포

 

- AWS CodeCommit

: 깃허브 역할 (repository) 

: 소스 형상(버전) 관리 서비스

: 비공개로 저장/관리

: git clone 후 git add/commit/push, pull받을 수도 있음

 

- CodeCommit repo 생성 (실습)

: clone 주소도 깃허브처럼 사용 가능

 

- AWS CodeBuild

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

: 소스코드 컴파일, 유닛 테스트 실행

: 자체 빌드 서버를 프로비저닝, 관리, 확장할 필요 없음

: Maven, Gradle 같은 빌드 환경을 제공함

 

- CodeBuild 빌드 프로젝트 생성 (실습)

: 소스 공급자에서 깃허브, 비트버킷, AWS CodeCommit .. 의 repo 연동 가능

: 개발 서버(develop) / 운영 서버(main/master) 브랜치 설정

: 환경 (운영체제, 런타임, 이미지, 이미지 버전, 서비스 역할 ...) 설정

: 소스 파일 내에 [Buildspec] 파일을 넣기 or 빌드 명령 삽입으로 빌드 스크립트 만들기

: 아티팩트 = 빌드 후 다음 스텝인 배포될 때의 필요한 파라미터

 

- AWS CodeDeploy

: 빌드된 코드를 넘겨받아 자동 배포

: CodeDeploy는 서버에서 실행됨, S3 버킷 혹은 깃허브 repo 등에 저장되는 애플리케이션 콘텐츠를 배포 가능

: CodeDeploy를 위해 기존 코드를 변경할 필요는 없음

 

- CodeDeploy 애플리케이션 생성 (실습)

: 애플리케이션 생성 > 이름, 컴퓨팅 플랫폼 설정

: 배포 그룹 생성 > 역할 (CodeDeploy 권한이 있는) > 로드밸런서 대상 그룹 선택 > 환경 구성

 

- AWS CodePipeline

: 대체로 커밋, 빌드, 배포를 단독적으로 사용하지는 않을 것임

: 코드 커밋/빌드/배포 파이프라인으로 연동해서 자동화

: 빠르고 안정적인 애플리케이션 및 인프라 업데이트 → 릴리즈 파이프라인을 자동화하는 데 도움이 되는 완전관리형의 CI/CD 서비스

: 서버를 따로 설정하거나 프로비저닝할 필요성을 줄일 수 있음

: AWS Management 콘솔이나 AWS CLI를 사용해 sw 릴리즈 프로세스 단계를 정의할 수 있음

 

- CodePipeline 생성 (실습)

: 개발 서버 / 운영 서버 가 있다면 각 서버마다 파이프라인 필요 → 두 개의 파이프라인이 각각 필요함 (각 서버에 대한 이벤트를 받아 해당 배포 서버로 배포하기 때문)

: 파이프라인 생성 > 소스(커밋 repo), 브랜치 설정 > 빌드 스테이지 설정(Jenkins, AWS CodeBuild) > 배포 스테이지 설정(지난 수업에서 만들어 둔 Elastic beanstalk으로 바로 배포해도 됨, 애플리케이션 이름 & 환경 이름 설정)

 

4. 종합 실습

→ Gradle로 SpringBoot 프로젝트 생성하는 단계에 데모 설명이 아예 없다.. (백엔드 모듈 구성하는 과정만 보여줌)

→ IDE에서 Gradle 플러그인 설치하고 영상 따라서 SpringBoot 구성하기..?

 

- 종합 실습 구성

: 하나의 VPC 안에 서브넷 구성

: 가용 영역(AZ) 2개 안에 각각 private/public 서브넷

: private 서브넷 두 개 (AZ가 2개) → 내부에 인스턴스(Elastic beanstalk), RDBMS(RDS) + AZ 2개 중 1개에만 private 서브넷이 NAT gateway로 외부와 통신

: public 서브넷 → [baston host] 터널링을 통해 접속

: public 서브넷은 internet gateway를 통해 외부와 통신

: 인터넷을 통해 도메인 만들어서 SSL 인증서 적용

: CloudFront 구성

: S3에 정적 웹 호스팅 기능으로 간단한 React 소스 올려서 배포

: 소스코드를 git에다 올렸을 때 CodePipeline을 통해서 자동 배포되도록 구성

 

- 과정

1) JAVA를 이용해 백엔드 모듈 구성 ✅ (Gradle, SpringBoot 프로젝트 생성) → ..? 설정 과정 눈으로 보기만

2) Elasticbeanstalk 인스턴스 생성 ✅ → 앞서 만든 Springboot 프로젝트 운영, 웹 서버 관리/배포/실행

• 만들어둔 VPC 설정
• private subnet 영역에 생성
• RDS 선택 (DB)
• beanstalk이 만들어지면 자동적으로 EC2도 만들어짐

3) S3 구성

4) React(UI, 프론트) 구성

5) RDS 구성

6) VPC(AWS 가상 네트워크) 구성 ✅

7) baston host 역할의 EC2 인스턴스 생성 (서버) ✅ → public 서브넷에 위치함

7) 가상의 도메인 구성해서 연결

8) SSL 구성

9) CI/CD 자동 빌드/배포 구성

 

- Maven/Gradle

: 자바 기반 프로젝트의 의존성 관리, 빌드 자동화 툴

: SpringBoot 애플리케이션을 빌드하고 관리하는 데에 Maven/Gradle..을 사용

: Maven/Gradle..을 사용해 필요한 SpringBoot 의존성을 프로젝트에 추가

 

- React

: FE

: UI개발

: JS 라이브러리

 

- SpringBoot/Spring

: Java 기반 BE 프레임워크

: 서버 로직 개발

: Java 기반 백엔드 애플리케이션을 빠르고 쉽게 구축하기 위한 프레임워크

: Spring Boot 프로젝트를 관리하고 빌드하는 데에 Maven/Gradle...을 사용해 프로젝트의 개발과 관리를 편리하게 할 수 있음

*) Spring 프레임워크: Java 기반의 애플리케이션 개발을 간소화하고 유연하게 만들어주는 프레임워크

*) Spring Boot 프레임워크: Spring 프레임워크를 보다 빠르고 쉽게 시작할 수 있도록 도와주는 도구, 내장된 설정과 간소화된 방식으로 Spring 애플리케이션을 빠르게 구축할 수 있도록 지원

 

- Elastic beanstalk과 EC2 관계

: Elastic Beanstalk은 Ebs로 배포할 애플리케이션을 선택하면, 필요한 EC2 인스턴스와 관련 리소스(로드 밸런서, 데이터베이스, 스토리지 등)를 자동으로 프로비저닝하고 구성하여 해당 애플리케이션을 실행함

: Elastic Beanstalk은 EC2 인스턴스 위에서 동작하지만, EC2 인스턴스 안에 직접 구축되는 것이 아니라 Elastic Beanstalk 자체적으로 애플리케이션을 관리함

: 사용자는 Elastic Beanstalk을 통해 애플리케이션을 배포, Elastic Beanstalk이 관리하는 인프라 위에서 애플리케이션을 실행함

 

- baston host

: 보안 목적으로 네트워크에 접근하는 데 사용되는 중간 단계의 보안 포인트

: 일반적으로 내부 네트워크에 접근하기 위해 외부에서 안전하게 접속할 수 있는 경로로 사용됨

1. 보안 강화: 외부 네트워크와 내부 네트워크 사이에 위치, 외부에서 내부 시스템에 직접 접근하지 못하도록 보안을 강화
2. 원격 액세스: 보안된 방법으로 내부 시스템에 원격으로 접근하기 위해 사용. ex) SSH나 RDP와 같은 프로토콜을 사용하여 내부 서버에 안전하게 접속
3. 관리 및 모니터링: 시스템 관리자가 시스템에 접근하여 관리하거나, 보안 감시 및 로그 수집 등을 위해 사용

: 일반적으로 외부에서 접속할 수 있지만, 내부 시스템으로의 접근은 엄격하게 제한됨 → 따라서 내부 네트워크에 있는 다른 호스트들에 대한 보안을 강화, 외부로부터의 접근을 통제하는 역할

 

 

---

 

💡Furthermore

• 설명 부족한 부분 따로 개념 이해
  
  • 온프레미스 인스턴스
  • baston host 터널링..? 
  • React
  • Springboot/Spring
  • Gradle/Maven
• 새 Elastic beanstalk, baston host, VPC 생성 아직 x (현재 이전 실습에서 생성한 것들만 남아있음)