지난번에 오라클과 제 나스에 시도했었으나 iptables를 비롯한 온갖 보안툴로 인해 실패했습니다.
게다가 이 글에서 소개할 이유 때문에 오라클 인스턴스와 제 나스가 연결이 되었다고 해도 실패했을 것입니다.
swarm을 시도하게 된 배경
독커 공식 문서에 따르면 3,5, 7 대.. 홀수 개의 매니저를 권장합니다.
기존에는 웹서버와 관련된 모든 서비스를 하나의 머신에, VPN 관련 서비스를 또 다른 머신에 넣어두었었습니다.
하지만 이번에 초고성능의 머신이 추가되었고, arm에서 실행 불가능한 앱을 제외하고는 모두 A1 인스턴스로 옮겼습니다.
문제는 litespeed 웹서버와 데이터베이스, memcached가 서로 다른 머신에 설치되었다는 것입니다.
그리고 제가 독커를 좋아하는 이유를 백번 활용하기 위해서는 서로 다른 머신에 하나의 네트워크를 구성하는 overlay 네트워크가 필요했습니다.
독커를 좋아하는 이유
바로 독커 네트워크가 DNS를 제공해주기 때문입니다.
docker-compose.yml 파일을 보면 아래와 같은 형식으로 이루어집니다.
# docker-compose.yml
version: '3.4'
networks:
default:
external:
name: d_strict
services:
mariaSQL:
container_name: ls.db
image: mariadb:latest
restart: always
volumes:
- "./data/db:/var/lib/mysql:delegated"
litespeed:
container_name: ls.litespeed
image: litespeedtech/openlitespeed:latest
volumes:
- ./lsws/conf:/usr/local/lsws/conf
- ./lsws/admin-conf:/usr/local/lsws/admin/conf
- ./sites:/var/www/vhosts/
- ./logs:/usr/local/lsws/logs/
- /dev/shm:/dev/shm
ports:
- 80:80
- 443:443
- 443:443/udp
- 2096:7080
restart: always
environment:
TZ: Asia/Seoul
LC_ALL: C.UTF-8
이 때 litespeed는 db에 접속할 때 ip를 이용할 수도 있지만 mariaSQL이나 ls.db를 이용해 접근할 수 있습니다.
또한 포트를 개방해주지 않아도 됩니다.
만약 위 예시에서 mariaDB는 10.1.1.1을 게이트웨이로 갖는 네트워크에 연결되어있고, litespeed는 10.1.2.1을 게이트웨이로 갖는 네트워크에 연결되었다고 가정해봅시다.
그렇다면 아래와 같은 형식의 독커 컴포즈가 작성될것입니다.
# docker-compose.yml
version: '3.4'
services:
mariaSQL:
container_name: ls.db
image: mariadb:latest
restart: always
networks:
- a
port:
- 3306:3306
volumes:
- "./data/db:/var/lib/mysql:delegated"
litespeed:
container_name: ls.litespeed
image: litespeedtech/openlitespeed:latest
networks:
- b
volumes:
- ./lsws/conf:/usr/local/lsws/conf
- ./lsws/admin-conf:/usr/local/lsws/admin/conf
- ./sites:/var/www/vhosts/
- ./logs:/usr/local/lsws/logs/
- /dev/shm:/dev/shm
ports:
- 80:80
- 443:443
- 443:443/udp
- 2096:7080
restart: always
environment:
TZ: Asia/Seoul
LC_ALL: C.UTF-8다른 점은 3가지입니다.
첫번째는 당연하지만 가장 위에서 네트워크를 지정하지 않고 머신마다 지정하게 되었다는 점이고
두번째는 mariaDB에 포트 개방 옵션이 추가되었다는 점입니다.
하나의 네트워크 안에 있을 때는 (ip주소):(포트)로 접속하면 포트 포워딩이 되어있지 않아도 접속이 가능합니다.
포트 개방은 네트워크 밖에서 연결할때 필요한 것이죠.
이건 다르게 말하면 80포트를 사용하는 컨테이너가 100개가 실행될수 있다는 것입니다.
단지 리버스 프록시 서버가 네트워크 안에 하나가 있다면 192.168.0.1:80, 192.168.0.1:80, 192.168.0.1:80과 같은 타겟으로 리버스 프록시만 구성해주면 작동하기 때문이죠.
제가 swarm을 적용하려고 하는 oracle free tier 환경에서는 swarm 스택 서비스는 잘 작동하지 않습니다.
일단 아키텍처부터 다르기 때문이죠..
하지만 저는 overlay 하나만을 위해 swarm을 시도해보았습니다.
swarm 시도 첫번째 실패
더 성능이 좋은 A1 인스턴스에서 docker swarm init을 시도합니다.
그리고 docker swarm join-token manager를 입력하여 매니저를 추가하는데 필요한 명령어를 구합니다.
다른 머신에서 docker swarm join --token <token> <ip>:2377을 입력합니다.
실패..
오라클 보안목록에서 분명히 허가 해줬다고 생각했는데 불가능했습니다.
이유는 간단했습니다.
소스 포트를 전체로 해줘야 했더군요..
swarm 시도 두번째
이번에도 실패했습니다.
분명 오라클은 통과했는데 왜 안될까..
iptables를 보니 icmp 를 막는 iptables의 차단 횟수가 계속 증가하더군요.
그래서 icmp 막는 규칙을 삭제했습니다.
swarm 구성 성공. 재부팅시 복구 불능.
진짜 문제는 여기였습니다.
분면 swarm이 구성되었고 두 머신 모두 leader가 될 수 있었지만 두 머신 중 한대라도 껏다켜면 다시 swarm 네트워크가 복구되지 않았습니다.
인터넷을 찾아보니 3대부터 사용하는 것을 권장한다고 하더군요.
그래서 머신 한대를 추가해보았습니다.
swarm 구성 성공. 재부팅 복구 가능
너무 웃긴게 이 부분이었습니다.
3대 중 2대를 동시에 재부팅을 해도 결국 3대가 켜지면 복구가 된다는 것입니다.
2대 중 1대를 재부팅하여 1대만 살아 있을 때는 복구가 안되더니, 3대 중 2대 종료는 복구가 가능..
심지어 3대 모두 동시에 재부팅을 하여도 살아납니다.???
결국 스웜은 최소 3대가 필요하다는 것이지요.
과연 쓸모가 있을까?
swarm 단독모드 장점
장점은 포트를 따로 오픈할 필요가 없다는 것입니다.
swarm 통신에 사용하는 두개의 TCP, 두개의 UDP만 오픈해준다면 새로운 독커 컨테이너를 추가한다 할지라도 따로 오라클 보안 목록을 건드린다거나 다른 머신의 포트를 확인할 필요를 줄일 수 있습니다.
swarm이 없었다면 80포트 같이 흔한 포트를 사용하는 서비스의 경우 다른 컨테이너에서 사용중인지도 확인해야하고, 포트를 변경함에 따라 연결하는 머신에서도 포트 변경이 필요합니다.
swarm을 사용하고 있다면 오라클에서 프리티어를 중단한다고 하여 다른 곳으로 넘어간다고 해도 그대로 옮겨가서 그대로 실행하면 문제 없이 사용 가능하겠죠.
swarm 단독모드 단점
하지만 swarm을 위해서는 꽤 많은 희생이 필요합니다.
스토리지 성능 하락도 있고, 디스크 용량에서도 큰 손해를 보며 생각보다 독커 네트워크의 dns가 느리다는 것입니다.
wordpress에서 ip로 db에 접속하는 것과 컨테이너 이름으로 접속할 때 DOM 불러오는 데에는 0.5초 이상의 지연이 존재합니다.
페이지 전체를 불러오는데에는 평균 1초의 지연이 존재했습니다.
오차 범위라고 하기에는 최대 최소 평균 모두 그러했고,
초반에는 캐시 때문일수도 있다고 생각하여 접속 방법을 번갈아가며 바꿔서 20회 정도 시도했으나 차이는 분명히 크게 존재했습니다.
아마 swarm leader로 둔 public IP가 존재하지 않는 E2를 없애버리고 그 스토리지까지 다른 머신에 나눠준다면 더 차이가 크지 않을까 생각합니다.
답글 남기기