원래의 Python + Poetry 프로젝트를 배포 방식 인터넷이 연결된 서버에 소스 코드를 배포한 뒤, `poetry install` 명령 하나로 필요한 Python 패키지들을 자동으로 설치 이 과정에서 Poetry는 `pypi.org`에서 패키지를 받아오고, `.cache/virtualenvs` 아래에 가상환경이 구성됨 하지만 서버를 현장에 설치해야하고 현장은 보안 때문에 인터넷을 연결할 수 없음 인터넷이 없는 서버에서 Python + Poetry 프로젝트 배포 가상환경 이 같은 빌드용 리눅스 PC 한 대를 준비하여 빌드를 해서 빌드한 파일을 가져가 서버에 배포 빌드한 가상환경 과 소스코드를 서버에 배포해야하는데가상환경은 /.cache/virtualenvs 경로에, 소스코드는 또 다른 경로에 있어서경..

초기엔 각각의 Nomad job 파일을 별도로 작성해 배포 서비스가 늘어날수록 관리가 복잡해지고, Job 하나 바꿀 때마다 다른 서비스와의 연결 상태가 깨지거나 누락되는 문제가 발생' 아래와 같이 하나의 파일로 비슷한 유형의 서비스 일괄 배포 가능하도록 수정api-service : api task들을 group 단위로 모아 실행database-service : service들을 group 단위로 모아 실행persist-infra : system-infra와 DB등 고가용성 서비스들을 모아 실행이외에도 device관련 계층 등의 서비스를 모아 실행job "persist-infra" { datacenters = ["dc1"] group "persist-infra-group" { count = 1 ..

프로젝트를 하면서 ‘버전 관리’는 그냥 Git commit log를 정리하는 수준이라고 생각 하지만 실제로 서비스를 운영하고, 배포 환경을 다루고, 긴급 상황에서 이전 상태로 롤백하거나 특정 시점의 설정을 되살려야 했던 경험을 겪고 버전 관리의 중요성을 느낌 개발과 배포를 효율적으로 정리하기 위해 X.Y.Z 형식으로 세자리 버전 넘버링 방식 사용 각 숫자의 의미를 다음과 같이 정함X : 서비스의 아키텍처 등이 크게 바뀌는 경우Y : 기능이 새로 추가되거나 UI/UX가 바뀌는 경우Z : 버그 수정, 오타 수정 등이 되는 경우 실제 배포 흐름 (v0.1.4) 1. 프론트엔드 빌드 - 빌드한 파일 압축 후 서버로 전송2. DB 변경 - mongo compass로 컬렉션 import3. 백엔드 배포 - 서버 ..