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 역할을 한다