행복한 지찬씌

이노그리드 특강_CI/CD_241023

지찬씌 — Thu, 31 Oct 2024 19:35:44 +0900

전날 생성한 Ingress에 플로팅 IP 설정

싱글 클러스터 컨테이너 플랫폼 포털 배포

- 작업 디렉터리 생성

- 컨테이너 플랫폼 포털 배포 Deployment 파일 다운 및 압축 해제

- 컨테이너 플랫폼 포털 변수 정의

=> control plane 플로팅 IP 마스터 노드 IP에 입력

=> IaaS Type 4(NHN)으로 수정

=> Host 도메인에 ingress의 플로팅 IP 입력

=> Provider Type은 standalone

- 컨테이너 플랫폼 포털 배포 스크립트 실행

=> 스크립트 실행이 실패하여 다시 다운받기 위해서는 uninstall 후 진행하고 다시 스크립트 실행

- 포털 관련 리소스 정상적으로 배포되었는지 확인

=> Vault Pod, Harbor Pod, MariaDB Pod, Keycloak Pod, 컨테이너 플랫폼 포털 Pod 확인

-포털 접속 확인

컨테이너 플랫폼 파이프라인 설치 (포털 배포 우선되어야 함.)

- 컨테이너 플랫폼 파이프라인 Deployment 파일 설치 및 tar 파일 압축 해제

(포털 배포하며 만든 디렉터리 사용 => ./workspace/container-platform)

- 파이프라인 변수 정의

=> 마스터 노드의 플로팅 IP 추가

=> 호스트 도메인(인그레스)의 플로팅 IP 추가

=> Provider Type은 standalone

=> 다른 설정은 디폴트

- 파이프라인 배포 스크립트 권한 설정 및 실행

- 설치 완료 후 파이프라인 리소스 조회

- 파이프라인 접속

Source Controler 설치 (포털 배포 우선되어야 함.)

- 컨테이너 플랫폼 소스 컨트롤 Deployment 파일 설치 & tar 파일 압축 해제 => cp-source-control-deployment-v1.5.1.tar.gz

(포털 배포하며 만든 디렉터리 사용 => ./workspace/container-platform)

- 소스 컨트롤 변수 정의 (파이프라인 환경 변수 설정과 동일)

=> 마스터 노드의 플로팅 IP 추가

=> 호스트 도메인(인그레스)의 플로팅 IP 추가

=> Provider Type은 standalone

=> 다른 설정은 디폴트

- 소스 컨트롤 배포 스크립트 실행

- 소스 컨트롤 리소스 조회

- 소스 컨트롤 접속

실습. 간단한 CI/CD 파이프라인 작업 (Spring-music App 구성 배포)

1. 배포 job 생성

- 신규 생성

=> 파이프라인 명 : spring-music

=> spring music 클릭하여 배포 job 추가

=> 빌더 : gradle (spring music의 빌더 타입은 gradle이다.)

=> 컨테이너 유형 : kubernetes

=> 형상관리 정보 : github에서 가져오기 떄문에 github 선택하고 레파지터리 URL 복사 + 붙여넣기

2. 품질 게이트 생성

3. 정적분석 job 추가

- 생성한 품질 게이트와 연결하고 저장

4. Test job 생성

- 추가 버튼

=> 작업 유형 JUnit-Test 설정

5. 파이프라인 설정 (kube config 등록)

=> 마스터노드(control plane) 콘솔에서 설치한 kubeconfig 내용을 입력

6. Deploy 배포 등록

=> namespace : default 로 수정

=> replicas : 3으로 수정

=> container;ports : 8080으로 수정

=> Service.yaml 내용도 namespace와 container;ports 수정

7. 배포 시작

- 빌드 job의 시작 버튼 클릭

=> 배포 완료 확인

8. 배포된 사이트 접속

- spring-music의 service port 확인 : 30810

- 사이트 접속. 주소: http://{마스터노드 플로팅 IP 주소}:30810

Yaml을 활용한 리소스 배포

1. Yaml 파일 작성

2. 디플로이먼트 배포

- namespace default로 설정하여 작성한 yaml 내용 입력 후 배포

3. 디플로이먼트와 동일한 방법으로 서비스 배포

4. 3번과 동일한 방법으로 인그레스 서비스 배포

5. 배포 확인

Kubernetes CLI를 활용한 리소스 배포

예제1. 파드를 생성하여 배포

1. namespace 생성 및 nginx 이미지를 사용한 파드 생성

2. 생성한 파드 조회

=> describe 명령어를 통해 상세 정보를 확인할 수 있다.

3. 생성한 파드에 서비스를 붙여 노출

=> 동일하게 describe 명령어를 통해 상세정보를 확인할 수 있다.

예제2. 디플로이먼트 배포

1. 디플로이먼트 생성 및 조회

2. 생성한 디플로이먼트에 서비스 노출 후 확인

3. edit 명령어를 사용해 replicas의 숫자 변경

4. replicas 숫자 변경 후 pod 개수 확인

=> kpaas-ningx2의 파드가 4개에서 3개로 개수가 변경된 것을 확인

예제3. vim 을 통한 yaml 파일 작성으로 deployment 생성

1. Deployment을 생성하기 위한 kpaas.yaml 파일 생성

2. Deployment 생성 및 리소스 확인

클라우드_7일차_241014

지찬씌 — Thu, 31 Oct 2024 09:21:42 +0900

EKS (Elastic Kubernetes Service)

EKS를 이용한 클러스터 구성

- Amazon EKS 클러스터 생성

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/create-cluster.html

- 관리형 노드 그룹 생성

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/create-managed-node-group.html

VPC 생성 - CloudFormation을 이용

https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml

1. 스택 생성

- CloudFormation 에서 스택 생성

- 템플릿 정보를 가지고 있는 S3 버킷 URL을 입력하여 템플릿을 가져오고 나머지 설정은 default 사용

- 스택 생성 후 VPC 확인

2. 클러스터 서비스 역할 생성

: 컨트롤플레인이 사용자를 대신해서 AWS 리소스를 관리하는데 사용하는 역할 부여

- IAM (Identity and Access Management) 에 접속하여 역할 생성

- 생성하는 역할 이름 설정하고 [역할 생성]

3. 클러스터 생성

- Amazon EKS 접속, 클러스터 생성

- 1단계 클러스터 구성에서는 클러스터 이름 / 역할 / 버전을 선택하고 나머지는 default로 설정.

- 2단계 네트워크 지정. 템플릿을 통해 생성된 VPC를 선택하면 자동으로 서브넷, 보안그룹 등이 설정된다.

클러스터 외부에서만 접근할 것이기 때문에 클러스터 엔드포인트 엑세스는 "퍼블릭"으로 설정.

- 3,4,5 단계는 모두 default 설정을 가져가고 6단계에서 최종 검토 후 클러스터를 생성

- 클러스터가 생성 중을 지나 활성화 됨을 확인

4. 생성된 클러스터와 로컬 PC의 kubectl이 통신하도록 설정

* 로컬 PC에서 kubectl 설치 확인

> kubectl version --client

* 로컬 PC에 kubectl 설치 (설치되지 않은 경우, 버전이 맞지 않은 경우)

윈도우 kubectl 설치 링크 : https://kubernetes.io/ko/docs/tasks/tools/install-kubectl-windows/

> curl.exe -L0 "https://dl.k8s.io/release/v1.31.0/bin/windows/amd64/kubectl.exe"

> 설치 후 버전 확인. kubectl version --client

* 로컬 PC의 프롬프트 어느경로에서든 kubectl을 사용하기 위해서 환경변수로 추가한다.

검색 > 시스템 환경 변수 편집 > "환경 변수" > PATH 더블 클릭 > kubectl.exe 위치 경로 등록

* AWS CLI 설치 확인

> aws --version

> 설치 링크 : https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html

- root 사용자의 엑세스 키를 발급 받아 등록

root 사용자의 엑세스 키는 IAM이 아니라 우측 메뉴의 보안 자격 증명에서 생성

- 엑세스 키 발급 이후는 기존의 엑세스 키 등록방법과 동일

> aws configure

AWS Access Key ID [****************HGAT]: AKI**********42FL

AWS Secret Access Key [****************B+UN]: 0ZFXHbNq******************i9zyyIzu+p3

Default region name [ap-northeast-2]:

Default output format [json]:

- EKS 클러스터에 연결할 수 있도록 인증 및 설정 정보를 구성

> aws eks update-kubeconfig --region ap-northeast-2 --name MyEKSCluster

- 서비스와 노드 정보 확인

> kubectl get service

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 176m

> kubectl get node

No resources found

5. EKS 노드 역할을 생성

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/create-node-role.html

- 신규 역할 생성

1단계. work 노드를 생성할 것이기 때문에 EC2 인스턴스에 대한 엔터티 및 사용 사례를 선택

- 2단계. 권한 추가 (AmazonEKS_CNI_Policy / AmazonEKSWorkerNodePolicy / AmaonEC2ContainerRegistryReadOnly)

- 나머지 설정은 default를 취하고 EKS 노드의 역할을 생성한다.

6. EKS 노드 그룹 생성

- AWS EKS에서 생성한 MyEKSCluster의 노드 그룹을 생성

- 1단계. 노드 그룹의 이름과 역할 설정

- 2단계. 컴퓨팅 및 조정 구성 설정

아래와 같이 default 설정을 가져간다.

- 3단계. 네트워킹 지정 후 생성

Public Subnet을 제외하고 Private Subnet으로 지정한다. (외부에서 worker 노드에 접근할 필요는 없기 때문)

- 노드 그룹 생성 확인 (각 속성의 화면에서도 확인할 수 있다.)

- 명령 프롬프트에서 노드 실행 확인

> kubectl get node -o wide

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME

ip-192-168-131-151.ap-northeast-2.compute.internal Ready <none> 3m6s v1.30.4-eks-a737599 192.168.131.151 <none> Amazon Linux 2 5.10.225-213.878.amzn2.x86_64 containerd://1.7.11

ip-192-168-205-186.ap-northeast-2.compute.internal Ready <none> 3m3s v1.30.4-eks-a737599 192.168.205.186 <none> Amazon Linux 2 5.10.225-213.878.amzn2.x86_64 containerd://1.7.11

- 클러스터 구성요소 설치 확인

> kubectl get namespace

NAME STATUS AGE

default Active 3h16m

kube-node-lease Active 3h16m

kube-public Active 3h16m

kube-system Active 3h16m

> kubectl get all -n kube-system

NAME READY STATUS RESTARTS AGE

pod/aws-node-dps28 2/2 Running 0 5m30s

pod/aws-node-r2s6r 2/2 Running 0 5m32s

pod/coredns-5b9dfbf96-ht656 1/1 Running 0 3h5m

pod/coredns-5b9dfbf96-lm897 1/1 Running 0 3h5m

pod/eks-pod-identity-agent-mmhlw 1/1 Running 0 5m32s

pod/eks-pod-identity-agent-v5kdd 1/1 Running 0 5m30s

pod/kube-proxy-cbbq5 1/1 Running 0 5m32s

pod/kube-proxy-jlzp4 1/1 Running 0 5m30s

7. 클러스터에 디플로이먼트와 서비스 생성

- Yaml 파일 작성

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 3

selector:

matchLabels:

app: webserver

template:

metadata:

labels:

app: webserver

spec:

containers:

- name: my-webserver

image: alicek106/rr-test:echo-hostname

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

spec:

type: LoadBalancer

selector:

app: webserver

ports:

- name: web-port

port: 80

targetPort: 80

- 배포

> kubectl apply -f eks-sample.yaml

> kubectl get all

NAME READY STATUS RESTARTS AGE

pod/hostname-deployment-7b57c676b9-7l664 1/1 Running 0 2m20s

pod/hostname-deployment-7b57c676b9-fvg4l 1/1 Running 0 2m20s

pod/hostname-deployment-7b57c676b9-zjvqx 1/1 Running 0 2m20s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

service/hostname-loadbalancer LoadBalancer 10.100.126.144 a02056dfb06f840f69f974b57 80:32697/TCP 2m20s

b4bf3d7-1963070520.ap-

northeast-2.elb.amazonaws.com

service/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 3h23m

NAME READY UP-TO-DATE AVAILABLE AGE

deployment.apps/hostname-deployment 3/3 3 3 2m20s

NAME DESIRED CURRENT READY AGE

replicaset.apps/hostname-deployment-7b57c676b9 3 3 3 2m20s

8. 브라우저를 통해 확인

파드 3개가 서비스 됨을 확인할 수 있다.

또한 EXTERNAL IP가 80포트로 서비스되고 있기 때문에 도메인의 시작은 http:// 이어야 한다.

9. 리소스 정리

- EKS 노드 그룹 삭제

=> 노드(EC2 인스턴스) 또한 함께 삭제된다.

- EKS 클러스터 삭제

=> 노드 그룹 삭제 이후 삭제 가능해진다.

- CloudFormation 삭제

- ELB (Elastic LoadBalancer) 삭제

- root 계정의 엑세스 키 삭제

- 생성한 역할 삭제

- EC2 인스턴스 및 VPC 삭제 확인

클라우드_6일차_241011

지찬씌 — Thu, 31 Oct 2024 09:21:24 +0900

VPC 생성

: Public 서브넷 1개와 Private 서브넷 1개로 구성

=> 연결된 라우팅 테이블 생성, public-rt와 연결되는 igw 생성

관리형 관계형 데이터베이스 서비스 생성 (RDS, Relational Database Service)

1. RDS 생성

- 데이터베이스 생성 후 엔드포인트와 포트 확인

- 클라이언트 PC에서 RDS로 연결 확인(MYSQL Workbench)

: 퍼블릭 엑세스가 불가능하므로 연결할 수 없다.

2. 베스천 호스트 생성

: 퍼블릭 서브넷에 EC2 인스턴스를 생성

3. 베스천 호스트를 통해서 RDS로 연결하도록 설정

4. MySQL Workbench를 사용해서 스키마와 테이블 생성

FastAPI 앱을 EC2에 배포

- Amazon Linux 2023 OS에 python 설치

https://jakpentest.tistory.com/entry/AWS-EC2-Amazon-Linux-2023-%EC%97%90%EC%84%9C-Python-Project-Setting

- SFTP를 이용해서 소스 코드를 업로드 (또는 github를 통해서 배포)

람다 함수 작성

1. 작업 디렉터리 생성 (C:\aws\board)

2. VS Code에서 lambds_function.py 파일 생성 및 람다 함수 실행 소스코드 작성

3. 람다 함수 실행에 필요한 패키치 설치 후 zip 배포 패키지 생성

4. 람다 함수 생성 및 코드 추가

5. 테스트 이벤트를 구성

6. 테스트 진행

=> timeout 오류 발생 시 제한 시간 변경 (3초 -> 60초)

=> Runtime 오류 발생. 에러 원인은 람다 함수가 mariaDB에 연결할 수 없기 때문으로 나옴

7. RDS에서 람다 함수 연결 설정

=> 연결 설정을 위해서는 RDS와 람다 함수가 같은 VPC에 존재해야 하고

=> VPC 연결을 위해서는 람다 함수의 역할에 AWSLambdaVPCAccessExcutionRole 정책을 연결해야 한다.

- 람다 함수에 AWSLambdaVPCAccessExcutionRole 정책 연결

- RDS에서 람다 함수 연결

- 람다 함수 테스트 및 db에서 확인

8. 소스 코드를 수정하여 등록 후 전체 조회 결과를 반환하도록 변경

- 코드 수정

- 새로 압축해서 람다 함수에 업로드하여 구동 확인

API Gateway 설정

https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/welcome.html

1. REST API 생성 후 배포

- REST API 생성

- 리소스 생성

- 메서드 생성

- 테스트

로그에 표시되는 내용은

API Gateway에서 보내는 로그의 내용이고

가운데 Authorization의 ******....

내용은 람다함수에서 보내는 로그 내용이다.

- API 배포

- 엔드포인트 확인 후 테스트

2. API Gateway와 연동하는 리액트 앱을 개발

- App.js에 아래 기능 구현

1) 제목, 내용, 글쓴이를 입력할 수 있는 입력창을 제공

2) 등록 버튼을 클릭하면 API Gateway에 등록한 API를 호출

3) 호출 결과 성공인 경우, 가져온 데이터를 출력

=> CORS 오류 발생

- CORS 오류를 해결하기 위해 API Gateway의 CORS 활성화

3. 반환받은 데이터를 화면에 출력하는 코드 추가

4. 리액트 코드를 빌드해서 배포 버전을 생성

- npm run build

5. S3 버킷 생성

- 버킷 생성

- 빌드 결과물 (.\build 디렉터리 아래 내용)을 S3 버킷에 업로드

- 정적 웹 사이트 호스팅 활성화

=> 정적 웹 사이트 호스팅을 활성화하여 버킷의 웹 사이트 엔드포인트로 접근하였지만 권한 오류가 발생한다.

- 객체 소유권을 ACL (Access Control List) 활성화로 변경하고 객체와 버킷 ACL에 대한 퍼블릭 엑세스를 열어준다.

AWS 특강_241028

지찬씌 — Mon, 28 Oct 2024 16:38:50 +0900

AWS Glue

: 전처리(ETL)를 주 목적으로 한 서비스

분석 파이프라인. 중요

- 위 데이터 분석 파이프라인의 저장 부분에서 데이터 전처리(ETL)를 담당하고 분석을 용이하게 하는 역할을 한다.

AWS Glue 데이터 카탈로그

: 모든 데이터 자산의 정형 및 운영 메타 데이터를 저장하는 중앙 레포지터리를 말하는데, 크롤링 혹은 직접 저장, 참조를 통해 메타 데이터를 데이터 카탈로그화 한다.

크롤러

: 하나의 웹페이지에서 다른 웹페이졸 연결되는 링크를 따라가며 웹 사이트를 자동으로 검색하고 스캔하는데 사용되는 프로그램이다.

AWS Glue의 Job

: Glue의 작업은 아래 3가지 방법으로 개발이 가능하다. 개인의 개발 방법과 리소스 사용 방식에 따라 적절하게 선택하면 된다.

1. Glue Studio (AWS 관리 콘솔)

2. SageMake Studio (AWS 관리 콘솔)

3. 로컬 (로컬 PC 혹은 EC2)

AWS SageMaker

: AWS의 Machine Learning 서비스

조직별 엑세스 제어의 핵심

: 사용자와 객체에 대한 태그 지정으로 엑세스 제어를 실현한다. 관리자로써 태그의 사용은 정말 중요하다.

관리하는 테이블의 수가 방대해지면, 행기반 / 열기반 관리 방식으로는 관리가 불가능하다.

따라서 태그 기반으로 관리하면 원활한 관리가 가능하다.

쿠버네티스에서도 태그와 비슷하게 레이블(label)로 스케줄링 등과 같은 기능에 사용한다.

AWS Lake Formation

: Lake Formation을 사용하면 데이터 메시 환경을 구현하는데 유용하다.

- 데이터 메시 환경

: 조직 내에서 각각의 부서들이 사용하는 여러 개의 테이블이 데이터를 서로 참조하고 공유하는 환경을 의미한다.

Data Zone

: 데이터 생산자와 데이터 소비자 모두에게 협업 도구를 제공하는 완전 관리형 서비스

실습 데이터 생산자 작업 (1~6까지 예상 사용자 : 생산자)

실습 Flow

소개

1. 실습 대상자와 전제조건

2. 실습의 목적

3. 사용하는 AWS 서비스

4. 실습에서 발생하는 요금

5. 주의사항

실습의 전체 흐름

1. Amazon DataZone 도메인 생성

2. 생산자 프로젝트 생성

3. 게시할 데이터 생성

4. 데이터 세트 게시

5. 소비사 프로젝트 생성 및 게시된 데이터 세트 구독

실습 본문

1. Amazon DataZone 도메인과 데이터 포털 생성

1) DataZone 관리 페이지 열기

2) 도메인 생성

- 도메인 생성 마법사에서 도메인 생성

- 도메인 생성 확인 후 하이브리스 액세스 모드 활성화

=> 편집 클릭

=> 체크박스 체크하여 하이브리드 액세스 모드 활성화

2. 생산자 프로젝트 생성

1) 프로젝트 생성화면 이동 후 새 프로젝트 생성

3. 프로젝트 환경 생성

1) 환경 프로필 생성

2) 환경 생성

4. DataZone에서 게시할 데이터 생성

1-1) Amazon S3에 데이터 업로드

1-2) S3 관리 콘솔 이동

1-3) 데이터 파일 업로드용 폴더 생성

=> 폴더 생성 확인

1-4) 데이터 파일 가져오기 및 업로드

2-1) Glue Crawler 관리 콘솔로 이동

2-2) Crawler 생성 -> 기본 정보 입력 -> S3 저장소 지정

=> S3 저장소 지정

2-3) Crawler 생성 : IAM 권한 지정

2-5 Lake Formation 권한 설정

2-6) Crawler 생성 : 타겟 db 설정 및 생성

2-7) AWS Lake Formation 권한 추가 (Crawler 권한)

2-8) Crawler 실행

5. 메타데이터 설정

1) Glue Table 데이터 반영

1-1) 데이터 세트 가져오기

- AWS 관리 콘솔에서 DataZone 검색 -> 도메인 보기 -> 도메인 클릭 -> 데이터 포털 진입 -> 왼쪽 위 sales 클릭

1-2) 메타데이터 반영

=> 스키마 탭에서 자동 반영된 것을 확인

2. 비즈니스 용어집 설정

2-1) 비즈니스 용어집 작성 화면으로 이동

2-2) 비즈니스 용어집으로 '정보구분' 등록

2-3) 비즈니스 용어집으로 '판매 지역' 등록

3. 메타데이터 양식 입력

3-1) 메타데이터 양식 작성 화면으로 이동

3-2) 메타데이터 양식에 '세일즈 메타데이터' 등록 -1 (판매 지역 용어집)

3-3) 메타데이터 양식에 '세일즈 메타데이터' 등록 -2 (정보구분 용어집)

3-4) 메타데이터 양식 활성화

6. Amazon DataZone에서 데이터 게시

1. 게시 작업 실행

1-1) 데이터 게시 - 1

- Sales에서 추가

- 이때 경고 메세지(비관리형 자산)가 발생한다면 AWS Lake Formation 권한 설정을 진행한다.

1-2) 데이터 카탈로그에 정보 추가

1-3) 데이터 카탈로그에 메타데이터 추가

1-4) 데이터 카탈로그의 메타데이터 양식 편집

1-5) 데이터 카탈로그의 스키마 편집 및 반영

7. 소비자 프로젝트 생성 (여기부터 예상 사용자 : 소비자)

1. 소비자 프로젝트 생성

2. 환경 프로필 생성

3. 환경 생성

8. 게시된 데이터 자산을 소비자로 구독

1. 데이터 검색

2. 데이터 구독 요청

9. 게시한 데이터에 대해 생산자가 소비자의 엑세스 승인

1. 구독 요청 확인

10. 데이터 생산자가 게시한 데이터 세트를 데이터 소비자가 Amazon Athena에서 분석

1. 구독 승인 확인

2. 데이터 표시

DevOps/Scrum 특강_241024~241025

지찬씌 — Fri, 25 Oct 2024 09:52:53 +0900

DevOps

: 개발조직과 운영조직이 끊임없는 협업을 통해 빠른 서비스 배포를 통해 비즈니스 가치를 올리는 기업 내 문화, 개발 도구 및 방법 등을 통틀어 말하는 것이다.

- 사전적 정의

DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합입니다. 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있습니다.

(from. aws)

특징

1) 협업

2) 자동화

3) 지속적인 소규모 배포

4) Infrastructure as a Code

DevOps의 방향성

1. New Ways of working

2. CALMS (Culture / Automation / Lean / Measurement / Sharing)

3. The Three Ways

: DevOps 조직으로 성장해 나가는 방법 3가지 과정

The First Wasy	The Second Way	The Thrid Way
Flow	Feedback	Continuous Experimentation & Learning
개발에서 운영으로 하나의 흐름으로써 서로의 협업이 없는 일의 방식	개발과 운영이 활발한 의사소통을 통해 짧은 피드백이 끊임없이 일어나고, 이것이 계속 발전해 나가는 형태	- 육성하는 문화 조성 - 실험, 위험 감수 및 실패로부터의 학습을 기반 - 반복과 연습이 숙련자로 나아가는 조건이라는 것을 이해한 문화

4. The Five Ideals

5. DevOps Practices

: "지속적인" 이라는 의미에 중점

6. CI / CD

- CI (Continuous Integration)

1) 모든 개발자는 최소 매일 트렁크에서 코드를 확인

2) 각 체크인은 (자동화된 빌드 / 자동화된 유닛, 통합 및 수용 테스트)에 의해 검증되어야 한다.

3) 일관된 코딩 표준에 의존

4) 버전과리 저장소와 CI 서버가 함께 커밋된 코드를 수집, 구축 및 테스트해야 한다.

5) 프로덕션 환경과 유사한 환경에서 실행해야 한다.

6) 프로덕션 환경으로 변경 전 코드 변경으로 인한 영향을 조기에 감지하고 신속하게 수정할 수 있어야 한다.

- CD (Continuous Deployment & Delivery)

7. DevOps Toolchains

Development LifeCycle : Agile Development Theory : Scrum Method

애자일 선언문

- 선언문 이미지 아래에 적혀있는 사항이지만 오른쪽의 강조된 항목에 높은 가치를 둔다는 것이지,

왼쪽 항목(공정과 도구 / 포괄적인 문서 / 계약 협상 / 계획)을 무시한다는 것이 절대 아니다.

애자일 방법론의 특징

1. 각 단계별로 한번 지나가면 되돌리기 어려운 폭포수 방법 (Waterfall)에 비해 짧은 주기로 반복함

- fast fail을 통한 빠른 수정

- 자율적, 주도적 수행

장점 1. 사용자 중심의 제품 구현

장점 2. 일하는 방식의 개선

- 완벽한 계획을 수립하는 대신, 일단 시작한 후에 끊임없이 개선을 노력

2. 기존 방법론에 비해 애자일은 고객가치와 TTM(Time To Market)을 추구하므로, 비용 및 범위가 고정되지 않는다.

스크럼(Scrum) 기법

: 스크럼은 럭비에서 유래된 용어이다.

단어의 유래와 아래 이미지에서 알 수 있듯이 스크럼은 팀워크와 책임감이 중요한 업무 프로세스 방법이다.

- 장점
: 팀원끼리 적극적으로 독려하고 서로에게 피드백을 제공하며,

궁극적으로 제품/서비스의 발전을 위해 꾸준히 노력한다는 점이다.

- 스크럼의 Process

: 복수개의 Sprint로 구성되어 있으며, 각 스프린트마다 4가지의 이벤트 활동이 있다.

1) 스프린트 계획

2) 스프린트 미팅

3) 리뷰 회의

4) 회고

- 스크럼 팀의 구성 및 역할구분

1) 제품 책임자

2) 스크럼 마스터

3) 개발팀

이노그리드 CI/CD 특강_241022

지찬씌 — Wed, 23 Oct 2024 09:35:52 +0900

K-PasS Container Platform 배포

NHN 클라우드 접속 후 키페어 등록 (좌측 Compute -> Key Pair)

서브넷 생성 (좌측 Network -> Subnet)

인스턴스 생성

플로팅IP 생성

- 각 인스턴스의 플로팅 IP 생성 후 연결

- 생성된 사설 IP & 플로팅 IP 정보 따로 저장

SSH 접속 (MobaXterm 사용)

- session 클릭

- host 주소 칸에 플로팅 IP를 입력하고 username에는 ubuntu를 입력

- private key를 사용하며 제공받은 private key(sesac파일)를 지정

NFS 설치 (NFS 전용 인스턴스에서 진행. sesac-edu-mjc075)

- APT 업데이트

- NFS 서버를 위한 APT 패키지 설치 진행

- NFS 서버에서 사용할 디렉터리 생성 및 권한 부여

- 공유 디렉터리 설정

- NFS 서버 재시작 후 설정 확인

SSH 생성 및 배포 (control plane: sesac-edu-mjc071에서 진행)

- RSA 공개키 생성, 출력 및 복사

- control plane & worker 노드의 authorized_keys 파일 본문에 공개키 붙여넣기

Deployment 다운

- 클러스터 Deployment를 다운하여 설치 작업경로에 위치

환경변수 정의

- 클러스터 설치 경로로 이동 및 클러스터 설치에 필요한 환경변수 정보 입력

- 환경변수 정의

K-PaaS 컨테이너 플랫폼 클러스터 설치

- 설치되는 로그를 확인하기 위해서는 control plane의 다른 터미널을 열고 다음 명령어를 입력한다.

- 노드 및 kube-system 네임스페이스 내부 파드의 설치, 작동 상태 확인

인그레스 컨트롤러 네트워크 설정

- 새 네트워크 인터페이스 생성

- 환경변수로 설정한 인그레스 사설 IP 지정 및 나머지 설정은 default로 하고 생성

- 인그레스 컨트롤러를 연결할 control plane 인스턴스 중지 후 네트워크 탭의 연결 추가

- Worker 노드(3개) 및 NFS 서버 노드(1개)의 플로팅 IP 연결 해제

클라우드_4일차_241008

지찬씌 — Tue, 15 Oct 2024 09:12:53 +0900

AWS CLI 를 이용한 VPC, EC2 생성

1. IAM 사용자를 생성 (루트 계정으로 Management Console에 접속해서 생성)

- CLI를 이용하여 control 할 것이기 때문에, managemnet console 접속 권한을 주지 않는다.

- 새로 생성한 사용자의 AccessKey 생성

- AWS CLI에 사용자 정보를 등록

> aws configure

- VPC 정보를 조회

> aws ec2 describe-vpcs

- 사용자 정보를 조회

> aws iam get-user

2. VPC 생성

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-vpc.html

- VPC 생성 명령어

> aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specification "ResourceType=vpc, Tags=[{Key=Name, Value=MyVPC}]" --output json

- VPC 생성 확인 (VPC 생성 시 출력된 내용과 같은지 확인)

> aws ec2 describe-vpcs

- VPC 내용에서 특정 내용만 가져오는 명령어

배열에 astrick(*)을 사용해도 동일하게 가져올 수 있다.

- VPC ID를 환경변수로 설정 및 확인

3. 인터넷 게이트웨이를 생성 후 VPC에 연결

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-internet-gateway.html

- 인터넷 게이트웨이 생성

- 환경 변수에 인터넷 게이트웨이 ID를 등록

- 인터넷 게이트웨이에 VPC 연결 (=VPC ID와 게이트웨이 ID 필수)

- AWS Management Console에서 확인

4. Subnet 생성

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-subnet.html

- PublicSubnetA라는 이름의 서브넷 생성 (cidr-block 범위, 가용영역, 이름을 붙여주기 위한 tag-specification 필요)

- PublicSubnetC라는 이름의 서브넷 생성

- 퍼블릭 서브넷 ID를 환경변수로 설정 및 조회

1) PublicSubnetA

2) PublicSubnetC

5. 퍼블릭 서브넷 설정

- 퍼블릭 라우팅 테이블 생성

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-route-table.html

- 라우팅 테이블 ID를 환경변수로 설정

- 라우팅 테이블에 인터넷 게이트웨이로의 라우팅 정보를 추가 및 확인

- 퍼블릿 서브넷에 퍼블릭 라우팅 테이블을 연결

https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-route-table.html

- 퍼블릭 서브넷에 퍼블릭 IP를 자동으로 할당되도록 설정

https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-subnet-attribute.html

1) 필요한 정보 추출

> aws ec2 describe-subnets

> aws ec2 describe-subnets --query "Subnets[*].{SubnetId:SubnetId,CidrBlock:CidrBlock,MapPublicIpOnLaunch:MapPublicIpOnLaunch}"

2) 퍼블릭 IP 자동할당 옵션(MapPublicIpOnLaunch) true로 변경

3) 옵션(MapPublicIpOnLaunch) 변경 확인

6. VPC DNS 호스트 이름을 활성화

https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-vpc-attribute.html

* 프라이빗 서브넷 생성

1. 개요

이름	가용영역	CIDR
PrivateSubnetA	가용영역A	10.0.20.0/24
PrivateSubnetC	가용영역C	10.0.40.0/24

2. 서브넷 생성 및 조회

3. 서브넷 ID 환경변수로 설정

4. 라우팅 테이블 생성

5. 라우팅 테이블 조회

6. 라우팅 테이블 ID 환경변수로 설정

7. 서브넷과 라우팅 테이블 연결

8. Management Console에서 조회

7. 키 페어 생성

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-key-pair.html

8. 보안 그룹

https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html

- 보안 그룹 생성 및 생성된 보안 그룹의 ID를 환경변수로 설정

- 보안 그룹에 인바운드 규칙 추가

https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html

9. EC2 인스턴스 생성

- 인스턴스 생성 시 사용할 사용자 데이터(인스턴스 생성 시 시작할 프로그램)를 담고 있는 텍스트 파일 생성

> notepad user_data.txt

메모장에 아래 코드 입력하고 저장 후 종료

#!/bin/bash

yum install -y httpd
systemctl enable --now httpd
echo "<h1>Hello AWS CLI</h1>" > /var/www/html/index.html

- 인스턴스 생성에 사용할 이미지 ID 확인 (ami-0e18fe6ecdad223e5)

- 인스턴스 생성

https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html

> aws ec2 run-instances --image-id ami-0e18fe6ecdad223e5 --count 1 --instance-type t2.micro --key-name AWS_CLI_KEY --security-group-id %MYWEBSERVERSG% --subnet-id %PublicSubnetA_ID% --user-data file://user_data.txt --tag-sepcification "ResourceType=instance, Tags=[{Key=Name, Value=MyWebServer}]"

- 인스턴스 ID 를 환경변수로 설정

- 인스턴스의 퍼블릭 주소 확인 및 요청

- 인스턴스로 SSH 접속

10. 리소스 정리

- 인스턴스 종료

https://docs.aws.amazon.com/cli/latest/reference/ec2/terminate-instances.html

- 보안그룹 삭제

https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html

- 서브넷 삭제

https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-subnet.html

- 인터넷 게이트웨이를 VPC로부터 분리

https://docs.aws.amazon.com/cli/latest/reference/ec2/detach-internet-gateway.html

- 인터넷 게이트웨이 삭제

https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-internet-gateway.html

- 퍼블릭 라우팅 테이블 삭제

https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-route-table.html

- 프라이빗 라우팅 테이블은 기본라우팅 테이블을 사용했으므로 삭제 불가 (새로 만들었다면 삭제)

- 키페어 삭제

https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-key-pair.html

- VPC 삭제

https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-vpc.html

- EC2 인스턴스가 삭제된 것을 확인

- VPC 리소스가 모두 삭제되었는지 확인'

AWS 환경에서 LoadBalancer 타입의 서비스를 연동

실습 진행을 위해 먼저 가상머신 실행

1. IAM 사용자 생성 및 시크릿 키 생성

2. 작업머신 (vagrant로 생성한 controlplane 가상머신)에 사용자 정보 등록

및 kOps를 이용해 클러스터 구성

- 작업 머신에 aws 명령어 사용을 위한 awscli를 설치한다.

- 생성한 사용자 정보를 등록한다.

- 최신 버전의 kOps 다운로드

https://kubernetes.io/ko/docs/setup/production-environment/tools/kops/

> curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64

- kOps 바이너리에 실행 속성을 부여

- kops 바이너리를 사용자 PATH로 이동

=> 이 설정을 통해 kops-linux-amd64 명령어를 줄여서 kops만으로 사용할 수 있다.

3. 클러스터 상태를 저장할 S3 버킷을 생성

- S3 버킷 생성

- S3 버킷에 버저닝(Versioning) 활성화

- 쿠버네티스 클러스터 이름과 S3 버킷 이름을 환경변수로 설정

4. 쿠버네티스를 설치할 EC2 인스턴스에 배포할 SSH 키를 생성

- SSH 키 생성

- SSH 키 확인

5. 클러스터 설정 구성

> kops create cluster --zones ap-northeast-2a --networking calico --ssh-public-key ./id_rsa.pub $NAME

Must specify --yes to apply changes

Cluster configuration has been created.

Suggestions:

* list clusters with: kops get cluster

* edit this cluster with: kops edit cluster mycluster.k8s.local

* edit your node instance group: kops edit ig --name=mycluster.k8s.local nodes-ap-northeast-2a

* edit your control-plane instance group: kops edit ig --name=mycluster.k8s.local control-plane-ap-northeast-2a

Finally configure your cluster with: kops update cluster --name mycluster.k8s.local --yes --admin

=> 클러스터 생성 후 어떻게 설정하는 것인지 마지막에 알려준다.

- 3개의 워커 노드를 생성하도록 설정

- 클러스터 생성 (약 15분 정도 소요)

> kops update cluster --name mycluster.k8s.local --yes --admin

kOps has set your kubectl context to mycluster.k8s.local

Cluster is starting. It should be ready in a few minutes.

Suggestions:

* validate cluster: kops validate cluster --wait 10m

* list nodes: kubectl get nodes --show-labels

* ssh to a control-plane node: ssh -i ~/.ssh/id_rsa ubuntu@

* the ubuntu user is specific to Ubuntu. If not using Ubuntu please use the appropriate user based on your OS.

* read about installing addons at: https://kops.sigs.k8s.io/addons.

6. Deployment 및 LoadBalancer 타입의 서비스를 생성

- Deploymnet 생성

=> 기존 실습에서 사용한 hostname-deployment.yaml 파일을 사용한다.

> cat hostname-deployment.yaml (yaml 파일 조회)

> kubectl apply -f hostname-deployment.yaml

- LoadBalancer 타입의 서비스 생성

=> 기존의 hostname-service-nodeport.yaml의 type을 loadbalancer로 바꾼 뒤 서비스 생성

> kubectl apply -f hostname-service-loadbalancer.yaml

7. 생성된 LoadBalancer 타입의 EXTERNAL IP로 요청

- EXTERNAL IP(동적으로 생성된 로드밸런서의 DNS 주소와 동일)로 요청을 전달하면 3개의 파드가 돌아가면서 응답을 제공하는 것을 확인할 수 있다.

8. 리소스 정리

- kOps 명령어를 이용해 생성한 쿠버네티스 클러스터는 kOps 명령어를 이요해 일괄적으로 사용할 수 있다.

> kops delete cluster $NAME --yes

- 버킷 삭제

- Management Console의 EC2에서 인스턴스 등의 삭제 확인

AWS Cloudformation

: AWS 리소스를 모델링하고 설정하여 서비스 관리 시간을 줄이고 AWS에서 실행되는 앱에 더 많은 시간을 사용할 수 있도록 돕는 서비스이다. (=앱 개발에 집중 할 수 있게 지원)

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/Welcome.html

1. AWS Cloudformation 작동 방식

1) YAML 또는 JSON 포맷으로 Cloudformation 탬플릿을 작성하거나, 샘플 탬플릿을 사용하여 인프라를 코드로 작성한다.

2) 로컬의 템플릿 코드를 체크아웃 하거나, S3 버킷에 템플릿을 업로드한다.

3) AWS 콘솔, CLI 또는 API를 통해 AWS Cloudformation을 사용하여 템플릿 코드를 기반으로 스택(stack)을 생성한다.

4) 템플릿에 지정된 스택(stack)을 통해 AWS 리소스에 대한 프로비저닝 및 구성 작업을 쉽게 수행할 수 있다.

(stack 생성에 실패하면, AWS Cloudformation에서는 생성한 리소스를 삭제하여 변경 사항을 롤백한다.

2. AWS Cloudformation 구성 요소

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html

- AWS Cloudformation을 사용하는 경우에는 템플릿 및 스택으로 작업한다.

템플릿을 생성하여 AWS 리소스와 해당 속성에 대해 설명하고,

스택을 생성할 때마다 Cloudformation에서 템플릿에 설명된 리소스를 프로비저닝한다.

- 탬플릿

> JSON 또는 YAML 형식의 텍스트 파일

> 스택에서 프로비저닝할 리소스를 설명

> Cloudformation Designer 또는 텍스트 편집기를 사용해 생성 가능하다.

> 템플릿의 구조 :

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/template-anatomy.html 참조

- 스택

> 하나의 단위로 관리할 수 있는 AWS 리소스 모음

> 스택의 생성, 수정, 삭제를 통해 리소스 모음의 생성, 수정, 삭제 가능

> 스택의 모든 리소스는 Cloudformation 템플릿을 통해 정의된다.

> 스택을 삭제하면 관련 리소스가 모두 삭제된다.

- 변경 세트

AWS Cloudformation을 활용한 네트워크 생성

1. 템플릿 생성

- CreateVPC_01.yaml 파일 작성

AWSTemplateFormatVersion: "2010-09-09"

Description: Make a VPC

Resources:

MyVPC:

Type: AWS::EC2::VPC

Properties:

CidrBlock: 10.0.0.0/16

EnableDnsHostnames: true

MyIGW:

Type: AWS::EC2::InternetGateway

MyVPCGatewayAttachment:

Type: AWS::EC2::VPCGatewayAttachment

Properties:

InternetGatewayId: !Ref MyIGW

# VpcId: !Ref MyVPC

VpcId:

Ref: MyVPC

MyPublicSubnetA:

Type: AWS::EC2::Subnet

Properties:

VpcId: !Ref MyVPC

CidrBlock: 10.0.10.0/24

AvailabilityZone: !Select <= 다음 코드의 내용을 가져오는 명령어

- '0' <= 그 알파벳 순서에서 0번째(=1번)을 가져온다.

- !GetAZs '' <= 가용영역의 순서가 알파벳 순서로 정렬되는데,

MyPrivateSubnetA:

Type: AWS::EC2::Subnet

Properties:

VpcId: !Ref MyVPC

CidrBlock: 10.0.20.0/24

AvailabilityZone: !Select

- '0'

- !GetAZs ''

MyPublicRT:

Type: AWS::EC2::RouteTable

Properties:

VpcId: !Ref MyVPC

MyPublicRoute:

Type: AWS::EC2::Route

Properties:

DestinationCidrBlock: 0.0.0.0/0

GatewayId: !Ref MyIGW

RouteTableId: !Ref MyPublicRT

MyPublicSubnetRTAssociationA:

Type: AWS::EC2::SubnetRouteTableAssociation

Properties:

SubnetId: !Ref MyPublicSubnetA

RouteTableId: !Ref MyPublicRT

MyPrivateRT:

Type: AWS::EC2::RouteTable

Properties:

VpcId: !Ref MyVPC

MyPrivateSubnetRTAssociationA:

Type: AWS::EC2::SubnetRouteTableAssociation

Properties:

SubnetId: !Ref MyPrivateSubnetA

RouteTableId: !Ref MyPrivateRT

Outputs:

VPC:

Description: MyVPC's VPC ID

Value: !Ref MyVPC

AZa:

Description: Availability Zone a

Value: !GetAtt

- MyPublicSubnetA

- AvailabilityZone

- 내장함수

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html

> 기본적으로 service-provider::service-name::data-type-name 의 형식을 가진다.

- 리소스 및 속성 유형

https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html

2. 스택 생성

- 출력 확인 : 템플릿에서 outputs 항목에 정의한 내용이 출력되는지 확인

- 리소스 생성 확인

1) VPC 생성 확인

: IPv4 CIDR, DNS 호스트 이름 항목이 템플릿에서 정의한 것과 일치하는지 확인

2) 인터넷 게이트웨이 생성 확인

: VPC와 연결되어 있는지 확인

3) 서브넷 생성 확인

: VPC, IPv4 CIDR, 가용영역, 라우팅 테이블 확인

4) 퍼블릭 라우팅 테이블 확인

: 인터넷 게이트웨이로의 라우팅이 포함되어 있는지 확인

5) 프라이빗 라우팅 테이블 확인

: local 라우팅만 포함되어 있는지 확인

3. 리소스 정리

=> 스택 삭제 (why? 스택으로 생성된 리소스는 스택을 삭제 시 관련된 리소스가 자동으로 삭제된다.)

=> 단, 버킷은 별도로 삭제 (why? 버킷에는 템플릿이 저장되어 있어 버킷 내부 객체부터 삭제)

context?ㄷ

클라우드_5일차_241010

지찬씌 — Mon, 14 Oct 2024 10:28:42 +0900

S3(SSS, Simple Stroage Service)

- 무제한 저장 용량을 제공하는 스토리지 서비스

최소 3개의 가용영역(AZ)에 데이터를 자동 분산 저장하기 때문에 성능, 확장성, 가용성, 내구성이 높다.

=> 가용성을 최대화 하기 위함

- 사용사례

1) 백업 및 복원

2) 재해 복구 (DR = 백업보다 상위 개념)

3) 아카이브

4) 클라우드 스토리지

5) 정적 웹 호스팅

- 버킷(Bucket)

> 객체 저장 공간 = 디렉터리

> 리전 단위로 생성

> 버킷의 이름은 유일해야 한다. (다른 AWS 사용자와도 겹치지 않아야함)

- 객체(Object)

> 저장되는 파일을 의미

> 개별 파일 업로드 사이즈는 최대 5TB까지 가능

S3 버전 관리

- 객체(파일)이 여러 버전을 가질 수 있다.

- 동일한 파일 이름을 업로드하면 여러 버전으로 저장할 수 있다.

(= 객체를 하나의 파일이 아닌 여러 버전으로 보존할 수 있다.)

- 실수로 객체를 덮어쓰거나 삭제한 경우, 이전 버전으로 복구가 가능하다.

- 실수로 객체를 삭제하는 것을 방지하기 위해 중요한 파일의 경우에는 MFA Delete 옵션을 추가할 수 있다.

=> Multi-Factor Authentication (다중인증)

- 버전 관리 기능을 사용하려면 해당 기능을 활성화해야 한다.

=> 기본적으로 버전 관리 기능은 비활성화되어 있다.

S3 객체 암호화

- 데이터를 전송 중에, 스토리지에 저장된 동안 보호하기 위한 암호화 서비스도 지원

- S3 객체의 암호화 유형 (SSE = Server Side Encryption)

1) SSE-S3

=> S3에서 관리하는 암호화

2) SSE-KMS

=> KMS(키 관리 서버, Key Management Server)에서 관리하는 암호화

3) SSE-C

=> 고객(사용자, Client)가 관리하는 암호화

4) 클라이언트측 암호화

S3 정적 웹 사이트 호스팅

- 정적 웹 사이트

=> 내용을 변경하지 않는 이상 항상 같은 내용이 제공되는 사이트

(ex: HTML로 구성된 회사소개 페이지)

- 동적 웹 사이트

=> 사용자 또는 환경에 따라서 다른 내용이 만들어져 제공되는 사이트

(ex: 게시판 페이지)

- S3에서 웹 사이트 호스팅을 하면 EC2 등의 별도의 웹 서버를 운영하지 않고 정적 웹 서비스를 제공할 수 있다.

- 웹 사이트 주소는 버킷이름.s3-website-리전.amazonaws.com 형식으로 생성된다.

- 정적 웹 호스팅을 이용해서 웹 서비스를 제공하면 해당 버킷의 퍼블릭 엑세스를 허용해야 한다.

S3 스토리지 클래스

https://aws.amazon.com/ko/s3/storage-classes/?nc=sn&loc=3

- 액세스 빈도, 데이터의 중요도에 따라 비용 및 성능이 다른 스토리지 클래스를 구분한다.

1. S3 Standard (범용)

- 일반적인 용도의 다양한 사용 사례에 적합하다.

- 짧은 지연 시간과 많은 처리량을 제공

2. S3 Intelligent-Tiering

: 엑세스 패턴을 알 수 없거나 예측할 수 없는 데이터 용으로 사용된다.

- 빈번한 엑세스에 최적화되어 있는 계층과 저렴한 비용 및 빈번하지 않은 엑세스에 최적화된 계층 두 개로 작동한다.

- 가장 비용 효과적인 엑세스 계층으로 데이터를 자동으로 이동해서 비용을 최적화하기 위한 설계이다.

3. S3 Standard-IA(Infrequent Access)

: 빈번하지 않은 엑세스 용

- 자주 엑세스하지 않지만 필요할 때 빠르게 엑세스 해야하는 데이터에 적합

4. S3 OneZone-IA

: 빈번하지 않은 엑세스용

- 자주 엑세스하지 않지만 필요할 때 빠르게 엑세스 해야하는 데이터에 적합

- 다른 스토리지 클래스와 다르게 단일 가용영역(AZ)에 데이터를 저장하지만, S3 Standard_IA 보다 20% 저렴하다.

=> 가용성 및 복원성이 매우 낮다.

5. S3 Glacier

: 아카이브 용

- Glacier 클래스는 접근에 빠른 속도가 필요없는 데이터를 관리하는 클래스이다.

- 검색 시간이 몇 분 부터 몇 시간까지 다양하게 구성된다.

6. S3 Deep Glacier Archive

: 아카이브 용

- 가장 저렴한 비용의 스토리지 클래스이고 검색 시간은 12시간 이내이다.

- 세금계산서와 같이 의무적으로 장기간(7~10년) 보관기한 정해져 있는 데이터 관리에 사용하는 클래스이다.

객체 수명주기 관리 (Liffecycle Policy)

: 객체가 저장되고 삭제될때 까지의 수명주기를 비용 효율적으로 관리하는 기능

- 예시

30일 경과 60일 경과 365일 경과

S3 Standard —---------> S3 Standard-IA —---------> Glacier —-----------> 삭제

이벤트 알림

: S3에 이벤트가 발생할 때마다 알리는 기능

- 이벤트에는 객체를 생성 / 복제 / 복원 등이 존재.

- 생성된 이벤트 알림을 SNS / SQS / Lambda 등으로 보낼 수 있다.

- 예시

객체(파일)가 삭제될 때마다 S3에서 SNS로 이벤트 알림을 사용자에게 이메일로 발송

전송 가속화 (Amazon S3 Transfer Acceleration)

: S3 버킷의 객체(파일)을 사용자에게 더 빠르게 전송해주는 기능

- AWS의 엣지 로케이션을 활용해 S3 데이터를 사용자와 가까운 곳에 캐싱해서 전송

객체 잠금

: 일정시간 또는 무기한으로 객체가 삭제되거나 덮어쓰이지 않도록 하는 기능

- Object Lock / Glacier Vault Lock 두 가지 종류의 잠금이 있다.

- 법적인 보존 기간이 존재하는 객체의 경우 사용한다. (= 객체의 변경이 있을 경우 문제가 발생하기 때문에)

요청자 지불 버킷

: 데이터 전송 비용을 버킷 소유자가 아닌 요청자에게 지불하게 하는 기능

=> 데이터를 다운로드 및 업로드하는 사용자

- 일반적으로 버킷(=디렉터리)에 데이터를 다운로드하거나 업로드할 때의 비용은 버킷 소유자가 지불한다.

S3 버킷 사용 실습

1. 버킷 생성 및 객체 업로드 및 생성된 URL 주소로 이미지 확인

2. 버킷에 퍼블릭 접근 권한을 부여

- 기본적으로 버킷에는 퍼블릭 접근에 대한 권한이 차단되어 있다. (퍼블릭 엑세스 차단 활성화로 표시)

- 하지만 URL을 통한 이미지 조회 여전히 불가능하다.

=> 버킷에 대한 접근 권한은 활성화했지만, 객체(강아지 사진)에 대한 접근 권한은 없기 때문

=> 객체에 대한 퍼블릭 엑세스를 설정해야한다.

3. 정적 웹 호스팅 설정

- 정적 웹 호스팅은 기본적으로 비활성화 되어있다.

4. 정적 웹 사이트 호스팅 기능을 이용해서 리액트 앱을 배포

5. 버전 관리

6. 리소스 삭제

AWS Lambda

https://aws.amazon.com/ko/lambda/

- 함수를 생성하며 작성한 소스코드를 실행하여 컨테이너를 실행한다.

1. Node 런타임을 사용하는 람다 함수 생성

2. 파이썬 런타임을 사용하는 람다 함수 생성

3. 이미지 썸네일을 자동으로 생성하는 람다 함수 생성

- 함수 생성

> 이름 : MakeThumbnailimage

> 런타임 : Python 3.12

- 함수 테스트

- 소스코드 작성

: S3-put object 이벤트가 발생했을 때 동작하는 코드

# Python 용 AWS SDK

# https://aws.amazon.com/ko/sdk-for-python/

import boto3

import os

import sys

import uuid

# from urllib.parse import unquote_plus

# https://pypi.org/project/Pillow/

from PIL import Image

import PIL.Image

# https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3.html

s3_client = boto3.client('s3')

# image_path의 1/2 크기의 이미지를 만들어서 resized_path에 저장

def resize_image(image_path, resized_path):

with Image.open(image_path) as image:

image.thumbnail(tuple(n/2 for n in image.size))

image.save(resized_path)

# 람다 핸들러 함수

def lambda_handler(event, context):

for record in event['Records']:

bucket = record['s3']['bucket']['name'] # example-bucket

key = record['s3']['object']['key'] # test%2Fkey <= test/key 값을 URL 인코딩한 값

tmpkey = key.replace('/', '') # path/file 형식을 pathfile 형식으로 변경

# S3 버킷으로부터 파일을 가져와서 저장할 경로와 (S3 버킷으로 전달할) 썸네일 이미지를 저장할 경로를 지정

download_path = '/tmp/{}{}'.format(uuid.uuid1(), tmpkey) # /tmp/uuidpathfile

upload_path = '/tmp/resized-{}'.format(tmpkey) # /tmp/resized-pathfile

# S3 버킷으로부터 파일을 다운로드

# https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/download_file.html

s3_client.download_file(bucket, key, download_path)

# 다운로드한 파일의 크기를 반으로 축소 = 썸네일 생성

resize_image(download_path, upload_path)

# 썸네일 이미지를 S3 버킷에 업로드

# 다운로드버킷이름-resized 이름의 버킷에 원본 파일명과 동일한 파일명으로 업로드

# https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/upload_file.html

s3_client.upload_file(upload_path, '{}-resized'.format(bucket), key)

=> 위 코드를 람다 함수의 소스 코드 작성 부분에 입력하고 test했을 때,

import module error가 발생한다.

=> PIL 모듈이 없기 때문에 발생하는 문제인데, 런타임을 설정할 때 기본 라이브러리와

AWS SDK(ex: boto3)를 제외한 모든 외부 라이브러리는 직접 추가해야 한다.

- 람다 실행환경과 동일한 환경에서 PIL 모듈을 빌드한 후 람다 레이어(계층)로 등록

https://pillow.readthedocs.io/en/stable/installation.html

1) 람다 런타임 확인

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

2) 람다 런타임의 운영체제와 동일한 운영체제를 사용하는 EC2 인스턴스를 생성

3) SSH 클라이언트를 이용해 EC2 인스턴스로 접속

4) PIL 모듈을 빌드

5) IAM에서 사용자를 추가

=> pillow 모듈을 S3 버킷으로 프로그램 방식으로 복사하기 위해 필요

6) EC2 인스턴스에서 S3 버킷으로 파일을 업로드하기 위해 엑세스 키 등록 및 S3 버킷 생성

7) PIL 라이브러리를 S3 버킷에 복사(=업로드)

8) 업로드한 객체의 URL 확인 및 업로드한 라이브러리를 람다 계층으로 등록

클라우드_3일차_241007

지찬씌 — Fri, 11 Oct 2024 09:11:27 +0900

웹 서비스 환경 구성

1. 루트 사용자로 로그인 후 IAM 사용자 생성

2. 새로 생성한 admin 계정으로 로그인 후 네크워크 생성(=VPC 생성)

=> 현재까지 완료한 내용.

이처럼 VPC 생성 마법사를 통해 VPC 내부 서브넷, igw, 라우팅을 설정하는 방법도 알아야 하지만,

저번처럼 직접 설정하는 방법 또한 아는 것이 중요.

3. 보안그룹 생성 - HTTP(80), SSH(22) port 에서의 접근을 허용하도록 생성

4. 웹 인스턴스 생성

- 사용자 데이터에 아래 내용 입력

=> 사용자 데이터 : 인스턴스 최초 생성 시에 실행하는 프로그램. 초기 설정에 대한 내용이 들어간다.

#!/bin/sh

amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2 <= lamp == linux aphchi mysqlmariadb php
yum -y install httpd php-mbstring

# Start the web server
chkconfig httpd on
systemctl start httpd

# Install the web pages for our lab
if [ ! -f /var/www/html/immersion-day-app-php7.tar.gz ]; then
cd /var/www/html
wget https://aws-joozero.s3.ap-northeast-2.amazonaws.com/immersion-day-app-php7.tar.gz
=> 경로에 저장된 php파일 다운.
tar xvfz immersion-day-app-php7.tar.gz
=> tar 명령어로 압축 해제
fi

cat <<EOF > /var/www/html/get-index-meta-data.php
<?php
  \$hostname = gethostname();
  \$results = explode(".", \$hostname);
  echo "<table style='width:100%'>";
  echo "<tr><th style='width:30%'>Meta-Data</th><th style='width:70%'>Value</th></tr>";
  echo "<tr><td>Private IP DNS Name</td><td>".\$hostname."</td></tr>";
  echo "<tr><td>Private IP</td><td>".getHostByName(\$hostname)."</td></tr>";
  echo "<tr><td>Region</td><td>".\$results[1]."</td></tr>";
  echo "</table>";
?>
EOF
=> 압축 해제된 내용에 대해 덮어쓰기 하는 코드

# Install the AWS SDK for PHP
if [ ! -f /var/www/html/aws.zip ]; then
cd /var/www/html
mkdir vendor
cd vendor
wget https://docs.aws.amazon.com/aws-sdk-php/v3/download/aws.zip
unzip aws.zip
fi

# Update existing packages
yum -y update

- 인스턴스의 퍼블릭 IPv4 주소로 접속이 가능함을 확인.

5. 인스턴스로 SSH 접속

- 과정

SSH 클라이언트 실행 -> 키 페어 등록 -> 인스턴스의 public IP / 22포트로 접속

- 기본 사용자 이름

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/managing-users.html

6. (웹 서버 설정이 모두 끝난 상태에서) AMI 생성

=> 생성한 webserver-ami 이미지를 이용해서 웹 서버 인스턴스를 public-subnet-c 서브넷에 추가로 생성하면...

사용자 데이터 항목에 입력했던 스크립트(프로그램 설치 및 설정)를 생략할 수 있다!

7. 로드밸런서 구성

- 동일한 기능(내용)을 제공하는 인스턴스가 현재 2개 실행되고 있다.

그러나 개별 인스턴스 주소로 접속하는 경우, 이용의 불편과 부하 집중되는 문제가 발생할 수 있다.

=> 이는 로드밸런서를 이용해서 서비스 되도록 수정하면, 부하 분산과 서비스 편의를 제공할 수 있다.

- 애플리케이션 로드밸런서 생성

- 보안 그룹 신규 생성

- 대상 그룹(target group) 생성 후 로드밸런서 생성

- 로드 밸런서가 활성화되면 로드 밸런서의 DNS 주소로 접근 (두개의 인스턴스가 교대로 응답하는 것을 확인)

8. 로드 밸런서를 통해서만 서비스를 이용할 수 있도록 제한

- 현재 사용자가 로드 밸런서를 이용하지 않고 개별 인스턴스로 직접 접근이 가능하다.

=> 모든 요청을 로드 밸런서를 통해서만 처리하도록 제한하기 위해서는....

개별 인스턴스에 로드 밸런서로부터 오는 HTTP(80)만 허용하도록 수정한다.

이 말은 보안 그룹(webserver-sg)를 수정해야 한다는 것이다.

9. 모니터링 기능을 추가

- Amazon CloudWatch

https://aws.amazon.com/ko/cloudwatch/

- Amazon SNS (Simple Notification Service)

https://docs.aws.amazon.com/ko_kr/sns/latest/dg/welcome.html

- SNS 콘솔에서 topic(주제)을 설정하고 구독, 구독자에게 메세지 발송

- webserver 인스턴스에 경보를 설정

- 브라우저를 통해 로드밸런스 주소로 접속한 후 LOAD TEST 를 클릭.

=> CPU사용률이 증가하는지 확인하고, 경보 이메일이 오는지 확인

10. 오토 스케일링(Auto Scailing)

- 앱의 부하(load)를 처리할 수 있도록 EC2 인스턴스를 자동으로 증가 또는 감소시켜주는 서비스

- 시작 템플릿 생성

- 대상 그룹(target group)에 등록된 대상을 제거

=> 로드밸런서의 대상 그룹을 오토 스케일링으로 자동으로 생성되는 인스턴스를 사용할 것이기 때문에

로드밸런서의 대상 그룹을 지정할 필요는 없다.

- Auto Scailing 그룹 생성

- 브라우저로 로드밸런스 주소로 접근하여 LOAD TEST 클릭

11. 리소스 정리 (순서 중요!!!!!)

- Auto Scailing 그룹 용량을 0으로 조정

- Auto Scailing 그룹 삭제

- 시작 템플릿 삭제

- 로드밸런서 삭제

- 대상 그룹 삭제

- 인스턴스 종료

- (AMI) 이미지 삭제

- AMI와 연결된 스냅샷 삭제

- 키페어, 보안그룹 삭제

- VPC 삭제

- SNS 구독 삭제

- SNS 주제 삭제

- 경보 삭제

- 사용자(admin) 계정 삭제

클라우드_2일차_241002

지찬씌 — Thu, 10 Oct 2024 09:14:08 +0900

(241002 작성 내용에서 계속....)

3. 사용자 그룹에 정책을 추가

4) EC2 인스턴스 생성 (AWS 안에 가상머신 생성)

4-1) 리전을 서울 리전으로 변경

4-2) 인스턴스 시작을 눌러 인스턴스 생성

5) S3 버킷 생성 후 크기가 작은 파일 업로드

- 버킷 : 파일 저장소. 버킷의 이름에는 중복이 없어야 한다. 중복이 있을 경우 저장 과정에서 충돌이 발생할 수 있음.

6) user1 사용자로 로그인(다른 브라우저 사용) 후 S3와 EC2 서비스로 접근

6-1) root 계정으로 user1의 콘솔 로그인 링크를 확인

6-2) 다른 브라우저에서 user1 계정으로 로그인하고 S3에 접속

- 버킷 목록 조회(List*), 객체 목록 조회(Describe*), 객체 상세 목록 조회(Describe*)이 가능하다.

> user1 계정에 대하여 S3readonlyaccess 정책을 적용했기 때문에 가능하다.

6-3) 버킷에 파일(객체) 업로드

- user1에 대한 계정은 S3readonlyaccess 정책만 적용했기 때문에 파일(객체) 업로드(Put*)는 불가능하다.

6-4) AmazonS3ReadOnlyAccess

https://docs.aws.amazon.com/ko_kr/aws-managed-policy/latest/reference/AmazonS3ReadOnlyAccess.html

- user1 사용자는 S3-Support 그룹에 포함되어 있고, S3-Support 그룹은 AmazonS3ReadOnlyAccess 권한을 가지고 있으므로, 버킷 목록을 조회(List*)할 수 있고, 버킷에 저장된 파일(객체) 목록(list*)과 상세 정보를 조회(Describe*)할 수 있고, 버킷에 저장된 객체를 다운로드(Get*)할 수도 있으나, 객체를 추가(Put*)하는 것은 불가능하다.

7) user1 사용자로 EC2 서비스에 접근

- EC2에 대한 권한이 없으므로 정보가 출력되지 않는다.

8) user2 사용자로 로그인

8-1) S3 서비스로 접근

- user2 사용자는 S3 서비스에 대해 아무런 권한이 없기 때문에 버킷 목록을 볼 수 없고, 모든 버튼이 비활성화 상태이다.

8-2) EC2 서비스로 접근하여 EC2 인스턴스를 조회 및 인스턴스 중지

- 인스턴스 조회에는 문제가 없다.

- readonlyaccess 권한이기 때문에 인스턴스 중지에 실패한다.

8-3) AmazonEC2ReadOnlyAccess

https://docs.aws.amazon.com/ko_kr/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html

- user2 사용자는 EC2-Support 그룹에 속해 있고, EC2-Support 그룹은 AmazonEC2ReadOnlyAccess 권한을 가지고 있으므로, 인스턴스 목록과 상세 정보는 조회는 가능하나, 인스턴스 중지, 시작, 재부팅은 불가능하다.

9) user3로 로그인

9-1) S3 서비스와 EC2 서비스에 접근

- EC2PullAccess 권한을 가지고 있기 때문에 S3 서비스에는 접근이 불가능하고 EC2 서비스에는 접근이 가능하다.

- 위와 같이 인스턴스 조회(Describe*) 항목만 출력되는 이유는 그룹 정책 적용 시 인라인 정책에서 경계 권한으로 ec2describe 사항을 넣어줬기 때문이다.

- 동일한 이유로 인스턴스 중지(Stop*)와 시작(Start*) 권한이 적용되어 있기 때문에 가능하다.

10) user3 사용자를 S3-Support 그룹에 추가한 후 S3 서비스로 이동

10-1) root 계정으로 user3 사용자를 S3-Support 그룹에 추가

10-2) user3 사용자로 S3 서비스에 접근

- 버킷 목록/상세 조회, 개체 목록/상세 조회 및 다운로드가 가능하다.

11) user1 사용자에게 EC2 인스턴스 읽기 전용 권한 부여 (인라인 정책으로 부여)

11-1) user1 계정으로 로그인 후 EC2 서비스 접근

12) 모든 리소스 삭제

12-1) S3에서는 객체(파일)을 모두 삭제한 후 버킷을 삭제한다.

12-2) EC2 인스턴스 종료

12-3) 사용자, 사용자 그룹 삭제

Access Key를 이용한 AWS 서비스 이용

* AWS 서비스를 이용하는 방법

1) Management Console

- 사람 사용자가 로그인 후 사용

2) AWS CLI

- 사람 또는 프로그램이 Access Key를 이용해서 사용

3) 각 개발 언어별 SDK(Source Development Kit)

- 응용 프로그램을 이용하여 사용

1. AWS CLI 설치

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html

- 설치가 완료되면 명령 프롬프트를 이용해서 설치 확인

C:\Users\crpark> aws --version

aws-cli/2.17.63 Python/3.12.6 Windows/11 exe/AMD64

C:\Users\crpark> aws iam list-users

Unable to locate credentials. You can configure credentials by running "aws configure".

2. 사용자 생성 후 Access Key를 발급

2-1) Access Key를 등록

2-2) 사용자 목록을 조회

3. S3 버킷 목록 조회

https://docs.aws.amazon.com/cli/latest/reference/s3/

https://docs.aws.amazon.com/cli/latest/reference/s3api/list-buckets.html

> aws s3api list-buckets

3-1) S3 버킷 생성 후 조회

- CLI를 이용한 버킷 생성

> aws s3api create-bucket --bucket mybucket-inno-6 --create-bucket-configuration LocationConstraint=ap-northeast-2

- 버킷 조회

> aws s3api list-buckets

LAB

AWS CLI를 이용해서 생성한 S3 버킷에 AWS CLI를 이용하여

(1) (작은 크기의) 파일을 업로드한 후

(2) 업로드한 파일을 확인하고

(3) 모든 작업이 끝나면 생성한 S3 버킷을 삭제한다.

(1) 버킷에 객체 등록 (put-object)

(2) 버킷에 객체가 등록되었는지 확인 => 객체 목록 조회 (list-objects)

(3) S3 버킷 삭제 => 객체 먼저 삭제 후 버킷 삭제

VPC (Virtual Private Cloud)

- AWS 사용자 계정 전용 가상 네트워크

- AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리

- 하나의 AWS 리전 안에서만 존재할 수 있고, A 리전에 만든 VPC는 B 리전에서는 보이지 않는다. => VPC peering

- 생성 시 RFC 1918에 지정된 프라이빗 주소 체계 사용을 권장한다.

VPC 구성 옵션

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/create-vpc-options.html

1. 기본 VPC (default VPC)

- 기본 VPC 구성 요소

2. 서브넷(subnet)

- VPC 내 논리적 구분

- 하나의 가용영역 내에서만 존재할 수 있다.

- 종류

1) 퍼블릿 서브넷

2) 프라이빗 서브넷

3. 탄력적 네트워크 인터페이스 (ENI, Elastic Network Interface, )

- 물리 서버의 네트워크 인터페이스와 같은 기능 수행

- VPC에서 가상 네트워크 카드를 제공하는 논리적 네트워크 구성 요소

4. 인터넷 게이트웨이 (igw, Internet GateWay)

- 퍼블릭 IP(나를 찾을 수 있는 주소) 주소를 갖는 인스턴스가 인터넷에 연결할 수 있도록 기능을 제공한다.

- 처음 VPC를 만들면 igw와 연결되지 않으므로, 직접 igw와 VPC를 연결해야 한다.

- 하나의 VPC는 하나의 igw만 연결할 수 있다. => 나가는 관문은 하나뿐

5. 라우팅 (routing)

- VPC의 네트워크 트래픽을 전달할 위치를 결정하는데 사용되는 규칙이다.

- 트래픽을 전달할 IP 주소 범위(대상 주소)와 트래픽을 전송할 게이트웨이, 네트워크 인터페이스 또는 연결(대상)을 지정

- VPC는 소프트웨어 함수로 IP 라우팅을 구현하고, 사용자는 라우팅 테이블만 관리하면 된다.

- 라우팅 테이블 == 라우팅의 집합으로, 서브넷과 연결할 수 있다.

- 기본 라우팅 테이블 = 기본 VPC와 함께 자동으로 제공되는 라우팅 테이블

> 기본 VPC인 경우, local 및 igw로의 라우팅을 포함한다.

> 기본 VPC가 아닌 경우, local 라우팅만을 포함한다.

- 예시 1.

----------- ---------------------

대상 주소(Destination) 대상(Target)

----------- ---------------------

172.31.0.0/16 local

0.0.0.0/0 igw-0b7313723843100f9

~~~~~~~ ~~~~~~~~~~~~~~~~~~~

인터넷 상의 모든 인터넷 게이트웨이

호스트 IP 기반

=> if, 172.31.10.10 으로 패킷을 보내려고 하면, local로 라우팅을 처리한다.

=> if, 198.51.100.50 으로 패킷을 보내려고 하면, 라우팅할 위치와 가장 근접하게 일치하는 항목을 기반으로 라우팅을 처리한다. >>> igw로 라우팅된다.

=> 결론적으로, 라우팅 테이블 항목 간의 순서는 중요하지 않다.

- 예시 2.

6. 보안 그룹 (SG, Security Group)

- 인스턴스의 ENI에서 송수신하는 트래픽을 제어한다.

- 모든 ENI는 최소 한개 이상의 보안 그룹과 연결되어야 하고, 보안 그룹은 또한 여러 ENI와 연결 될 수 있다. (= N:N 관계)

- 생성할 때 그룹 이름 / 설명 / 포함될 VPC를 지정하고, 생성 후에 인바운드/아웃바운드 규칙을 지정한다.

=> 트래픽을 허용한다는 말

- 상태 저장 방화벽 역할을 수행 => 보안 그룹이 트래픽을 한 방향으로 전달하도록 허용할 때 반대 방향의 응답 트래픽을 지능적으로 허용하는 것

7. 네트워크 접근 제한 목록 (NACL, Network Access Contorl List)

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html#default-network-acl

- 보안 그룹과 유사하다.

> VPC에서는 삭제할 수 없는 기본 NACL이 있다.

- 서브넷에 연결되어 해당 서브넷과 송수신되는 트래픽을 제어한다.

=> NACL >>>> ENI

- 상태 비저장을 띈다

> NACL을 통과한 연결 상태를 추척하지 않는다.

> 모든 인바운드/아웃바운드 트래픽의 허용 규칙을 별도로 작성해야 한다.

- NACL의 경우 규칙을 적용할 때 규칙 번호의 오름차순으로 처리하고, 만족하는 규칙이 있을 경우 해당 규칙을 제외한 나머지는 무시한다.

=> 순서에 영향을 받음!

- 보안 그룹 VS NACL

항목	보안 그룹	네트워크 ACL
운영 레벨	인스턴스	서브넷
적용범위	인스턴스와 연결된 경우에만 인스턴스에 적용	연결된 서브넷에 배포된 모든 인스턴스에 적용 (보안 그룹 규칙이 지나치게 허용적일 경우 추가 보안 계층을 제공)
규칙 지원	허용 규칙만 지원	허용 및 거부 규칙 지원
트래픽 허용 규칙 순서 종속성	트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가
상태 저장

VPC 생성 -> EC2 인스턴스 생성(웹 서버 설치) -> 인스턴스로 22, 80 포트 접근

1. VPC 생성

2. 인터넷 게이트웨이 생성

- VPC를 인터넷에 연결하기 위해 생성

3. 서브넷 생성

4. 라우팅 테이블 생성하고 서브넷에 연결

5. 라우팅 테이블에 인터넷 게이트웨이로의 라우팅을 추가

=> 퍼블릭 라우팅 테이블로 변경

6. NACL 확인

7. SSH Client 프로그램(Bitvise)을 이용하여 EC2 인스턴스로 접속

8. 내 PC에서 EC2 인스턴스의 80포트로 요청

=> 연결되지 않음

=> NACL에서는 모든 포트 접근을 허용하고 있으나 보안그룹에서 80포트 접근을 허용하고 있지 않음.

=> 따라서 보안그룹에서 80포트로 들어오는 요청을 허용하는 규칙을 생성

9. NACL에 80 포트로 들어오는 트래픽을 거부하는 규칙을 10번으로 추가

=> 이 경우 NACL에서 80포트로 들어오는 요청이 거부되어 인스턴스에 접근이 불가하게 된다.

10. NACL에 80포트로 들어오는 트래픽을 허가하는 규칙을 20번으로 추가

=> 이 또한 접근이 불가하다.

=> 오름차순으로 규칙을 적용하므로 10번에서 접근을 거부하였기 떄문에 20번 규칙은 적용되지 않는다.

11. NACL에 80 포트로 들어오는 트래픽을 허가하는 규칙을 5번으로 추가

=> 인바운드/아웃바운드 규칙이 오름차순으로 적용되므로 5번이 가장 먼저 적용되기 때문에 다음 순번의 규칙은 무시된다.

12. 리소스 정리 (중요!)

1) EC2 종료

Amazon EC2 (Elastic Compute Cloud)

https://aws.amazon.com/ko/pm/ec2/

- 안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스

- 안정적인 확장 가능한 인프라에 온디맨드로 엑세스한다.

- 99.99%의 가용성을 지원하는 서비스 수준 계약 (SLA, Service Level Agreement)이다.

AMI (Amazon Machine Image)

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/AMIs.html

인스턴스 유형

https://aws.amazon.com/ko/ec2/instance-types

- 명명 규칙

https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html

행복한 지찬씌

이노그리드 특강_CI/CD_241023

싱글 클러스터 컨테이너 플랫폼 포털 배포

컨테이너 플랫폼 파이프라인 설치 (포털 배포 우선되어야 함.)

Source Controler 설치 (포털 배포 우선되어야 함.)

실습. 간단한 CI/CD 파이프라인 작업 (Spring-music App 구성 배포)

Yaml을 활용한 리소스 배포

Kubernetes CLI를 활용한 리소스 배포

클라우드_7일차_241014

EKS (Elastic Kubernetes Service)

EKS를 이용한 클러스터 구성

클라우드_6일차_241011

VPC 생성

관리형 관계형 데이터베이스 서비스 생성 (RDS, Relational Database Service)

FastAPI 앱을 EC2에 배포

람다 함수 작성

API Gateway 설정

AWS 특강_241028

DevOps/Scrum 특강_241024~241025

DevOps

Development LifeCycle : Agile Development Theory : Scrum Method

이노그리드 CI/CD 특강_241022

클라우드_4일차_241008

AWS CLI 를 이용한 VPC, EC2 생성

* 프라이빗 서브넷 생성

AWS 환경에서 LoadBalancer 타입의 서비스를 연동

AWS Cloudformation

AWS Cloudformation을 활용한 네트워크 생성

클라우드_5일차_241010

S3(SSS, Simple Stroage Service)

S3 버전 관리

S3 객체 암호화

S3 정적 웹 사이트 호스팅

S3 스토리지 클래스

객체 수명주기 관리 (Liffecycle Policy)

이벤트 알림

전송 가속화 (Amazon S3 Transfer Acceleration)

객체 잠금

요청자 지불 버킷

S3 버킷 사용 실습

AWS Lambda

클라우드_3일차_241007

웹 서비스 환경 구성

클라우드_2일차_241002

Access Key를 이용한 AWS 서비스 이용

VPC (Virtual Private Cloud)

VPC 생성 -> EC2 인스턴스 생성(웹 서버 설치) -> 인스턴스로 22, 80 포트 접근

Amazon EC2 (Elastic Compute Cloud)

AMI (Amazon Machine Image)

인스턴스 유형

EBS (Elastic Block Store) = 하드디스크

EBS 스냅샷

탄력적 주소 (EIP, Elastic IP)