서론

최근 SSO 서버 개발을 진행하였는데, 테스트를 진행함에 있어 서로 다른 두 도커 컴포즈로 구성된 프로젝트간에 API 요청이 필요한 상황이 발생하였다. 이 과정에서 네트워크 설정에 관해 학습한 내용 및 트러블슈팅을 기록으로 남기고자 한다

본론

In Docker Compose

도커 컴포즈(Docker Compose)란 다수의 도커 컨테이너(Docker Container)들로 이루어진 애플리케이션을 보다 간편하게 관리하기 위한 도구이다. 이러한 도커 컴포즈로 구성된 프로젝트를 빌드할 경우 기본적으로 내부 컨테이너들간의 통신을 위한 default 네트워크를 생성한다. 일반적으로 프로젝트명_default 형식으로 생성된다.

아래와 같은 도커 컴포즈 파일(docker-compose.yml)이 있을 때 구성된 네트워크를 살펴보면 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

# docker-compose.yml

version: "3"

services:
  django: &django
    build:
      context: ..
      dockerfile: ./bin/compose/production/django/Dockerfile
    image: my_project_django
    depends_on:
      - postgres

  postgres:
    build:
      context: .
      dockerfile: ./compose/production/postgres/Dockerfile
    image: my_project_postgres

  nginx:
    build:
      context: ..
      dockerfile: ./bin/compose/production/nginx/Dockerfile
    image: my_project_nginx
    ports:
      - "8412:80"
    depends_on:
      - django

1
2
3
4
5
6
7
8
9

# 활성화된 도커 네트워크 확인

> docker network ls

NETWORK ID     NAME                        DRIVER    SCOPE
45afd37df4f2   bridge                      bridge    local
024ac5a121bb   host                        host      local
c2ad1c8aeadf   none                        null      local
fced302c4d64   my_project_default          bridge    local

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

# 활성화된 도커 네트워크 상세 정보

> docker network inspect my_project_default

[
    {
        "Name": "my_project_default",
        "Id": "34d046c7981b88c2df9dd4aacf5b130e4a92bf9c99bbc6d11e6c074bf72ab326",
        "Created": "2024-02-27T05:04:59.280736237Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.128.0/20",
                    "Gateway": "192.168.128.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "01253d81aab5bc696bfff747e562b6efa49caf9ff12a89e012cfaae3f4671861": {
                "Name": "my_project-nginx-1",
                "EndpointID": "a5a33350d0e2cacfaff9d270ceffd6397dacd2622e78802b5f01b9282a66d181",
                "MacAddress": "02:42:c0:a8:80:05",
                "IPv4Address": "192.168.128.3/20",
                "IPv6Address": ""
            },
            "3feff36c3541910f679b04adba1076dcd6588ed5d830072b645a4ffff633b86e": {
                "Name": "my_project-django-1",
                "EndpointID": "39614375de2f40039e890c01ad047b42074d051efb91ee70721b48ca930dc33a",
                "MacAddress": "02:42:c0:a8:80:04",
                "IPv4Address": "192.168.128.4/20",
                "IPv6Address": ""
            },
            "9499f051f6d855a5b8c21e9c420fa2b284da70f98f3203d3ac6182f2cd952eae": {
                "Name": "my_project-postgres-1",
                "EndpointID": "f4b38c73cff5c428857cfee1b56469accafa473137714cb8f028e21e6b952959",
                "MacAddress": "02:42:c0:a8:80:02",
                "IPv4Address": "192.168.128.2/20",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "my_project",
            "com.docker.compose.version": "2.23.3"
        }
    }
]

서론

목적

진행하는 프로젝트는 다른 외부 서비스로부터 우리 서비스에서 필요로하는 데이터를 수신받아야 하는데, 해당 외부 서비스에서 지원하는 DB가 MS SQL, Oracle 두 종류로 국한되는 상황이다. 반면 우리 프로젝트에서 사용할 DB는 PostgreSQL 이다. 때문에 해당 외부 서비스로부터 데이터아 우리 서버로 옮겨줄 중계 DB가 필요한데, 이를 Naver Cloud Platform 내 클라우드 서버를 통해 수신받을 예정이다. 해당 클라우드 서버 설정은 이전에 다루었고 이번엔 수신받은 데이터를 어떻게 우리 서버로 옮길지에 대해 다루도록 하겠다.

고찰

네이버 클라우드상에 위치한 DB 서버로부터 데이터를 추출하기 위해선 다양한 방법이 있을 것 같다. 우선적으로 여러 방법들 중 어떤 방법이 가장 적절한지에 대해 고민하는 것이 선행되어야 할 필요가 있다. CSV 파일을 추출하여 Gitlab에 업로드하는 것도 고려하였으나, 사원 정보를 Gitlab과 같은 퍼블릭 저장소에 올리는 것은 적절한 방법이 아닌 것 같아 고려하지 않았다.

방법

가장 처음 생각한 것은 데이터베이스에 데이터가 INSERT 되는 것을 감지하여 일련의 작업을 수행하는 것이었다. 찾아보니 MSSQL Trigger를 통해 데이터가 INSERT 되는 것을 감지할 수는 있으나, 해당 코드는 SQL 쿼리문으로만 작성되어야 했다. 수신 DB가 MSSQL로 동일하게 구현되었을 경우는 SQL 쿼리문을 통해 데이터 복사가 가능하였으나, 본 프로젝트엔 수신 DB가 PostgreSQL로 구현될 예정이기에 해당 방법은 배제하였다.

스크립트를 통한 자동화

서론

최근 회사 업무로 인해 네이버 클라우드 플랫폼(이하 NCP)에 MS SQL DB를 구축해야 할 일이 생겼다. 이에 자료를 찾아보니 Window 환경에서 MS SQL을 구축하는 정보들은 다수 존재하나 macOS 환경에서 구축하는 글은 드물어 관련 경험을 기록하고자 한다.

본론

NCP 설정

기본적으로 MS SQL을 NCP에서 호스팅하기 위해선 2가지 방법이 존재한다.

Cloud DB for mssql

• MSSQL을 위한 DBMS 및 각종 툴들이 설치된 상태
• 별도의 데이터베이스 설정 없이 웹상에서 바로 모니터링 및 이용 가능
• 스탠다드 기준 한달 62만원 정도의 비용 발생

Basic Server

• 기본 Linux 서버로, MSSQL을 호스팅하기위한 별도의 설정이 필요함
• Ubuntu 18.04 환경
• 스탠다드 기준 한달 7만원 정도의 비용 발생

서론

이전 글을 통해 Docker-compose 구성을 통한 각 서버별 Docker Container들을 구성하였는데, 진행하다 보니 CI 자동화도 알아보고 싶어 이에 대해 다루고자 한다. 본 글에서는 AWS EC2 인스턴스 내 Jenkins를 통해 CI 자동화에 대해 다루고자 한다. 현재 회사 특성상 CD 까지 진행하는데 어려움이 있을 듯 해 ‘CI/CD’가 아닌, CI만을 다루고자 한다.

본론

CI/CD 란?

CI = 지속적인 통합(Continuous Integration)을 의미하는 단어로 ‘빌드와 테스트’를 자동화한 것이다.

CD = 지속적인 전달(Continuous Delivery) or 지속적인 배포(Continuous Deployment)를 의미하는 단어로 CI가 완료된 이후 사용자에게 전달하는 배포 과정을 자동화한 것이다.

즉, CI는 개발 과정에서 필요한 빌드 및 테스트 단계를 자동화한 것이고 CD는 테스트가 완료된 코드를 사용자에게 전달하기 위한 도구이다.

프로젝트 구성

서론

Nginx(엔진엑스) 에 대해 찾아보는 와중 기존 내가 알고있던 웹 서버(Web Server)에 대한 개념이 상충하는 것이 있어 이를 정리하고자 한다. 본 글에서는 Web Server와 WAS의 개념 비교부터 시작하여 가장 보편적으로 사용되는 Web Server 엔진 및 실제 사용될 수 있는 프로젝트 구성을 Docker-compose를 통해 구성해보고자 한다.

본론

Web Server

위키백과에 정의된 웹 서버에 대한 정의는 다음과 같다

웹 서버(Web server)는 다음의 두 가지 뜻 가운데 하나이다.

1. 웹 서버: 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아들이고, HTML 문서와 같은 웹 페이지를 반환하는 컴퓨터 프로그램
2. 웹 서버 (하드웨어): 위에 언급한 기능을 제공하는 컴퓨터 프로그램을 실행하는 컴퓨터

웹 서버(web server)는 HTTP 또는 HTTPS를 통해 웹 브라우저에서 요청하는 [HTML 문서나 오브젝트(이미지 파일 등)을 전송해주는 서비스 프로그램을 말한다. 웹 서버 소프트웨어를 구동하는 하드웨어도 웹 서버라고 해서 혼동하는 경우가 간혹 있다.

출처 : https://ko.wikipedia.org/wiki/웹_서버

위에 정의된 바와 같이 웹 서버란 HTTP, HTTPS 통신 프로토콜을 통해 사용자가 요청하는 HTML 문서나 오브젝트, 즉 정적인 파일들을 전달해주는 서비스 프로그램을 말한다. 다만 이러한 정적인 페이지들의 경우 과거에는 충분하였을 지 모르나 기술이 발달한 요즘 시대에는 부족한 것이 사실이다. 이러한 태생적인 한계를 극복하기 위한 것이 WAS(Web Application Server) 이다.