[AWS] S3 호스팅에 도메인 연결하기

S3에서 정적 웹호스팅을 할 수 있다는 이야기는 들어 보았지만, 아직까지 해 볼 경험이 없었는데
지인 덕분에 간만에 재밌는걸 해봐서 잊지 않으려고 기록합니다.

이미 많은 포스팅들도 있고, 공식 가이드 문서도 충분히 잘 정리 되어 있으니 참고 하시기 바랍니다.

도메인은 이미 구매하였다는 가정하에 진행합니다.
이 포스팅에서 사용할 도메인은 [travelerapp.kr](http://travelerapp.kr) 입니다.(곧 만료 예정)

S3 설정하기


  1. 우선 별 다른 설정없이 s3 버킷을 생성하여줍니다.
    이때 주의할점은 버킷명을 호스팅 하고자 하는 도메인과 일치시켜 주어야 합니다.

    버킷 생성하기

    또한 권한 설정시 퍼블릭 액세스를 꼭 체크 해제 해주어야 합니다.

    버킷 생성하기(권한 설정) - 퍼블릭 액세스 체크해제

  2. 버킷이 생성되면 호스팅 하고자 하는 파일을 업로드하여줍니다.
    호스팅시 누구나 접근 가능하게 하기때문에 퍼블릭 액세스를 허용 해야합니다.

    파일 업로드시 퍼블릭 액세스로 변경

  3. 그 후 속성 → 정적 웹 사이트 호스팅 메뉴에 들어가서
    인덱스 문서(메인 페이지), 오류 문서(404 등 오류가 발생했을때 노출 할 페이지) 2가지를 설정하여줍니다.

    정적 웹호스팅 설정

    저는 아래와 같이 main.html과 error.html으로 설정했습니다.
    저장 후 빨간색 박스 안에 있는 엔드포인트에 본인이 설정한 페이지가 정상적으로 노출되는지 확인합니다.

    정적 웹호스팅 설정 - 엔드포인트 확인

    또한 /detail.html 과 같이 존재하지 않는 페이지를 조회하였을때에 오류 문서로 설정한 페이지가 정상적으로 노출되는지도 확인합니다.

  4. 마지막으로 버킷의 정책을 설정하여 줍니다.

    해당 리소스 하위 경로에 대한 조회 권한을 설정하는것으로, 아래의 빨간 박스 내용이 자신이 설정하려는 도메인과 동일해야합니다.

    버킷 정책 편집 - 편집기 안의 빨간 박스의 내용을 본인의 도메인으로 설정

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    {
    "Version": "2012-10-17",
    "Id": "Policy1579004958999",
    "Statement": [
    {
    "Sid": "Stmt1579004957334",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::static.travelerapp.kr/*"
    }
    ]
    }

이것으로 S3에 대한 설정은 끝입니다.

Route53 설정하기


자세히 보기

AWS Dev Day Seoul, 2019 메모

틀린 내용이 있다면 제가 졸아서 잘못 메모했을 수 있습니다…..

AWS Fargate를 사용한 서버리스 컨테이너 활용 하기 - 삼성전자 개발자 포털 사례

  • ECS
  • EKS
  • Fargate for ECS
  • Fargate for EKS (on the roadmap)

ECS

쿠베 없이 간단하게 사용가능

EC2 인스턴스를 직접관리해야하는 단점

Fargate를 활용해 해결 가능

  • 서버가 없는 컨테이너 환경
  • 서비스와 컨테이너에대한설정만 관리
  • ECS 대비 EC2 관리에대한 부담만 덜어짐
  • ECR을 이용해 이미지를 배포할 수 있음
  • Networking - aws
  • LayerStorage - task당 10GB
  • VolumeStorage - 공용 볼륨

QA Automation을 중점적으로 CI/CD를 구축함

SRE

아키텍쳐 ECS 클러스터를 이용함.

Fargate 활용시 → 무중단배포전략 기본 탑재, 빠르게 deploy 가능, 비용 절감

ECS의 EC2옵션에 비해 45%절감(compute 비용만)

task 별로 관리가 가능하기때문

워크스페이스를 CloudFoundry playform 오픈 소스를 사용하여 구현
프로메테우스기반으로 VALET 대시보드 구현

task가 runtime으로 넘어갔을때만 과금이 됨.

클러스터안에 서비스가 매핑

활용 사례

백엔드기준

  • 서치, k-v DB, API

클러스터세팅

  • TG,vpc,subnet,SG

task cpu : 1024 MB , 512 task CPU

Events 탭을 이용하여, 이벤트 발생 확인 가능

build.sh → upload.sh (ECR에 업로드)

ECS workshop - https://ecsworkshop.com/

실시간 데이터 처리를 위한 현대적 애플리케이션 개발 방법

Amplify

CLI 툴체인 및 UI 구성요소 포함하는 클라이언트 프레임워크

전체 앱 구축 테스트 배포 및 호스팅을 위한 dev tool 제공

AppSync

관리형 서버리스 gQL 서비스

다양한 데이터 소스 활용 가능

디바이스가 오프라인일 경우에도 가능

오프라인시 변경된 데이터만 동기화처리

queries → get

mutation → create | update

subscriptions → pub | sub

Cognito

IAM을 모두 제공할 수 없음

Kinesis

DocumentDB

엘라스틱서치 DB 랑 유사하게보임

몽고 DB와 호환됨

초당 수백만건 요청 처리 가능

컴퓨팅과 스토리지 레이어를 분리하여 컴퓨팅 리소스만 확장 가능, 스토리지는 오토스케일됨

데이터를 파티션으로 분산저장(3개의 AZ에 복제)

AppSync를 활용하여 query와 mutation 분리

DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기

3개의 az에 마스터 노드 배포

az당 두개의 인스턴스 배포

c타입 인스턴스로 배포됨

deprecated 되는 시점에 마스터노드를 강제 업데이트함.

Latest 버전부터 3개 이내의 버전으로 관리되도록 aws에서 관리해줌

EKS는 명령형 인프라가 아닌 선언형 인프라

VPC ink → Network load Balancer

How To Connect with Kubernetes

  • 쿠버네티스에서 제공하는 로드밸런서
  • ALB ingress → IP가 유동적이라 Lambda에서 처리할 수 있으나 번거로움
  • 쿠버네티스의 Node Port 이용

kube2Iam을 이용해 IAM을 관리

HPA → pod 오토스케일링

Cluster autoscaler → 노드 오토스케일링(pod를 더 이상 배치할 공간이 없을때)

Monitoring

프로메테우스를 통해 수집 → 그라파나를 통해 → cloudwatch 메트릭을 사용해 대시보드 제공

로그 : 엘라스틱서치와 클라우드워치 fluentD

클라우드워치를 두고 로그패턴을 이용해 노티 가능 → 엘라스틱서치로 전송

엘라스틱 서치 Authentication은 cognito

nginx 리버스프록시로 사용해 키바나접근

AWS Xray를 이용해 APM 체크

배포는 Spinnaker를 이용해서 쿠버네티스 배포할때 용이

pod는 엔드포인트도 계속 변경됨
eks 자체 기능으로 IAM과 쿠버네티스의 IAM을 연결하는 기능 제공예정

Monitor

기존에는 가장 성능 좋은 쿠버네티스 로깅 플랫폼 fluentd(루비로 작성됨)
→ fluent Bit이 C로 만들어진 더 고성능을 요구할때 사용할 수 있는 플랫폼

Networking

어노테이션만으로 nlb alb 등 선택 가능
ALB는 L7형태로 ingress controller에서 해석해서 처리

Logging

EFK
pod → fluentd → cloudwatch→ kibana
FluentBit을 사용하면 더 Optimized 할 수 있다.

Application Mesh

기존 서비스 Mesh는 envoy proxy를 사용
AppMesh는 EKS만 쓸 수 있는게 아닌 Fargate ECS EC2 EKS Kube on EC2등에서도 사용가능

Distribute Logging

전체 콜스택 모니터링하기 어려움
X-Ray를 활용
모든 쿼리스트링 모니터링 가능

코드 기반 인프라(IaC)를 활용한 현대 애플리케이션 개발 가속화, 우리도 할 수 있어요

Re-host
데이터센터 → EC2

Re-platform
가상머신 → 컨테이너

Re-factor
모놀리스 → 마이크로 서비스

Re-invent
호스트플릿 → 서버리스

자동화

  • 인프라 구성 자동화
    • 서비스에 필요한 리소스 프로비저닝
  • 애플리케이션 배포 자동화
    • 애플리케이션을 더 효율적, 안전하며, 빠르게 배포
    • 애플리케이션을 빌드, 테스트, 배포

코드기반 인프라의 목적

인프라 변경 사항을 반복적이고 예측 가능하게 함.

CloudFormation

클라우드 인프라 템플릿을 정의하기 위한 언어 - JSON | YAML

1
2
3
4
$ cdk init
$ cdk diff
$ cdk deploy [paramter]
# if you type "y", deploy the app

CDK Deploy 를 활용하면 Cloudformation을 활용해 배포하게됨

cdk를 사용하면 table.grantReadWriteData(fn); 과 같은 함수를 통해 권한을 얻을 수 있음

APIGateway.LambdaRestApi()를 사용하면 API Gateway에 대한 IAM 권한을 가질 수 있음.

→ serverless framework 사용시 serverless.yml 파일에 iam을 설정하던 부분을 함수로 명시 하는거였음.

Loader

ECS Clustuer, ECS Fargate를 이용해 클러스터 생성(규모에 상관없이 재사용가능하도록함)

Monitor

cdk-watchful를 활용하여 cloud watch와 연결 가능

jsii →js로 만든것을 다른언어에서 사용가능하도록 해줌 cdk에서 활용됨

프로세스

Code Commit → CDK 앱과 Lambda 함수 코드는 동일한 리포지토리에 저장됨

Code Build → CdkCodeBuild 프로젝트는 CDK 앱을 synthesize하여 CloudFormation 템플릿을 생성

배포환경은 동일하게 로컬환경은 개발자 본인만을 위한것이다.

클라우드9이나 CloudFormation, 도커등 동일한 환경을 제공할 수 있어야함.

점심 도시락


닭강정, 새우튀김, 갈비찜?돼지고기찜? + 된장국 (나머진 안 먹어봐서 모르겠습니다)

굿즈(SWAGS)

  • 티셔츠
  • 머그컵
  • 방향제
  • 담요
  • 보틀
  • 디퓨저
  • 다이어리