[65일 차] 21.10.26 : DevOps 6

AWS CodeStar

AWS S3

AWS CLI

AWS EBS

---

1교시

 

 

• AWS CodeStar

애플리케이션의 개발-빌드-배포까지 빠르게 진행하는 통합 서비스

개발 플랫폼은 뭘로 할지, 배포는 어디에 할지 등을 설정하고 시작하면 알아서 환경을 구성해 준다.

(CloudFormation으로 알아서 해준다)

알아서 다 해준다고는 하지만, 구성 내용이 뭔지는 알아야 한다(상세하게 알 필요는 없지만)

-> CodeCommit, CodeBuild, CodeDeploy, CodePipeline

 

* 장점

- 통합된 UI로 한 번에 여러 활동을 관리할 수 있다.

- CD 도구 체인을 구성해 신속한 코드 배포 가능

- 소유자, 기여자 및 최종 사용자 추가로 안정적인 협업 가능

- UI 구성이기에 Dashboard를 사용해 전체 개발 프로세스의 진행 상황 추적 가능

 

개발자 도구 섹션에 있는 CodeStar로 이동

프로젝트 만들기 > 템플릿 선택(Node.js) > 프로젝트 이름 작성, 프로젝트 리포지토리 선택(CodeCommit)

(IAM 설정도 알아서 만들어준다)

> 생성

생성 중에 CLoudFormation을 확인해 보면 스택 파일이 생성되고 있다.

조금 기다리면 CodeCommit에 필요한 파일들이 업로드된 저장소도 생긴다.

CodeBuild, , CodeDeploy, , Lambda, CodePipeline도 생성된다.

AWS Cloud9 설정 클릭 > 이름 작성 후 생성

 

(AWS Elastic Beanstalk : 웹 서비스를 빠르게 배포할 수 있는 서비스)

 

기존 과정은

App 개발을 Cloud9에서 진행(소스코드 작성)

-> 작성한 코드를 CodeCommit에 저장(업로드)

-> 저장한 코드를 CodeBuild를 통해 빌드

-> 빌드 내용을 S3 버킷에 저장

-> CodeDeploy에서 S3에 저장된 내용을 기반으로 실제 운영 환경에 배포

 

CodeStar에서는 소스 코드는 이미 만들어진 것이고, 위 과정들도 알아서 진행해준다.

권한이나 역할 관련 작업도 알아서 해준다.

CodeCommit ~ 운영환경 배포 부분은 CodePipeline이 통합하던 작업인데, CodeStar는 CodePipeline을 생성해 그룹으로 만든다.

 

CodeStar 상세 정보 > IDE 탭 > Open IDE > 터미널을 보면 git clone으로 저장소를 복제하는 것이 보인다 > 좌측 목록에 보면 저장소 clone 결과가 보인다

git config --global user.name YOUR_USER_NAME

git config --global user.email YOUR_EMAIL_ADDRESS

를 실행해서 사용자 설정

 

애플리케이션 엔드포인트는 CodeStar 상세 정보 우측에 있는 '애플리케이션 보기'를 누르면 애플리케이션으로 접속할 수 있다.

이 초기 화면은

저장소 폴더 구성

index.html이 웹 페이지 파일이다. 들어가서 수정해 보자. 수정 후 저장

사용자 인증은 아까 했으니 업로드 과정을 진행하면 CodePipeline이 변동을 감지하고 빌드 과정을 다시 진행한다.

-> CodePipeline을 가보면 진행 과정을 확인할 수 있다.

 

※ Node.js 애플리케이션의 index.html을 수정할 때, 왜인지는 모르겠지만 

index.html

Congratulation을 빼니 에러가 발생했다. 뭔 이유인지는 모르겠다. 어디에 그런 걸 확인하는 코드가 있나 보다.

 

삭제하려면 CodeStar 프로젝트를 삭제하면 다 사라진다. S3 버킷은 수동으로 삭제.

-> 업데이트 도중 삭제하기 시작하면 뭔가 많이 꼬인다. 이전 작업들이 모두 끝난 뒤에 삭제를 시작할 것.

---

2교시

 

 

• AWS 코어 서비스

1. 클라우드에 데이터 저장

1.1. 객체 저장하기 : S3와 S3 Glacier

   -> aws cli를 활용하여 S3 버킷 생성, 파일 업로드

   -> SDK를 활용하여 애플리케이션과 S3 통합

   -> S3에 정적 웹 사이트 호스팅

   -> S3 Glacier 사용

1.2. 하드 드라이브에 데이터 저장 : EBS와 인스턴스 스토어

1.3. 관계형 DB 사용하기 : RDS

1.4. NoSQL DB 서비스 프로그래밍 : DynamoDB

 

2. 고가용성 아키텍처 설계

3. 인프라 디커플링

4. 장애 허용 시스템 아키텍쳐 설계

 

https://awscli.amazonaws.com/AWSCLIV2.msi

Windows용 AWS-CLI 다운로드 후 Windows 터미널로 들어가서 aws --version을 치면 AWS-CLI 버전이 나온다

 

사용자 폴더에 .aws 폴더가 생기는데, 여기에는 config 파일과 credentials 파일이 있다.

config 파일은 AWS API가 AWS CLI에게 자격 증명을 묻고 AWS CLI가 대답할 때(aws configure) 사용할 사용자 정보

 

IAM > 사용자 추가 > 이름 작성, 액세스 유형은 액세스 키 방식 > 기존 정책 직접 연결(원래는 실습에 사용할 정책만 연결해야 하지만, 편의상 AdministratorAccess 연결) > csv 파일 받아놓기

Windows 터미널로 돌아와서 aws configure 실행 > csv 파일에 있는 정보 입력/리전은 ap-northeast-2, 기본 출력 형식은 yaml > 사용자 폴더에 .aws 폴더가 생겼다.

여기에 있는 config 파일과 credentials 파일을 보면 정보들이 입력되어 있다.

이제 AWS로 EC2 인스턴스를 통해서가 아닌 명령어를 통해 접속할 수 있다.

 

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html

What is the AWS Command Line Interface? - AWS Command Line Interface

AWS CLI 명령어 문서 참조

명령어는 대체로 " aws 서비스명 명령 파라미터값 " 이런 구조다.

---

3교시

 

 

1.1.1. 객체 스토어

그림 파일이라는 객체가 있다면 내부에는

1) 전역 고유 키

2) 메타데이터 : 접근 제어, 파일 타입, 태그, 크기, 생성 날짜 등

3) 데이터 : 텍스트, 그림, 영상 등

S3 버킷에서의 전역 고유 키는 URI 주소라고 볼 수 있다.

 

1.1.2. S3 서비스(Simple Storage Service)

-> 저장 공간을 무제한 제공

-> 고가용성(High Availability)과 내구성(Endurance)

-> GB당 $0.025, 접근성 요청 즉시, 내구성 연중 99.9999%

aws s3 mb s3://버킷명

-> S3 버킷 만들기

 

1.1.3. S3 버킷 백업 설정

aws s3 sync [업로드할 파일 경로] s3://버킷명/backup

-> 버킷의 backup 디렉터리에 업로드한 파일이 올라가 있다.

S3 데이터를 로컬에 백업하는 폴더를 하나 만들고, 

-> aws s3 cp --recursive s3://버킷명/backup [백업 폴더 경로]

aws s3 rb --force s3://버킷명

-> S3 버킷 지우기. --force로 내부 파일 미리 삭제할 필요 없이 바로 버킷 삭제

 

1.1.4. S3 Glacier

-> GB당 $0.005, 접근성 요청 후 3~5시간 소요, 내구성 연중 99.9999%

 

Glacier와 함께 사용할 S3 버킷 생성 후 파일 아무거나 업로드

만든 S3 버킷 상세 정보에서 속성 탭 > 지능형 계층화 아카이브 구성 > 구성 생성 > 이름 입력, 구성 범위는 '이 구성은 버킷의 모든 객체에 적용', 아카이브 설정은 '아카이브 액세스 계층' 체크하고 전환까지 남은 기간은 90 입력 > 생성

 

실습 끝났으니 버킷은 삭제.

여기까지가 'aws cli를 활용하여 S3 버킷 생성, 파일 업로드'

이번에는 'SDK를 활용하여 애플리케이션과 S3 통합'

---

4교시

 

 

1.1.5. SDK를 활용하여 애플리케이션과 S3 통합

-> S3 버킷은 HTTPS 방식의 API로 접근 가능

 

지금까지는 AWS CLI 또는 콘솔을 통해 S3 버킷 서비스에 접근했다.

웹 애플리케이션이 직접 S3 버킷과 연동하려면(CRUD) SDK를 사용한다.

 

애플리케이션은 강사님이 주신 파일을 받고, Windows에 Node.js 받아서 기본값으로 다운로드

(다운로드하고 터미널 다시 시작) node -v와 npm -v로 설치 확인

터미널에서 해당 디렉터리로 이동 후 npm install 실행

> node server.js [버킷명] 실행 후 http://localhost:8080으로 접속

(당연히 버킷은 만들어놓고 실행해야 한다)

---

5교시

 

 

강사님이 주신 Node.js 파일에 에러가 있어서 해결하느라 한 교시를 날렸다.

오랜만에 Node.js를 만지니 몽실몽실하다. 졸작의 추억.

 

※ S3 링크를 사용할 때

-> https://[버킷명].s3.amazonaws.com/[파일 경로]

이런 식으로 작성한다. 강사님이 주신 버전에는 https://s3.amazonaws.com/[버킷명]/[파일 경로] 이런 식이었는데, 인터넷을 뒤지다 보니 의견이 좀 갈렸다.

1) 후자의 링크 방식은 구식이다. 

2) 따로 폴더가 없다면 후자의 방식으로 해도 상관없다.

그런데 내 실습의 경우에는 따로 폴더가 없었는데도 에러가 났으니, 2)는 틀린 의견으로 보인다.

---

6교시

 

 

강사님은 에러가 해결 안돼서 대충 20분 정도 씨름하셨다.

어쨌거나 해결했고, 테스트했으니 끝. 이제 버킷 삭제

 

Node.js로 애플리케이션을 만들었는데, 얘는 인증 과정을 어떻게 통과했지?

aws-sdk에서 자격 증명을 한 적이 없는데?

-> AWS-CLI에서 인증한 내용이 AWS-SDK로 넘어왔기 때문.

 

 

1.1.6. S3에 정적 웹 사이트 호스팅

(정적 콘텐츠니까 가능한 것. 동적 콘텐츠를 쓰려면 EC2 써야지)

-> 사용자 정의 인덱스 문서 및 오류 문서 정의

-> 모든/특정 요청에 대한 리다이렉션 정의

-> S3 버킷에 대한 사용자 정의 도메인 설정

 

일단 S3 버킷을 만들자.

-> 콘솔에서 만드는 버킷은 기본적으로 퍼블릭 액세스가 차단되어 있다.

-> AWS-CLI의 mb 명령어로 생성하면 기본값은 퍼블릭 액세스가 허용되어 있다.

 

대충 html 파일 하나 만들어서 버킷에 업로드

-> 버킷이 정적 호스팅이 가능하게 만들고, 이 안에 있는 hello.html을 불특정 다수가 이 개체의 URL을 확인할 수 있다면 해당 버킷 내부의 이 객체에 접근할 수 있게 해야 한다.

---

7교시

 

 

간단한 정적 웹 사이트 호스팅

 aws s3api put-bucket-policy --bucket [버킷명]] --policy file://[정책 파일.json]

이러고 버킷의 권한 탭으로 가서 버킷 정책을 보면 수정된 것을 볼 수 있다.

 

aws s3 website s3://[버킷명] --index-document [인덱스 파일]

실행하면 버킷 상세 정보의 속성 탭의 하단에서 정적 웹 사이트 호스팅이 활성화되고, 웹 사이트 엔드포인트 링크를 볼 수 있다. 접속하면 인덱스 파일이 웹으로 보인다.

 

이러면 끝. 버킷 삭제

 

 

1.2. 하드 드라이브에 데이터 저장 : EBS와 인스턴스 스토어

-> EC2 인스턴스에 네트워크 스토리지 연결하기(NFS)

-> EC2 인스턴스의 인스턴스 스토어 사용하기

-> 블록 레벨 스토리지 백업하기

-> 블록 레벨 스토리지 성능 점검 및 튜닝

-> 인스턴스 스토리지와 네트워크 연결 스토리지 비교

 

1.2.1.

운영 체제는 open, write, read와 같은 시스템 콜을 통해 블록 레벨 스토리지에 접근하는 길을 열어준다.

read 요청의 흐름을 단순화하면 다음과 같다.

1) 애플리케이션이 /path/to/file.txt 파일을 읽기 원한다면 read라는 시스템 콜을 호출

2) OS는 그 read 요청을 파일 시스템에 전달

3) 파일 시스템은 /path/to/file.txt를 해당 데이터가 저장된 디스크 블록으로 변환

 

1.2.2.

AWS는 2종류의 블록 레벨 스토리지를 제공한다 : NAS, 인스턴스 스토리지

NAS(= EBS)

-> 네트워크 연결을 통해 EC2 인스턴스에 부착

-> 데이터 가용성 99.9999%

인스턴스 스토리지

-> 호스트 시스템이 EC2 인스턴스에 제공하는 보통의 하드 디스크

전자는 EC2 인스턴스에 종속적이지 않고, 후자는 종속적

 

1.2.3.

네트워크 연결 스토리지(NAS)

EBS(Elastic Block Store)는 네트워크로 연결되는 블록 레벨 스토리지를 99.9999%의 가용성으로 제공

 

특성

1) EC2 인스턴스에 속하지 않는다. 따라서 EC2 인스턴스를 종료하더라도 EBS 볼륨은 남아있다.

2) 연결된 EC2 인스턴스가 없거나, 한 번에 하나의 EC2 인스턴스에 연결될 수 있다.

3) 보통의 하드 디스크처럼 사용할 수 있다.

4) RAID1과 유사하다 = 데이터가 백그라운드에서 여러 디스크에 저장된다.

EBS 구조

※ 같은 EBS 볼륨을 여러 서버에 연결할 수 없다.

---

8교시

 

 

EBS 구축은 CloudFormation에 사용할 yml 파일을 받아서 진행했다.

-> EC2 인스턴스와 볼륨이 생겼다.

 

인스턴스에서 만든 볼륨은 파일 시스템이 설치되어 있고, 따로 만든 볼륨(/dev/xvdf)은 빈 상태로 있다.

빈 볼륨에 파일 시스템 설치 및 마운트 > 마운트 경로(/mnt/volume)에 파일 생성 > 마운트 해제

스택 업데이트 > 스택 세부 정보 지정에서 AttachVolume을 no로 선택 후 업데이트

 

다시 EC2 인스턴스로 접속해서 확인해보면?

> 마운트 해제했으니 다른 볼륨이 없다.

> EBS 탭의 볼륨으로 가보면 사용 가능한, 사용 중이지 않은 볼륨이 하나 있다.

> 아까와는 달리 AttachVolume을 yes로 바꾸고 업데이트

> EC2 인스턴스로 접속해서 디스크 확인 : 추가 볼륨(/dev/xvdf)이 장착되어 있다.

> 다시 마운트(/mnt/volume)하고 내부 목록을 보면? : 아까 만들었던 파일이 그대로 있다.

 

실습 끝. CloudFormation 스택 삭제.

 

 

내일은 데이터 백업, 하드 디스크 성능 보기, NFS 서버 구성 등을 진행

---

오늘은 다시 들을 부분 없다. 오예