Yesterday I learned
"클라우드의 최대 장점은 on - premise"
"paas 는 하드웨어에 OS or 개발환경을 놓아주는 것을 말한다"
"VPC 끼리는 보안그룹을 공유하지 않는다"
"VPC 에는 서브넷이 존재 한다"
"사설영역을 연결하는 방법이 있다 - VPC Peering"
Today I learned
- 서브넷 생성 - rapa-vpc-rds-sub1
RDS
데이터베이스는 중요한 리소스이기 때문에 고가용성을 추구하기 떄문에 멀티 AZ(Availability Zone)를 구성해야 한다
가용영역 C 로 서브넷 생성
pub-sub2 생성 10.10.11.0 /24 - public 라우팅 테이블
pri-sub2 생성 10.10.12.0 /24 - private 라우팅 테이블
rds-sub2 생성 10.10.13.0 /24 - private 라우팅 테이블
- 라우팅 테이블에 생성했던 서브넷들을 명시적 서브넷 연결한다.
1. 바스티온 (bastion) 호스트
퍼블릭 서브넷을 갖는 인스턴스 내에서 프라이빗 서브넷 안의 인스턴스에 연결할 수 있다.
- 바스티온 인스턴스 생성
- 쉘과 연결하기 위해 ssh 허용한 기존 보안 그룹을 선택한다
- xshell ssh로 접속
- 바스티온을 테스트하기 위하여 프라이빗 서브넷 내의 인스턴스인 Tomcat 인스턴스 생성
- 프라이빗 서브넷 인스턴스의 키페어를 새로 생성
- 새로운 보안 그룹 생성 ssh 접속은 물론 허용하고, Tomcat (WAS) 서버의 사용자 지정 TCP 8080 포트를 열어준다.
tomcat 의 프라이빗 IP를 가지고 ssh 접속시도
아마 permission denied 오류를 뿜을 것이다.
키페어를 베스천한테 scp로 전달 해야 ssh에 접속이 가능하다
방금 만들었던 프라이빗 키페어 rapa-pri.pem 키페어 파일을 베스천 키페어 와 같은 장소(디렉토리)에 놓아야한다.
- 키페어들이 존재하는 폴더 경로를 복사해서 cmd 창에서 디렉토리 경로로 이동
- ec2-user 의 홈디렉토리 확인
- ec2-user 의 홈디렉토리로 rapa-pri 키페어 파일을 이동
-
실무에서도 키페어 관리를 이런 방식으로 한다고 한다
-
키페어 파일에 권한 부여
- SSH 로 접속 확인 -i 옵션은 키페어 파일이다
- 당연히 외부랑 통신은 불가
- 외부와 통신에 성공하고 톰캣 패키지를 다운받으려면 인스턴스의 outbound 트래픽을 허용해야 한다.
즉, nat gateway를 퍼블릭 서브넷에 생성해야 한다.
NAT Gate way
- NAT 게이트 웨이를 만드려면 탄력 IP (고정 아이피)가 필요하다
- NAT 게이트웨이 생성
- 서브넷은 반드시 pub-sub1을 선택
- NAT 게이트웨이를 생성했으면 프라이빗 라우팅 테이블에 등록해야한다
-
쉘로 접속한 톰캣 인스턴스로 가서 외부로 통신이 가는지 확인
-
정상적으로 송신이 가능하다
- 탄력 IP 와 NAT 게이트웨이는 과금이 될 수 있기 때문에 역순으로 삭제 해야 한다.
[삭제 순서]
- 라우팅 테이블 목록에서 삭제
- nat 게이트웨이 삭제
- 탄력적 IP 릴리즈
RDS 서브넷 그룹 만들기
RDS 는 가용영역 a,c 에 대해 서브넷 그룹을 만들어 줘야한다
kakao 라는 vpc를 192.168.0.0/16 대역으로 생성. 3tier로 구분된, 두개의 가용영역 (A 및 C )를 갖는 서브넷을 구성하여 테스트 해보자
- bastion 호스트를 통해 pri-sub2에 구성한 서버에 ssh로 접근
- pri-sub2 에 존재하는 서버의 아웃바운드 트래픽 하용
- VPC 생성
- 서브넷 생성
- 인터넷 게이트웨이 생성
- 프라이빗 서브넷 라우팅 테이블
- 퍼블릭 서브넷 라우팅 테이블
- 탄력적 IP 생성
- NAT 게이트웨이
- 결과
2. ELB (Elastic Load Balancer)
하나의 인스턴스 생성
- 인스턴스 이름 : web
키페어 : rapa
퍼블릭 세브넷 - rapa 키페어
- ssh로 Xshell 로 접속
[ec2-user@ip-10-10-1-165 ~]$ sudo yum -y install httpd
[ec2-user@ip-10-10-1-165 ~]$ sudo systemctl restart httpd
[ec2-user@ip-10-10-1-165 ~]$ sudo systemctl enable httpd
[ec2-user@ip-10-10-1-165 ~]$ cd /var/www/html/
[ec2-user@ip-10-10-1-165 html]$ sudo touch index.html
[ec2-user@ip-10-10-1-165 html]$ sudo vi index.html
[ec2-user@ip-10-10-1-165 html]$ curl localhost
webserver
webserver2 라는 내용이 보여지는 web2 인스턴스를 AZ-c 에 생성
[ec2-user@ip-10-10-11-167 ~]$ sudo yum -y install httpd
[ec2-user@ip-10-10-11-167 ~]$ sudo systemctl restart httpd
[ec2-user@ip-10-10-11-167 ~]$ sudo systemctl enable httpd
[ec2-user@ip-10-10-11-167 ~]$ sudo touch index.html
[ec2-user@ip-10-10-11-167 ~]$ ls
index.html
[ec2-user@ip-10-10-11-167 ~]$ sudo vi index.html
[ec2-user@ip-10-10-11-167 ~]$ sudo mv index.html /var/www/html/
2-1. 로드 밸런서 생성
어플리케이션 로드 밸런서 (ALB)
- 7계층이고 SSL 인증서를 붙이는 것이 가능하다 - 서비스 단 까지 로드밸런싱 하고싶다
대신 7계층에서 로드밸런싱이 되게 되면 패킷이 있으면 7계층까지 열어봐야함
네트워크밸런서와 비교했을때 부하가 많이 발생할 것임
네트워크 로드 밸런서 (NLB)
- 네트워크 로드 밸런서는 4계층 port 를 로드 밸런싱 한다
탄력 IP를 붙일 수 가 있다
로드밸런서 계획(Scheme)
- Internet-facing
- Internal
우리는 웹서버를 외부에 노출시켜야 하므로 Internet-facing 을 선택
- Mapping (AZ-a , AZ-b)
- 보안 그룹은 기존에 생성했던 web 보안 그룹 선택
2-2. Target Group 생성
-
새로운 탭이 생성 된다.
-
인스턴스 선택
헬스 체크 (Health Check)
- Healthy threshold - 문제가 생겼다가 괜찮다 적어도 몇번은 성공해야한다
- Unhealthy threshold - 몇번 성공 못하면 안괜찮다고 판단한다
- Timeout - 몇초 이내에 응답해야한다
- Success codes - 성공 code 노출
- 다시 ELB 탭으로 진입 하고, 새로고침 버튼을 눌러 타켓그룹을 지정해준다
- End Point를 기억하고 쉘 Curl 명령어로 확인 혹은 크롬 창에서 테스트 해본다
- 앤드포인트로 접속
- 로드밸런서도 과금의 대상이기 때문에 삭제는 필수이다.
- 로드 밸런서 삭제
- 타겟 그룹 삭제
NLB로 똑같이 로드밸런서를 생성하여 로드밸런싱 여부를 확인해보자.
- Curl 명령어로 확인
3. 커스텀 AMI 만들기
- 아마존 리눅스 2 + httpd (state: enabled) 의 세팅을 가진 커스텀 AMI를 만들것이고, EC2 인스턴스 web1 의 이미지를 복사할 것이기 때문에 인스턴스 중지 해준다 인스턴스는 종료하면 안된다.
- 중지시킨 인스턴스 작업 - 이미지 및 템플릿에 이미지 생성 하고 이미지 이름은 web-img로 생성한다/
커스텀 AMI 로 인스턴스 를 생성
[과금 이슈]
- 기존의 인스턴스 모두 종료
- AMI 등록취소도 해주고 스냅샷도 삭제해준다.
문제
- 워드프레스가 설치된 커스텀 AMI 를 이용하여 각각 wp1, wp2라는 인스턴스를 생성하여 로드밸런싱 되도록 해보세요.
DB는 RDS를 이용해 구성
[참고] php -v 7.x 이상 Amazone Linux 환경에서 설치하기
https://techviewleo.com/install-php-7-on-amazon-linux/
해결과정
-
아마존 리눅스를 베이스 AMI 로 하는 인스턴스 생성
-
Shell로 ssh 로 접속하여 wordpress 구성을 위한 패키지 설치 - wp-config.php 파일 생성까지의 과정
-
인스턴스 중지 후 AMI 이미지 생성
-
인스턴스 wp1, wp2 생성
-
ssh 로 wp1, wp2 인스턴스를 Shell 로 접속
-
RDS 에서 Data base 생성 RDS 내의 데이터 베이스 2개가 필요하다.
-
RDS 생성이 완료됐다면 아무 인스턴스에서 mariadb-server 패키지를 설치해 RDS 엔드포인트를 이용하여 mysql에 접속
-
초기 데이터베이스는 이미 생성됐으니 남은 Data base create
-
각각의 wp1, wp2 인스턴스 wp-config.php 파일에 DB 정보 입력 후 httpd 서비스 재시작
-
wp1, wp2 각각 wordpress 접속이 되는지 확인
-
로드밸런싱을 증명해야 하므로 wp1, wp2 둘 중 하나를 다르게 구성
-
ELB - ALB 생성
-
Target Group 생성 후 ALB 에 할당
-
"엔드포인트"/wordpress 를 크롬 접속창에 접속하여 로드밸런싱이 되는지 확인
