웹 ssh 클라를 찾다가 발견한 프로그램.


사용자인증 및 사용자에 따른 커넥션 설정에다가 SSH 는 기본이고 RDP와 VNC 까지 지원을 한다.

RDP 테스트를 해봤는데 매우 쓸만한 수준.

심지어 모바일까지 잘 지원을 한다!


tomcat 위에서 돌아간다는 점만 제외하면 정말 마음에 드는데.... tomcat 은 싫으니 docker 에다가 넣어버리자.


guacamole 는 커넥션을 유지하면서 서버 역할을 해주는 데몬과 프론트엔드 인스턴스 2개로 분리되어 있다.

docker에서 각각 guacamole/guacd (데몬), guacamole/guacamole (프론트) 이미지를 사용하면 됨.


사용자와 연결설정 저장 등을 위해 mysql 등의 DB를 사용하게 되고 보통 이것까지 docker 로 돌리지만, 난 내 DB에 연결할 것이므로 생략.


먼저 이미지를 받아온다.

docker pull guacamole/guacd
docker pull guacamole/guacamole


그리고 도커 이미지에서 mysql 테이블 생성을 위한 스크립트를 가져온다.

docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --mysql > initdb.sql


사용자나 DB는 알아서 생성을 하고, 해당 스크립트로 DB 구성을 한다.

mysql -hhost -uuser -p db_name < initdb.sql


컨테이너 설정을 위해서 docker-compose 를 사용한다.

없다면 설치를 해주고.. 아래 내용으로 docker-compose.yml 파일을 만든다.

version: '3'
services:
  guacd:
    hostname: guacd
    image: guacamole/guacd
    restart: always

  guacamole:
    image: guacamole/guacamole
    restart: always
    ports:
      - 8080:8080
    links:
      - guacd
    environment:
      GUACD_HOSTNAME: guacd
      MYSQL_HOSTNAME: DB_HOST
      MYSQL_DATABASE: DB_DATABASE
      MYSQL_USER: DB_USER
      MYSQL_PASSWORD: DB_PASSWORD


그리고 아래 명령어를 치면 아래처럼 컨테이너가 생성됨!

docker-compose up -d
Creating network "guacamole_default" with the default driver
Creating guacamole_guacd_1 ...
Creating guacamole_guacd_1 ... done
Creating guacamole_guacamole_1 ...
Creating guacamole_guacamole_1 ... done


이제 http://서버주소:8080/gucamole 로 들어가면 로그인창을 볼 수 있다.


기본 계정(위 mysql 설정을 통해 자동 생성됨)은 ID: guacadmin / PW: guacadmin



nginx 등으로 라우팅을 해주면 편하게 쓸 수 있을 듯.

apache2 나 nginx 에서 프록시 설정은 https://guacamole.apache.org/doc/gug/proxying-guacamole.html 을 참고하자.



참고 URL:

https://pages.wiserain.com/articles/deploying-guacamole-using-docker/

https://guacamole.apache.org/doc/gug/proxying-guacamole.html

Win Server 2012 + Hyper-V 조합으로 쓰다가 도저히 불편해서 결국 Host 를 Linux 계열로 밀어버리는 대 공사 진행.


Ubuntu 18.04 + KVM 조합으로 결정했다.

Host 에서는 no GUI 로, SSH를 통해 설치 및 사용하고, KVM 가상머신 생성 및 설정은 X11 forwarding 을 통해 진행함.



KVM 설치

sudo apt install qemu-kvm libvirt-bin bridge-utils ubuntu-vm-builder

# GUI manager
sudo apt install virt-manager



이후 VM 관련 작업을 할때 매번 sudo 를 이용하고 싶지 않다면, 관련 그룹에 계정을 추가해준다.


그냥 설치만 해도 내 사용자 계정이 libvirt 그룹에 자동으로 추가되던데, 다른 계정을 이용했거나 필요에 따라 진행.


보통 libvirt, kvm, libvirtd 3개 그룹에 집어넣던데 환경에 따라... 난 이미 libvirt 그룹엔 속해져있었고 libvirtd 그룹은 생성이 안되어 있어서, kvm 에만 추가해두었다,

sudo adduser $(id -un) libvirt
sudo adduser $(id -un) kvm

# 나의 경우 libvirtd 그룹은 없었음
# sudo adduser $(id -un) libvirtd


가상머신 설치

가상머신 설치용 이미지나, 디스크는 기본적으로 /var/lib/libvirt/images 경로를 참조하고 사용한다. 필요하면 바꿔주면 되겠지만, 난 귀찮아서 그대로 사용, 설치 전 iso 이미지를 저기다가 넣어주었다.


커맨드라인으로 생성하고 관리하는 방법도 있는데, 난 X11 forwarding 을 사용.

ssh 연결시에 -X 옵션을 넣어주고 연결한다.


* Mac 이라면 XQuartz 를 설치해줘야한다.

또한 XQuartz 실행시에 키보드가 한글로 되어 있다면 이후에 계속 키 입력이 이상하게 되니 주의해주자.

그리고 연결 끊고 재연결시엔 독에서 XQuartz 를 직접 끄고 다시 연결해줘야하는 듯...


ssh -X user@host

$ virt-manager



그럼 이런 창이 뜬다. 이 상황에서 가상머신 생성, 설정, 콘솔보기 등을 할 수 있음.


생성은 알아서 하는걸루.. 별거 없다.



네트워크 관련 설정

브릿지 NIC 생성 및 사용하기

기본적으론 virbr0 란 이름으로 NAT NIC 만 생성해준다.


1. br0 인터페이스 생성

Ubuntu 17? 18? 부터 네트워크 인터페이스 관리를 위해 netplan 패키지를 이용한다.

설정 파일 경로는 /etc/netplan/


적당히 60-kvm.yaml 이란 이름으로 만들어서 br0 네트워크 인터페이스를 생성해준다.

eno1 은 브릿지 하려는 NIC 이름. br0 도 필요하다면 이름을 바꿔줄 것.


sudo vi /etc/netplan/60-kvm.yaml
network:
  version: 2
  bridges:
    br0:
      dhcp4: false
      interfaces: [eno1]
# 설정 적용
sudo netplan apply


적당한 경로에 아래 내용을 가진 br0.xml 파일을 만들고 그 밑 명령어로 KVM NIC를 설정해준다.

<network>
        <name>br0</name>
        <forward mode='bridge'/>
        <bridge name='br0'/>
</network>
virsh net-define br0.xml
virsh net-start br0
virsh net-autostart br0


이 후 아래와 같이 확인할 수 있다.

virsh net-list --all
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 br0                  active     yes           yes
 default              active     yes           yes


이제 NIC 설정에 "Virtual network 'br0' : Bridge network 가 나타나서 사용할 수 있다.

virt-manager 로 새 VM을 만들땐 NIC 를 하나밖에 선택을 못할텐데,

마지막 단계에 "Customize configuration before install" 체크박스가 있고, 이걸 체크하면 뜨는 설정 창에서 Add Hardware 를 통해 NIC 를 추가할 수 있다.






NAT 고정 IP 설정하기

기본으로 생성되는 NAT NIC 는 IP 를 DHCP 로 할당한다.


가상머신에서 static ip 를 설정해줘도 되겠지만, host에서 특정 Mac 주소에 대해 고정 IP 를 할당하는 방법



virsh net-edit default
# 처음이라면 에디터를 선택하라고 뜰텐데 편한걸 선택하면 된다. 난 vim basic.

<ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
      <host mac='52:54:00:FF:FF:FF' name='NAME' ip='192.168.122.XXX'/>
    </dhcp>
  </ip>
</network>


dhcp 부분을 찾아서 위와 같이 특정 맥 어드레스에 대해 아이피 주소를 할당해준다.


이 후 아래 명령어를 통해 변경사항 적용.



virsh net-destroy default
virsh net-start default


개인적으로 nginx 자체는 매력적이라고 생각했지만, php-fpm 이라던가 uwsgi 같이 웹서버에서 직접 붙지 않고 socket 으로 연결되는 방식이 마음에 들지 않아 잘 사용하지 않았다. 

설정 및 관리가 좀 더 번거롭기도 했고..


이제는 마음에 안들었던 몇가지를 감수하고 장점을 취해보기 위해서 사용해보려고 하는데,  여전히 개떡같은 uWSGI 설정법을 정리해봄.


----------
2020.06.28 gunicorn 설정 추가

uWSGI보다 gunicorn 이 더 좋다고 한다.
나의 경우 웹소켓을 쓰려는데, uWSGI는 제대로 안되고 gunicorn + eventlet 조합으로 해야해서 스택을 변경해봄.


큰 차이는 없다. 거의 비슷...
----------

환경은 Ubuntu 18.04 + Nginx + uWSGI/gunicorn + Python3 + Flask.

이 방법의 최대 장점 중 하나가 프로젝트별로 python 버전에 구애받지 않고 venv 를 전혀 무리 없이 돌릴 수 있다.. 인 것 같은데 난 평소에 그렇게 안쓰고 있으니 일단 생략.


1. 패키지 설치

apt에도 있긴 한데, pip으로 설치해줘도 된다.

pip install uwsgi

pip install gunicorn


2. 프로젝트 wsgi 설정

프로젝트 폴더에 이런식으로 파일을 만든다.

wsgi.py

from flask_app import app

if __name__ == '__main__':
    app.run()

uwsgi.ini (gunicorn 의 경우엔 필요없음)

[uwsgi]
#plugin = python3
module = wsgi:app

master = true
processes = 3

socket = /tmp/PROJECT.sock
chmod-socket = 664
vacuum = true

die-on-term = true

plugin = python 은, uwsgi 를 apt로 설치한 경우 필요한 것 같음.


3. systemd unit 생성

/etc/systemd/system/ 경로에 PROJECT.service 로 파일을 만든다.

[Unit]
Description=WSGI instance to serve PROJECT
After=network.target

[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/PATH/TO/PROJECT
#Environment="PATH=/PATH/TO/BIN"
#ExecStart=/usr/bin/uwsgi --ini uwsgi.ini
ExecStart=/usr/local/bin/gunicorn -k eventlet -w 3 --bind unix:wsgi.sock -m 007 wsgi:app

[Install]
WantedBy=multi-user.target

뭐 User, Group 이라던가 적당히 해주고, 그 밑에 WorkingDirectory, 환경변수, 실행커맨드 등도 적당히 수정해준다.

gunicorn 도 uwsgi처럼 configuration 파일을 만들어서 할 수 있지만, 명령어로도 충분한 듯...

-k, --worker-class=: 워커 프로세스 종류. sync(기본값), eventlet, gevent 등이 있다.

-w, --workers=: 워커 갯수. 시스템 프로세스 코어당 2~4개가 권장이라는 듯?

-m: unix socket으로 만들 경우 umask


이 후

sudo systemctl enable PROJECT

sudo systemctl start PROJECT

이렇게 자동 실행 설정 및 서비스 시작 해주면 된다.


4. Nginx 설정

sites-available 등의 설명은 생략.


아래와 같이 구성하자. 수정이 필요하다면 적당히 수정...


server {
        listen 80;
        server_name 사이트주소;

        #location / {
        #        include uwsgi_params;
        #        uwsgi_pass unix:///tmp/PROJECT.sock;
        #}
        location / {
                include proxy_params;
                proxy_redirect off;
                proxy_pass http://unix:/PATH/TO/PROJECT/wsgi.sock;
        }
        #location /socket.io {
        #        proxy_pass http://unix:/PATH/TO/PROJECT/wsgi.sock:/socket.io;
        #        include proxy_params;
        #        proxy_http_version 1.1;
        #        proxy_redirect off;
        #        proxy_buffering off;
        #        proxy_set_header Upgrade $http_upgrade;
        #        proxy_set_header Connection "Upgrade";
        #}
        location /static {
                alias /PATH/TO/PROJECT/flask_app/static;
        }
}

업스트림 설정으로 분산화를 하거나, uri 에 따라 다른 프로젝트로 연결하는 것도 가능하다. 이건 내가 쓸일 있을때 수정해둘거임.

uwsgi 는 전용 지시어인 uwsgi_param, uwsgi_pass 를 사용하는데, gunicorn 은 그냥 proxy 관련 지시어들을 사용한다.

소켓을 어디에 만드느냐는 큰 차이 없음.

websocket 을 사용할 경우 주석처리한 것처럼 따로 설정을 해주면 된다.


5. 로그 보기

프로젝트 폴더에 만들었던 uwsgi.ini  에서 log 파일 경로를 지정할 수도 있지만,

sudo journalctl -u PROJECT 로 볼 수도 있다.

uwsgi 관련 로그는 여기에서,

접속 기록이나 파이썬 에러 로그 등은

/var/log/nginx/access.log, /var/log/nginx/error.log 에서 확인할 수 있다. 물론 설정에서 각각 바꿔줬으면 다르겠지?



참고

How To Serve Flask Applications with uWSGI and Nginx on Ubuntu 18.04 (DigitalOcean)

uWSGI documentation

gunicorn documentation

맨날 검색하다가 작성.


압축

$ tar -zcf [.tar.gz] [...]


압축 해제

$ tar -zxf [.tar.gz]


옵션

-f: use archive file or device ARCHIVE

-c: create a new archive

-x: extract files from an archive

-z: filter the archive through gzip


-p: extract information about file permissions (default for superuser)

-t: list the contents of an archive

-v: verbosely list files processed

서버에서 

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 10.0.2.220"

이런류의 설정을 넣어두면, OpenVPN 으로 연결시 모든 트래픽이 VPN 을 통하게 된다.


이를 client 설정 파일에서 override 할 수 있는데, 여러 방법이 있지만 설정파일을 이용하는 방법을 기술.

다른 방법은 아래 참고 URL 로 들어가보자.


위 서버 설정에서의 첫번째 줄, push ~~ def1 ~~ 어쩌구 설정을 썼다면 client 설정 파일에 아래 라인들을 포함하면 된다.

route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway


만약 서버에서 def1 옵션을 사용하지 않았을 경우 아래 와 같은 방법으로.(뭐가 다른진 잘 모르겠다)

route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway



+

위 방법까지만 하면 VPN 대역만 라우팅될텐데, 나같이 내부망에 VPN 서버 파두고 쓰는 경우엔 추가로 라우팅 테이블을 수정해야 한다.

내가 사용하려는 내부망은 10.0.0.0/8 대역을 사용하고, DNS 설정도 필요하니 아래와 같이 설정을 추가

route 10.0.0.0 255.0.0.0
dhcp-option DNS 10.0.2.220


DNS 설정의 경우 VPN 클라이언트 옵션에서 "수동으로 설정한 네트워크 설정 변경"을 허용해주어야 한다.

이건 클라이언트마다 다르니 알아서 찾아서 켜주도록 하자.



참고

https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway

https://serverfault.com/a/631048

ubuntu 17 부터인지

ifupdown 대신 netplan 이 네트워크 설정을 담당하고,

기본 nameserver 로는 127.0.0.53, systemd-resolved 가 작동하면서 알아서 질의한다.


같은 시기에 설치한 ubuntu 18 서버 두대 중 한대가 dns 질의가 안되었는데,


$ nslookup google.com

Server: 127.0.0.53

Address: 127.0.0.53#53


** server can't find google.com: SERVFAIL


$ sudo journalctl -u systemd-resolved -f

Jun 26 18:53:46 hostname systemd-resolved[688]: Got packet on unexpected IP range, refusing.



대충 이런 상황...?


원인을 찾아보니 황당하게도 iptables 설정 문제.

포트 포워딩을 하면서 SNAT 을 위해 아래와 같이 설정해두었는데 이게 문제였다.

# iptables -t nat -A POSTROUTING -j MASQUERADE



로컬 인터페이스에 대해서도 SNAT 이 걸려서 뭔가 문제라고 판단을 하였고, 

# iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE

이렇게 네트워크 인터페이스를 지정해주고 문제 해결.


참고로 네트워크 인터페이스 지정을 안해주니 sudo 도 hostname 을 제대로 못찾아서 에러를 낸다.

127.0.1.1 주소를 /etc/hosts 파일에 hostname 과 연결해주면 해결되지만, (또 그렇게 연결해두라고 하지만)

SNAT 설정을 안해두면 애초에 이 문제가 발생하지 않음.


여튼 해결.

'Linux, Server, Web' 카테고리의 다른 글

tar 압축/해제  (0) 2018.09.10
[OpenVPN] client 에서 route 설정하기  (0) 2018.07.31
Heroku + Python + Flask  (0) 2017.12.06
Mac + VirtualBox + Xpenology 설치하기  (0) 2017.11.25
AWS Lambda 에서 RDS + 외부 인터넷 접근  (0) 2017.07.30

Heroku는 Git 을 기반으로 패키지를 업로드한다.

프로젝트와 git 은 이미 만들어져있다고 가정하고, 해당 디렉토리 아래에서 진행한다.


참고로 Python 3.6


0. Prerequisite

heroku cli 바이너리가 필요한데, 맥에서는 그냥 brew 로 설치가능하다.

$ brew install heroku


Python 버전은 3.6 그리고 virtualenv 패키지가 여러개가 있는데, heroku 는 pipenv 를 쓰는 듯?

$ pip install pipenv


$ pipenv install

로 현재 경로에 virtualenv 환경을 만들고,

$ pipenv shell

을 입력하면 알아서 source 해준다.


1. virtualenv 패키지 설치

$ pipenv install 패키지명

으로 설치하면 Pipfile 에 알아서 넣어줌. 다른 방법은 모르겠음.


gunicorn 도 venv 안에 깔아줘야하는지 모르겠지만, 난 그냥 깔아줬다.


그리고 $ pipenv lock 을 하면 PipfilePipfile.lock 파일을 만들어주는데, 이것 역시 git 에 추가해주자.


2. Procfile 생성

heroku 에서 run 할때 어떤 command 를 실행해야하는지를 알려주는 파일이다.

나의 경우 
web: gunicorn flask_app:app
이렇게 한줄만 있으면 되었음.

web 은 heroku 서비스 관련 예약어이고, 그 뒤론 명령어인데
gunicorn 이란 wsgi 패키지를 이용하는 듯.

난 flask_app/__init__.py 의 형태지만,
프로젝트 루트의 flask_app.py 안에 app = Flask(name) 같은 형태도 가능하다.

마찬가지로 git 에 추가.

3. heroku cli

우선 로그인을 하자
$ heroku login

$ heroku local
로 현재 웹을 테스트 해볼 수 있다.

프로젝트 생성은
$ heroku create

이후 소스 푸시 및 빌드는
$ git push heroku master

$ heroku open

하면 주소가 열린다.


기존에 쓰던 맥북을 서버용도로 쓰려고 남겨 뒀는데, 활용도가 크지 않아 판매 후 NAS를 하나 사려다가,

어떤 제품을 고를지 머리 아파져서 그냥 Xpenology 란걸 사용하기로 했다.

데이터 용량이 크게 많이 필요한 것도 아니라서...


Xpenology 는 Synology의 핵펌인 듯


불친절 주의.

아래에서 참고를 했으니 친절을 원하면 저곳으로 가자.


1. VirtualBox 설치

알아서 설치하자


2. Jun's mod 및 DSM(Synology 펌웨어) 다운로드

정식 다운로드 경로는 잘 모르겠고, 여기저기 블로그에서 다운로드 링크를 제공한다.

나는 download.iroot.kr 에서 설치했다.


최신버전은 안될 수도 있다해서 그냥 이 곳에 있는걸 그대로 사용했다.



3. img 변환

부트로더인 synoboot.img 을 .vmdk(VMWare) 혹은 .vdi(VirtualBox)로 변환할 필요가 있다.

맥에 VirtualBox 를 설치했을테니, 

$ VBoxManage convertdd synoboot.img synoboot.vdi --format VDI

로 간단하게 변경하자.


4. VirtualBox 에서 이미지 생성

스샷도 찍어뒀지만... 귀찮다.


대충 아래와 같이 진행하면 된다.

  1. Linux (Other Linux 64-bit)로 생성
  2. RAM 1GB 이상(난 4GB)
  3. 하드디스크 추가 없이 생성
  4. 생성된 이미지 설정
    1. 프로세서 적당히 바꿔주기
    2. 저장소에서 IDE 제거하고
      1. SATA - synoboot.vdi 연결
      2. SCSI - 데이터용 하드 생성
    3. 오디오 사용안함
    4. 네트워크는 첫번째 어댑터는 NAT, 두번째 어댑터를 브리지 모드 (왜 이래야하는지 모르겠지만 이래야 잘됨)
  5. 시작
  6. find.synology.com 접속해서 기다리기
    • 네트워크 설정 때문에 2개가 나올 수 있는데, 무시하고 아무거나 하나 선택하면 됨
  7. 설정 쭉쭉하면 끗


내가 만든 Lambda 함수에서는 AWS RDS 에 접근도 필요했고, 외부 인터넷으로의 접근도 필요했다.

RDS SG(Security Group) 설정상 Lambda 를 VPC 내에 뒀는데, 이러면 Lambda 에서 외부 인터넷으로 접근이 안된다..!


현재 내가 찾은 해결법들은 꼼수 포함 4가지.

1. RDS의 SG설정을 전체 허용, 혹은 Amazon EC2 IP 목록 허용한다.

SG를 전체허용한다면 Lambda 를 VPC 내에 두는 이유가 사라진다.


후자는 Lambda 가 있는 리전의 Amazon EC2 IP 들을 RDS 의 SG 에 때려박아두는 방법.


Amazon 이 사용하는 IP 주소 목록은

https://ip-ranges.amazonaws.com/ip-ranges.json

이 주소에서 JSON 형태로 확인할 수 있다.


관련 설명은 https://docs.aws.amazon.com/ko_kr/general/latest/gr/aws-ip-ranges.html 여기 참고.



대충 위의 접어둔 파이썬 코드를 이용해서,

ap-northeast-2 region 의 EC2 service ip prefix 만 가져온 다음에, 이걸 Security Group 에 넣으면 해결.


Source 에 쉼표로 구분된 값을 넣고 저장하면 알아서 분리된다.


2. AWS에서 제공하는 Managed NAT Gateway를 사용한다.

 VPC 에 Managed NAT Gateway 를 생성하여, VPC 내의 Private subnet 이 외부 인터넷 접속이 가능해주게끔 구성하는 방법

다만 이 NAT Gateway 비용이 월 $40가 넘는다...


3. 외부 인터넷으로 접근하는 함수, VPC 내에서 DB에 접근하는 함수 두개를 만들어 함께 사용한다.

Lambda 비용이 두배로 들겠지만, 어차피 1백만회를 초과할 것 같지도 않고, 초과해도 NAT Gateway 비용보다는 쌀 것 같달까...


다만, VPC 설정이 된 람다함수는 다른 람다함수를 호출할 수 없다. 람다 호출 자체가 외부 인터넷을 사용하는 셈이라..

VPC 밖의 함수를 A(외부 인터넷 연결 가능), VPC 안의 함수를 B 라고 한다면,

항상 A 호출 -> A에서 B를 호출하여 DB작업 -> A에서 결과를 받아서 후처리 -> 반환

의 형태를 취해야한다. 경우에 따라 상관없을 수도 있지만 비효율적으로 될 수도 있는 방법.


4번의 방법을 몰랐기 때문에 난 이렇게 구성해뒀다.


4. ec2 로 NAT instance 를 직접 구축한다.

AWS 에 문서가 있다. -> VPC NAT Instances


후에 시간있을때 적용해볼 예정.

위 글에선 미리 만들어진 AMI를 사용하는데, 나는 기존 Ubuntu Instance 를 어떻게 활용해볼 예정이다.


AWS RDS 의 mysql 혹은 mariadb 서버의 기본 타임존 설정은 UTC 이다.

클라이언트에서 timezone 설정이 되니 굳이 바꿔줄 필요는 없었지만... db 직접 접속했을때 내가 불편해서 값을 바꿔보았다.





AWS 콘솔에서 RDS 로 이동 후 Parameter Groups 에서 새 그룹을 먼저 만들어준다.

서버가 실행될때 파라미터들을 설정해주는 그룹인데, 하나의 인스턴스가 동시에 여러개의 그룹을 가질 수는 없는 것 같다.





그걸 몰랐기에 난 이름을 대충 timezone-kst 로 만듦.(중요하진 않다.)


Group Family 는 자기가 사용하는 Instance에 맞춰주자.







생성된 그룹을 선택 후 Edit Parameters 를 선택하고,

time_zone 값을 찾아서 원하는 지역으로 설정 후 저장한다.







이제 다시 Instance 메뉴로 돌아와, 타임존을 변경할 Instance 를 수정한다.



변경된 설정은 Instance 가 재부팅된 후에 적용된다.

그냥 두면 Maintainance 시간에, Apply Immediately 옵션을 체크하면 그거보단 조금 이르게 적용되겠지만,

난 당장 결과를 보고 싶으니 콘솔에서 직접 Reboot 했다.





완료.


타임존이 바뀔 뿐이기 때문에 정상적으로 프로그래밍을 해왔다면 기존 테이블의 Timestamp 데이터 등도 신경 쓸 필요가 없다. (변경된 Timezone 에 맞게 표시된다)




참고:

https://aws.amazon.com/ko/premiumsupport/knowledge-center/rds-change-time-zone/

+ Recent posts