linuxer-admin
aws-ami-Permissions-ami공유
ami 를 공유하는 방법을 포스팅해 볼까한다.
계정간 인스턴스 이동을 진행하려면 꼭 알아야한다.
ami 메뉴에서 권한수정을 클릭한다.
공유할 계정의 aws 계정 번호를 입력하여 권한을 추가한다.
공유된 계정에서 인스턴스 생성 페이지에서 나의 AMI에서 소유권에 나와 공유됨만 체크해본다.
공유된 AMI를 확인한다.
다른 방법으로 ami 를 확인할수 있는데
공유 받은 계정에서 프라이빗 이미지를 검색해서 확인할수 있다.
리전이 다르다면 스냅샷을 리전복사 한다음에 공유를 하자.
끝!
Azure-네트워크 구성 및 망분리
azure 에서 망분리가 먼저 선행되어야 할 과제이다.
aws 에서의 망분리는 계층적 망분리로 서브넷과 라우팅 테이블을 이용하여 망분리를 구현한다. 하지만 gcp / azure는 망분리의 개념이 좀 다르다.
서브넷을 통한 망분리가 아닌 공인IP의 유무로 망분리를 구현한다.
근래에 구성도를 작성하면서 한편으로 계층적 망구성이 구성도 그리긴 불편한 생각이 들긴한데 그래도 익숙하고 편한데 azure 와 gcp 를 보니까 aws 의 망구성이 관리의 편의성이 떨어지는 느낌이기도 하고..조금 애매한 느낌이 든다.
azure 에서는 어떤 인프라도 리소스그룹안에서 만들어진다. gcp의 프로젝트 개념과도 같다. 그렇지만 좀 다른게 리전에 종속된다.
한국리전은 중부와 남부로 나뉘는데 중부를 azure 에선 중부를 주로 추천하는데 나는 중부말고 남부를 선택했다.
요구하는 바는 구독 그룹네임 리전 리소스 그룹다음에는 virtual network 를 생성하는데 VN은 서브넷을 생성하게 된다.
가상네트웤의 최대 크기는 10.0.0.0/8 까지로 16777216개 주소 를 사용할수 있다.
서브넷을 3개로 나누었고 서브넷은
보안그룹을 서브넷에 설정하여 접근제어가 가능하다.
aws 의 구성의 경우엔 az 별 서비스별 서브넷을 설정했지만 azure 는 az가 명시적으로 지정되지 않아 서비스별 서브넷을 생성해서 사용하는것이 최선으로보인다.
서브넷의 보안그룹으로 막으려면 tag ip id 로 명시적으로 막자.
서브넷별 nsg 가 구성되는게 좋을것 같다.
가상머신은 공용아이피를 없앤 채로 생성한후 나중에 공용IP를 부여할수있었다.
직렬연결은 가상화 머신의 화면을 그대로 포워딩해주는 방식으로 보이며 공용IP가 없는 상태에서도 연결할수 있었다.
굉장히 불편한 부분은 이다음에 발생했는데 lb 는 sku 개념덕분에 혼파망이 되었다.
sku는 basic / standard 두가지로 나누어져있는데
인터넷 통신
기본적으로 VNet의 모든 리소스는 인터넷으로 아웃바운드 통신을 할 수 있습니다. 공용 IP 주소 또는 공용 Load Balancer를 할당하여 리소스에 대해 인바운드로 통신할 수 있습니다. 공용 IP 또는 공용 Load Balancer를 사용하여 아웃바운드 연결을 관리할 수도 있습니다. Azure의 아웃바운드 연결에 대한 자세한 내용은 아웃바운드 연결, 공용 IP 주소 및 Load Balancer를 참조하세요.
하...모든인스턴스는 인터넷과 통신이 가능하다. 이거때문에 한참을 헤멧다.
nat gw가 필요가 없다..............................충격 막으려면 NSG로 막아라.
그래서 일단 정리하자면 azure 의 모든 네트워크 접근제어는 네트워크 단위가 아니라 NSG에서 모두 컨트롤한다.
azure LB사용할땐 가용성 집합을 이용해서 VM을 만든다.
리소스그룹-vpc-subnet-가용성집합-vm-lb 순으로 생성하게 된다.
LB는 베이직과 스텐다드..하 sku 개념이 제일짜증난다.
LB를 베이직으로 생성시에
???같은 가용성 집합인데????
음...이유는 다음에 찾아보기로 하고..
sku 가 스텐다드인경우엔 잘 된다..음 베이직이라 제한이 있는것으로 이해하고 지나가기로 한다.
상태 체크는 로드벨런스 안에서..아니면 zure monitor 을 이용하자.
근데 LB에서 페이지가 뜨는건 잘안됬다 왜지?
그리고 스터디를 마치고 집에와서 백엔드 규칙만 재생성하니 정상적으로 잘됨..뭐야이거..빡치네..
aws-cloudfront-s3-lambda cross-account access
cloudfront - s3 를 이용하게되면 결국 OAI를 이용한 Bucket policy를 사용하게 된다.
단일 계정에서 사용할 경우엔 cloudfront 에서 자동으로 생성까지 해주므로 어려울것이 전혀없다.
그런데 이제 이게 파트너사를 통해서 cloudfront 전용계정을 사용하게 된다던거 multi account 로 프로젝트를 진행할경우 자동으로 생성이 되지 않는다. 이 경우에 어떤방식으로 s3 Bucket policy 를 설정해야 하는지 포스팅하려 한다.
먼저 Bucket policy 를보자
{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K28W3EQ"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
}
]
}
일반적으로 계정에서 버킷정책을 설정하면 위와같은 형태로 적용을 한다.
가끔 정상적으로 적용이되지않는경우엔
{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity 49821f785cce6ee4f575de3f01c503dade8a7b15003aa337faa471d830d07493cbb195eec14f0d86d4a914622e1e42"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::*"
}
]
}
이런식으로 caninucal user id 를 이용하여 정책을 설정하면 자동으로 OAI ID로 정책이 적용되게 된다.
여기까진 아주 쉬웠다. 그런데
람다 엣지를 이용한 리사이즈를 하는 프로세스에서 단일계정이 아니라 교차계정을 구성하게 되면 lambda가 A 계정에서 B 계정으로 접근하게 해줘야한다. 이부분에서 조금 헤멧는데 결국엔 굉장히 간단한 부분이었다.
s3 Bucket policy 에서 계정의 role을 허용해주면 끝..
{
"Version": "2012-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": " Grant a CloudFront Origin Identity access to support private content",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E39X8K58WRN3EQ",
"arn:aws:iam::328341115633:role/lambda-resize-cloudfront"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::linuxer-resize/*"
}
]
}
arn:aws:iam::328341115633:role/lambda-resize-cloudfront
json 문법에 또 약해서 좀 해멧는데 금새 해결할수 있었다..
aws-EFS-backup-restore
EFS를 사용하고 백업/복구 이야기를 하려고한다.
EFS는 NFS기반의 편리한 서비스다. aws backup로 스냅샷 방식의 백업이 가능하다.
현재 측정크기가 6.0kib인데
# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 475M 0 475M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 404K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 4.6G 3.5G 57% /
tmpfs 99M 0 99M 0% /run/user/0
fs-7eb4fb1f.s.ap-northeast-2.amazonaws.com:/ 8.0E 0 8.0E 0% /mnt/efs
root@ip-10-0-0-12 wordpress]# cd /mnt/efs
# du --max-depth=1 -h
258M ./ftp
258M .
실제론 그렇지 않다. 일정 GB이상의 데이터가 쌓여야 명령어가아닌 gui에서 확인할수 있다.
오늘은 이 파일시스템을 백업할거다.
aws backup를 사용할때 유의할점은 백업볼트를 생성할때 각각 목적에 맞게 분할해서 사용하라는 거다. 급하게 작업하다가 관리가 너무 불편해져서 결국 나눴다.
일반적으론 볼트생성->계획생성->규칙생성->리소스할당 순서다.
리소스할당은 tag 기반으로도 가능하고 리소스ID 유형으로도 가능하다.
여기까지 백업계획을 이용한 스케줄 백업이었고 단발성 백업은 대시보드에서 온디멘드 백업으로 진행하면 된다.
진행중인 jab는 작업부분에서 확인할수 있다.
용량이 작어서 금방 백업이 완료됬다.
백업은 증분방식이고 복구지점에 카운트가 올라간다.
복원을 진행해 보면
전체/부분/소스/새 이렇게 선택지가 나눠지는데 얼마전 나에게 혼란을 줬던 부분은 전체-소스 파일 시스템에 복원이다.
복원을 누르면 작업탭에 복원에서 확인할수 있다.
Pending-> Running -> Completed 단계를 거친다.
Pending 이 한국어 에선 보류중으로 나오는데 처음에 좀 당황했다.
보류...??????????????????????????????????????????????
하고 Pending 좀 오래걸린다. 거의 10분 이상걸린적도있다.
root@ip-10-0-0-12 ~]# cd /mnt/efs/
root@ip-10-0-0-12 efs]# ll
total 16
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-33-30-039Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-47-22-912Z
drwxr-xr-x 4 root root 6144 Jan 18 11:24 aws-backup-restore_2020-01-18T03-49-03-261Z
drwxr-xr-x 3 jth-ftp jth-ftp 6144 Aug 21 21:20 jth-ftp
aws-backup-restore_2020-01-18T03-33-30-039Z 같은 형식으로 복원 시작시간으로 디렉토리가 생성되고 복원이 된다. 당연히 복원되는 양에 따라서 속도도 다르다.
3번 복원을해서 3개의 디렉토리가 추가 생성된거다. 사용용량이 df 로는 안보이지만 aws 콘솔에선 보인다.
처음 복구할 땐 덮어쓰기로 생각해서 한참을 기다려도 복구가 안되는거같아 EFS의 /를 마운트 해보고서야 알았다. 아 디렉토리 생성 후 복구되는구나.
그래서 이제 추가로 파일 복구를 해보기로 했다.
root@ip-10-0-0-12 wp-admin]# pwd
/mnt/efs/jth-ftp/wordpress/wp-admin
root@ip-10-0-0-12 wp-admin]# ll
total 980
/mnt/efs/jth-ftp/wordpress/wp-admin 디렉토리를 복구해보겠다.
부분 복원으로 선택하고~ 작업은 부분복원이 좀더 걸리는거 같았다.
/mnt/efs/aws-backup-restore_2020-01-18T04-09-39-782Z/jth-ftp/wordpress/wp-admin
경로로 이동해서 복구 확인해봤다.
root@ip-10-0-0-12 wp-admin]# ll
total 980
정상적으로 잘복구 된것을 확인할수 있었다.
efs 를 매우 애용하는 입장에서 파일복구가 가능해진것은 매우 반길 일이다.
아 추가로 EFS 에서 Bursting 모드를 사용할경우 BurstCreditBalance 를 가지게 되고 사용시 소모가 된다. 그런데 백업이나 복구시에는 크레딧을 따로 소모하지 않았다.
읽어주셔서 감사하다!