처음의 목표
엘라스틱 서치 db를 구축하는 것이 목표였고, 이를 위해 리서치를 진행한 결과 엘라스틱서치보다 aws에서 오픈소스화한 오픈서치를 설치하는 것이 맞다고 판단하였습니다.
이를 위해 진행한 단계를 설명드리겠습니다.
우선 첫번째로는 aws rds에서 elsaticsearch나 opensearch db를 지원해주지 않기 때문에 aws에서 진행하는 Amazon OpenSearch Service로 진행하려 하였으나, 이는 구동에 들어가는 최소한의 서버스펙으로도 월 십몇만원에 달하는 비용이 들것으로 추산되었기 때문에 다른 방법을 찾기로 하였습니다.
두번째로는 aws ec2에서 opensearch를 설치하여 ec2로 db를 사용하려는 시도를 하였으나, 이마저도 현재는 테스트가 목적인데도 불구하고 opensearch는 구동에 최소 ram이 1기가(실제로는 1.5기가 이상)정도가 필요하기 때문에 ec2비용이 꽤 나올것이라 판단하여 취소하였습니다. (실제로 설치까지 완료하고 db를 구동시켰으나 ram이 부족하다는 경고문구가 떴습니다.)
따라서 그 이후에는 제 로컬환경에 우선 설치해서 테스트를 진행하는 방향으로 선회하였고, 그 과정에서 여러 방법을 시도하여 opensearch환경을 구축하려 시도하였습니다만 java와 jdk를 깔아야 하는 등 여러 복잡한 과정속에서 실패하였고, 최종적으로 도커를 사용하여 설치한 후 구동하게 되었습니다.
도커란?
Docker는 오픈 소스 소프트웨어로, 컨테이너라는 개념을 사용하여 애플리케이션을 패키징하고 배포하는 것을 돕습니다.
컨테이너는 가벼운 및 독립적인 '패키지'로, 어떤 환경에서든 일관되게 실행되도록 애플리케이션과 그에 필요한 모든 종속성을 포함합니다. 컨테이너는 호스트 운영 체제의 커널을 공유하지만 프로세스 공간을 격리하므로, 각 컨테이너는 별도의 시스템으로 동작합니다. 이는 컨테이너가 가상 머신보다 훨씬 적은 오버헤드와 더 빠른 시작 시간을 가지게 해줍니다.
Docker를 사용하면, 개발자는 애플리케이션을 개발하고 패키지화한 후, 이를 다른 컴퓨터나 서버에서 그대로 실행할 수 있습니다. 이는 "내 컴퓨터에서는 잘 동작하는데, 다른 컴퓨터에서는 왜 안 동작하지?"와 같은 문제를 해결해줍니다.
따라서 "Docker 컨테이너에서 실행된다"는 것은, 해당 애플리케이션(이 경우엔 OpenSearch)이 Docker 컨테이너라는 독립적인 환경에서 실행된다는 것을 의미합니다. 이렇게 하면, 해당 애플리케이션을 실행하기 위한 모든 종속성과 설정이 컨테이너에 미리 패키지화되어 있으므로, 사용자는 복잡한 설치 과정 없이 손쉽게 애플리케이션을 실행할 수 있습니다.
도커로 opensearch 설치하는 과정
Docker 설치: Docker가 로컬 환경에 아직 설치되어 있지 않다면, Docker 공식 홈페이지에서 해당 운영체제에 맞는 Docker 설치파일을 다운로드하고 설치합니다.
Docker OpenSearch 이미지 실행: 아래 명령어를 통해 Docker에서 OpenSearch 이미지를 다운로드하고 컨테이너를 실행합니다.
docker run -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" opensearchproject/opensearch:latest
이 명령어를 통해 Docker는 opensearchproject/opensearch:latest 이미지를 DockerHub에서 찾아 다운로드합니다. 이 이미지는 OpenSearch를 실행하기 위한 모든 종속성과 설정이 이미 패키지화된 상태입니다. docker run 명령은 이미지를 컨테이너로 실행하는 작업을 수행합니다. -p 플래그는 컨테이너와 호스트 사이에 포트를 매핑하며, -e 플래그는 컨테이너에 환경 변수를 설정합니다.
OpenSearch 접속: Docker 컨테이너가 성공적으로 실행되면, 웹 브라우저에서 http://localhost:9200으로 접속하여 OpenSearch가 제대로 실행되었는지 확인할 수 있습니다.
이런 방식으로 Docker를 이용하면 OpenSearch를 로컬 환경에 직접 설치하고 설정하는 수고를 덜 수 있습니다. 하지만 Docker에 대한 이해가 필요하며, 또한 실행 중인 Docker 컨테이너는 시스템 리소스를 소비하므로 이 점에 유의해야 합니다.
명령어 디테일
1. `docker run`: Docker 명령어의 일부로, Docker 이미지를 컨테이너로 실행합니다.
2. `-p 9200:9200 -p 9600:9600`: `-p` 플래그는 컨테이너의 포트를 호스트의 포트와 매핑합니다. 이 예제에서는 컨테이너의 9200번 포트를 호스트의 9200번 포트에, 컨테이너의 9600번 포트를 호스트의 9600번 포트에 매핑하고 있습니다. 즉, 호스트 시스템에서 9200번 및 9600번 포트를 통해 OpenSearch 서비스에 접근할 수 있습니다.
3. `-e "discovery.type=single-node"`: `-e` 플래그는 컨테이너에 환경변수를 설정하는 역할을 합니다. 여기서는 "discovery.type" 환경변수를 "single-node"로 설정하여 단일 노드로 실행되도록 합니다. 이렇게 하면 OpenSearch가 클러스터를 형성하려는 시도를 하지 않고 단독으로 실행됩니다. OpenSearch는 여러 서버 또는 "노드" 간에 데이터와 작업을 분산할 수 있는 기능을 가지고 있습니다. 이렇게 여러 노드로 구성된 그룹을 "클러스터"라고 합니다.
클러스터는 여러 노드가 함께 작업하며, 데이터를 분산 저장하고 처리할 수 있습니다. 이는 고 가용성, 부하 분산, 고성능 검색 및 분석 기능을 가능하게 합니다.
그러나 단일 노드 환경에서는 클러스터를 형성할 필요가 없습니다. 이 경우, discovery.type=single-node를 환경 변수로 설정하면 OpenSearch는 자체를 단독 노드로 간주하고 클러스터 형성을 시도하지 않습니다. 이렇게 하면 OpenSearch의 초기 구성이 간단해지고, 단독 서버에서의 실행이 더욱 안정적이게 됩니다.
4. `opensearchproject/opensearch:latest`: 이 부분은 실행할 Docker 이미지를 지정합니다. 여기서는 opensearchproject의 opensearch 이미지를 사용하고 있으며, `:latest`는 이 이미지의 최신 버전을 사용하겠다는 의미입니다.
따라서 이 명령어는 DockerHub에서 opensearchproject의 최신 opensearch 이미지를 다운로드하고, 이 이미지로 Docker 컨테이너를 생성하며, 이 컨테이너는 단일 노드로 실행되고 호스트 시스템의 9200번 및 9600번 포트를 통해 서비스를 제공합니다.
주의할점
로컬 환경에 설치하고 실행한 후, 파이썬장고서버와 터미널에서 오픈 서치에 접속을 시도하였으나 번번히 실패하였습니다. 그 이유는 ssl인증 때문이었습니다. OpenSearch는 보안상의 이유로 기본적으로 SSL/TLS 인증을 요구합니다. 하지만, Docker 컨테이너 내에서 테스트 목적으로 실행하는 경우 SSL/TLS 인증을 비활성화할 수 있습니다.
먼저, OpenSearch의 환경 설정을 변경해야 합니다. Docker를 이용한 OpenSearch의 실행 명령어를 다음과 같이 수정합니다:
docker run -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" -e "plugins.security.disabled=true" opensearchproject/opensearch:latest
여기서 `"plugins.security.disabled=true"`는 보안 플러그인을 비활성화하는 환경 변수입니다. 이렇게 설정하면 SSL/TLS 인증을 비활성화할 수 있습니다.
하지만, 이렇게 설정한 OpenSearch 인스턴스는 공개 네트워크에서 사용하기에 적합하지 않습니다. 데이터를 암호화하지 않으므로 보안이 매우 취약합니다. 따라서 이 설정은 로컬 개발 환경에서 테스트 목적으로만 사용해야 합니다.
또한, 이 설정은 OpenSearch의 다른 보안 기능들도 비활성화합니다. 예를 들어, 사용자 인증 및 권한 설정, 인덱스 레벨 보안, 오디트 로깅 등이 비활성화됩니다. 이런 기능들이 필요하면서 SSL/TLS 인증만 비활성화하고 싶다면, OpenSearch의 YAML 설정 파일을 직접 수정하여 특정 보안 기능만 비활성화하는 방법을 고려해야 합니다. 그러나 이 방법은 복잡하고, 실수로 중요한 보안 기능을 비활성화할 위험이 있으므로 주의가 필요합니다.
'server' 카테고리의 다른 글
| server - 서버 시간 관리 및 도커 환경에서의 시간 관리 (0) | 2024.02.21 |
|---|---|
| server - Docker 이미지 최적화: .git 디렉토리 제외하기 (0) | 2024.02.20 |
| server - 상태 유지 서버와 무상태 서버 이해하기: 비교 분석 (0) | 2023.06.12 |
| server - Read Committed와 Repeatable Read의 차이 (0) | 2023.06.06 |
| server - 장고와 데이터베이스에서의 스키마 이해하기 (0) | 2023.06.06 |