카테고리 없음

AWS - IAM, NLB, ALB

YunHyeong 2023. 4. 26. 19:59

1. IAM

1.1. IAM 사용자 생성 후 인스턴스 생성

- 검색 창에 IAM 검색

- 인증과 접근 권한을 관리하는 서비스

 

- AWSServiceRoleForSupport는 삭제가 안됨

- 안지워지는 서비스는 수시로 이용하고 있는 서비스의 일부일 가능성이 있음

 

- 그룹 만들기

- 필요한 정책을 만들 수 있다 (= 고객관리형)

- AWS 자체에서 주는 권한(= AWS 관리형)

- admin 권한이지만 test 일단은 낮은 권한을 줘본다.

 

 

- "AWS Management Console에 대한 사용자 액세스 권한 제공" : user 사용자에게 web UI와 CLI 방식을 모두 제공하기 위해 체크

- "IAM 사용자를 생성하고 싶음 " : 콘솔에서 IAM 사용자를 로그인 할 수 있도록 설정하는 항목.

- 만일 AWS의 회사 계정을 임원이 사용하고 있다고 가정

- 새로운 신입 사원이 들어왔다고 했을때 초기에 어려운 비밀 번호를 임원이 발급해준다.

- 신입사원은 처음 로그인할 때는 임의로 발급된 어려운 비밀번호로 로그인하고 이후에 원하는 패스워드로 바꾼다.

- 처음부터 원하는 비밀번호를 발급하게 하면 임원이나 타인이 그 비밀번호를 알 수 있기 때문에 이런 과정을 거친다.

 

- admin 그룹에 사용자(user)를 추가 -> 사용자는 EC2ReadOnly 권한을 갖게 된다.

 

- root 사용자가 로그인 상태에서는 user사용자로 로그인하기 어렵다

 

- 하지만, 브라우저 오른쪽 상단에 점 세개 표시를 누르고 새 시크릿 창을 누르면 user 사용자로 로그인이 가능하다.

- 복사한 URL을 붙여넣기 한 후 아이디와 생성된 비밀번호를 입력하고 로그인한다.

 

- 처음 임시로 발급받은 비밀번호를 원하는 비밀 번호로 변경한다.

 

- root 계정에서 만든 EC2 인스턴스를 user 계정에서도 확인할 수 있다

- 하지만 생성은 안된다(EC2ReadOnly 권한만 부여했기 때문에)

 

- admin그룹 권한이 너무 낮다. 

- EC2ReadOnlyAccess 권한을 삭제하고 권한을 높여준다.

- EC2ReadOnlyAccess 권한을 삭제하고

- EC2FullAccess 권한을 부여한다(=권한을 높인다)

 

- 사용자(user)에게 곧바로 권한이 전달되어 EC2 인스턴스(web02)를 만들 수 있다.

 

1.2. RDS

- user(사용자)는 RDS에 대한 권한이 없기 때문에 RDS 사용이 불가능 하다

- admin 그룹에서 RDS 권한을 FullACcess로 추가한다.

 

- 권한을 받은 user는 데이터베이스 생성이 가능하다

- 엔진은 MariaDB로 설정하고

- 버전은 10.3.35로 선택한다.

 

- DB 식별자를 설정하고

- 마스터 사용자 이름을 적어준다(admin은 사용하지 말것)

- 암호는 대문자, 소문자, 특수기호를 혼합하여 어렵게 만든다.

 

- 인스턴스 구성을 dbt3.micro로 설정한다.

 

- vpc : my-vpc를 선택

- 퍼블릭 엑세스를 아니오로 선택한다

- 하지만 플랫폼끼리 연결할 때 퍼블릭 엑세스가 필요한 상황에서는 "예"를 선택

 

- 보안그룹은 기존에 만든게 없기 때문에 새롭게 생성한다.

- 가용영역은 2d로 설정하여 EC2 인스턴스들과 구별한다.

- 이제 DB를 생성한다.

 

- DB를 생성하면 자동으로 백업이 진행된다.

- 스냅샷을 남겨 놓음으로써 백업이 가능하다.

 

1.3. Route53

- 사용자에게 Route53에 대한 권한이 아예 존재하지 않음

- 페이지 view조차 되지 않는다.

 

- admin 그룹에 Route53FullAccess 권한을 준다.

 

- 호스팅 영역을 생성한다

- 도메인 이름 : yunhyeong.shop

 

- 생성된 호스팅영역 4개를 가비아에 옮겨준다.

2. ELB(= NLB)

2.1. user 사용자의 권한 변경

- 사용자가 할일이 많아졌기 때문에 해당권한들을 모두 지우고

- AdministratorAccess권한을 준다.

- 실습을 진행하면서 user사용자의 더 많은 권한이 필요했기 때문에 권위가 높은 AdministratorAccess을 부여

 

2.2. MobaXterm 접근 후 웹 서버 띄우기 

- MobaXterm으로 web01과 web02 인스턴스에 접근한다

- foo.tar라는 부트스트랩 파일을 루트 경로에 옮긴다.

- tar xvf foo.tar -C /var/www/html 명령어를 활용하여 index.html 파일을 수정한다

 

- curl http://169.254.169.254/latest/meta-data/

- 메타데이터 이용

- AWS EC2 화면에서 볼수 있는 정보들을 CLI에서 메타데이터로 사용가능

- ex) curl http://169.254.169.254/latest/meta-data/public-ipv4 명령어를 이용하면 public IP 확인가능

 

* 언어설정 변경

- 리전이 나와있는 오른쪽 상단 옆에 있는 계정버튼의 설정으로 들어가 언어를 변경할 수 있다.

 

- 로드밸런서 화면으로 들어가서 NLB 생성 버튼을 누른다

 

- 체계 인터넷 경계

- IP 주소 유형 : IPv4

 

- vpc : my-vpc

- 가용영역은 web01과 web02가 있는 가용영역을 선택한다.

- 서브넷은 두 가용영역 모두 퍼블릭으로 해야한다.(web01, web02 모두 public 서브넷에 있기 때문에)

 

- 로드밸런서를 통해 들어오는 트래픽을 web01과 web02 모두에 전달할 수 있도록 그룹으로 묶는다.

- 두 web서버가 80포트로 외부와 통신하기 때문에 NLB의 80포트를 열어놔서 외부에서 web서버에 접근하도록 만든다. 

 

* 그림 요약

 

 

- 두 인스턴스를 선택하고 "아래에 보류 중인 것으로 포함" 버튼을 누른다.

- 아래에 두 서버가 대상으로 포함되는 것을 볼 수 있다.

- target group으로 web01과 web02를 묶는다

- NLB Health Check

 

- NLB의 주소로 접근

- 부하분산 방법 : 최소 연결 방식(least connection) : 연결 수가 가장 적은 서버에 네트워크 연결방향을 정합니다. 동적인 분산 알고리즘으로 각 서버에 대한 현재 연결 수를 동적으로 카운트할 수 있고, 동적으로 변하는 요청에 대한 부하를 분산

 

- NLB 도메인 생성

- user로 로그인 (root 계정의 IAM 대시보드에서 오른쪽 상단에서 id 확인가능)

- NLB의 접근하는 주소가 길었기 때문에 단순한 도메인 이름으로 바꿔주었다.

 - 주소가  http://nlb.yunhyeong.shop/ 으로 변함, 단순해진 주소로 접근이 가능하다.

 

3. ALB(Aplication Load Balancer)

* 자동 관리형 DB가 구현 가능하다

* 타겟 그룹에 대상을 넣으면 자동으로 동기화

* AMI -> template : 생성된 template으로 web02, web03...을 만든다

* web01은 template을 만드는데 사용된다.

* web서버들이 private IP만 갖도록 만든다

* ALB를 통해서만 접근할 수 있도록 한다(포워딩)

* Round robin 방식 활용

 

3.1. Wordpress 인스턴스 생성

- template을 만들어야하기 때문에 우선은 public 서브넷으로 설정한다

 

- 사용자 데이터 삽입

 

 

- DB의 보안그룹의 인바운드 규칙이 강의실 IP로 설정되어 있기 때문에 강의실에 있는 모든 PC들은 DB 인스턴스에 접근이 가능해진다.

- 이를 web 보안 그룹으로 편집해서 오직 web 서버를 거쳐서만 DB 서버에 접근할 수 있도록 만든다.

 

- 소스 정보를 web 보안그룹으로 변경

 

3.2. ALB 생성

- vpc를 선택하고 서브넷을 web서버가 있는 가용영역으로 설정한다.

- 서브넷은 둘다 퍼블릭으로 선택한다.

- 아무리 서버가 pvt 영역에 있더라도 접속자의 입장에서 생각하여 pub 영역으로 매핑 정보를 셋팅한다.

 

- ALB는 독자적인 보안 그룹이 필요

- NLB는 보안그룹이 없지만 ALB는 있다.

- HTTP, HTTPS 만 인바운드 규칙을 허용

 

- 이때 새 보안 그룹 생성 버튼을 눌러서 ALB의 새 보안 그룹을 만든다

- VPC를 반드시 my-vpc의 아이디로 넣어야한다.

 

- 리스너는 프론트엔드다

- 사용자가 ALB로 접근하는 포트를 명시한다.

- 대상그룹은 사용자가 ALB에 80포트로 접근하면 그 트래픽을 전달할 그룹이다.

 

- 보안그룹안의 소스로 넣기 위해서 ?

 

- 백엔드 target 그룹(web서버 그룹)에 ALB를 통해서 포워드 할예정.

 

- 샘플링 작업이기 때문에 Wordpress라는 가상머신 하나만 선택

- 이후 이 인스턴스를 이미지로 만들고 template으로 사용할 예정

 

- wordpress 인스턴스 생성시 설정한 사용자 데이터에서 php 설치 과정이 있었기 때문에 오류가 발생

- 대상그룹 설정시 "/" 경로로 설정했기 때문에 AWS의 ALB는 index.html을 찾는다

- 하지만 wordpress 설치시 설정된 index.php가 최우선 순위로 설정되고, index.html의 파일이 존재하지 않기 때문에 ALB는 index.html 파일을 읽지 못하여 상태코드 200을 반환하지 못한다

- 따라서 반드시 상태검사용으로 index.html 파일을 만들고 대상 그룹의 경로를 "/index.html"로 변경하여 상태코드 200을 반환하도록 만들어야한다.

- 이 경로를 "/index.php"로 변경해도 ALB는 이를 읽지 못한다

 

- httpd.conf 파일에서 우선순위를 index.php가 더 높게 설정해준다. 

- 이러면 index.html 파일이 존재해도 index.php 파일의 우선순위가 더 높아진다.

- 수정 후 sudo systemctl restart httpd.conf 수행

 

- 상태 검사 항목에서 경로를 "/index.html"로 지정한다.

- 이렇게 함으로써 index.html을 인식할 수 있어서 ALB는 상태 검사시 200을 반환한다.

 

- MobaXterm에서 web01서버로 접근

- 이전에 생성한 RDS DB인 wp-dbserver 주소로 접근하여 wordpress 데이터베이스를 만든다.

 

- Route53에서 alb의 레코드를 생성

- blog.yunhyeong.shop 주소에 접근하면 wordpress 화면을 볼 수 있다.

 

* 가비아에서 도메인 정보를 매핑한 후 window 서버에서 nslookup -type=ns yunhyeong.shop 명령어를 활용하면 도메인 정보가 잘 생성 됐는지 확인할 수 있다.

 

3.3. Image 생성

- 샘플로 만든 wordpress 인스턴스를 이미지로 만들어서 다른 인스턴스도 만들예정이다.

 

- 이미지를 생성하면 자동으로 스냅샷이 생긴다.

 

3.3. Template 만들기

- 이미지를 이전에 생성한 my-ami-wp로 설정한다.

- 사진에는 나와 있지 않지만 보안그룹을 반드시 web으로 선택해야한다

- 그래야 ALB와 연결 가능

- 템플릿 완성 확인 가능

 

-  worppress의 단점은 퍼블릭 IP를 가지고 있다는 점이다.

- 현재 상태로는 ALB를 거치지 않고도 퍼블릭 IP를 통해서 인스턴스에 접근할 수 있다.

- 따라서 ALB의 대상그룹에서 wordress 인스턴스를 등록 취소한다.

 

- 다른 설정은 전부 동일하지만 네트워크 설정은 변경이 필요하다

- 서브넷을 Private subnet으로 설정하여 외부에서 인스턴스에 바로 접근할 수 없도록 한다.

 

- 같은 템플릿으로 총 3개의 인스턴스를 만들어 본다.

 

 

- 이제 생성한 wp인스턴스들을 타겟 그룹에 넣어준다.

- 대상 등록 항목에서 my-tg-alb를 선택하고 wp인스턴스들을 선택하여 "아래에 보류 중인 것으로 포함"을 클릭하여 대상 등록을 마쳐준다.

- ALB가 Haproxy 역할을 한다