AWS S3 에 웹호스팅 적용하기 응용(실습 #8)

콘솔 설정을 통해 간단하게 실습#7 을 수행했으면

이번에는 수업자료 내용대로만 하지 말고 각자의 방식대로 

웹호스팅 서비스를 구현했으면 좋겠습니다.

 

저는 aws CLI 와 콘솔을 적절히 사용해서 originalchoi-bucket-web2 를 만들고 

기타 설정을 추가로 적용해보도록 하겠습니다.

 

윈도우 터미널로 wsl 우분투를 열고 aws s3 ls 를 실행해봅니다.

별도의 설정과 로그인 절차 없이 지난번에 반영해둔 계정정보를 바로 활용할 수 있어서 편합니다.

 

 

aws s3 cli 커맨드를 살펴보며 버킷 만드는 것부터 다시 진행해봅니다.

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-services-s3-commands.html

AWS CLI에서 상위 수준(s3) 명령 사용 - AWS Command Line Interface

 

매뉴얼에서 하라는 대로 버킷을 만들려고 하는데 에러입니다.

제 계정 정보에 리전명이 기입되어야 될 것 같네요.

 

사실 그전에 crendential 생성은 책에서 하라는대로 한건데..

역시 실전은 다릅니다.

 

wsl 내의 ~/.aws/config 파일을 확인하고 

기존 default 에서 제가 주로 활용할 서울리전(ap-northeast-2)로 변경해줍니다.

 

터미널을 재시작한 후 s3 mb 명령을 다시 해봤는데 여전히 config 파일에서 오류가 있나보네요

그냥 aws configure 로 다시 설정하겠습니다.

 

다시 설정하고 aws mb 로 make bucket 을 해주니까 잘 됩니다.

이제보니 제가 config 파일에 리전명을 형식에 맞지 않게 썼었습니다.

 

 

이제 기존 web1 버킷의 파일들을 web2 버킷으로 카피 해보겠습니다.

 

일반적으로 적용되는 * 문자로는 모든 객체명을 반영시킬 수 가 없습니다.

aws 에서는 객체명을 key 로 인식하는데 * 이라는  key 를 찾을수가 없어서 cp 에 실패했다고 나오네요.

 

버킷을 통째로 복사할 수 있나 싶어서 시도해봤는데 안됩니다.

 

이럴 때는 sync 명령을 쓰면 됩니다.

 

 

이번엔 아까와 다르게 버킷 내부에 폴더를 하나 새로 만들고 s3 내의 저장경로를 바꿔보도록 하겠습니다.

aws s3 밑에 mkdir 식의 명령이 있을 줄 알았는데 없네요..

 

 

aws cli  를 이용해서 버킷 내에 새 폴더를 생성하고 싶으면 s3api 커맨드를 이용해야 합니다.

s3api 커맨드에 서브커맨드 put-object 를 입력하고

옵션으로 버킷명과 객체키값(객체명, 이 경우엔 마지막에 / 를 붙여서 폴더로 인식해줌) 을 함께 입력합니다.

 

이제 web2 버킷의 / 에 존재하는 기존 데이터들을 /test 로 옮기겠습니다.

버킷의 / 경로를 --recursive 옵션을 붙여주면 해당 경로의 데이터들을 mv 로 옮길 수 있습니다.

 

이번엔 web2 버킷의 test 폴더를 web1 버킷으로 copy 해봅시다.

기존 web1 버킷의 내용물 입니다.

 

recursive 옵션으로 cp 완료

 

하지만 web1 버킷의 객체들은 변화가 없습니다.

 

자세히 보니 마지막 수정날짜(2023.10.15 pm 9:03:43) 는 최근 작업시점이 반영되었네요.

즉 cp 가 되긴 되었는데 web1/ 에 덮어쓰기 되었습니다.

 

기존 작업로그를 살펴보니 소스 경로의 폴더가 복사된게 아니라

소스 경로 폴더의 하위 파일들이 대상 경로 web1/ 으로 복사된 것을 확인할 수 있습니다.

 

대상 경로에 새폴더는 존재하지 않지만 web1/test 까지 지정해서 cp 를 다시 해봅니다.

 

test 폴더가 잘 반영되었습니다.

 

이전의 콘솔 메뉴로든 cli 명령으로든 새폴더 생성을 하면서 알 수 있듯 버킷내 폴더는 같은 객체인데

경로를 구분해주는 / (prefix) 역할을 합니다.

실제 새 폴더를 생성하는 것이 아닌 경로 구분자( / ) 를 추가해주는 개념입니다.

 

이는 기존의 리눅스 환경과 다르니 주의하도록 합시다.

아래 예제를 한번 더 실습해보면 그 차이를 다시 느낄 수 있을 것입니다.

 

다시 web2 버킷으로 돌아와서 /test/ 하위 객체들을 퍼블릭 공개로 전환하고

/test/index.html 을 기준으로 정적 웹사이트 구성을 마무리 합시다.

 

s3api 의 put-object-acl 을 사용하면 단건 파일에 대해 public-read 를 부여합니다.

 

index.html 에 퍼블릭이 부여되었다고 해서

index.html 을 통해서 동일 폴더에 있는 다른 html 문서는 접근할 수 없습니다.

 

 

 

특정 객체 접두사(프리픽스, 폴더 구분)에 읽기 읽기 액세스 권한을 부여하려면 다음과 비슷한 버킷 정책을 추가합니다.

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"AddPerm",
      "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::DOC-EXAMPLE-BUCKET/publicprefix/*"]
      }
  ]
}

 

위 정책을 텍스트 파일로 만들고

aws cli 를 통해서 해당 텍스트 파일을  업로드 하며 권한을 부여할 수 있을 것 같은데 방법을 못 찾았네요 ㅋ

 

그래도 웹콘솔에서 수동 정책 설정은 처음이니 한번 해봅시다.

 

 

버킷 정책 편집을 반영하려고 하니 퍼블릭 액세스 설정과 충돌합니다.

 

 

기존에는 버킷의 퍼블릭 액세스 차단 설정시 3,4항목의 퍼블릭 차단만 유지했는데

정책 적용시 퍼블릭 엑세스 차단을 실행하는 3,4항목을 비활성화 해줘야겠습니다.

 

다시 버킷 정책을 설정하니 반영이 잘 되었습니다.

 

test/2.html 의 경우 개별 객체에 public read  가 부여되지 않았지만

 

 

버킷 정책에 따라 index.html 을 통해서든

 

직접 url 을 통해서든 public read 가 잘 이루어지는 것을 확인할 수 있습니다.

 

 

이제 마지막으로 웹사이트 구성을 하며 마치겠습니다.

 

aws cli 로 뭐 할수 있는게 없나..

tab tab 으로 자동완성 하다보니 서브 커맨드 website 가 눈에 띕니다.

help 로 빠르게 확인해봅시다.

 

example 을 보니 처음 웹 콘솔로 작업했던 화면 메뉴랑 다를 것도 없는 것 같네요.

 

사실 원래 계획은 web1 버킷의 /test/index.html 을 도메인 index 로 삼고 싶었는데

이렇게는 구성이 안 되는것 같습니다.

 

빠르게 web1/* 들을 퍼블릭으로 전환하고 작업을 마무리 합시다.

 

기왕이면 에러 페이지도 하나 만들어주고 작업합시다.

 

이제 /index.html 을 기준으로 하고

erorr 발생시 test/error.html 을 리턴해주는 정적 웹호스팅 서비스를 운용하게 되었습니다.

에러 페이지도 잘 작동합니다.

 

 

[참고자료]

 

https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/s3-example-static-web-host.html

Amazon S3 버킷을 정적 웹 호스트로 사용 - AWS SDK for JavaScript

 

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/using-folders.html

Amazon S3 콘솔에서 폴더를 사용하여 객체 구성 - Amazon Simple Storage Service

 

 

https://repost.aws/ko/knowledge-center/read-access-objects-s3-bucket

Amazon S3 버킷의 일부 객체에 퍼블릭 읽기 액세스 권한 부여