이미지를 통해 EC2를 생성하고, 서비스를 제공하기 위해 추가적인 설정이 필요하다.

 

이 경우에 EC2 인스턴스 OS에 직접 붙어야하는데 크게 3가지의 방법이 있다.

 

- AWS Console Manager에서 다이렉트로 연결
- Key를 사용한 SSH 통신
- AWS Session Manager 설정

 

ㅁ 콘솔 매니저를 통한 다이렉트 접근

 

인스턴스 클릭 후, 직접 연결을 통해 붙을 수 있다.

 

외부에서 접근할 수 있는 Public IP 및 OS User 정보가 필요하다.

 

※ Linux : ec2-user / Ubuntu - ubuntu

 

※ Private Subnet에 존재하는 EC2는 Public IP가 존재하지 않기때문에, AWS 콘솔 매니저에서 붙을 수 없다.

 


 

ㅁ Key를 통한 EC2 인스턴스 접근

 

AWS 콘솔을 통한 접근은 편리하지만

Public IP가 없는 Private IP 접근이 어렵고, 로컬 PC기반에서 파일 전송 등의 작업이 안된다.

 

그래서 Key 인증기반으로 원격접속을 수행하려한다.

공개 - 개인 키 인증방식으로 개인키만 가지고있으면 어디서든 접근이 가능하다.

※ 그래서 키 관리에 더욱 주의해야한다.

 

AWS Key Pair 인증방식이란?

더보기

EC2 인스턴스에 존재하는 공개키와, 개별로 발급 된 개인키를 조합하여 복호화를 진행하는 방식

Host에 공개키가 존재하고 발급받은 개인키를 통해 접속한다.

 

1. Public Subnet 에 있는 WEB 서버에 Key로 접속하기

2. WEB 서버를 Bastion Host (경유 호스트)로 두어, Public Subnet을 통한 Prviate Subnet 접근

 

- Public Subnet 에 있는 WEB 서버에 Key로 접속하기

 

- 먼저, WEB서버 연결을 위한 Key를 발급받는다

- 인스턴스 생성 시, 해당 Key를 매칭해준다.

- PuttyGen을 통해, Public Key를 Private로 변환

- Putty 접속시 해당 Key를 SSH-Auth-authentication에 등록

 


 

ㅁ SSM (Systems Manager)를 통한 Session Manager로 접근

 

인스턴스가 재시작될때마다 Public IP를 새로 받기에, 매번 방화벽을 뚫어주기는 힘들다.
그렇다고 EIP를 받아쓰기엔, 비용적인 부담이 있어 Session 매니저를 사용해보려한다.

[ 장점 ]
1. 키 페어가 따로 필요없다.
2. Bastion Host (경유서버)가 따로 필요 없다.
3. IAM 롤을 통해, 일부 사용자에게만 접속권한 부여가능
4. 443으로 나가는 포트만 뚫려있으면, 특별한 설정이 필요없고 바로 붙을 수 있다.

[ 단계 ]
1. SSM agent 설치 
2. 해당 인스턴스의 443 Outbound 추가. ( SSM이 443 통신임 )
   - 기본적으로 Outbound에 대해선 막혀있지 않을것임
3. IAM에 session manager 역할 생성 ( AmazonEC2RoleforSSM )
4. 인스턴스에 해당 역할 매핑

- WEB ( Public Subnet )





- WAS ( Private Subnet )


인바운드 정책없이 연결 및 Outbound 인터넷 통신 확인

'IT > AWS' 카테고리의 다른 글

(6) 서비스 흐름도 정리  (1) 2021.11.10
(5) EC2 시스템간 연결  (0) 2021.11.08
(3) EC2 / WEB-WAS-DB 세팅  (0) 2021.11.05
(2) 인터넷 게이트웨이 및 라우팅 테이블 설정  (0) 2021.11.03
(1) VPC , 서브넷 및 EC2 생성  (0) 2021.11.03

지난장에서 인터넷 통신이 되는 Public 인스턴스를 만들었다.

 

해당 인스턴스에 Nginx를 설치하여 WEB 서버로 사용하고,

WAS와 DB를 구성하여 연결해보자.

 


1) WEB EC2 구성

 

ㅁ nginx 설치 및 구동

 

sudo apt install nginx
sudo service nginx start

2) WAS용 인스턴스 추가

 

해당 인스턴스는 실제 로직과 데이터가 담겨있기때문에, Private Subnet에 생성해야한다.

 

ㅁ 인스턴스 생성

 

Public과 동일하지만 Subnet 부분과 보안설정은 변경한다

 

- Subnet : Private

- 보안그룹 : SSH 및 서비스 통신은 WEB서버를 통해서만 받도록 설정

 

ㅁ NAT 게이트웨이 생성

 

Private Subnet에 있는 WAS나 DB의 경우

외부에서 접근은 불가능하더라도, 인터넷 사용이 필요한 경우가 있다. ( apt-get , curl 등 )

 

해당 경우에는 NAT 게이트웨이를 두어, Public subnet 망을 통해서 나갈수 있게 설정해준다.

 

- 연결유형을 Public으로 두어, 인터넷에 연결 ( Inbound는 차단 )

- EIP (탄력적 IP)를 부여해, 해당 IP로 외부에 통신함.

 

 

ㅁ Private 전용 라우팅 테이블 생성 및 연결

 

Public Subnet의 라우팅 테이블은

10.0.0.0/24 (VPC 내 통신)은 local로 설정되어있어, VPC 내부에서 찾는다.

 

Private Subnet은 VPC 내부 통신외에, 나가는 요청만 NAT 게이트웨이를 통하므로

라우팅 테이블을 따로 만들어서 할당해야한다.

 

 

- local 통신은 동일하게 두고, 인터넷 통신은 public subnet에 있는 NAT 게이트웨이로 통신한다.

 

 


 

ㅁ WAS 인스턴스 환경 구성

 

- 파이썬 및 Flask 설치

※ Flask : Rest api 구성을 위한 Micro web framework

sudo apt-get update
sudo apt install python3
sudo apt-get install python3-pip
sudo pip3 install Flask

 

-python 파일 작성 후 구동 테스트

 

rest.py

더보기

from flask import Flask  
from flask_restx import Api, Resource 

app = Flask(__name__)  
api = Api(app)  


@api.route('/api/users')  # /api/user 에 클래스 매핑
class HelloWorld(Resource):
    def get(self):  
        return {"id": 123,
        "name": "kim"}

if __name__ == "__main__":
    app.run(debug=True, host='0.0.0.0', port=82)

 

- 에러 발생

 

restx 모듈을 못찾았다. 

해당 모듈 설치 후 재실행

sudo pip3 install flask_restx

 

- 구동완료


 

3) DB용 인스턴스 구성

 

 

ㅁ PostgreSQL 설치

 

sudo apt-get update
sudo apt install postgresql 

 

ㅁ DB 접근제어 허용

 

PostgreSQL는 기본적으로 접근허용이 막혀있다.

Listen Address에 *를 넣어 접근가능하게 변경해주자 ( 재시작 필요 )

sudo vi /etc/postgresql/12/main/postgresql.conf

 

 

sudo vi /etc/postgresql/12/main/pg_hba.conf

 

 

ㅁ 데이터 베이스 생성

 

- DBMS 접속

 

sudo su postgres
psql
CREATE DATABASE "USER"; // USER 데이터베이스 생성

 

- USER 생성 및 권한부여

 

CREATE USER test WITH PASSWORD 'a123456789';
ALTER USER test WITH SUPERUSER;
ALTER USER test WITH LOGIN;

 

- 해당 유저로 접속 및 Sample 데이터 생성

 

psql -U test -d USER // test유저로 USER 데이터베이스 접근
CREATE table user_info( id int NOT NULL, name char(20) DEFAULT NULL, PRIMARY KEY (id) );
INSERT INTO user_info VALUES(1234,'kim');
INSERT INTO user_info VALUES(123,'Lee');
commit;

 

※ psql: error: FATAL:  Peer authentication failed for user "test" 에러 발생

 

더보기

검색해보니 local 통신 방식에서 perr를 md5로 바꿔주라고 함

 

sudo vi /etc/postgresql/12/main/pg_hba.conf

 

검색해보니 local 통신 방식에서 perr를 md5로 바꿔주라고 함

 

sudo vi /etc/postgresql/12/main/pg_hba.conf

 

 

'IT > AWS' 카테고리의 다른 글

(5) EC2 시스템간 연결  (0) 2021.11.08
(4) EC2 원격 접속 ( 작성중 )  (0) 2021.11.07
(2) 인터넷 게이트웨이 및 라우팅 테이블 설정  (0) 2021.11.03
(1) VPC , 서브넷 및 EC2 생성  (0) 2021.11.03
(0) AWS 학습 로드맵  (0) 2021.10.22

앞선 장에서 클라우드 망 구성 및 EC2 인스턴스를 생성해보았다.

 

하지만 해당 인스턴스를 세팅하기위해 접속시도하면, 접속이 되지 않고 네트워크 세팅을 확인하라는 경고가 나온다.

외부 환경에서 VPC로 접근할때 연결해줄 인터넷 게이트웨이가 없어서 그런 것 같다.

 


ㅁ 인터넷 게이트웨이

 

인터넷과 VPC를 연결해주는 게이트웨이

 

크게 2가지 목적으로 사용된다.

1. VPC 라우팅 테이블에 목적지 추가
2. 퍼블릭 IPv4 주소를 할당된 인스턴스로 NAT(네트워크 주소변환) 수행

 

1) VPC 라우팅 테이블에 목적지 추가

 

- VPC 안에 존재한 라우팅 테이블에, 인터넷과 연결할수 있게 경로를 설정해준다.

 

 

2) 퍼블릭 IPv4 주소를 할당된 인스턴스로 NAT(네트워크 주소변환) 수행

 

- 인스턴스 정보를 살펴보면 아래와 같다.

외부에서 접근가능한 IP는 3.38.94.10 이지만, VPC를 구성할때 10.0.0.0/24 네트워크로 구성했다.

퍼블릭 서브넷은 10.0.0.0/25로 할당했으므로, 인스턴스의 호스트IP 범위는 10.0.0.0 ~ 10.0.0.127 이다.

 

3.38.94.10와 매핑되는 VPC 안의 인스턴스주소는, 프라이빗 IPv4주소인 10.0.0.82 이다.

그래서 3.38.94.10으로 접근한 트래픽에 대해, 10.0.0.82로 접근할수 있도록 해주어야한다.

이때 인터넷 게이트웨이가 NAT(네트워크 주소 변환)을 수행한다.

 


ㅁ 라우팅 테이블

 

다른 네트워크끼리 통신할때는 라우터를 통해야한다.

라우팅 테이블에는 목적지에 대한 노선이 담겨있으며, 라우터는 이를 참조해 통신한다.

 

기본적으로 VPC 內 통신에 대해, 라우팅 테이블이 적용되어있다.

 

 

VPC ( 10.0.0.0/24 )에 대한 통신은, 로컬 라우팅을 통해 VPC 내에서 목적지를 찾는다.

 

 

그렇다면, 인터넷 통신은 어떻게 연결할까?

 

인터넷에 대한 통신을 ( 0.0.0.0 ) , 위에 만들어놓은 인터넷 게이트웨이에 연결해주자.

 

 

이후 해당 라우팅 테이블에 Public Subnet을 연결해주면

인터넷 - 인터넷게이트웨이 - 퍼블릭 서브넷 통신이 가능해진다.


인터넷에서 Public Subnet에 생성된 인스턴스로 연결까지 마쳤으니, 한번 접속해보자

 

콘솔을 통해 임시 연결하였으며, 기존의 발급받은 Key를 통해 원격접속도 가능하다.

 

'IT > AWS' 카테고리의 다른 글

(5) EC2 시스템간 연결  (0) 2021.11.08
(4) EC2 원격 접속 ( 작성중 )  (0) 2021.11.07
(3) EC2 / WEB-WAS-DB 세팅  (0) 2021.11.05
(1) VPC , 서브넷 및 EC2 생성  (0) 2021.11.03
(0) AWS 학습 로드맵  (0) 2021.10.22

이번장에서는 간단한 시스템 구현을 통해

 

AWS에서 제공하는 서비스와 흐름에 대해 알아보려한다.


0) 비용정책 설정

 

AWS 요금에 대해 조금만 검색하다보면 요금폭탄으로 인한 고민글들이 많다.

 

계정생성후 제공되는 프리티어 사용 예정이라 큰 요금이 지출되지는 않겠지만

DDOS 공격이나, 미사용 인스턴스로 인한 지속적 트래픽, Key 유출로 인한 사례 등 위험에 노출되어있다.

 

따라서 가장먼저 비용정책 설정을 통해 사전감지 및 제한을 걸어두려한다.

 

 

ㅁ Billing Console에서 예산 설정

 

- 월 / 30$ : 학습용 시스템으로, 일 트랜잭션이 100회를 넘지않을 것이다.

- 알림 설정 : 25$에 알림 임계치를 걸어, 사전에 인지

                 추후 대량 트래픽 시스템이나, 부하테스트시에는 예산 및 알림설정 변경 예정

 

 

※ 악의적인 트래픽에 의한, 요금폭탄을 방지하기 위해 아래의 사항을 명심하자

 

ㅁ Key 발급 주의

 - 상당수가 Key 유출로 인해, 요금폭탄을 맞는다.

   Git에 소스를 올릴때 자기도 모르게 함께 올리거나 문의글, 블로그 작성중에 노출되기도 한다.

 

 - 이를 방지하기 위해, Key 사용시에는 IAM을 통하여

   Root , 사용자 키를 나눠서 사용해야하고 Key 관리에 신경써야할 것이다.

 

ㅁ AWS 콘솔 계정관리

 

 

1) 설계

 

EC2 생성에 앞서, 어떤 아키텍쳐로 구성할지 그려보자

 

 

- 리젼 : 해외에서 접속하는 트래픽도 없고, 학습용으로 만드는 시스템. 서울로 지정

- VPC 및 서브넷 : 가상의 클라우드망을 만든 후

                       유저가 접근할 수 있는 Public 서브넷에 웹서버를 두고 인터넷 게이트웨이를 연결한다.

                       WEB으로 온 리퀘스트는 Private 서브넷으로 전달하기 위해

                       Route Table 을 연결하고, WEB에서만 요청을 받기위해 보안그룹 설정을 해둔다.

 

 

2) VPC 생성

 

EC2 및 서브넷들이 포함될 가상의 클라우드 망을 만들어보자.

 

IP 대역대는 기본으로 추천해주는 10.0.0.0/24를 설정했으며

/24의 의미는 앞의 24비트, 즉 10.0.0 까지는 네트워크 주소로 나머지 비트는 호스트 주소로 사용한다는 뜻이다.

ex) 10.0.0.0 = 10.0.0 네트워크의 첫번째 호스트 주소

 

결국 10.0.0.0 ~ 10.0.0.255 범위의 호스트 총 256개를 사용한다는 의미이다.

 

 

3) 서브넷 생성

 

클라우드 망을 만들었으니, 유저에게 공개될 Public 서브넷과 Private 서브넷으로 나눈다. 

 

서브넷(Subnet)은 말 그대로 분할된 작은 네트워크를 의미하며

기존의 네트워크에서 좀더 적절한 단위로 조절한 것이다.

 

우리는 10.0.0.0 ~ 10.0.0.255 를 사용할 수 있으므로 절반으로 서브넷을 나눌 것 이다.

 

Public : 10.0.0.0 ~ 10.0.0.127 
Private : 10.0.0.128 ~ 10.0.0.255

 

절반이므로 기존 /24에서 1비트를 더 사용한 /25가 될 것이다.

 

Public : 10.0.0.0/25
Private : 10.0.0.128/25

 

/25인 이유

더보기

먼저 10.0.0.0을 비트로 표현해보자면

 

0000 1010 / 0000 0000 / 0000 0000 / 0000 0000 가 될것이다.

 

VPC 구성시 /24로 앞에 24비트까지는 네트워크 주소로 사용하기로 했으니

 

호스트 주소는 아래와 같이 사용할 수 있다.

0000 1010 / 0000 0000 / 0000 0000 / 0000 0000

~ 0000 1010 / 0000 0000 / 0000 0000 / 1111 1111

 

서브넷은 기존 /24에서 2개로 나누기로 했기 때문에, 그 구분자는 25번째 비트가 될 것이다.

 

[Ex]

Public : 0000 1010 / 0000 0000 / 0000 0000 / 0000 0000 ~ 0000 1010/ 0000 0000 / 0000 0000/ 0111 1111

- 25번째 비트가 0이면 Public 서브넷 ( 10.0.0.0 ~ 10.0.0.127 )

 

Private: 0000 1010 / 0000 0000 / 0000 0000 / 1000 0000 ~ 0000 1010/ 0000 0000 / 0000 0000/ 1111 1111

- 25번째 비트가 1이면 Private 서브넷 ( 10.0.0.128 ~ 10.0.0.255 )

 

즉 네트워크 구분자 24bit까지 + 서브넷 구분자 1bit를 통하여 /25가 되는것이다.

Public 서브넷에는 Public IP가 할당될수 있도록, 자동 IP 할당설정을 체크해준다.

 

위의 VPC에 할당된 서브넷 2개를 만들었다. 현재까지는 아래와 같다.

 

 

4) EC2 생성

 

이제 실제로 서비스가 구동될 EC2 인스턴스를 만들어보자.

 

우리는 3개의 인스턴스가 필요하다. 1) Nginx , 2) Python [Rest-Api] , 3) PostgreSQL 

 

 

ㅁ 이미지 선택

 

인스턴스를 시작할때 기본으로 사용될 운영체제, 어플리케이션 등이 포함된 이미지를 선택해야한다.

 

도커 이미지처럼 남들이 만들어놓은 것을 사용하면 편하겠지만, 비용이 발생한다. 직접 만들자..

 

 

Ubuntu 20.04 LTS 버전을 사용하였다.

 

 

ㅁ 인스턴스 유형 선택

 

사용할 수 있는 CPU, 메모리, 스토리지 및 네트워킹 용량에 따라 다양한 유형으로 나뉜다.

 

사용 목적에 따라 그룹이 나뉘며 ( t2, c2, p2, r2 )

세대가 높을수록 최적화가 더 잘되어있다고 한다.

 

나는 프리티어여서 선택의 여지없이, t2.micro로 선택하였다.

 

 

 

ㅁ 인스턴스 세부정보 구성

 

해당 인스턴스의 정보를 설정한다.

 

여러 항목이 있지만 아래 내용만 확인하고 넘어갔다.

- 인스턴스 개수 1 ( Auto Scaling 은 다음장에서 진행 )

- 네트워크 ( 위의 VPC )

- 서브넷 ( 유저가 접속하는 Nignx 용도이므로, Public Subnet으로 할당 )

 

 

ㅁ 스토리지 추가

 

기본적으로 루트 디렉토리가 포함되어있어, 특별한 추가는 하지않았다.

 

스토리지에는 다양한 종류가 있는데

 

※ 이미지에 따라 EBS와 인스턴스 스토어를 지원하는데
   인스턴스 스토어를 루트 디렉토리를 사용 시, 인스턴스 종료에 따라 초기화.

 

- EBS ( Block Storage ) : 블록단위의 스토리지. 

- 인스턴스 스토어 : 물리적 디스크로부터 임시로 스토리지를 할당받음.

                         인스턴스 종료시에 해당 스토리지가 회수되므로 데이터를 보존할 수 없다.

- EFS ( File Storage ) : EC2용 파일 스토리지. On-Promise 환경에서 Mount 된 NAS 디스크와 같다고 보면된다.

                             클라우드 환경답게, 사용한 만큼만 용량이 유지된다.

 

- S3 ( Simple Storage Service ) : 객체 저장 스토리지. 다양한 종류에 객체를 저장할 수 있고, 웹에서도 접근이 가능하다.

                                           Buckets + Key + version 조합으로 접근한다.

 

 

ㅁ 태그 - Pass

 

 

ㅁ 보안그룹

 

방화벽 규칙을 어떻게 적용할지에 대한 내용이다.  기본적으로 모든 Inbound 방화벽은 막혀있으며, Out bound는 열려있다.

 

콘솔에서 OS로 원격접속할 SSH포트 (22) 및 유저가 웹을 통해 접근할수 있도록 HTTP포트 (80)을 열어주었다.

 

ㅁ 검토

 

모든 단계를 마치니, AWS에서 경고메세지를 주었다.

 

해당 인스턴스에 모든 호스트에서 접근가능하다는 내용이었다.

 

WEB서버는 인터넷망에 오픈이므로 냅두고, 인스턴스 원격접속만 내 IP로 지정해주었다.

 

ㅁ 키 생성

 

SSH 설정을 하였더니, 키를 생성하라는 문구가 나왔다.

 

기존의 Public-Private 키페어 방식이며

 

키 관리에 자신이 없어 비밀번호로 로그인 할 예정이다.

 

=> AMI 즉 이미지의 비밀번호를 알아야한다.. 그냥 키쓰자

 

     생성된 키를 Putty Key Generator를 통해 불러오고, private key로 다시 저장한다.

 

      해당 키를 사용하여 보안접속을 한다

 

'IT > AWS' 카테고리의 다른 글

(5) EC2 시스템간 연결  (0) 2021.11.08
(4) EC2 원격 접속 ( 작성중 )  (0) 2021.11.07
(3) EC2 / WEB-WAS-DB 세팅  (0) 2021.11.05
(2) 인터넷 게이트웨이 및 라우팅 테이블 설정  (0) 2021.11.03
(0) AWS 학습 로드맵  (0) 2021.10.22

AWS 시스템을 구축하기에 앞서, 3가지 서비스에 대한 개념을 이해해야한다.

- Network (VPC)
- 클라우트 컴퓨팅 (EC2)
- 엑세스 관리 (IAM)

 

ㅁ VPC

 

클라우드의 가상 네트워크 환경.

 

IP , 라우팅, 게이트웨이 및 보안설정 등을 담당하며, 리전 내에 위치한다.

※ 리전 : 서비스를 제공하는 데이터센터들이 모여있는 위치

 

리전 내에 위치하나, 가용영역 (AZ) 기준으로 구분하여 여러개의 VPC를 가질 수 있다.

※ 가용영역 : 리전내에 물리적으로 격리되어 있는 데이터센터

 

 

ㅁ EC2

 

AWS에서 제공하는 독립된 클라우드 컴퓨터 서비스.

 

아마존 머신 이미지 (AMI) 기반으로 인스턴스를 쉽게 생성할 수 있으며,

CPU, 메모리, 스토리지, 네트워크 등의 리소스 사용 목적에 따라 최적화된 인스턴스를 제공한다.

 

인스턴스 스토어위에서 올라가기 때문에, 종료시 데이터가 사라진다.

저장이 필요한 파일은 EBS에 두고, S3 버킷에 정적 컨텐츠나 로그를 두는 것이 일반적이다.

 

 

ㅁ IAM

 

리소스를 제어할 수 있는 엑세스 권한을 중앙에서 관리하는 서비스

 


AWS 시스템을 이해하기 위해, 아래와 같은 시나리오로 공부하려한다.

 

시나리오 1. WEB - WAS - DB 3티어 시스템 구성해보기

기존에 도커를 공부하며 구성해두었던, API 서버 아키텍쳐를 그대로 사용하려한다.

( WEB - 리퀘스트를 WAS 서버로  포트포워딩 / WAS - API 서버 / DB - 업무 데이터 저장 )

 

예상되는 작업 순서는 아래와 같고, 4/5/6 단계는 시나리오 2에서 진행하려 한다.

 

1. 리전을 선택하고
2. VPC 생성
3. 퍼블릭 / 프라이빗 서브넷 결정
  + 퍼블릭 : 주로 웹서버로 인터넷에 연결 필요
  + 프라이빗 : 백단 소스, DB 등. 보안그룹 설정필요
4. ELB를 통해 로드밸런싱
5. Auto Scaling 설정 ( Scale up / Sacle out ) 
  + Scale Up은 지원 안하는가?
6. Route 53을 통해 도메인 서비스 제공가능.
7. 비용처리 정책
8. 로깅 정책 -> S3로 저장
9. 백업 정책 -> EBS ( 부팅 및 데이터 볼륨 ) , 스냅샷은 S3에 저장

 

※ WEB은 Public Subnet, WAS/DB 는 Private Subnet에 두고

   사용자 및 각 인스턴스 간 커넥션을 어떻게 연결할 것인지 생각해보며 진행할 것

 

 

시나리오 2. 고가용성 설정 및 부하 테스트, 로그 확인

 

시나리오 1에서 구성한 시스템에 고가용성 및 서비스를 위한 설정들을 추가할 예정이다.

- ELB : 트래픽 분산
- Auto Scaling : 시스템 부하 시, 서버를 추가하여 서비스 안정화
- Route 53 : DNS 등록

 

설정 추가 후, 부하테스트를 통해 작동여부를 확인하고 AWS Cloud Watch 를 사용해보고자 한다.

 

 

시나리오 3. Iac ( Infrastructure As Code ) 적용

Iac : 코드를 통해 인프라 환경 구성 및 관리 자동화를 수행

      환경 구성 간편화 및 개발/운영간 환경의 일관성이 유지된다.

 

대표적인 툴로는 AWS CloudFormation, Terraform, Ansible 등이 존재하는데

한번씩 사용해보고 차이점을 서술할 예정이다.

 

'IT > AWS' 카테고리의 다른 글

(5) EC2 시스템간 연결  (0) 2021.11.08
(4) EC2 원격 접속 ( 작성중 )  (0) 2021.11.07
(3) EC2 / WEB-WAS-DB 세팅  (0) 2021.11.05
(2) 인터넷 게이트웨이 및 라우팅 테이블 설정  (0) 2021.11.03
(1) VPC , 서브넷 및 EC2 생성  (0) 2021.11.03

Oracle VM 설치

 

Oracle 사이트에서 Virtual Machine 최신버전을 받는다.

https://www.oracle.com/kr/virtualization/technologies/vm/downloads/virtualbox-downloads.html?source=:ow:o:p:nav:mmddyyVirtualBoxHero_kr&intcmp=:ow:o:p:nav:mmddyyVirtualBoxHero_kr

 


Ubuntu server 이미지 받기

 

https://ubuntu.com/download

- 컨트롤러 IDE에 Ubuntu 이미지 지정

 


Proxy 설정

 

Proxy 문제로 외부 인터넷 연결이 안됌

 

   -> /etc/apt/apt.conf.d 밑에 아무파일이나 만들고 하기 내용 입력

Acquire::http::proxy "http://proxy.server:port/";
Acquire::https::proxy "http://proxy.server:port/";

 

참고 ( https://wlsvud84.tistory.com/26 )

 


Geust Addition 설치

 

VM 호스트 서버와 게스트 서버간에

클립보드 및 복사 붙여넣기 기능을 활성화 하였으나, 작동하지 않음

 

구글링에 Geust Addition 설치해보라는 글 발견하여 설치

 

다운로드 - ( Oracle VM ftp Arcive : http://download.virtualbox.org/virtualbox/ )

 


apt-get 다운로드 서버 변경

 

프록시 연결하여도, 프록시망에서 모든 URL 방화벽이 오픈된게 아니기 때문에

 

가끔 ubuntu 아카이브 서버까지 접근해야하는경우 연결이 안된다.

 

속도 이슈도 있고, 카카오 미러페이지로 다운로드 서버를 변경하자

 

vi /etc/apt/sources.list 內 URL 변경

=> :%s/kr.archive.ubuntu.com/mirror.kakao.com/g 을 통해 전부 치환가능

 


인증서 설정

 

ㅁ 인증서를 구한다음에 openssl을 통해 crt 확장자로 바꿔준다.

openssl x509 -in ABC.pem -inform pem -out ABC.crt

 

ㅁ /usr/share/ca-certificates/extra 디렉토리 생성후, 변환된 crt 인증서 이동

 

ㅁ 인증서 패키지 reconfig후 해당 인증서 추가.

sudo dpkg-reconfigure ca-certificates 

'IT > 서버 구성해보기' 카테고리의 다른 글

로컬서버 (2) WAS - DB 연결  (1) 2021.04.23
로컬서버 (1) 환경 설정  (0) 2021.04.23

내가 생각하는 쿠버네티스. 줄여서 k8s라 부르는 용어에 대한 정의는 아래와 같다.

 

컨테이너 관리를 위한 오픈소스 플랫폼 

 

좀더 다양한 해석이 있을 수 있지만,

아직 아무것도 모르는 단계에서 '컨테이너 관리' 에 집중하려 한다.

 


기능

 

쿠버네티스 공식문서에 따르면, 기능은 아래와 같다.

 

  • 서비스 디스커버리 ( 서비스에 매핑된 IP와 클래스를 찾아줌 )
  • 로드 밸런싱 ( 컨테이너에 대한 트래픽을 분산 )
  • 오케스트레이션 ( 스토리지 , 네트워킹 등 리소스에 대한 관리 )
  • Roll Out & Roll back ( 자동 배포 및 특정버전 롤백기능 )
  • bin 패키징 ( 필요한 컨테이너 리소스를 효율적으로 부여 )
  • 셀프 힐링 ( 기능 체크를 통한 정상여부 확인 및 Fail된 컨테이너에 대해 자동으로 재시작 )
  • 보안 ( 토큰 및 SSH 키 등의 관리 )

 

 

구성요소

 

공식 문서상 아키텍처는 아래 그림과 같다.

 

https://kubernetes.io/ko/docs/concepts/overview/components/

 

봐도 모르는 상태라 

 

먼저 구성요소들에 대해 정리하고, 흐름을 하나씩 파악해보려한다.

 

1) Pod

 

쿠버네티스에서 배포를 하는 최소단위. 하나 이상의 컨테이너를 포함한다.

 

이전 도커에서는, 컨테이너 단위로 배포를 했었으나 쿠버네티스에는 스토리지 및 네트워크가 포함된다.

=> IP:Port 및 디스크 볼륨 공유가능

 

물론 여러개의 컨테이너도 포함될 수 있으며, 배포 시 Pod 단위로 넘어간다

 

https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

 

 

2) Node

 

이러한 하나 이상의 Pod들이 모여, 노드를 구성한다.

 

노드는 Pod가 배포되고 수행되는 최소한의 하드웨어 단위이며,

 

물리적 혹은 가상화된 개별 머신으로 생각하면 된다.

 

아래 아키텍처를 확인해보면 노드에 Kubelet과 k-proxy가 붙어있다.

 

이에 대해 확인해보자.

 

 

2-1 kubelet

 

위 그림상, Control Plane ( Master Node )와 통신하며 작업을 관리하는 에이전트이다.

 

2-1 kube-proxy

 

iptable 관리 및 네트워크 분산이라고 나와있으나

 

간단하게 Control Plane ( Master Node )와 통신 자체를 담당하는 네트워크 관리 담당이다.

 

 

 

3) Control Plane

 

Master Node라고도 불리며, 클러스터에 대한 관리를 담당함. 이벤트 감지 및 처리, 스케쥴링 등을 수행한다.

 

 

3-1 API Server

 

사용자가 접근할수 있도록, HTTP / REST 등의 API를 제공하며

 

컨트롤 플레인 內 컴포넌트나 Node와 통신하며 요청을 수행함.

 

 

3-2 etcd

 

고가용성 데이터 저장소.

 

key - value 형식이며, 클러스터에 대한 정보등을 저장한다.

 

( ex: Pod 생성시 정보 기록 . 실행 Node , 상태값 등 )

 

https://www.kangwoo.kr/2020/09/05/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EC%9D%98-etcd-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0/

 

3-2 Scheduler

 

새로 생성된 Pod를 감지하고, 어느 Node에 부여할지 결정

 

3-3 Kube Controller Manager

 

클러스터 內 오브젝트를 관리 ( 노드, 레플리카 셋, 서비스 등 )

 

 

 

※ Cloud Controller Manager ( c-c-m )

 

AWS, Azure 등 클라우드에 특화된 모듈로,

 

쿠버네티스 컨트롤러들을 클라우드에서 관리할 수 있게 연결해준다.

 

로컬환경에서 VDI로 구성할거라, 자세히는 다루지 않을 예정

 


 

 

정리

 

 

사용자가 Pod를 만드는 상황을 통해, 흐름을 정리해보려 한다.

 

1) API 서버로 Pod 생성 요청

 

 

2) API 서버에서 etcd로, 요청된 Pod 의 Manifest 입력

 

3) API 서버에서 컨트롤러 매니저에 Pod 생성 요청

 

생성된 Pod는 다시 API Server로 전달되고, 이 Pod 정보를 다시 etcd에 입력

 

4. API 서버에서 스케쥴러에 Pod 할당 요청

 

스케쥴러는 할당 가능한 Worker Node를 회신하고, API 서버는 etcd에 입력

 

 

5) 할당받은 Node에 Pod 생성 요청

 

Kube Proxy를 통해 네트워크 통신을 하고, Kubelet 에서 Node에 Pod를 띄운다.

 

Kubelet은 Pod 상태를 주기적으로 회신하고, API Server는 etcd에 기록한다.

 

 

이번에는 유저 요청에따라 동적으로 데이터를 리턴해주려고한다.

 

이를 위해, DBMS를 설치해 데이터를 저장하고, 조건에 맞는 Value 값을 찾아서 회신할 것이다.


1) My sql 설치

sudo apt-get update
sudo apt-get install mysql-server

 

※ 방화벽 설정이 되어있다면, Mysql 포트를 열어주어야 한다. ( 3306 )

 

sudo ufw allow mysql

 

ㅁ 실행 및 DBMS 접속

 

service mysql service
mysql -u root -p

 

ㅁ 데이터베이스 및 유저생성

 

Mysql> CREATE DATABASE USER;
Mysql> CREATE USER 'pyadm'@'localhost' IDENTIFIED BY 'password';

 

ㅁ 권한 부여 및 확인

 

Mysql> GRANT ALL PRIVILEGES ON USER.* to pyadm@localhost;
Mysql> grant all privileges on *.* to 'pyadm'@'localhost';
root> mysql -u pyadm -ppassword

 

2) 데이터 구성

 

ㅁ ID를 KEY 값으로, 이름을 필드로 갖는 user_info 테이블 생성

CREATE table user_info( id int(10) NOT NULL, name char(20) DEFAULT NULL, PRIMARY KEY (id) );

 

ㅁ 테스트 데이터 입력

 

INSERT INTO user_info VALUES(1234,'kim');
INSERT INTO user_info VALUES(123,'Lee');
commit;

 

3) Python - Mysql 연결

 

pip3 iinstall --proxy [proxy_ip] --trusted-host pypi.python.org --trusted-host files.pythonhosted.org --trusted-host pypi.org PyMysql

 

ㅁ 테스트 코드 작성 ( 커넥터 설정 및 커서 )

 

import pymysql

user_db = pymysql.connect (
  user='pyadm',
  passwd='password',
  host='localhost',
  db='user',
)

cursor = user_db.cursor()
sql= " select * from user_info"

cursor.execute(sql)
print(cursor.fetchall())

 

4) request 에서 조건값 가져오기

 

http://localhost:80/api/users/1234

 

ㅁ Rest_api 서버 코드 수정

 

@api.route('/api/users/<int:id>')   -- id라는 변수를 만들어 int 값 저장
class HelloWorld(Resource):
  def get(self,id):  -- 멤버 변수 파라미터로 id 설정
    return {"id": id, -- id 변수값
              "name": "kim"}

 

 

5) 가져온 조건값을 DB에 입력하여, 리턴해주도록 수정

 

@api.route('/api/users/<int:id>')
class HelloWorld(Resource):
 def get(self,id):
    cursor = user_db.cursor()
    sql = " select * from user_info where id= " + str(id)
    cursor.execute(sql)
    data=cursor.fetchall()
    return {"id": data[0][0],
              "name": data[0][1]}

 

 

Nginx는 경량 웹 서버로, 가벼움과 높은 성능을 목표로 하는 웹서버이다.

 

주로 정적 웹페이지를 리턴하는 용도나 Reverse Proxy를 통해 로드밸런서로 사용한다.


특징으로는 Event-Driven 구조로 되어있어, Apache 웹서버에 비해 더 작은용량으로 운영이 가능하다.

 ※ Apache 웹서버는 1개의 클라이언트 요청 = 1개의 쓰레드로, 동기화방식.

 

Event-Driven 에서는, 요청을 Event Handler를 통해 이벤트를 발생시키고

 

비동기로 처리하여 다량의 요청을, 효율적으로 처리할 수 있다.

 


Reverse Proxy를 사용해서 아래 그림처럼 아키텍처를 구성해보려한다.

 

1) 기존 80포트로 열려있던 python api 서버를 82포트로 변경

2) Nginx 설치 및 Reverse Proxy 설정

apt-get update
apt-get install nginx

 

/etc/nginx/conf.d/default.conf 

 

server {
 listen 80; // 80포트로 리슨하고
 
 location /api/ { //api 리퀘스트 요청이 온다면
 proxy_pass http://localhost:82; // 파이썬 rest_api 서버로 포워딩
 }
}

3) Nginx reload 및 Python 가동 후 연결

 

nginx -s reload
python3 rest_api.py

=> Nginx 에서 해당 리퀘스트 처리 페이지를 찾지 못하였다.

  => 프로세스가 안떠있는가? ( X )

  => 컨테이너 포트오픈이 안되어있는가? ( X )

 

가정1) rest_api 컨테이너 포트오픈이 안되었다?

 

Nginx 까지는 도달하였으나, rest_api 컨테이너는 오픈이 안되어있어 도달하지 못했다.

=> 같은 컨테이너에 Nginx 와 Python을 띄운거라 네트워크 이슈는 아닌 것으로 예상

 

가정2) rest_api 포트 ( 82 ) 에 대해, 컨테이너 포드 포워딩이 안되어있다.

 

현재 Nginx 포트 ( 80 )은 -p 80:80 설정으로,

Localhost:80으로 오는 리퀘스트를 컨테이너 80포트로 자동 매핑해주고있다.

 

하지만 Rest_api 포트 ( 82 )에 대해서는 매핑되는게 없어

Nginx에서 Localhost:82로 포워딩 하면, 컨테이너의 IP:82와 연결이 되지 않아 발생하지 않을까?

 

현재 컨테이너 커밋후, 포트매핑 추가하여 가동해보자.

 

sudo docker run -it -p 80:80 -p 82:82 sk007001/rest_api:python /bin/bash

=> 똑같이 404 에러가 발생한다.

 

하지만 이번에는, localhost:82 포트로는 바로 rest_api 호출이 가능하다

 

가정3) Reverse Proxy가 제대로 동작하지 않는다.

 

프론트인 Nginx도 문제없고, 백단에 Python도 제대로 리슨중이니

 

중간을 연결해주는 Reverse Proxy가 문제있지 않을까?

 

일단 스택오버플로우에서, /etc/nginx/site-enabled 의 default 링크를 지워보라는 답변을 발견했다.

 

=> 지우고 접속해보니, 80 포트로 접속한 리퀘스트가 82로 포워딩 되는것을 확인했다.

==> 그렇다면, 파이썬에서 받았는데 404 에러가 발생하는 이유는???

 

가정4) Python Rest_api 코드의 문제

 

먼저 발견한 특이점은, Nginx에 localhost:80/api/users 로 보내어도

 

Reverse Proxy를 타면 localhost:82/api/users/ 로 리퀘스트가 보내진다는 것이었다.

 

파이썬 코드를 열어보니 /api/users 로 클래스 매핑이 되어있었고, 이를 수정해준뒤 제대로 리턴해주는것을 확인하였다.

 

 

+ Recent posts