22.06.16

 

   목차   

 

1. 간단한 필기

2. WordPress-DB 연동

3. VPC

 - VPC 정리

 - VPC 생성

 - 서브넷 생성

 - 인터넷 게이트웨이 생성

 - 라우팅 테이블 편집 및 서브넷 연결

4. 생각 정리

---

 

   간단한 필기   

 - bastion
    - 인스턴스는 주로 공개하지 않고 로드밸런서만 공개함
    - 인스턴스를 외부에서 관리하지 못하기 때문에 사용
    - 얘를 통해서만 내부에 접속이 가능
    - Azure에서는 jumpbox라 부름
    - 인스턴스를 생성해서 bastion으로 만들면됨

 

 - Session : 논리적인 연결
    - 로드밸런서 생각(1에서 로그인 할때 2로 넘어가면 풀리는거 어떠냐?)
    - 접속한 사용자의 ip랑 로그인한 서버의 ip를 해쉬하여 항상 해쉬값을 일치시키는 방법 존재
    - 쿠키는 클라이언트가 가지고 있어 해킹에 취약
        - 서버가 데이터를 저장해 안전하게 지키자가 세션임(그래서 서버가 가지고 있음)
    - statefull, stateless 방식도 알자
        - 로그인 안하는건 stateless, db는 statefull

 

 - 캐시서버(프록시라 생각)
    - 다른 나라 근처에 캐시서버를 두어 우리나라의 컨텐츠를 가지고 있게 하는것
    - 변화가 있을 때마다 정보를 받아와야함

 

 - SPOF : 단일 실패 지점
    - 이중화 하는 이유
    - 존재하면 안됨

 

 - RAID: 디스크의 중복기능 기술

 

 - System monitoring software : 트래픽 감시

 

 

   WordPress-DB 연동   

 - AWS에서 인스턴스 생성 후 진행

 

amazon-linux-extras로 확인

    - docker의 경우 default로 Repository가 받아져 있기 때문에 yum으로 설치 진행

    - 설치 진행 후, 필요한 이미지 PULL(Wordpress, MySQL)

 

mysql 이미지를 사용하여 컨테이너 생성 시 필요한 옵션 및 환경변수를 설정하여 m1 컨테이너 생성

 

wordpress 이미지를 사용하여 컨테이너 생성 시 필요한 옵션 및 환경변수를 설정하여 wp 컨테이너 생성

 

컨테이너 동작 확인

 

DB 접속을 위해 MySQL-Client 설치 후, DB 접속

    - Wordpress와 연동 시 필요한 DB 생성(이름은 원하는대로 설정 후, 설정 파일 수정)

 

Wordpress와 DB연동을 위해 설정파일 수정

 

wp-config.php 수정 확인

    - cat으로 확인

 

포트포워딩한 포트로 접속을 위해 보안 그룹에 포트 추가

 

Wordpress 접속 확인

 

Wordpress 접속 확인

 

Wordpress에서 새로운 사용자 추가

 

사용자 추가된 것 확인

 

wordpress DB에서 확인

 

 

   VPC   

 

   VPC 정리   

 - VPC가 다르면 통신 x
    - 피어링 연결을 하면 다른 VPC와도 연결가능(다른 리전과도 가능)

 - VPC는 리전별로 5개가 최대

    - 기본적으로 Default VPC 쓰는 중이다

 

   VPC 생성   

 

구성도

    - 제일 유명한 3Tier 구성이다

    - DB는 관리형 서비스 이용
        - 개입할 필요가 X, 모든 유지보수를 AWS에서 담당
        - DB 인스턴스에 접속불가 오로지 쓰기만
        - 서버에는 접속불가 서버에서 돌아가는 애플리케이션에만 접속 가능
            - DB, Router53

 

서비스 검색창에서 VPC 검색

 

원래 존재하던 Default VPC 삭제

 

VPC 생성

 

VPC 생성

    - VPC는 prefix 16까지 지원한다

    - 테넌시 : 누군가 공유하거나 나혼자 쓰거나
        - 적용되면 리소스를 나혼자 쓰는거라 비용이 올라간다

 

태그 따로 설정없이 VPC 생성 진행

    - 태그 : 특정역할끼리 묶을 수 있음
        - 흩어져있는 리소스를 모을 수 있음(그룹핑 작업)
            - 역할별, 웹서버끼리

 

   서브넷 생성   

 - 가용영역 A에 홀수 IP, 가용영역 B에 짝수 IP

 - 서브넷이 VP의 영역보다는 클 수가 없다

 

서브넷 생성 진행

 

생성한 VPC에 서브넷 생성을 진행

 

서울 리전에는 4개의 가용영역이 존재하는 것을 확인

 

가용영역 A 설정 후, IP 설정(짝수) 후 서브넷 생성

 

가용영역 C 설정 후, IP 설정(홀수) 후 서브넷 생성

 

가용영역 A 설정 후, IP 설정(짝수) 후 서브넷 생성

 

가용영역 C 설정 후, IP 설정(홀수) 후 서브넷 생성

 

가용영역 A 설정 후, IP 설정(짝수) 후 서브넷 생성

 

가용영역 C 설정 후, IP 설정(홀수) 후 서브넷 생성

 

서브넷 생성 확인

    - WAS : Web Application Server(미들웨어)

        - DB에서 정보를 불러오는 것

        - TOMCAT이 대표적

 

   인터넷 게이트웨이 생성   

 

인터넷 게이트웨이 생성

 

인터넷 게이트웨이 이름 지정 후 생성

 

 

VPC에 IGW 연결

 

   라우팅 테이블 편집 및 서브넷 연결   

 

VPC 생성하면 자동 생성되는 라우팅 테이블에 외부통신을 위해 IGW 추가

    - 네트워크 대역이 다를 때, Local 대역에 속하면 Local 간 통신하기 위해 라우팅

    - 네트워크 대역이 다를 때, Local 대역에 속하지 않으면 IGW를 통해 외부 통신을 위해 라우팅

 

외부로 나가기 위해 라우팅 테이블에 서브넷 연결

 

서브넷 연결 확인

 

DHCP 옵션 세트 자동 생성

    - dhcp 옵션 세트 : 내부망이 생성된애들 한테 알아서 ip 뿌린다는 것

 

   테스트   

 

가용영역 A에 인스턴스 생성

 

가용영역 C에 인스턴스 생성

 

생성 후, Elastic IP 할당

 

WEB_A 에서 외부통신 확인

 

WEB_C와 통신 및 내부 통신 확인

 

WAS_A 서브넷을 사용하여 인스턴스 생성

 

WAS_C 서브넷을 사용하여 인스턴스 생성

 

생성 확인

 

WEB_A에서 SSH를 통해 WAS_A 연결하여 외부 통신이 안되는 것을 확인

 

 

   생각 정리   

 - IGW가 없으면 Elastic IP를 붙일 수가 없다
 - 라우팅 테이블에 Anyware-IPv4를 넣어주는 이유는 외부로 나가기 위함
    - 0.0.0.0/0 을 라우팅 테이블에 추가해주지 않으면 Elastic IP 할당이 안되는 것을 확인
        - xShell과의 연동도 끊기는 것을 확인
        - 즉, 외부로 나가기 위해서는 Elastic IP가 필요
 - 그렇다면 라우팅에 서브넷 연결(명시적 연결)을 해주는 이유는?
    - 만들었던 6개의 서브넷은 기본적으로 Default Routing table에 연결되어 있는 상태
        - 명시적 연결이 없는 서브넷의 설명을 보면 기본 라우팅 테이블에 연결 상태로 되어있다
            - 즉, Default Routing table의 경우 굳이 명시적 연결을 붙이지 않아도

               Elastic IP할당이 가능 및 xShell 접속(확인 완료)

            - Default Routing table이 아닌 새로운 Routing table을 생성하여 명시적 연결 테스트 완료
                - 결국 Default가 아닌 Routing table에서 명시적 연결을 통해 해당 서브넷이

                   외부와 통신할 수 있게 해주는 용도로 사용하는 것