-EBS Volume
1. EBS를 만들어서 각 디렉토리에 마운트
/ 100GB < disk EBS (ec2 생성하면서 루트 디렉토리에 이미 달라붙어있음)
/home/ec2-user 10GB < disk
/home/apache 500GB < disk 특정 디렉토리에 마운트 해보자!
/home/tomcat 500GB < disk
/usr/bin/tomcat/ 500GB < disk
2. EBS 만든 다음 분할해서 마운트
EBS 1TB > partition
EBS 1TB(500GB + 500GB) > LVM / RAID
데이터볼륨일 경우 sdf 이후부터 사용하는 걸 권고
nvme1n1 을 통해 볼륨 생성된 거 확인
root 밑에 data 디렉토리 만들어주고 xfs 파일시스템으로 변환해주어야 한다. (그냥 지나가 버리면 안됨)
파일시스템을 포맷해주면 그에 맞는 기능을 제공받을 수 있음. (OS같은 느낌)
nvme1n1 볼륨을 data 디렉토리에 마운트 시키겠다. (sudo mount /dev/nvme1n1 /data)
그리고 lsblk 통해 확인한 결과, 마운트포인트에 /data가 나온 것을 확인할 수 있다.
그러나, 재실행하고 다시 web-server 접속 시 마운트 포인트에서 사라지게 된다.
왜냐하면 fstab 파일에 선언되어있지 않기 떄문에 재실행할때마다 마운트는 해제된다.
/etc/fstab에 nvme1n1에 대한 마운트 및 파일 시스템 정보를 넣어야 한다. (shift+INSERT 통해서 복붙하기)
reboot (재실행) 하고 나서 다시 web-server 접속하고 lsblk한 결과 여전히 /data에 마운트되어있는 것을 확인할 수 있다.
-Snapshot
lab-edu-snapshot-web 생성 (Name 태그까지 붙여서 하기)
나머진 하나는 어제 만든 AMI임 (AMI도 Snapshot에 포함)
볼륨의 경우 암호화안한 상태로 만들면 중간에 암호화 불가능하지만 snapshot으로 복제할 경우 암호화 가능
볼륨 탭에 생성된 것을 확인할 수 있다.
해외리전복사 eu-central-1 (프랑크푸르트)
수명주기정책
5 유지 - 5개 넘어가면 6개부터 이제 먼저 만들어진 거 하나씩 제외하겠다
만약에 월요일에 오면? 3개가 늘어나있을 것이다!
S3 - Access Control List
S3 콘솔 -> 버킷 만들기
S3 버킷은 전세계적으로 겹치면 안되는 이름을 가져야하기에 계정 id를 넣어주기로함
IAM 권한 자체가 우리 계정에 있기 때문에 객체에 이미지 파일을 넣을 수 있다.
=> 퍼블릭 X, ACL을 허용하겠다
아까 객체 url주소를 복사하여 링크 접속하면 업로드한 이미지가 뜨게 된다.
추가 업로드
다른 이미지 추가업로드 과정에서 ACL을 사전 정의 ACL(Any open)하고 주의 참조버튼 누른다.
추가된 이미지의 객체 url 링크로 접속하면 새로 업로드한 이미지 화면이 뜬다.
객체 삭제 그리고 버킷항목들어가서 버킷 삭제까지 할 수 있다.
AWS CLI -> AMAZON S3 생성
EC2FullAccess 랑 AmazonS3FullAccess 권한 설정
확인
jq - 코드 안에서 변수담을 때 활용할 수 있는 명령
버킷 네임에 변수 담음
버킷 형성 및 리스트로 확인
Workshop 디렉토리 밑 images/animal_picture을 버킷에 담겠다. (recursive: 반복!! 계속해서 데이터를 업로드)
버킷 생성이 확인됐으나 접속이 안 됨!! =.> Pre-signed
REGION: ap-northeast-2 (서울)
OBJECT_KEY: golden_retriever.jpg (이미지 파일)
OBJECT_URL: 해당 주소
이 명령어를 치면 주소가 결과값으로 나오고 복붙해서 링크 접속하면 된다. (기간은 30초)
30초 지나니까 다시 차단된 것을 확인할 수 있다.
Bucket Policy
ACCESS DENIED 뜨는 것을 확인할 수 있다 -> 버켓에 권한이 없기 때문!!!
터미널 2개 생성 (WEB_SERVER, VSCODE)
VSCODE 터미널에서 명령어 실행
OUTPUT바뀐 것을 확인할 수 있음
아웃풋 파일의 내용을 AWS 버킷 -> 정책에 복붙
그 결과 엑세스 거부되었던 웹 서버에서 똑같이 되는 것을 확인할 수 있음
IP기반 Bucket Policy
복붙해놓은 버킷 정책 삭제
Access Denied 확인
NAT Gateway -> 웹 페이지가 인터넷 구간으로 나가려면 필요하기 때문에 있음
쉘 스크립트 실행통해 output 파일 형성 + 똑같이 버킷 편집에 복붙
(+ NAT 게이트웨이 항목보면 3.35.113.67 똑같은 ip주소가 들어온 것을 확인할 수 있음)
다시 명령어 입력한 결과 정상적으로 들어온 것을 확인할 수 있음
Wifi 바뀌었을 때 vscode 접속이 안된다! -> 보안그룹에 vscode랑 bastion 인바운드 편집해서 내 ip주소로!!
(bastion의 경우 http에 대해서 내 ip주소로)
Database
DB
-자신을 위한 네트워크 (Subnet)
-라우팅 테이블 추가
-인터넷으로 향한 경로 X (노출 위험)
1. DB subnet 생성
2. 라우팅 테이블 생성 및 DB 서브넷 연결
3. 보안 그룹 생성
4. 서브넷 그룹 생성
RDS 콘솔 들어가기
5. AURORA 생성
당연히 DB는 퍼블릭 액세스 해주면 안되고!! db 위해 생성한 보안 그룹 선택
운영적 측면에서 꺼놓기
DB 생성완료
Aurora PostgreSQL 접속
/Workshop/Scripts/ 접속 및 postgres 접속 tool 설치
read replica 설치를 안 했지만 읽기와 라이터가 구분되는 것을 확인 (만약에 read replica 했으면 인스턴스에 다 몰리게 됨)
리드 인스턴스와 라이터 인스턴스의 도메인을 nslookup한 결과, 둘이 똑같은 ip주소가 나왔음을 확인할 수 있다.
라이트 인스턴스 도메인주소를 넣고 비밀번호(1******8) 넣은 결과 접속 확인
DBMS Engine 생성
trip_advisor db에 접속
이 때 비번은 engine 생성할 떄 설정해놓은 비번을 넣는다.
Read Replica
파라미터 그룹 생성 및 timezone 변수 수정
DB 수정에서 암호화 및 파라미터 그룹 디폴트 -> 생성한 파라미터 그룹으로 변경 // 즉시 적용까지 확인
읽기추가 항목에서 DB인스턴스 식별자에 이름 넣음
확인 결과
테이블 생성 및 조회
오른쪽 터미널에서 리드 인스턴스로 접속하겠다.
데이터 입력이 되는 것 확인
aurora multi az(이중화) 활성화
RDS - Multi az
Aurora - read replica가 multi az 처럼 수행 (writer가 죽으면 자신이 standby -> active 로 바꿔서 수행)
Writer Instance IP 반복 조회
장애 조치를 수행하면서 ip주소가 바뀌는 것을 확인할 수 있음
라이터 인스턴스 주소가 바뀌고
리더의 주소가 라이터 인스턴스의 이전 주소임을 확인할 수 있음!!!
'IT > AWS' 카테고리의 다른 글
AWS - Route 53 (0) | 2025.01.21 |
---|---|
AWS - Cloud Formation, VPC Peering, VPC Endpoint (1) | 2025.01.20 |
AWS - EC2 (0) | 2025.01.16 |
AWS - Cloud Basic Theory, VPC (0) | 2025.01.15 |