OpenStack_(2) 환경 구성
MariaDB ~ KeyStone 배포 전

 

이번 작업은 컨트롤러 노드에서만 하면되고, 오픈스택 구성 시 설정하는 비밀번호는 쉽게 하기 위해서 그냥 openstack 으로 하겠습니다.

 

그전에 crudini 라는 ini 파일 수정할 때 사용하기 좋은 툴이 있는데요,, 설정파일 변경할 때 사용하니깐 좋더라구요. 

그래서 이번에도 깔아서 사용해봤습니다.

 

# Install crudini
yum install -y wget
wget https://github.com/pixelb/crudini/releases/download/0.9.3/crudini-0.9.3.tar.gz
tar xvf crudini-0.9.3.tar.gz
mv crudini-0.9.3/crudini /usr/bin/
pip3 install --user iniparse  
ln -s /usr/bin/python3 /usr/bin/python
rm -rf crudini-0.9.3 crudini-0.9.3.tar.gz

crudini를 사용하기 위해서 python이라는 명령어를 사용할 수 있어야 하는데, 만약 /usr/bin/python 라는 파일이 없다고 뜨면 심볼릭 링크를 설정해주면 됩니다!

 

사용법은 데이터베이스 설정 파일 사용할 떄 한번 보여 드리겠습니다.

 

 

 


 

# SQL 데이터베이스 설치 및 설정

- 대부분의 openstack 서비스들은 SQL 데이터베이스를 사용해서 정보를 저장한다.
- 보통 컨트롤러 노드에서 실행
- PostgreSQL을 포함하여 다른 SQL 데이터베이스 또한 지원 가능

yum install -y mariadb mariadb-server python3-PyMySQL

crudini --set /etc/my.cnf.d/openstack.cnf mysqld bind-address 10.177.13.30
crudini --set /etc/my.cnf.d/openstack.cnf mysqld default-storage-engine innodb
crudini --set /etc/my.cnf.d/openstack.cnf mysqld innodb_file_per_table on
crudini --set /etc/my.cnf.d/openstack.cnf mysqld max_connections 4096
crudini --set /etc/my.cnf.d/openstack.cnf mysqld collation-server utf8_general_ci
crudini --set /etc/my.cnf.d/openstack.cnf mysqld character-set-server utf8

cp /etc/my.cnf.d/openstack.cnf /etc/my.cnf.d/openstack.cnf.backup

systemctl restart mariadb.service
systemctl enable --now mariadb.service

mysql_secure_installation

 

crudini --set 이라는 명령어를 사용하면 아래와 같은 형식으로 설정 파일이 변경이 됩니다. 물론 vi 에디터를 사용하여 할 수도 있지만, 많은 설정을 해야할 때는 스크립트처럼 사용하면 유용하겠죠?

 

그리고 항상 설정파일은 백업을 해두셔야 좋습니다!

위 설정을 통해서 만들어진 설정파일입니다. 물론 오픈스택 메뉴얼에 다 나와있구요!

 

 

만약 데이터베이스 재시작이 안되면, selinux 때문일 수도 있으니, 재부팅 한번 하시고 진행하시면 됩니다.

 

 


 

 

# 메시지큐(RabbitMQ) 설치 및 설정

- openstack은 메시지 큐를 사용하여 서비스 간의 작업 및 상태정보를 조정
- 일반적으로 컨트롤러 노드에서 실행
- RabbitMQ, Qpid 등 여러 큐 서비스 지원하지만 대부분 배포판은 RabbitMQ를 지원한다.

 

yum install -y rabbitmq-server

#사용자 추가
rabbitmqctl add_user openstack openstack
rabbitmqctl set_permissions openstack ".*" ".*" ".*"

systemctl enable --now rabbitmq-server.service
systemctl restart rabbitmq-server.service

 

 

 

 


 

 

# Memcached 설치 및 설정
- 서비스를 위한 identity 서비스 인증 메커니즘에서는 토큰을 캐싱하기 위해서 memcached 사용
- 보통 컨트롤러 노드에서 사용
- 프로덕션 배포에서는 해당 구성요소에 대한 보안을 위하여 방화벽, 인증 및 암호화의 조합을 활성화 하는 것을 권장한다.

 

yum install -y memcached python3-memcached
cat /etc/sysconfig/memcached
sed -i 's/127.0.0.1/10.177.13.30/g' /etc/sysconfig/memcached
cp /etc/sysconfig/memcached /etc/sysconfig/memcached.backup

systemctl enable --now memcached.service
systemctl restart memcached.service

항상 crudini를 쓰는 것은 아니구요,,,필요할때만 사용합니다

그리고 설정파일은 백업!

 

 

 


 

# ETCD 설치 및 설정
- openstack 서비스들은 분산 키 잠금 관리, 구성 저장, 서비스가 살아있는지 다른 시나리오에 대한 지속적 추적을 위하여
안정적인 분산 키-값 저장소인 etcd를 사용한다.
- 보통 컨트롤러 노드에서 실행

 

yum install -y etcd

cat /etc/etcd/etcd.conf
cp /etc/etcd/etcd.conf /etc/etcd/etcd.conf.backup

설정 파일 확인 후에 백업 진행합니다.

 

etcd를 관리 네트워크를 통해서 다른 노드로부터 액세스할 수 있도록 하기 위해서 설정 파일을 변경해야합니다.

 

 

 

etcd.conf 파일에 url을 호스트네임으로 지정하니 에러가 뜨더군요..그래서 변수 설정을 해서 진행합니다.

 

CONTROLLER_IP=10.177.13.30
echo ${CONTROLLER_IP}

cat > /etc/etcd/etcd.conf << EOF
#[Member]
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="http://${CONTROLLER_IP}:2380"
ETCD_LISTEN_CLIENT_URLS="http://${CONTROLLER_IP}:2379"
ETCD_NAME="controller"
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${CONTROLLER_IP}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${CONTROLLER_IP}:2379"
ETCD_INITIAL_CLUSTER="controller=http://${CONTROLLER_IP}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"
ETCD_INITIAL_CLUSTER_STATE="new"
EOF

systemctl enable --now etcd
systemctl restart etcd

 

변수로 삽입을 하면 자동으로 IP로 변환되기 때문에 자주 사용하는 방법입니다.

 

 

이상.

 

환경 설정은 끝났고, 다음부터는 서비스을 배포하도록 하겠습니다.

 



 

OpenStack_(1) 환경 구성
가상 머신 설치 및 설정 ~ 오픈스택 패키지 설치

 

 

 

 

 

 

VMware에서 네트워크 설정을 이렇게 해놨고, NAT 게이트웨이는 10.177.13.1로 설정했습니다.

Host-only는 내부 통신용이기 때문에 게이트웨이가 필요 없습니다.

 

 

Contoller 가상 머신 설정 입니다.

 

 

 

Compute 가상 머신 설정입니다.

 

 

다른 설정들은 하기 나름이니 중요한 부분만 다루도록 하겠습니다.

참고로 저는 아래와 같이 설정만 했습니다.

 

 

설치 전 네트워크 설정과 호스트네임 설정도 미리 해줍니다.

 

 

 

 


 

 

작업전에 CenOS8은 EOS가 된 OS이기 때문에, 레포지토리 경로 수정부터하고 진행합니다.

 

http://mirrorlist.centos.org -> http://vault.centos.org 로 변경해주시기만 하면됩니다.

 

저는 쉽게 작업하기 위해서 ssh로 접속해서 작업 진행했습니다.

 

mirrorlist 주석 처리, baseurl 주석 해제 후 경로 변경 해주시면 됩니다.

# repo 수정
cd /etc/yum.repos.d
sed -i 's/mirrorlist/#mirrorlist/g' ./CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' ./CentOS-*
cat CentOS-Base.repo

yum clean all
yum install -y vim

 

이렇게 설치가 잘된다면 성공적으로 잘 하신겁니다!!

 

 


 

그 다음 해줘야할 것은 실습 환경을 원활하게 하기 위해서 selinux와 방화벽을 해제 하겠습니다.

위부터 현재 진행하고 있는 작업은 Controller와 Compute 모두 해줘야합니다.

 

selinux는 위 상태가 되도록 해야합니다.

 

방화벽도 해제해줍니다

 

# selinux & firewall 해제
getenforce
setenforce 0
getenforce 
sed -i 's/enforcing/disalbed/g' /etc/selinux/config
cat /etc/selinux/config

systemctl disable --now firewalld
systemctl status firewalld

 

 

 


 

 

이제 네트워크 설정을 해야합니다.

설치 전에 네트워크 설정을 해놨기 때문에, NAT 네트워크(ens160)은 자동으로 올라올 것이고, host-only만 켜주면 됩니다.이후 ip도 한번 확인해주시구요

# network 설정
ip a
nmcli con show
nmcli con up ens192

 

오픈스택 메뉴얼에도 나와있듯이 /etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME 파일을 아래와 같이 수정해주면 됩니다. 다른 부분은 수정안해도되고 아래의 부분만 수정하시면 됩니다.

DEVICE=INTERFACE_NAME
TYPE=Ethernet
ONBOOT="yes"
BOOTPROTO="none"

 

위 사진 처럼 말이죠 host-only 네트워크(ens192)도 동일하게 설정해줍니다.

 

 

 


 

이제는 /etc/hosts 에 controller와 compute의 IP와 호스트네임을 지정해줘야하는데요. 쉽습니다.

호스트네임으로 핑을 보냈을 때 잘 간다면 성공한 것입니다.

단 /etc/hosts 파일에 127.0.1.1이 localhost로 설정되어 있으면 주석처리 해주셔야합니다. 하지만 저는 안되있기 때문에 넘어가줍니다.

 

 

 


NTP 설정도 해야합니다.

일단 Controller에 정확한 시간을 맞춘 후에 Compute가 Controller를 바라보게 하면 됩니다.

# ntp

# Controller
timedatactl set-timezone Asia/Seoul
yum install -y chrony
vi /etc/chrony.conf
----
...
#pool 2.centos.pool.ntp.org iburst
server time.bora.net iburst
allow 192.168.99.0/24
...
---
systemctl restart chronyd
systemctl enable --now chronyd
timedatectl
chronyc sources -v

# Compute
yum install -y chrony
vi /etc/chrony.conf
----
...
#pool 2.centos.pool.ntp.org iburst
server controller iburst
...
---
systemctl restart chronyd
systemctl enable --now chronyd
timedatectl
chronyc sources -v

시간이 잘 맞는지만 확인해봅니다.

 

 

 

 

 


 

이제 본격적인 openstack 패키지를 받아야합니다.

모든 노드에서 이 작업을 해야합니다. 

OS 버전에 따라서 배포되는 openstack 패키지가 다르니 공식사이트에서 확인후에 패키지 추가 하시면 됩니다.

# 패키지 추가
yum install -y centos-release-openstack-ussuri
yum config-manager --set-enabled powertools

sed -i 's/mirrorlist/#mirrorlist/g' ./CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' ./CentOS-*

yum upgrade -y

# 오픈스택 클라이언트 설치
yum install -y python3-openstackclient

 

 

 

패키지 추가 시에 이렇게 뜬다면 mirrorlist 때문에 그런 것 같습니다.

아까 레포지토리 설정했던 명령어 한번 더 입력해준 후에 upgrade 하면 정상적으로 될 것입니다.

 

 

다음 편에 mariadb부터 초기 환경 구성 진행하겠습니다.!

 

CentOS 8을 이용한 Openstack 환경 구성(1)

 

 

ansible을 이용하여 openstack 구성을 자동화하는 작업을 하려고 합니다. 그전에 메뉴얼 설치를 해봐야 수월하게 yaml 파일 코드를 작성할 수 있을 것으로 생각되 메뉴얼 설치를 진행하려 합니다.

 

openstack은 AWS, GCP, Azure 같은 퍼블릭 클라우드에서 사용하는 것을 입맛에 맞게 구성하여 사용할 수 있도록 하는 오픈소스 기반 클라우드 입니다.

 

자세한 내용은  openstack 공식 사이트에서 메뉴얼을 보시면 많은 도움이 됩니다.

설치도 아래 사이트에서 보고 추가적으로 덧붙여서 진행하는 것이니 참고바립니다.

https://docs.openstack.org/ko_KR/ 

 

OpenStack Docs: Korean

OpenStack 문서에 오신 것을 환영합니다 OpenStack이란? OpenStack은 클라우드 운영체제입니다. 데이터 센터의 컴퓨팅 자원, 스토리지 자원, 네트워크 자원의 대규모 풀을 제어합니다. 이런 것들은 모두

docs.openstack.org

 

 

Controller Node Component

- Nova

- Neutron

- Keystone

- Placement

- Horizon

- Glance

 

Compute Node Component

- Nova

- Neutron

- Cinder (Block Storage)

 

 

Cinder는 Block Storage 서비스를 제공하는 컴포넌트 인데, 원래는 Storage 노드를 따로 설치해서 하는 것을 권장하지만 지금은 테스트를 해볼 것인 관계로 Compute 노드와 같이 구성을 해보겠습니다.

 

또, Controller와 Compute 양쪽에 동일한 서비스가 있습니다. 바로 Nova, Neutron인데요.

각 서비스에 대한 역할이 정해져 있는데, 자세한 설명은 각 서비스를 설치할때 하는 걸로 하고 간단히 설명하자면

Nova -> 오픈스택 컴퓨팅 서비스로써, 클라우드 컴퓨팅 시스템을 호스팅하고 관리하는 서비스 입니다.

Neutron -> 오픈스택 네트워킹 서비스로써, 네트워크 인터페이스 장치를 생성하고 네트워크 연결을 위한 서비스 입니다.

 

 

같은 서비스지만 다른 역할을 하는데요,

우선, 컨트롤러와 컴퓨트는 Master-Worker 구조로, 예전에 k8s에서 한 것과 유사한 구조를 보입니다.

  • 컨트롤러 측 서비스 -> 전체를 관리하는 역할
  • 컴퓨트 측 서비스 -> 각 노드에서 실제 동작을 수행하는 역할

Nova를 비교해보자면,

  • 컨트롤러 측 -> API, Scheduler, Conductor, Novncproxy
  • 컴퓨트 측 -> Compute

Neutron

  • 컨트롤러 측 -> Server, DHCP-agent, Metadata-agent, L3-agent, Openvswitch-agent, ovs-cleanup
  • 컴퓨트 측 -> openvswtich-agent

 

정도로 볼 수 있습니다. 위에서 나온건 실제로 서비스를 구성할 때 설치 항목이나 설정하는 부분에서 확인이 가능합니다.

 

 

 

이제는 실제 구성을 어떻게 할 것인지를 확인해야합니다.

 

먼저, 오픈스택을 설치할 각 노드의 컴퓨팅 리소스를 정해보겠습니다.

 

- Controller Node: 2 코어, 4G 메모리, 100G 스토리지

- Compute Node: 4코어, 8G 메모리, 100G + 100G 스토리지(cinder 구성시 추가할 예정)

 

프로그램: VMware Workstaion 17 Pro

OS: CentOS 8

NIC * 2ea - (외부 - NAT + 내부 - hostonly)

- 외부 -> Contoller (10.177.13.30/24), Compute(10.177.13.40/24)

- 내부 -> Contoller(192.168.99.30/24), Compute(192.168.99.40/24)

 

이 정도로 정해놓고 환경 구성으로 진행해보겠습니다.

 

 

 

 

 

 

 

'클라우드 > Openstack' 카테고리의 다른 글

Openstack_(2) 환경 구성 마무리  (0) 2025.05.22
Openstack_(1) 환경 구성  (0) 2025.05.22

저번에 VPC를 구성하고 퍼블릭, 프라이빗 서브넷을 구축한 후에 IGW(인터넷 게이트웨이)까지 연결을 했습니다. 

아직 테스트까진 안헀는데요!! 오늘은 테스트하고 NAT 게이트웨이를 일반적으로  AWS에서 제공하는 NAT 게이트웨이가 아닌 인스턴스를 이용하여 구성해보겠습니다.

 

이렇게 구성하는 이유는?? 바로 비용 효율적인 측면 때문인데요.

클라우드를 사용하면 일시적으로 빠르고 쉽게 사용할 수 있다는 장점이 있습니다. 하지만 단점으로는 지속적으로 사용할 시 관리가 되지 않는다면 비용 폭탄을 받게 될 수도 있다는 단점이 있죠....! 그래서 프리티어가 끝난 저 또한 비용에 대해서 매우 민감합니다...ㅋㅋㅋ 

 

VPC 구성만으로는 비용이 나오지 않습니다.

EC2 인스턴스를 이용하면 컴퓨팅 비용(t2.micro 제외)과 EBS 볼륨에 대해서만 비용을 부과하고,

NAT 게이트웨이...비용이 생각보다 쌥니다...!

 

그럼 보안 그룹부터 구성을 해보겠습니다.

 

NAT 인스턴스 구성만 보실 분들은 4. NAT 게이트웨이 부터 보시면 됩니다.

 

1. 보안 그룹

보안 그룹(Security Group)은 AWS에서 인스턴스에 대한 인바운드 아웃바운트 트래픽을 제어하는 가상의 방화벽입니다.

물론 보안 그룹도 기본적으로 하나 생성이 되는데요. 저는 따로 생성을 해주겠습니다.

일반적으로 리눅스를 다운받고 테스트하기 위해서 VMware Workstation를 사용하는데요 이럴때는 firewalld, iptabels, ufw 와 같은 방화벽에 의해서 지배를 받습니다. 물론 어떤걸 사용하냐에 따라 다르겠지만요.

하지만 AWS같은 경우는 인스턴스에서 방화벽 설정을 해줄 필요 없이 쉽게 콘솔에서 설정이 가능하다는 것입니다.

 

보안 그룹의 특징

a) 인스턴스 기준 적용 (1차 보안 계층)

b) 룰에 대한 허용 규칙만 적용

c) 아웃바운드 요청에 대한 응답 자동 허용

d) 등록된 모든 규칙을 평가하여 트래픽 허용

e) 특정 그룹을 지정시에만 인스턴스에 적용

 

말이 점점 길어지는데요... AWS Network ACL과도 비교하고 싶지만,,, 그것은 나중에 심도깊게 가고 오늘은 실습 위주로 진행 해보겠습니다.

 

1) "보안 그룹 생성"

보안 그룹을 생성하면 인스턴스를 만들때 바로 사용할 수 있습니다. 테스트 용도로만 사용할 예정이니 한개만 생성해서 퍼블릭, 프라이빗 구분없이 SSH, ICMP 만 열어서 사용을 하도록 하겠습니다.

 

 

2. 키 페어

AWS EC2 인스턴스를 생성하고 ssh 접근을 하기 위해서는 password 방식을 사용하지 않고 공개키 방식을 사용합니다.

물론, password 방식을 사용하게끔 설정할 수 있지만 보안적으로 좋지 못합니다.

공개키는 암호학적인 부분인데, 공개키 알고리즘은 공개키와 개인키 두 개의 키쌍을 이용하여 함호화, 키 분재, 인증을 하는 방식입니다.

쉽게 설명하면 개인키는 말 그대로 서버의 주인이 가지고 있어야하는 키 입니다. 공개 키는 서버에 접근할 수 있어야 하는 사람에게 제공하게 됩니다.

공개 키는 암호화에 사용되고 개인 키는 복호화에 사용하여 올바른 공개키를 가지고 있는 사람이 공개키를 가지고 인증을 하면 접근을 허용하게 해주는 것입니다.

 

간단하니 바로 실습 진행합니다.

 

1) "키 페어 생성"

키 페어를 생성하기 위해서는 이제 VPC가 아니라 EC2로 접속해야합니다!

키 페어 유형은 공개키 알고리즘을 선택하는 것, 키 파일 형식은 어떤 방식으로 접근을 하냐에 따라 방식이 다릅니다.

putty로 접근을 하는 경우에는 .ppk를 선택하시면 됩니다.

 

키를 생성하면 testKey.pem 파일이 다운 받아집니다. 이 키파일 잃어버리지 않게 조심하고 잘 챙겨야합니다.

삭제를 하거나 잃어버리면 인스턴스로 접근을 할 수 없게 되니 주의!! 또 주의!!! 하셔야합니다.

 

생성하는건 생각보다 간단하죠?

 

 

3. EC2

EC2는 AWS에서 인스턴스 또는 EC2 인스턴스라고 불리우는데요 쉽게 생각하시면 가상머신입니다. 서버를 구성할 때 이 인스턴스로 구성을 하게 되죠. 

 

지금 생성하는 인스턴스는 퍼블릭 서브넷에 패치하여 인터넷이 잘 되는지 테스트하기 위함입니다.

 

1)  "인스턴스 시작" - 퍼블릭 서브넷

인스턴스 이름은 멋있는 원하는 이름으로 지정해주시고 저는 OS를 ubuntu로 해주었습니다. 다른 리눅스가 편하신 분들은 그걸로 진행하시면 됩니다.!!

인스턴스 유형은 인스턴스에 할당되는 하드웨어 부분을 선택할 수 있는 것인데요. 당연히 서버의 성능이 좋아지면 가격도 올라가겠죠?? t2.micro는 프리티어가 사용 가능하니 선택해줍니다!

키 페어 꼭 선택해주시구요. 

다음은 중요한 네트워크 설정입니다. "편집"을 눌러서 창을 크게 키워주세요.

퍼블릭 서브넷, 그리고 인터넷이 되려면.. 퍼블릭 IP 즉 공인 IP가 있어야겠죠? 인터넷 게이트웨이가 있다고 한들 공인 IP가 없으면 인터넷 안됩니다! 

그리고 보안 그룹은 이전에 생성한 보안 그룹으로 설정해 줍니다. 다 하셨으면  우측에 "인스턴스 시작"하여 생성 해줍니다.

 

 

2)  인스턴스 접속

저는 mobaXterm을 자주 이용합니다.

Remote host에는 인스턴스의 공인 IP, 그리고 username에는 ubuntu를 넣으시면 됩니다. 만약 amazon linux를 사용하시는 분은 username을 ec2-user로 하시면 됩니다. 

그리고 중요한 PEM 키를 넣어줘야겠죠? "Use private key"를 체크하여 키 페어(.pem)키의 경로를 입력해줍니다.

"OK"를 누른 후에 이런 창이 뜨면 "Accept"를 눌러줍니다.

성공적으로 접근했죠?? 이제 구글의 dns 주소인 8.8.8.8로 핑을 쏴봅니다.

잘됩니다. 참 간단하죠?

 

동일한 방법으로 프라이빗 서브넷에도 인스턴스를 하나 생성해주겠습니다. 

 

3)  "인스턴스 시작" - 프라이빗 서브넷

이전과 동일한 작업이지만 네트워크 설정만 달라집니다.

퍼블릭 서브넷 인스턴스를 생성할 때는 퍼블릭 IP를 활성화 해줬지만, 프라이빗 서브넷은 퍼블릭 IP가 있으면 안됩니다!! 이게 있으면,,,왜 프라이빗..? 그쵸? 

다 똑같이 진행하지만 퍼블릭 IP만 비활성화 해줍니다.

 

근데 여기서 하나 문제!! 퍼블릭 IP가 없으면 어떻게 프라이빗 서브넷에 있는 인스턴스에 접근합니까??

 

답은 Bastion 인스턴스를 생성해 접근하면 됩니다. Bastion은 jump server, jump box, jump host 등등 으로 불리우는 데요. 프라이빗 서브넷의 인스턴스에 접근하기 위한 일종의 게이트웨이 입니다. 프록시 서버랑은 살짝 다른 개념이에요~

 

Bastion은 주로 내부 네트워크 보안 접근을 제공하기 위해 사용되며, 외부 사용자가 내부 서버에 직접 접속하는 것을 방지합니다. 내부 서버로 들어가기 위한 중간 다리라고 생각하심 됩니다.

 

프록시 서버는 클라이언트와 서버 간의 통신을 중계하는 것입니다. 사용자의 요청을 대신하여 외부 서버와 통신하는 것이므로 Bastion과 차이가 있습니다~

 

4)  내부 인스턴스 접근

점프서버를 따로 생성해야 할까요..?? 아니요~ 이전에 테스트 용으로 만들어 놓은 인스턴스는 이제 Bastion 입니다...ㅋㅋ

ssh를 이용하여 접근해보죠 근데 그렇게 하기 위해서는 이 인스턴스에도 공개 키가 있어야겠죠?? 파일을 옮겨와 사용해보겠습니다. 

mobaXterm의 가장 유용한 기능 파일을 드래그만 하면 바로 가져올 수 있습니다..!

다른 방법은 그냥 testKey.pem 파일을 노트패드로 열어 복사해와도 됩니다!

 

이제 접근해보겠습니다. 그전에 내부 서버의 사설 IP를 확인해야겠죠?

인스턴스를 선택하면 아래 프라이빗 주소가 나옵니다.

testKey.pem 파일을 chmod를 이용해 600(-rw-------)으로 변경해주고 ssh 를 통해 접근해주니 성공적으로 접근했죠?

 

외부 핑테스트 까지 해보겠습니다.

네 트래픽이 나가지 않죠? 정상입니다. 오해하지 마세요!!

 

NAT 게이트웨이는 프라이빗 서브넷에 있는 인스턴스가 외부와 통신할 수 있게끔 도와줍니다. 하지만 따로 생성을 하지 않았죠??

 

이제 해보겠습니다.

 

 

 

4. NAT 게이트웨이

NAT게이트웨이는 퍼블릭 서브넷에 존재해야합니다. 프라이빗 서브넷의 인스턴스가 외부로 통신하게끔 도와주려면 NAT 게이트웨이도 공인 IP가 할당되어 있어야 하기 때문이죠

 

하지만 비용이 너무 비쌉니다. 그 해결법 중 하나가 인스턴스를 하나 생성해 마스커레이드 설정하여 NAT로 사용하는 것입니다.

리눅스에는 iptalbes나 netfilter와 같은 유용한 네트워크 기능이 많고 커널단에서 NAT와 같은 기능이 지원합니다. 많은 트래픽을 보내야한다면 그냥 NAT 게이트웨이를 쓰는 편이 더 좋겠지만 테스트용 서버일 경우에는 안정성이나 성능이 크게 상관없기 때문에, 진행해보겠습니다.

 

하지만 약간 손이 가는 작업이라면, 고가용성을 위해서 MultiAZ를 사용하는 경우에는 각 AZ 마다 생성을 해줘야한다는 점!!

 

여기서부터는 좀 복잡합니다!

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/work-with-nat-instances.html

 

프라이빗 리소스가 VPC 외부에서 통신할 수 있도록 지원 - Amazon Virtual Private Cloud

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

AWS에서 제공하는 docs 입니다. 참고하셔서 작업하시면 됩니다.

 

저는 이전에 프라이빗은 2c 퍼블릭은 2a에 만들어서 얼릉 2c에 퍼블릭 서브넷을 만들어 보겠습니다.

빠르게 2c에 퍼블릭 서브넷을 생성하고 라우팅 테이블에 추가하였고, 인스턴스까지 생성했습니다.

보안 그룹도 NAT 인스턴스에 맞게 설정해줬습니다. 위 가이드 docs 사이트에 AWS에서 권장하는 보안그룹 설정이 있으니 참고하시면 됩니다.

 

 

1)  서버 사전 작업

# set root passwd
sudo passwd

# update && upgrade 
sudo apt update && sudo apt upgrade -y

# install net-tools
sudo apt install -y net-tools

업그레이드 되면 재부팅 해주시면 됩니다!!

# reboot
sudo reboot

 

 

2)  IP Forwading과 마스커레이딩 활성화

# enable ip forwarding
sudo sysctl -w net.ipv4.ip_forward=1
또는
/proc/sys/net/ipv4/ip_forward 값을 1로 변경

하지만 둘다 영구적으로 활성화되는 것이 저장되지 않는다.

# 영구 활성화
sudo vi /etc/sysctl.conf

ip_forward 부분 주석 해제

# 구성 파일 적용
sudo sysctl -p

# 마스커레이딩 활성화할 인터페이스 확인
netstat -i

# 마스커레이딩 활성화
sudo /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# 저장
sudo /sbin/iptables-save

 

3)  소스/대상 확인 변경

라우터에는 Reverse Path Forwarding이라는 개념이 있는데, 기본적으로 쓸데없는 패킷이 라우터간에 왔다 갔다 돌아나오는 것을 방지하도록 설정되어 있습니다.

인스턴스로 NAT를 사용하려면 이것을 비활성화 해야합니다. 그렇지 않으면 다 잘 되있어도 패킷이 오지 않습니다.!

이렇게 설정 후 저장 해줍니다.

 

4)  라우팅 테이블 편집

위 작업까지 다 했다면 라우팅 테이블 편집을 하면 됩니다.

프라이빗 라우팅 테이블을 선택해주고 라우팅 편집을 해야합니다.

모든 IP를 대상으로 nat 인스턴스를 선택해줍니다. -> 변경사항 저장

 

 

5)  테스트

이제 테스트만 남았습니다. 위 사진은 프라이빗 서브넷에 있는 10.0.10.10의 IP를 가지고 있는 인스턴스입니다. 물론 이전에는 통신이 안됬는데요. 설정을 하고나니 이제 통신이 되는 모습입니다.

 

이렇게 인스턴스를 통해서 NAT 게이트웨이를 구성했습니다. AWS docs에 자세한 설명도 있으니 잘 참고해서 직접 실습해보시면 도움 많이 될 것 같습니다.

 

오랜만에 블로그 글을 씁니다~~

이전에 클라우드 교육을 받은 적이 있는데요. 이전에 배운것을 까먹으면 안되기 때문에 다시 차근차근 블로그에 작성하며 이전 기억을 되살려 보려고 합니다. 

 

오늘은 AWS를 처음 이용하는 초심자에게 적합하게 쉽게 설명하며 수동으로 VPC 구성을 해보려합니다. 요즘은 VPC 구성을 자동으로 해주긴하지만 "그래도"!! 수동으로 구성하는 것이 기본이기 때문에 빠질 수 없겠죠?

기초부터 천천히 한 번 시작해보겠습니다

 

 

1. 리전 (Region)

클라우드를 사용하는데 리전이라는 말을 많이 사용하는데요. AWS가 전 세계에 가지고 있는 데이터 센터의 물리적 위치를 리전이라고 합니다.

콘솔에서도 확인할 수 있는데요. 이것들이 리전을 나타내죠 서울도 있고 가까운 오사카에도 리전이 있는 것으로 보입니다.

 

 

2. 가용영역(AZ)

각 리전에는 가용영역이라고 하는 격리된 위치의 여러 개의 데이터센터를 가지고 있습니다. 가용성(서버가 지속적으로 유지하는 것을 보장하는 것)이 보장되기 위해서 데이터센터가 하나만 있으면 안되겠죠?? 보조로 두 세개는 있어야 한다는 것입니다.

쉽게 설명하자면 안경을 하나만 사용하는데 안경이 부서지면 예비 안경이 있어야 합니다. 안경을 착용하는 사람은 공감하겠지만 1개만 가지고 있지는 않죠?? 이렇게 생각하면 쉽습니다!

그래서 나중에 직접 실습해볼때 보겠지만 서울에는 4개의 가용영역이 있습니다. 각각 다른 지역의 데이터센터에서 자원을 사용하는 것이죠.

 

 

3. VPC(Virtual Private Cloud)

AWS를 사용할 줄 안다면 필수적으로 알아야하는 개념인데요.

VPC는 클라우드 환경에서 퍼블릭과 프라이빗으로 논리적으로 독립된 네트워크 영역을 의미합니다. VPC 안에는 서브넷, 라우팅테이블, 인터넷 게이트웨이, NAT 게이트웨이, 보안 그룹 등등 다양한 구성요소로 이루어져있습니다.

 

좀 쉽게 하려면 네트워크에 대한 부분이 깊게는 아니더라도 좀 알고 있어야 이해가 쉽게 될 것 같습니다.

실습을 위주로 설명을 계속 진행하겠습니다.

!실습!

1. VPC 생성을 눌러줍니다!

 

2. "VPC 만" 을 선택하고 아래와 같이 설정해줍니다.

여기서 "VPC 등"을 선택하면 자동으로 서브넷과 라우팅 테이블을 다 구성해줍니다. 저희는 수동으로 할 것 이기 때문에 "VPC 만"으로 설정해줍니다.

 

IPv4 CIDR은 사용할 사설 IP 대역대를 설정해주는 것인데요. 10.0.0.0/16 으로 설정하여 10.0.0.1 ~ 10.0.255.255 총 65534 개를 사용할 수 있도록 해줍니다.

잘 생성된 모습입니다. 이제 바로 서브넷으로 가봅시다.

 

그리고 수동으로 구성할 땐 이 순서를 잘 기억해 주셔야합니다!

 

 

4. 서브넷(Subnet)

서브넷은 서브네트워크를 줄임말입니다. IP 네트워크의 논리적인 영역을 부분적으로 나눈 하위 망을 말하는 것이죠.

10.0.0.0/16은 65534개를 사용할 수 있다고 했습니다. 여기서 서버는 10대만 있으면 되는데 10.0.0.0/16을 하면 IP가 낭비되겠죠?? 그것을 방지하기 위해서 각 서브넷으로 논리적으로 IP를 나눠주는 것입니다.

 

예시, 10.0.0.0/16 은 10.0.0.0 ~ 10.0.0.1 ~ 10.0.255.255 입니다. 

A subnet (10.0.0.0/24) => 10.0.0.0 ~ 10.0.0.255 까지  사용 가능합니다.

B subnet (10.0.10.0/24) => 10.0.10.0 ~ 10.0.0.255 까지 사용 가능합니다.

 

VPC에서 할당한 IP 대역대를 벗어나지 않고 서브넷으로 논리적으로 한번 더 나눠 주는 것이죠. VPC CIDR를 벗어나지 않는다면 서브넷을 몇개로 나눠도, 몇 개를 생성해도 상관없습니다. 다만 관리적인 측면에서도 생각을 해야하죠.

 

그래서 서브넷은 인터넷에 노출되어 있는 퍼블릭 서브넷과 인터넷에 노출되어 있지 않고 숨겨져있는 프라이빗 서브넷으로 나눠집니다.  여기서도 중요한 것이 있는데, 진행하면서 계속 설명을 해드리겠습니다~!!

 

 

!실습!

1. "서브넷 생성"을 눌러줍니다.

 

2. 이전에 생성한 VPC를 선택해줍니다.

 

이제 서브넷을 생성할 건데요 저는 그냥 간단히 2개만 생성해 보겠습니다.

 

쉽게 작업을 하기 위해서는 네이밍 작업도 중요합니다.

첫 번째 서브넷은 public 서브넷으로 설정을 하기 위해서 pub라는 네이밍을 해줍니다. SB는 subnet입니다.

가용영역은 ap-northeast-2a로 설정해줍니다. 지정해주지 않으면 랜덤으로 배치되니 꼭 확인해주셔야합니다!

 

그리고 아까 가용역역에 대해서 설명했었죠? 서브넷을 생성할 때 가용영역에 대한 항목이 있습니다.

2a,2b,2c,2d 즉, 서울 리전에는 4개의 가용영역이 있다. 이렇게 설명이 가능하고, 고가용성 보장을 위해서는 서브넷을 서로 다른 가용영역에 배치를 해야합니다.

 

두 번째 서브넷 입니다. CIDR는 10.0.10.0/24로 설정해줍니다. 가용영역은 ap-northeast-2c 입니다.

이후 서브넷을 생성해줍니다.

 

잘 생성되었습니다.

 

 

4. 인터넷 게이트웨이(Internet GateWay)

인터넷 게이트웨이는 VPC와 인터넷간의 논리적인 연결입니다. 1개의 VPC당 1개의 IGW만 연결이 가능하며 IGW가 연결이 되어 있지않다면 그 서브넷은 폐쇠망 즉, 인터넷이 되지 않습니다.

인터넷 게이트웨이는 양방향으로 연결을 지원하기 때문에 외부 인터넷에서 퍼블릭 서브넷의 퍼블릭 IP로도 정상적인 통신이 가능한 것이죠!

 

 

!실습!

1. "인터넷 게이트웨이 생성"을 눌러줍니다.

 

2. 네이밍 후 "인터넷 게이트웨이 생성"을 눌러줍니다.

처음 생성하면 상태가 Detached 로 되어 있습니다. 이유는 VPC와 연결을 아직 시켜주지 않아서 그런것ㅇ비니다. 당황하지 말고 계속 진행합니다.

 

 

2. 작업 -> VPC 연결 -> test-vpc 선택

이제 정상적으로 Attached 가 되었습니다. VPC에 IGW가 붙었다는 말이죠. 하지만 붙이기만 해서는 안됩니다!!

라우팅 테이블에 추가해줘야 퍼블릭 서브넷에 인터넷이 되겠죠?

 

5. 라우팅 테이블(Routing Table)

VPC를 생성하면 자동으로 가상 라우터가 생성됩니다. 이 가상 라우터에는 각각 분리된 네트워크의 주소(VPC)를 나타낼 수 있는 라우팅 테이블이 정의되어 있는데요.

참, 라우터는 데이터 패킷을 목적지로 최적의 경로로 전송시켜주는 장치입니다. 최적의 경로를 지정해주는 것이 라우팅 테이블에 정의되어 있지요. 자세한 내용은 검색을 해서 찾아보기를 추천드립니다...!

 

 

처음에는 기본으로 생성되는 라우팅 테이블이 있지만, 실습을 위해서 따로 설정해줄 것입니다.

 

 

!실습!

1. "라우팅 테이블 생성"을 눌러줍니다.

기본적으로 생성되어 있는 라우팅 테이블이 있는데요 무시하고 새로 두개를 만들어줄것입니다.

이렇게 라우팅 테이블이 잘 생성되었습니다. 여기서 중요한 내용을 알려드리겠습니다.

 

 

지금 생성한 서브넷과 라우팅 테이블에 pub과 pri 이라고 네이밍을 해줬습니다. 그럼 네이밍을 해준 것만으로 퍼블릭 서브넷과 프라이빗 서브넷이 자동으로 설정될까요??

 

답은 아닙니다. 서브넷이 퍼블릭과 프라이빗으로 나눠지는 것은 바로 인터넷과 통신할 수 있도록 도와주는 게이트웨이인 IGW(인터넷 게이트웨이) 유무에 따라서 나눠집니다.

 

즉, 라우팅 테이블IGW가 들어가 있다면. 퍼블릭 서브넷 으로 분류

라우팅 테이블에 프라이빗 서브넷이 외부와 통신할 수 있도록 도와주는 NAT 게이트웨이에 들어가 있다면 프라이빗 서브넷으로 분류 됩니다.

 

어떤 식으로 서브넷이 나눠지고 나눠지는 기준이 무엇인지에 따라 정확히 확인하고 설명할 줄 알 필요가 있습니다.

 

 

2. "test-pub-RT"에 IGW 경로 추가하기

현재는 퍼블릭 서브넷에 IGW가 라우팅 테이블에 추가되어 있지 않은 것을 확인할 수 있는데요. 작업을 해보겠습니다.

 

 

3. "라우팅 편집" -> "라우팅 추가"

 

라우팅 추가를 해줬습니다. 대상은 0.0.0.0/0으로 설정해줍니다. 의미는 모든 IP의 접근을 허용하겠다. 라는 의미입니다. 

후에 인터넷 게이트웨이를 눌러주면 생성했던 인터넷 게이트웨이가 뜨는 것을 확인할 수 있습니다.

이후에 "변경 사항 저장"을 눌러줍니다.

이제 이 라우팅 테이블은 인터넷 게이트웨이가 포함이 되어 있습니다. 그럼 이 라우팅 테이블을 퍼블릭 서브넷에 연결시켜줘야겠죠?!!

 

헷갈릴 수도 있겠지만 모든 것이 논리적으로 나눠져있고 그것을 연결을 시켜주는 것입니다.

 

 

 

4. "서브넷 연결" -> "서브넷 연결 편집" -> 퍼블릭 서브넷 선택

여기서 퍼블릭 서브넷을 선택해줍니다. 

프라이빗 서브넷은 선택하시면 안됩니다!!! 그럼 프라이빗이 프라이빗이 아니게됩니다....!

그리고 VPC 만들 때 생성된 - 이름을 가진 기본 라우팅 테이블에서 퍼블릭 라우팅 테이블을 기본으로 설정해줍니다.

 

이제 깔끔하네요!

 

 

오늘은 여기까지하고 다음 포스트에서는 NAT 게이트웨이 부터 진행을 해보도록 하겠습니다.

 

 

'클라우드' 카테고리의 다른 글

AWS EC2 인스턴스를 이용해 NAT 구성하기  (2) 2024.10.02

+ Recent posts