Development Note

version: '3' services: planka: image: ghcr.io/plankanban/planka:latest restart: on-failure volumes: - user-avatars:/app/public/user-avatars - project-background-images:/app/public/project-background-images - attachments:/app/private/attachments ports: - 3000:1337 environment: - BASE_URL=http://plank.example.com:3000 - DATABASE_URL=postgresql://postgres@postgres/planka - SECRET_KEY=secret - DEFAULT_ADMIN_EMAIL=admin@example.com # Do not remove if you want to prevent this user from being edited/deleted - DEFAULT_ADMIN_PASSWORD=Password - DEFAULT_ADMIN_NAME=Admin - DEFAULT_ADMIN_USERNAME=admin depends_on: postgres: condition: service_healthy postgres: image: postgres:14-alpine restart: on-failure volumes: - db-data:/var/lib/postgresql/data environment: - POSTGRES_DB=planka - POSTGRES_HOST_AUTH_METHOD=trust healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d planka"] interval: 10s timeout: 5s retries: 5 volumes: user-avatars: project-background-images: attachments: db-data:

Docker Compose 파일 분석: Planka 애플리케이션 실행 환경 구성 이 Docker Compose 파일은 Planka라는 애플리케이션을 실행하기 위한 두 가지 서비스, planka와 postgres를 정의하고 있습니다. 각 서비스는 Docker 컨테이너로 실행되며, 서로 연결되어 애플리케이션을 구성합니다. 1. planka 서비스 image: ghcr.io/plankanban/planka:latest: Planka 애플리케이션의 최신 이미지를 사용하여 컨테이너를 생성합니다. restart: on-failure: 컨테이너가 실패하면 자동으로 재시작합니다. volumes: 컨테이너 내부 디렉토리와 호스트 시스템 디렉토리를 연결합니다. user-avatars, project-background-images, attachments: 사용자 아바타, 프로젝트 배경 이미지, 첨부 파일을 저장하는 디렉토리를 각각 연결합니다. ports: 컨테이너의 1337 포트를 호스트 시스템의 3000 포트에 연결합니다. 즉, http://localhost:3000 으로 접속하면 Planka 애플리케이션에 접근할 수 있습니다. environment: 애플리케이션 실행에 필요한 환경 변수를 설정합니다. BASE_URL: 애플리케이션의 기본 URL을 설정합니다. DATABASE_URL: PostgreSQL 데이터베이스 연결 정보를 설정합니다. SECRET_KEY: 애플리케이션 보안을 위한 암호화 키를 설정합니다. DEFAULT_ADMIN_EMAIL, DEFAULT_ADMIN_PASSWORD, DEFAULT_ADMIN_NAME, DEFAULT_ADMIN_USERNAME: 기본 관리자 계정 정보를 설정합니다. depends_on: postgres 서비스가 "healthy" 상태가 될 때까지 planka 서비스 시작을 기다립니다. 2. postgres 서비스 image: postgres:14-alpine: PostgreSQL 14 버전의 Alpine Linux 기반 이미지를 사용하여 컨테이너를 생성합니다. restart: on-failure: 컨테이너가 실패하면 자동으로 재시작합니다. volumes: 데이터베이스 데이터를 저장하는 디렉토리를 호스트 시스템에 연결합니다. environment: 데이터베이스 이름(POSTGRES_DB)을 설정하고, 호스트 기반 인증 방식(POSTGRES_HOST_AUTH_METHOD)을 사용합니다. healthcheck: 컨테이너의 상태를 주기적으로 확인하여 정상적으로 실행 중인지 확인합니다. pg_isready 명령어를 사용하여 PostgreSQL 서버가 준비되었는지 확인합니다. 3. volumes user-avatars, project-background-images, attachments: 이름만 정의된 볼륨입니다. Docker Compose는 이 볼륨들을 자동으로 생성하고 관리합니다. db-data: PostgreSQL 데이터베이스 데이터를 저장하는 볼륨입니다. 요약: 이 Docker Compose 파일은 Planka 애플리케이션과 PostgreSQL 데이터베이스를 Docker 컨테이너로 실행하고, 필요한 설정 및 연결을 구성하여 애플리케이션 실행 환경을 구축합니다.

1. 기술 블로그 내용 1회 정독 2. Container 기술 및 Docker container 사용법 익히기 (기술블로그 Docker vs. Kubernetes 참조) 3. Grafana+Prometheus에 대한 개념 익히기 4. Grafana에서 Alert 추가하기 (grafana.slowplat.com) (id: slowadmin, p/w: slowgrafana@4411) - 각 서버 서비스 포트 모니터링 및 서비스 포트에 이상이 있을때 Alert 보내기 (mailto: tony.cho@slowplat.com, leo.heo@slowplat.com)

git switch -c jenkins_pipline_test --track origin/develop git switch -c jenkins_pipeline --track origin/develop git switch -c deploy-test --track origin/develop # 로컬에서 브랜치 삭제하기 명령어 git branch -d localBranchName(로컬의 브랜치 이름) # 원격에서 브랜치 삭제하기 명령어 git push origin --delete remoteBranchName(원격 브랜치 이름)

git submodule init git submodule update cd env && ./file_crypto.sh dec && cd - && cd android/app/signing && ./file_crypto.sh dec && cd -

flutter build apk --release --target-platform=android-arm64

# GitLab 토큰 : tok glpat-c_5G2BVyz2wKS5ZcBvHE

# 빌드 명령어 flutter build appbundle --obfuscate --split-debug-info=./build/debug_info

1. docker 명령어 숙지. 2. 서버 인스턴스에 접근하여 컨테이너 내부에 있는 파일을 외부로 복사하거나 반대로 외부의 내용을 내부로 복사할 수 있어야 함. 3. do

# docker port # api CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 149105e3901d slowtalk.kr-central-2.kcr.dev/slowtalk/api-dev:latest "supervisord -c /etc…" 4 hours ago Up 4 hours 9000/tcp, 0.0.0.0:39000->8000/tcp, :::39000->8000/tcp api-dev-container 27ac0c4ba7c3 gcr.io/cadvisor/cadvisor:latest "/usr/bin/cadvisor -…" 7 weeks ago Up 10 days (healthy) 0.0.0.0:8090->8080/tcp, :::8090->8080/tcp cadvisor 840af957a918 prom/node-exporter:latest "/bin/node_exporter …" 7 weeks ago Up 10 days 0.0.0.0:9100->9100/tcp, :::9100->9100/tcp node-exporter # chat CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b27853befb24 gcr.io/cadvisor/cadvisor:latest "/usr/bin/cadvisor -…" 7 weeks ago Up 10 days (healthy) 0.0.0.0:8090->8080/tcp, :::8090->8080/tcp cadvisor 46a5c4f485c6 prom/node-exporter:latest "/bin/node_exporter …" 7 weeks ago Up 10 days 0.0.0.0:9100->9100/tcp, :::9100->9100/tcp node-exporter # push CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 91221486fc1d slowtalk.kr-central-2.kcr.dev/slowtalk/push-dev:latest "supervisord -c /etc…" 5 hours ago Up 5 hours 9000/tcp, 0.0.0.0:9000->8020/tcp, :::9000->8020/tcp push-dev-container d9760242f0db gcr.io/cadvisor/cadvisor:latest "/usr/bin/cadvisor -…" 7 weeks ago Up 10 days (healthy) 0.0.0.0:8090->8080/tcp, :::8090->8080/tcp cadvisor a5a86a41ee4e prom/node-exporter:latest "/bin/node_exporter …" 7 weeks ago Up 10 days 0.0.0.0:9100->9100/tcp, :::9100->9100/tcp node-exporter

API 서버 (api-dev-container) 9000/tcp: 컨테이너 내부에서 애플리케이션이 실제로 수신 대기하는 포트입니다. 외부에서 직접 접근할 수 없습니다. 0.0.0.0:39000->8000/tcp: 호스트 시스템의 39000번 포트로 들어오는 요청을 컨테이너 내부의 8000번 포트로 연결합니다. 즉, 외부에서 http://호스트_IP:39000으로 접속하면 API 서버에 접근할 수 있습니다. :::39000->8000/tcp: IPv6 주소를 사용하는 경우에도 위와 동일하게 호스트 시스템의 39000번 포트로 들어오는 요청을 컨테이너 내부의 8000번 포트로 연결합니다. CHAT 서버 CHAT 서버 컨테이너는 현재 docker ps 명령 결과에 나타나지 않습니다. 따라서 포트 정보를 확인할 수 없습니다. CHAT 서버가 실행 중인지, 그리고 포트 매핑이 제대로 설정되었는지 확인해야 합니다. PUSH 서버 (push-dev-container) 9000/tcp: 컨테이너 내부에서 애플리케이션이 실제로 수신 대기하는 포트입니다. 외부에서 직접 접근할 수 없습니다. 0.0.0.0:9000->8020/tcp: 호스트 시스템의 9000번 포트로 들어오는 요청을 컨테이너 내부의 8020번 포트로 연결합니다. 즉, 외부에서 http://호스트_IP:9000으로 접속하면 PUSH 서버에 접근할 수 있습니다. :::9000->8020/tcp: IPv6 주소를 사용하는 경우에도 위와 동일하게 호스트 시스템의 9000번 포트로 들어오는 요청을 컨테이너 내부의 8020번 포트로 연결합니다. 모니터링 도구 (cadvisor, node-exporter) cadvisor: 0.0.0.0:8090->8080/tcp: 호스트 시스템의 8090번 포트로 들어오는 요청을 컨테이너 내부의 8080번 포트로 연결합니다. cAdvisor 웹 인터페이스에 접근할 수 있습니다. :::8090->8080/tcp: IPv6 주소를 사용하는 경우에도 위와 동일하게 호스트 시스템의 8090번 포트로 들어오는 요청을 컨테이너 내부의 8080번 포트로 연결합니다. node-exporter: 0.0.0.0:9100->9100/tcp: 호스트 시스템의 9100번 포트로 들어오는 요청을 컨테이너 내부의 9100번 포트로 연결합니다. Prometheus가 node-exporter에서 시스템 메트릭을 수집할 수 있도록 합니다. :::9100->9100/tcp: IPv6 주소를 사용하는 경우에도 위와 동일하게 호스트 시스템의 9100번 포트로 들어오는 요청을 컨테이너 내부의 9100번 포트로 연결합니다. 주의 사항: 호스트 시스템의 방화벽 설정에 따라 외부에서 컨테이너 포트에 접근하지 못할 수 있습니다. 방화벽 설정을 확인하고 필요한 포트를 열어주어야 합니다. PUSH 서버와 API 서버 모두 호스트 시스템의 9000번 포트를 사용하고 있습니다. 이는 포트 충돌을 일으킬 수 있으므로, PUSH 서버의 포트 매핑을 변경하거나 Reverse Proxy를 사용하여 트래픽을 적절히 라우팅해야 합니다. 다음 단계: CHAT 서버 컨테이너의 포트 정보를 확인하고 필요 시 포트 매핑을 설정합니다. PUSH 서버의 포트 충돌 문제를 해결합니다. Reverse Proxy 설정 시 각 서버에 대한 적절한 포트 번호를 지정합니다. . api, chat, push 매핑 되어 있는 ip 정보 - api "MONGODB_LOGGER": { "HOST": "10.0.2.254", "PORT": 27017, DATABASE_SLOWTALK": { "HOST": "10.0.3.79", "PORT": 5000, "READ_PORT": 5000, "PUSH_KAFKA": { "bootstrap_servers": ["10.0.35.25:9092", "10.0.33.244:9092", "10.0.33.243:9092"] "SMS_KAFKA": { "bootstrap_servers": ["10.0.35.25:9092", "10.0.33.244:9092", "10.0.33.243:9092"] , "topic" : "SMSServer" - api 로컬 "MONGODB_LOGGER": { "HOST": "210.109.55.105", "PORT": 27017, "DATABASE_SLOWTALK": { "HOST": "210.109.55.245", "PORT": 5000, "READ_PORT": 5000, PUSH_KAFKA": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] "SMS_KAFKA": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] - chat "MONGODB_CHATBOT": { "HOST": "10.0.2.254", "PORT": 27017, "DATABASE": "ChatBot", "MONGODB_CHATTING": { "HOST": "10.0.2.254", "PORT": 27017, "DATABASE": "ChatServer", "COLLECTION": "Chatting", "DATABASE_SLOWTALK": { "HOST": "10.0.3.79", "PORT": 5000, CHATTING_PUBSUB": { "bootstrap_servers": ["10.0.35.25:9092", "10.0.33.244:9092", "10.0.33.243:9092"] "CHATTING_PUSH_PUBSUB": { "bootstrap_servers": ["10.0.35.25:9092", "10.0.33.244:9092", "10.0.33.243:9092"] - chat 로컬 "MONGODB_CHATBOT": { "HOST": "210.109.55.105", "PORT": 27017, "DATABASE": "ChatBot", "MONGODB_CHATTING": { "HOST": "210.109.55.105", "PORT": 27017, "DATABASE": "ChatServer", "DATABASE_SLOWTALK": { "HOST": "210.109.55.245", "PORT": 5000, "CHATTING_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] "CHATTING_PUSH_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] - push "MONGODB_PUSH": { "HOST": "210.109.55.105", "PORT": 27017, "DATABASE_SLOWTALK": { "HOST": "210.109.55.245", "PORT": 5000, PUSH_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] , "topic" : "PushServer" "CHATTING_PUSH_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] "SMS_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] - push 로컬 "MONGODB_PUSH": { "HOST": "210.109.55.105", "PORT": 27017, "DATABASE_SLOWTALK": { "HOST": "210.109.55.245", "PORT": 5000, "PUSH_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] "CHATTING_PUSH_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] , "topic" : "ChattingPushServer" "SMS_PUBSUB": { "bootstrap_servers": ["210.109.55.175:9094", "210.109.54.17:9094", "210.109.55.220:9094"] # 궁금한 거 1. chat 서버와 kafka 서버는 모니터링 도구만 docker로 사용하는데 서비스를 docker에 올리지 않는 것인가요? 서버가 죽어있었슴 2. 그렇다면 chat 서버와 kafka는 어디서 구동되고 있는 것인가요? 네이티브 컨트롤러(클러스터, 통신), 브로커(서버) - 카프카 공부 진행 3. 통합 서버를 운용할 경우 컨테이너로 나누게 될텐데 config 설정 파일은 어떻게 구분시키나요? 빌드 크리거, 소스코드 클론, 개발, prod config 파일 - 도커이미지 - 컨테이너레지스트리 - 4. Reverse Proxy 설정하기 위해서 nginx 경로로 들어가서 설정 파일을 여는 걸로 알고 있는데, nignx 디렉터리가 존재하지 않습니다. 설정 파일 경로는 어디인가요? npm 기존거 확인 5. 인스턴스에 접속한 후, 루트 계정의 암호는 어떻게 설정이 되어있나요?

# api, chat, push 서버 통합 상세 계획 1. 카카오 클라우드 인스턴스 생성 - 인스턴스 스팩 - 이름 : dev-api-chat-push - 유형 : t1i.medium - 운영체제 : rocky linux 9 - vCPU : 2 - 메모리 : 4GB - 스토리지 : 30GB - 키페어 : slowtalk.pub (pem으로 pub 생성 : ssh-keygen -f my_key.pem -y) - 네트워크 : 퍼블릭 IP 할당, 보안 그룹 설정(com-bastion-target-sg, com-monitoring-target-sg), 추가적인 서비스 포트 보안 그룹 설정, 포트 번호 변경이 있으니 보안 그룹도 설정 - api 포트 : 19000 - chat 포트 : 29000 2. 도커 컨테이너 생성 및 네트워크 설정 - 컨테이너 생성 - vm 인스턴스 생성 - vm 초기화 스크립트(위키) 첨부파일 확인, vm 스크립트를 사용하여 도커 컨테이너 생성 (포함 되어 있음) - Dockerfile 작성된거 이용 (api, chat, push 컨테이너) - 컨테이너 생성 및 빌드 - 젠킨스 - 컨테이너 포트 설정 (api-39000,8090,9100 / chat-9000,8090,9100 / push-9000,8090,9100) 매핑 어디서 설정하는지 찾기, 외부 호스트 포트 곂치지 않아야함. - 카카오 클라우드 보안 그룹 설정 변경 - docker port 인바운드 규칙 추가 - 디테일하게 확인 각각에 어떤 식으로 커넥션이 이루어지는지 파악 api chat - 클라이언트 인바운드를 어떤식으로 열어야 하는가 클라이언트는 api - push는 다름 # 수정된 포트 API 서버: 컨테이너 내부 포트: 8000 호스트 시스템 포트: 39000 CHAT 서버: 컨테이너 내부 포트: 8010 호스트 시스템 포트: 39001 PUSH 서버: 컨테이너 내부 포트: 8020 호스트 시스템 포트: 9000 정상적인 동작이 되는지 확인 후 젠킨스 파이프라인 진행 - vm 인스턴스에서 push 한 코드를 git clone 후 docker 빌드 한 후 이미지 생성 - deploy 해보면서 확인 - 컨테이너 레지스트리 - 단계를 나눠서 작업하기 - 기존 설정되어 있는 config를 열어서 확인 (ip주소만 다를 거임) - docker build - 도커 이미지를 생성하는 과정 - 컨테이너와 이미지에 대한 차이 검색 - 컨테이너 : 동적 ex) 애플리케이션 - 이미지 : 정적, ex)애플리케이션 실행 파일 # NCP Container Registry의 레지스트리 이미지 이름 / 로컬에 있는 이미지 이름으로 변경 후 실행해야함!! DOCKER_IMAGE_NAME="slowtalk.kr-central-2.kcr.dev/slowtalk/${APP_NAME}:latest" # 로컬 도커 이미지 경로 /var/lib/docker/image/overlay2/imagedb/content/sha256/ 컨테이너 충돌있는지 확인 후 npm 1. config 수정 업로드 2. 서버에서 도커 재빌드 - git clone -b deploy-test ssh... - dockerfile이 존재한는 디렉터리에서 - docker build -t [이미지] . - bash deploy-DEV.sh 3. 젠킨스 파일 수정 - parmeters - deployserverIPs 수정 # 젠킨스 돌리면 자동 카피 됨 // sh '''cp configs/config-Dev.json configs/config.json''' - 파이프라인 스크립트에서 환경 변수 설정 - 파이프라인에서 변수 (파라미터, 글로벌 env, 로컬 env) - 인헤도 될거같음 # 커밋 덮어씌우기 git commit --amend -m "새로운 커밋 메시지" git push origin HEAD -- force git commit -m "chore: Jenkins Global Env 설정" # api 스웨거 로그인 slowplat test API 서버: - apitest.slowplat.com - 스웨거 화면이 뜨는지 확인 - config.json 수정 - config-Dev와 config.json 일치 - Jenkinsfile 수정 - parmeters - deployserverIPs 서버ip 수정 CHAT 서버: - wstest.slowplat.com - config.json 수정 (config-Dev와 config.json 일치) - /templates/chatbot.html - refresh_token 수정 (3분마다 제한됨) - aes_encrypt.py - python /Users/tony.cho/Development/AES_ENC/aes_encrypt.py "slowplat | test" | tr -d '₩n' | pbcopy - soket url 수정 - 'wss://wstest.slowplat.com/chatbot' - Jenkinsfile 수정 - parmeters - deployserverIPs 서버ip 수정 PUSH 서버: - config.json 수정 (config-Dev와 config.json 일치) - 서버 스타트에 대해서 로그 확인 - kafbat 확인 - deploy-DEV 변경 - Jenkinsfile 수정 - parmeters - deployserverIPs 서버ip 수정 - 로드벨런서 9001 포트에 연결 로그 확인, 서버 스타트에 대해서 - push 문제 없이진행 되면 젠킨스 파일 수정!! + DeployDev_Jenkinsfile을 DeployProd_Jenkinsfile 처리 방식으로 수정 - Dev는 Jenkins 파일의 parameter로 처리 -> Prod는 PROD_CHAT_SRV_IPS와 같이 Jenkins Global Env로 설정되도록 수정. - Dev는 Jenkins 파일의 parameter로 처리하고 있고 Prod는 PROD_CHAT_SRV_IPS와 같이 Jenkins Global Env로 설정이 되도록 되어 있습니다. - 관리측면에서 더 좋은 방식이니 수정 필요 + 추가로 젠킨스 알면 좋은 거 - 음 jenkinsfile이니까 서버에는 로그가 기록되지 않고, jenkins에 등록이 되는구나 맞아? 그리고 jenkins agent 인스턴스에 접속하면 해당 로그를 볼 수 있나? 답안 표시 네, 맞습니다. Jenkinsfile에서 실행되는 sh 명령어의 출력 결과는 Jenkins 에이전트 인스턴스에 기록되지 않고, Jenkins 서버의 빌드 로그에 저장됩니다. 따라서, 헬스 체크 결과를 포함한 모든 로그들은 Jenkins 웹 인터페이스의 빌드 콘솔 출력에서 확인할 수 있습니다. Jenkins 에이전트 인스턴스에 직접 접속하여 로그를 확인하는 것은 일반적으로 권장되지 않습니다. Jenkins 에이전트는 빌드 작업을 실행하는 환경을 제공하는 역할을 하며, 로그 저장 및 관리 기능은 Jenkins 서버에서 담당합니다. 따라서, 헬스 체크 로그를 확인하려면 Jenkins 웹 인터페이스에서 해당 빌드의 콘솔 출력을 확인하는 것이 가장 안전하고 효율적인 방법입니다. 플랜보다 시간이 많이 걸린 이유 파악 - 다음에 할때는 이것보다 몇배는 빨라져야된다. - 환경에 익숙, 없는거 만들라는게 아니잖아. 근데 다음에는 없는 기능을 만들어야해, 고로 기본기를 잘 알아야 한다. - 새로운 기술을 잘 모르는 건 당연하지만, 단기간에 습득하는 사람이 있듯이, 기본기가 반역이 되어서 업무가 진행되니, 관련 기술이나 테크닉에 대해서는 학습이 필요하다. - 스터디를 하면서 꼼꼼히 메모하는 것이 중요 - 실패했을 땐 어디가 실패했는지, 성공했을 땐 어떻게 했는지 매뉴얼 작성이 필요 3. Reverse Proxy 설정 - nginx 설치 , npm 서버에서 설정 - nginx 설정 파일에서 ip 주소 및 컨테이너 포트정보를 수정하여 트래픽 라우팅 규칙 설정 - 정상적으로 작동하는지 테스트 4. jenkins pipeline 수정 - 도커 이미지 빌드 경로 수정 (ex. dev-api -> dev-api-chat-push) 할 필요 x - Jenkinsfile 확인 - 파이프라인 스크립트에서 환경 변수 설정 - 파이프라인에서 변수 (파라미터, 글로벌 env, 로컬 env) - 수정된 파이프라인을 이용하여 빌드 및 테스트 진행 - scripts/deploy-DEV.sh 수정 (api, chat, push 함께 배포) - 뭘 수정해야 되는 지 파악, config 수정이 되어야되는지 파악 - configs/config-DEV.json 수정 (mongoDB, postgresql, redis, kafka 연결 정보 / 포트 번호) 5. 매뉴얼 작성 - 중요한 정보만 - 인스턴스 생성 정보 - 컨테이너 생성 및 실행 방법 - Jenkins Pipeline 수정 내용 - DNS 설정 변경 내용 - Reverse Proxy 설정 내용 - 기타 관련 정보 및 주의 사항

# 터널링으로 인스턴스 접속하기 # bastion host에 접속 ssh -i ~/.ssh/slowtalk.pem rocky@210.109.54.69 # dockerfile 디렉토리에서 도커 빌드 docker build -t api-dev . docker build -t chat-dev . docker build -t push-dev . # 도커 이미지 확인 # 파일 권한 부여 sudo chown rocky:rocky docker # 스크립트 수정 # 로컬 이미지 경로 : /var/lib/docker/image/overlay2/imagedb/content/sha256/[컨테이너ID] # 로컬 테스트용 스크립트 경로 추가 LOCAL_IMAGE_ID="sha256:c1291292d9a785f34adbf7d38dfb541710443082ff96d2ece891f03492ed2a21" # docker test 실행 docker run --restart always -v /etc/localtime:/etc/localtime:ro -e TZ=Asia/Seoul -p ${DOCKER_PORT}:${LOCAL_PORT} --name ${APP_NAME}-container -d ${LOCAL_IMAGE_ID} # 컨테이너 실행 docker run -d -p 8080:80 my-image # 접속 포트 설정 ssh -i ~/.ssh/slowtalk.pem -L <로컬 포트>:<대상 서버 IP>:<대상 서버 포트> rocky@<Bastion Host IP> ssh -i ~/.ssh/slowtalk.pem -L 6379:10.0.0.238:6379 rocky@<Bastion Host IP> ssh -i ~/.ssh/slowtalk.pem -L 6379:10.0.0.238:6379 210.109.54.69 -p 10063 ssh -i ~/.ssh/slowtalk.pem 210.109.54.69 -p 10063 ssh -i ~/.ssh/slowtalk.pem -L 22:10.0.0.122:22 210.109.54.69 -p 10061 ssh -i ~/.ssh/slowtalk.pem rocky@210.109.54.69 -p 10098

# real-api 배포용 스크립트 APP_NAME="push-dev" # NCP Container Registry의 레지스트리 이미지 이름 # DOCKER_IMAGE_NAME="slowtalk.kr-central-2.kcr.dev/slowtalk/${APP_NAME}:latest" # 로컬 테스트용 LOCAL_IMAGE_ID="sha256:f046496c4f96e98afa679d67cb312be2276065a5a1d92f23a9a372005d0912a9" # 배포서버 /etc/nginx/conf.br/kbo-fast-api.conf 참고 LOCAL_PORT=8020 DOCKER_PORT=9000 echo "${APP_NAME} Docker start" # 기존에 실행중인 도커 중지, 삭제 if [ $( docker ps -a | grep ${APP_NAME}-container | wc -l ) -gt 0 ]; then sudo docker ps -a -q --filter "name=${APP_NAME}-container" | grep -q . && docker stop ${APP_NAME}-container && docker rm ${APP_NAME}-container | true echo "${APP_NAME} down" fi # 이미지 pull docker pull ${DOCKER_IMAGE_NAME} echo "${APP_NAME} Docker run" # docker 실행 # docker run --restart always -v /etc/localtime:/etc/localtime:ro -e TZ=Asia/Seoul -p ${DOCKER_PORT}:${LOCAL_PORT} --name ${APP_NAME}-container -d ${DOCKER_IMAGE_NAME} # docker test 실행 docker run --restart always -v /etc/localtime:/etc/localtime:ro -e TZ=Asia/Seoul -p ${DOCKER_PORT}:${LOCAL_PORT} --name ${APP_NAME}-container -d ${LOCAL_IMAGE_ID} # 안쓰는 더미 도커 이미지 삭제 docker images | grep "<none>" | awk '{print $3}' | xargs -r docker rmi

리눅스에서 화살표 방향키를 사용하지 않고 history를 검색하는 방법은 다음과 같습니다: 1. Ctrl+R: Ctrl+R을 누르면 'reverse-i-search' 모드가 시작됩니다. 찾고 싶은 명령어의 일부를 입력하면, 입력한 문자열과 일치하는 가장 최근 명령어가 표시됩니다. 계속해서 Ctrl+R을 누르면, 이전에 실행했던 명령어 중 일치하는 명령어들을 차례로 볼 수 있습니다. Ctrl+G를 누르면 검색을 종료하고 일반 모드로 돌아갑니다. Enter 키를 누르면 선택된 명령어가 실행됩니다.

1. 인스턴스 생성 및 보안 그룹 설정 : 1시간 2. vm 생성 스크립트로 컨테이너 생성 : 1시간 3. jenkins pipeline 수정 : 2시간 4. Reverse Proxy 설정 : 1시간 5. 매뉴얼 작성 : 1시간 총 6시간 소요 예정입니다. 앱태스트까지 진행을 고려해서 명일 오후 중(3시 이전)까지 완료해보겠습니다.

# api 서버 Dev private ip : 10.0.1.127 Dev public ip : 210.109.54.95

# api 서버 config-Dev

1. api, chat, push 서버를 하나의 vm으로 통합하기 위해 카카오 클라우드 인스턴스를 생성한다. - vm 인스턴스 스팩 - t1.small - 운영체제 : rocky9 - vCPU : 2 - 메모리 : 3 - 스토리지 : 50 - 네트워크 : 2. 하나의 vm에 api, chat, push 컨테이너를 생성하여 관리한다. - api, chat, push 컨테이너 생성후 네트워크 설정 3. Jenkins pipeline을 수정하여 각 컨테이너에서 빌드될 수 있게 한다. 4. DNS 설정을 검토 후 수정이 필요한 경우를 파악한다. 5. Reverse Proxy를 포트번호에 맞게 설정한다. 6. 관련 수정사항 정리하여 매뉴얼을 작성한다. - 생성하기 위해서 인스턴스 사양을 설정할때 램은 3기가로 설정할거야. 다른건 어떻게 설정할지 정해줘.

API, CHAT, PUSH 서버 통합 프로젝트 상세 계획 1. 카카오 클라우드 인스턴스 생성 인스턴스 스펙: 이름: 통합서버 (혹은 적절한 이름으로 지정) 유형: t1.small 운영체제: Rocky Linux 9 vCPU: 2 메모리: 3GB 스토리지: 50GB (SSD) 네트워크: 퍼블릭 IP 할당, 보안 그룹 설정 (추후 상세 설정) 생성 절차: 카카오 클라우드 콘솔 접속 인스턴스 생성 페이지 이동 위 스펙대로 설정 후 인스턴스 생성 인스턴스 생성 완료 후 퍼블릭 IP 확인 2. 도커 컨테이너 생성 및 네트워크 설정 컨테이너 생성: 통합서버에 SSH 접속 Docker 설치 (설치되어 있지 않은 경우) API, CHAT, PUSH 서버 각각에 대한 Dockerfile 작성 혹은 기존 이미지 활용 Dockerfile을 이용하여 이미지 빌드 이미지를 기반으로 컨테이너 생성 및 실행 네트워크 설정: 각 컨테이너에 필요한 포트를 호스트에 노출 (예: API - 80, CHAT - 3000, PUSH - 8080) 카카오 클라우드 보안 그룹 설정 변경: 컨테이너에 노출된 포트에 대한 인바운드 규칙 추가 방화벽 설정 확인 및 필요 시 수정 3. Jenkins Pipeline 수정 기존 Pipeline 분석: 현재 API, CHAT, PUSH 서버 각각에 대한 빌드 및 배포 과정 파악 수정 방향: 각 컨테이너 이미지 빌드 빌드된 이미지를 통합서버에 배포 통합서버에서 컨테이너 실행 필요 시 롤백 기능 추가 테스트: 수정된 Pipeline을 이용하여 빌드 및 배포 테스트 수행, 문제 발생 시 수정 4. DNS 설정 검토 및 수정 현재 DNS 설정 확인: API, CHAT, PUSH 서버 각각에 대한 도메인 및 IP 정보 확인 수정 필요 여부 판단: 통합 후에도 기존 도메인을 유지할 경우: Reverse Proxy 설정을 통해 트래픽 라우팅 새로운 도메인으로 변경할 경우: DNS 레코드 수정 필요 DNS 레코드 수정 (필요한 경우): 도메인 등록 업체 콘솔 접속 A 레코드 혹은 CNAME 레코드 수정 변경 사항 적용 확인 (전파 시간 소요될 수 있음) 5. Reverse Proxy 설정 Reverse Proxy 도구 선택: Nginx, HAProxy 등 적절한 도구 선택 및 통합서버에 설치 설정 파일 수정: 도메인 및 컨테이너 포트 정보를 기반으로 트래픽 라우팅 규칙 설정 SSL/TLS 설정 (HTTPS 사용 시) 테스트: 설정 적용 후 각 서비스 정상 접속 확인 6. 매뉴얼 작성 수정 사항 정리: 인스턴스 생성 정보 컨테이너 생성 및 실행 방법 Jenkins Pipeline 수정 내용 DNS 설정 변경 내용 Reverse Proxy 설정 내용 기타 관련 정보 및 주의 사항 매뉴얼 작성: 위 정보를 바탕으로 유지보수 담당자가 참고할 수 있는 매뉴얼 작성 추가 고려 사항 데이터 백업 및 마이그레이션: 통합 과정에서 데이터 손실 방지를 위해 백업 및 마이그레이션 계획 수립 모니터링 및 로깅: 컨테이너 및 시스템 자원 모니터링, 로그 관리 시스템 구축 성능 테스트 및 최적화: 부하 테스트를 통한 성능 병목 구간 파악 및 최적화 보안: 시스템 및 컨테이너 보안 설정 강화, 취약점 점검

# 이번 주 안에 # 전반적인 회사 시스템 구성 파악 DB 서버 구성 확인 - 로드밸런서(haproxy) 패일오버 기능 - port 5000 : 마스터 - port 5001 : 스밴바이 - 해당 포드로의 접속 방법 - - 기본적인 구성 - postgresql cluster (오토 페일오버) - pgbouncer - patroni 수동 패일오버 방법 - 1. 러프하게 기록 - 2. 매뉴얼로 상세하게 기록 # 시스템 장애발생 시 어떻게 복구할 것인지 서버 부하, 장애 발생시 자동 스케일 아웃 되도록 설정 되어있음. - 만약 자동적으로 스케일 아웃이 되지않는 경우, 수동으로 어떻게 처리할 수 있는가? - postgresql, mongoDB, redis 각각 어떻게 처리 할 수 있는지 알아보기. # GitHub: postgresql cluster https://github.com/vitabaks/postgresql_cluster?tab=readme-ov-file # Patroni + etcd + HAproxy를 이용한 HA 구성 https://bstar36.tistory.com/m/411 # 연결풀링 https://xshine.tistory.com/167 DB 서버 동작 확인 - Postgres Cluster Master, Standby 접속 -> 위키 설정 적용 - DBeaver 다운 https://dbeaver.io/download/ - https://wiki.slowplat.com/projects/slow_talk_service/wiki/DB_Server - Postgres Cluster Master - Instance Name: auto failover 기능으로 인해 master 서버 인스턴스는 변경 될 수 있음 - Private IP: 10.0.17.174 (LB 주소) - Port : 5000 - Forwarding port : 10000 - Username: postgres - Password: (Bitwarden - 보안 - 카카오 클라우드 - prod-pg-patroni) - Postgres Cluster Standby - Instance Name: auto failover 기능으로 인해 master 서버 인스턴스는 변경 될 수 있음 - Private IP: 10.0.17.174 (LB 주소) - Port : 5001 - Forwarding port : 10000 - Username: postgres - Password: (Bitwarden - 보안 - 카카오 클라우드 - prod-pg-patroni) - patroni 사용해서 node 확인 - patroni node 접속 - patronictl root 권한 실행 - sudo /usr/local/bin/patronictl -c /etc/patroni/patroni.yml list | Member | Host | Role | State | TL | Lag in MB | +----------+-------------+---------+-----------+----+-----------+ | pgnode01 | 10.0.16.210 | Replica | streaming | 10 | 0 | | pgnode02 | 10.0.17.123 | Leader | running | 10 | | | pgnode03 | 10.0.16.76 | Replica | streaming | 10 | 0 | +----------+-------------+---------+-----------+----+-----------+ DB 서버 failover test - 수동방법 (여러 시나리오 구성) - 수동으로 어떻게 바꿔줄 수 있는가? - 수동으로 패일오버 할 때 얼마만에 복구할 수 있는가? - 데이터 로스가 발생하는가? - 오토방법 (여러 시나리오 구성) - 어떤 시나리오로 자동으로 오토 패일오버를 시킬 것인가? - 얼마만에 복구가 되는가? - 데이터 로스가 발생하는가? * postgreSQL 서비스 중단, 네트워크 연결 문제, 스토리지 장애 마스터 노드 장애 시나리오 및 failover 테스트 Patroni의 failover 기능을 테스트하기 위해 마스터 노드에 발생할 수 있는 다양한 장애 시나리오와 각 시나리오에 대한 failover 테스트 방법을 알아보겠습니다. 주의: 실제 운영 환경에서 테스트를 진행할 때는 반드시 데이터 백업을 먼저 수행하고, 테스트 환경을 분리하여 운영 환경에 영향을 주지 않도록 주의해야 합니다. 1. PostgreSQL 서비스 중단 시나리오: PostgreSQL 서비스가 예기치 않게 중단되거나 수동으로 중지된 경우 테스트 방법: 현재 마스터 노드에서 PostgreSQL 서비스를 중지합니다. (systemctl stop postgresql 또는 service postgresql stop) patronictl list 명령으로 클러스터 상태를 확인하고, 마스터 노드가 변경되었는지 확인합니다. 애플리케이션 또는 클라이언트에서 데이터베이스 연결을 시도하여 새로운 마스터 노드로 자동으로 연결되는지 확인합니다. 2. 노드 시스템 다운 시나리오: 마스터 노드의 시스템이 다운되거나 재부팅되는 경우 테스트 방법: 현재 마스터 노드를 강제로 종료하거나 재부팅합니다. patronictl list 명령으로 클러스터 상태를 확인하고, 마스터 노드가 변경되었는지 확인합니다. 애플리케이션 또는 클라이언트에서 데이터베이스 연결을 시도하여 새로운 마스터 노드로 자동으로 연결되는지 확인합니다. 3. 네트워크 장애 시나리오: 마스터 노드와 다른 노드 간의 네트워크 연결이 끊어지는 경우 테스트 방법: 현재 마스터 노드의 네트워크 인터페이스를 비활성화하거나 방화벽 규칙을 변경하여 다른 노드와의 통신을 차단합니다. patronictl list 명령으로 클러스터 상태를 확인하고, 마스터 노드가 변경되었는지 확인합니다. 애플리케이션 또는 클라이언트에서 데이터베이스 연결을 시도하여 새로운 마스터 노드로 자동으로 연결되는지 확인합니다. 4. 스토리지 장애 시나리오: 마스터 노드의 스토리지 시스템에 장애가 발생하여 데이터베이스 파일에 접근할 수 없는 경우 테스트 방법: (주의: 데이터 손실 가능성이 있으므로 반드시 백업 후 테스트 환경에서만 진행해야 합니다.) 현재 마스터 노드의 데이터 디렉토리를 다른 위치로 이동하거나 삭제하여 데이터베이스 파일에 접근할 수 없도록 만듭니다. patronictl list 명령으로 클러스터 상태를 확인하고, 마스터 노드가 변경되었는지 확인합니다. 애플리케이션 또는 클라이언트에서 데이터베이스 연결을 시도하여 새로운 마스터 노드로 자동으로 연결되는지 확인합니다. 추가 고려 사항 복제 지연 시간: 비동기 복제를 사용하는 경우, failover 시 일부 데이터 손실이 발생할 수 있습니다. 복제 지연 시간을 최소화하여 데이터 손실 가능성을 줄이는 것이 중요합니다. 애플리케이션 연결 관리: 애플리케이션은 failover 발생 시 새로운 마스터 노드로 자동으로 연결을 재설정할 수 있어야 합니다. 연결 풀링 라이브러리나 ORM(Object-Relational Mapping) 프레임워크를 사용하는 경우, failover 처리 기능을 지원하는지 확인해야 합니다. 모니터링 및 알림: Patroni 클러스터의 상태를 지속적으로 모니터링하고, failover 발생 시 알림을 받을 수 있도록 설정해야 합니다. 테스트 결과 분석 각 시나리오에 대한 failover 테스트를 수행한 후에는 다음 사항들을 확인해야 합니다. failover가 예상대로 작동했는지 확인합니다. 새로운 마스터 노드가 정상적으로 서비스를 제공하는지 확인합니다. 애플리케이션 또는 클라이언트가 새로운 마스터 노드에 자동으로 연결되는지 확인합니다. 데이터 손실이 발생했는지 확인합니다. (특히 비동기 복제 사용 시) 결론 Patroni를 사용하면 PostgreSQL 클러스터의 고가용성을 확보하고 데이터 손실 가능성을 최소화할 수 있습니다. 다양한 장애 시나리오에 대한 failover 테스트를 통해 Patroni 설정 및 애플리케이션 연결 관리가 올바르게 동작하는지 확인하고, 문제 발생 시 신속하게 대응할 수 있도록 준비해야 합니다. 시스템 로그 확인 - mongoDB에 접속하여 로그 확인 - mongoDB는 docker로 올라가 있음 - mongo compass 다운 -> 위키에 설정 적용 - https://www.mongodb.com/pt-br/ko-kr/products/tools/compass - https://wiki.slowplat.com/projects/slow_talk_service/wiki/DB_Server - prod - URI : mongodb://slowmgroot:4gFrzsfT2JNeD6@10.0.19.109:27017/admin - Proxy/SSH - SSH Hostname : 210.109.54.69 - SSH Port : 10005 - SSH Username : rocky - SSH Identiy File : slowtalk-prod.pem - dev - URI : mongodb://slowmgroot:mgrtpw4411@10.0.2.254:27017/admin - Proxy/SSH - SSH Hostname : 210.109.54.69 - SSH Port : 10060 - SSH Username : rocky - SSH Identiy File : slowtalk.pem - kafbat ui를 사용하여 kafka 확인 - 토픽 목록 : kafka 클러스터에 존재하는 모든 토픽 목록을 확인 - 토픽 세부 정보 : 각 토픽의 파티션 수, 복제 백터, 메세지 보전 기간 등 세부 정보 확인 - 메시지 조회, 메세지 갱신, 컨슈머 그룹 정보 - kafbat 설명 : https://github.com/kafbat/kafka-ui - 로그 확인 후 어디가 어떻게 장애가 났는지 파악 문자인증 - 클라 api - 응답 - 로그 - 로그 확인 경로 - 로그 확인 후 대응 방법 체크 - 문자인증 api 쓰는 법 : 클라 - push 서버로 어떻게 데이터를 보낼까? - 문장인증 호출 - 로그 : mongoDB - 로그 파악 # sudo 권한 필요한 디렉터리 / 파일 -> 파일 안들어가지거나 명령어 먹지 않을 경우 sudo /usr/local/bin/patronictl -c /etc/patroni/patroni.yml list s pg bouncer - Postges 성능의 부하를 줄어줌 / 연결 풀링의 이해 - https://xshine.tistory.com/167

# kafka의 핵심 구성 요소 1. 토픽 (Topic) - 메시지 분류 : kafka는 메시지를 토픽이라는 논리적인 단위로 분류하여 관리 - 생산자-소비자 연결 : 토픽은 생산자(Producer)가 메시지를 보내는 곳이자, 소비자(Consumer)가 메시지를 읽어오는 곳 - 파티션 분할 : 각 토픽은 여러 개의 파티션(Partition)으로 나누어 저장. 파티션은 메시지 순서를 보장하는 단위이며, 여러 브로커에 분산 저장 - 복제 : 각 파티션은 여러 브로커에 복제되어 데이터 안정성을 보장 2. 브로커 (Broker) - 메시지 저장 : kafka 클러스터를 구성하는 서버. 토픽의 파티션을 저장하고 관리 - 클러스터 구성 : 여러 브로커가 함께 클러스터를 수성하여 확장성과 가용성을 높임 - ZooKeeper 연동 : ZooKeeper를 사용하여 클러스터 구성 정보, 토픽 정보, 파티션 정보 등을 관리 3. 생산자 (Producer) - 메시지 발행 : 메시지를 특정 토픽에 발행하는 역할 - 파티션 선택 ㅣ 메시지를 어떤 파티션에 저장할지 선택 가능 4. 소비자 (Consumer) - 메시지 구독 : 특정 토픽을 구독하여 메시지를 읽어오는 역할 - 컨슈머 그룹 : 여러 소비자가 하나의 컨슈머 그룹을 형성하여 토픽의 파티션을 분담하여 처리 - 오프셋 관리 : 각 컨슈머는 자신이 읽은 메시지 위치를 오프셋(Offset)으로 관리하여 다음 읽을 위치를 기억함 # kafka의 전반적 개념 - 분산 메시징 시스템 : 대용량 데이터 스트림을 처리하기 위해 사용 - 실시간 처리 : 메시지를 빠르게 처리하여 실시간 데이터 스트림 처리에 적합 # 카프카 구조 알아보기 https://velog.io/@jwpark06/Kafka-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%A1%B0-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

# 회사 테스트 : 조태연, 010-5767-4411 pin 00000 # 민우 : 010-8695-2201 # 데일리 빌드 후 close → 마켓빌드가 되면 추가적으로 한번 더 테스트 # 240828 앱 테스트 개인, 개인설정, 로그인, 회원가입, 피드, 고객문의 개인 - 사용자1(허진영)과 사용자2(김민우)가 회원가입을 진행 후, 서로의 프로필을 누를 경우 회원이 아니라는 메세지 출력되는 이슈 - 사용자1(허진영)이 사용자2(김민우)를 직접 추가 할 경우, 정상적으로 친구 생성 - 사용자를 직접 추가를 진행할 때, 친구목록에 당 친구가 없는데도 "이미 친구입니다."라는 메세지 출력되며 친구목록에 친구 추가가 되지 않는 이슈 - 슬로우톡 초대 문자의 url을 받은 상대방이 아이폰일 경우, 페이지가 로딩 되지 않는 이슈 : 다이나믹 링크 작동 안됨 채널 - 채널 소식에서 댓글을 등록하면 삭제나 수정이 불가능한 이슈 - 채널 소식에서 댓글 시간이 9시간 전으로 설정 (13시 26분 등록 -> 04시 26분 등록) 온보딩 - 이미지를 터치해서 넘기는 방식의 불편하여 개선 필요 -> 사용자의 손을 고려했을 때, 전체화면에서 이미지를 넘길 수 있도록 수정 요청. 챗봇 - 240828 13시 36분 현재 챗봇에게 메시지 남겨도 답변이 없음 채팅 - 사용자1(허진영)이 채팅방을 생성하여 사용자2(김민우)에게 보낼 때, 처음 push되는 메세지가 전달되지 않음 - 채팅방 안에서의 이미지 다운로드 등의 이벤트 기능이 없는 이슈 # 240829 앱 테스트 동네 - 동네 피드에서 다른 사용자가 남긴 글에 댓글 작성이 불가능한 이슈 # 데일리 빌드 후 close → 마켓빌드가 되면 추가적으로 한번 더 테스트

# DB - 트랜젝션 - 데드락 전체적인 윤곽을 그리고 여러번 보면서 디테일을 살리기. 오히려 한곳만 봐서 이해하지 못하는 경우가 발생 포커스를 장애상황에 대해서 어떻게 대응할지 파악부터!! - DB, 앱, kafka에 대해서 문제가 생길 경우, 어떻게 장애 복구 CTO 실의 우선순위 - 운영의 포커스!! - 대응을 하지 못할 수 있음 -> 장애복구 시간이 딜레이가 발생 -> 안됨 - 장애 케이스들 - 인터넷에 찾아보기! - 같은 구성의 시스템이 없기 때문에 상황이 다를 수 있음 - 서버의 부하가 생겼을 때 어느 서버가 다운될까? - 실제로 어느 서버가 부하가 걸리는지 어떻게 확인? - 서버는 혼자 동작하지 않음 우선적으로 해야 할 것 - 서버별로 장애를 어떻게 대응할 것인가? - 앱서버 어떻게? - Kafka 어떻게? - Kafka 증설 하는 방법 알아? 모르지 - 알도록! - mongodb, redis 어떻게? - 이중화가 안되어 있으니 이중화 하는 방법도 고민. 페일오버 기능이 되었는지 확인, 빠르게 복구, 기존 성능을 가져가면서 복구 뭐는 어떻게 봐야되는지 서버에 따라 특징이 다르다 예) 앱서버 같은 경우 볼륨보다는 cpu, 메모리 성능을 사용하기 때문에 거기서 장애가 발생한 경우 어떻게 대응할 것인가. 레디스 - 메모리 - 어떤 지표? 문제가 생기기전에 미리 케치 # 장애 대응 방법 예시 문자 - 로그 확인 경로 - 로그 확인 후 대응 방법 체크 - 문자인증 api 쓰는 법 : 클라 - push 서버로 어떻게 데이터를 보낼까? - 문장인증 호출 - 로그 : mongoDB - 로그 파악 # redis conf 파일 찾아보기

# 용어 정리 커넥션 풀 (Connection Pool): - 애플리케이션에서 데이터베이스에 연결이 필요할 경우 미리 준비된 Connection 객체를 사용하여 애플리케이션의 성능을 향상시킴 스레드 풀은 - 작업처리에 사용되는 스레드를 제한된 개수만큼 정해놓고 작업큐 (Queue)에 들어오는 작업들을 하나씩 스레드가 맡아 처리 - 그렇게 하면 작업처리 요청이 폭증되어도 스레드의 전체개수가 늘어나지 않으므로(제한해서 하나씩 처리하기 때문) 시스템 성능이 급격히 저하되지 않는다. # 앱서버 장애대응 어떻게? 구글링 참고 실제로 어떻게 동작하는지 봐야함. 어떤 api가 있는가 - 대략적인 어떤 기능? - 이 처리는 어떤처리? db조회, 리턴 스웨거 확인 crud로 처리할 수 없는 것에 대한 동작은 어떻게 되는가. 어떻게 이중화 처리가 되는가? 경합처리 - 똑같은 디비를 바라보고 있는데 왜 문제가 안생겨? 두 개의 인스턴스에 같은 컨테이너가 올라가고 DB 서버 커넥션이 같을 때 경합 처리는 다음과 같은 방식으로 이루어질 수 있습니다. 1. DB 서버 측 잠금 (Lock) 메커니즘: 행 수준 잠금 (Row-Level Locking): DB 서버는 동시에 여러 트랜잭션이 같은 데이터에 접근하려고 할 때, 행 수준 잠금을 사용하여 데이터 일관성을 유지합니다. 즉, 한 트랜잭션이 특정 행을 수정 중일 때 다른 트랜잭션은 해당 행에 대한 수정을 대기해야 합니다. 테이블 수준 잠금 (Table-Level Locking): 경우에 따라 DB 서버는 전체 테이블에 대한 잠금을 사용할 수도 있습니다. 이 경우, 한 트랜잭션이 테이블을 수정하는 동안 다른 트랜잭션은 해당 테이블에 대한 모든 작업(읽기 및 쓰기)을 대기해야 합니다. 2. 애플리케이션 측 경합 처리: 낙관적 잠금 (Optimistic Locking): 애플리케이션은 데이터를 읽어올 때 버전 정보 또는 타임스탬프를 함께 가져옵니다. 데이터를 수정하려고 할 때, 가져온 버전 정보 또는 타임스탬프와 현재 DB의 정보를 비교하여 다른 트랜잭션에 의해 데이터가 변경되었는지 확인합니다. 만약 변경되었다면, 충돌을 감지하고 적절한 처리(예: 재시도 또는 오류 처리)를 수행합니다. 비관적 잠금 (Pessimistic Locking): 애플리케이션은 데이터를 읽어올 때 명시적으로 잠금을 획득하고, 수정이 완료될 때까지 잠금을 유지합니다. 이렇게 하면 다른 트랜잭션이 해당 데이터에 접근하는 것을 방지하여 충돌을 예방할 수 있습니다. 그러나 잠금 경합으로 인해 성능 저하가 발생할 수 있습니다. 3. 분산 잠금 (Distributed Locking): Redis, ZooKeeper 등: 여러 인스턴스가 공유하는 외부 저장소를 사용하여 분산 잠금을 구현할 수 있습니다. 이를 통해 여러 인스턴스 간에 데이터 접근을 조정하고 경합을 방지할 수 있습니다. # 앱서버의 특징 - cpu, 메모리 사용량이 중요 - 앱을 구동시키며 컨테이너를 동해서 cpu 및 메모리 작업이 많기 때문. - 앱서버 이중화 처리 - 서버 업그레이드를 하는 시점에서 서비스 중단 시간이 발생하기 때문에 시간 차를 고려해서 배포하는 것이 필요 - 서버의 두대의 인스턴스가 동일한 컨테이너로 작동 - 경합처리? 똑같은 디비를 바라보고 있는데 왜 문제가 생기지 않는가? # 앱 서버별 특징 api, chat : 인바운드 요청에 따른 아웃바운드 응답을 줘야함. push : 인바운드를 직접 받지 않고 다른 서버에서 받은 요청을 가공해서 응답을 줌 # 앱서버의 구성 API - prod-api-1 - api-prod-container - prod-api-2 - api-prod-container CHAT 서버 - prod-chat-1 - chat-prod-container - prod-chat-2 - chat-prod-container PUSH 서버 - prod-push-1 - push-prod-container - prod-push-2 - push-prod-container

# kafka 문제 발생 로그 파일 깨짐 meta properties, 나머지 파일도 깨지면서 정상작동이 안됨 약간 의심 : 특정 브로커 - 잘 종료가 안되서 깨진 상태로 싱크 된 이유로 보임 카프카 3대가 정보 공유 - 비정상적 데이터 저장시 다른 서버도 비정적 데이터 저장 유사적인 상황에서 파악해야한다. - 구글링 - 러프하게 파악 장상적 메세지 쌓임 채팅 : 웹 소켓 채널 / 한 쪽 안될 시 Push 연결 안될 시 소켓 연결이 되어 있는지 확인 (Redis)에서 연결이 되어 있는 지 연결이 안되어있으면 그게 문제, 아니면 Push (kafka) # kafka 로그 경로 log.dirs=/tmp/kafka-logs 언애 meta.properties 파일 존재 # 해결 방법 카프카 설정파일(카프카 설치 디렉토리/config/server.properties)의 log.dirs 항목에서 설정되어 있는 카프카 로그 path로 가보면 meta.properties라는 파일이 있는데 해당 파일을 지워주고 카프카를 재시작해주면 해결된다. $ cd [log-dir] $ rm -rf meta.properties $ systemctl restart kafka-server # 참고 블로그 https://eg3020.blogspot.com/2020/11/apache-kafka-metapropertie.html https://twofootdog.tistory.com/93 # meta.properties 저장 데이터 cluster.id: 카프카 클러스터를 고유하게 식별하는 ID입니다. 클러스터 내 모든 브로커는 동일한 cluster.id를 가져야 합니다. broker.id: 해당 브로커를 고유하게 식별하는 ID입니다. 클러스터 내 각 브로커는 서로 다른 broker.id를 가져야 합니다.

dev-postgres port 5432

# 버전 0.9.1 1. 개인화면s 설정 > 프로필 이미지 등록 문제 (#148) - 정상 동작 d 주소록 친구 추가/삭제 문제 (#160) - 정상동작 주소록 친구 중 회원인 친구 인식 문제 (#150) - 정상 동작 직접 친구 추가 시 발생하는 이슈 (#151) - 정상동작 추가적으로 발생한 이슈 - 주소록 친구 추가를 진행 후, 개인의 친구 목록에서 회원인 친구를 클릭할 경우, 친구 목록 화면에서 "이미 친구입니다" 토스트 메시지와 함께 회원인 친구가 친구 목록에서 보이지 않음 - mongodb에서 해당 친구 정보 삭제를 2번 재진행 후 친구 목록에 회원인 친구 정상 출력 처음 테스트 진행 시, 정상 동작하였으나, 다시 테스트 시 같은 문제 발생 - db에서 정보 삭제 후 재시도 3회만에 다시 추가됨을 확인 2. 채널 화면 채널 소식의 댓글 수정/삭제 문제 (#153) - 정상 동작 댓글 시간 표시 문제 (#154) - 정상 동작 3. 채팅 화면 채팅방 메시지 시간 UI 위치 문제 (#146) - 정상 동작 채팅방 나간 경우의 문제 (#147) - 정상 동작 채팅방 내의 친구 프로필 진입 문제 (#156) - 정상 동작 4. 챗봇 화면 챗봇 대화 응답 없는 문제 (#155) - 정상 동작 # 추가 이슈 1. 프로필 이미지는 정상 등록되어 채팅방 프로필은 업데이트 되나, 친구 목록에서 친구 프로필 확인 시, 빈 이미지 상태로 나옴 2. 162번 수정 - 채팅방 다중 생성 1. 채팅을 받는 사용자 입장에서 두개의 채팅방이 생성되며, 두 개 이상의 채팅방이 한 채팅방 내용을 포함하고 있음(나갔던 채팅방까지 포함) 2. 추가적으로 테스트를 진행하며, 채팅방을 보고 있을 때는 메세지가 전송되지만, 채팅방 밖에 있을 때에는 메세지를 받지 못하는 이슈가 발생 : Mongodb에서 메세지가 정상적으로 전송 됨을 확인

# 루트 권한 실행 docker exec -u root -it prometheus sh # 해당 파일 탐색 docker exec -it prometheus cat /etc/hosts # prometheus 설정 적용 (모니터링 서버) my_hosts 파일 수정 > add_hosts_tocontainer.sh 실행 > docker-comose 제시작 # prometheus 설정 적용 (해당 서버) prometheus는 monitoring instance에서 /home/rocky/prometheus_grafana/prometheus/config/prometheus.yml 파일을 편집하고 prometheus cotainer 재시작 # 수정 명령어 sudo vi prometheus/config/prometheus.yml docker-compose restart && ./add_prometheus_hosts.sh # prometheus 참고 블로그 https://magpienote.tistory.com/262 # 앞으로의 과제 이 설정 과정을 자동화할 수 있는가?

# wikijs 문법 # 이미지 사이즈 지정   # 앵커, 링크 생성 ## 제목2 {#앵커_이름} [[#앵커_이름|표시할 텍스트]] # 파일등록 [공식 칸반 가이드 (PDF 다운로드)](attachment:The-Official-Kanban-Guide_Korean_A4.pdf) # 문법 정리 블로그 https://retr0.wiki/%EC%9C%84%ED%82%A4-%EB%AC%B8%EB%B2%95 # 사용법 정리 블로그 https://www.dongyeon1201.kr/63c594da-135a-48a9-9808-3001ba2a5b3a

# jenkins 문제 발생 해결 # 로그 확인 https://jenkins.slowplat.com/computer/cloud%2Dslowtalk%2Dnode/log Warning: no key algorithms provided; JENKINS-42959 disabled SSHLauncher{host='210.109.54.69', port=22, credentialsId='jenkins_ssh_agent', jvmOptions='', javaPath='/usr/bin/java', prefixStartSlaveCmd='', suffixStartSlaveCmd='', launchTimeoutSeconds=60, maxNumRetries=10, retryWaitTime=15, sshHostKeyVerificationStrategy=hudson.plugins.sshslaves.verifiers.KnownHostsFileKeyVerificationStrategy, tcpNoDelay=true, trackCredentials=true} [09/05/24 13:37:59] [SSH] Opening SSH connection to 210.109.54.69:22. Searching for 210.109.54.69 in /var/jenkins_home/.ssh/known_hosts Searching for 210.109.54.69:22 in /var/jenkins_home/.ssh/known_hosts [09/05/24 13:37:59] [SSH] WARNING: No entry currently exists in the Known Hosts file for this host. Connections will be denied until this new host and its associated key is added to the Known Hosts file. Key exchange was not finished, connection is closed. # 인스턴스 확인 slowinfra > Infra 인스턴스(젠킨스 마스터) 확인 > jenkins 컨테이너 확인 > monitering 인스턴스(젠킨스 슬레이브) 확인 # Insra (젠킨스 마스터) /var/jenkins_home/.ssh/known_host 작성해야 함 - 수정 방법 - 젠킨스 슬레이브 인스턴스로 ssh 접속하면 자동으로 해쉬값 작성됨 # 또 다른 방법 Dashboard > Nodes > cloud-slowtalk-node > Configure에서 Host Key Verification Strategy를 Non verifying Verification Strategy로 설정

# 젠킨스 2.462.2 업그레이드 infra 인스턴스 > jenkins-blueocean > ./jenkins_update.sh 2.462.2 # 정상적으로 동작이 안되는 이슈 - Jenkins war 파일이 정상적으로 다운로드 되었는가? - 원하는 버전이 다운로드 되는지 체크 (2.462.2) - #!/bin/bash # 버전 정보 확인 if [ -z "$1" ]; then echo "Usage: $0 <version>" exit 1 fi VERSION=$1 JENKINS_CONTAINER_NAME="jenkins-blueocean" JENKINS_WAR="update/jenkins.war" JENKINS_WAR_SHA="update/jenkins.war.sha256" #if [ -f $JENKINS_WAR ]; then # echo "File exist, delete it" # rm -f $JENKINS_WAR #fi # Jenkins WAR 파일 다운로드 echo "Download jenkins.war & jenkins.war.sha256" if [ ! -e "$JENKINS_WAR" ]; then wget https://ftp.yz.yamagata-u.ac.jp/pub/misc/jenkins/war-stable/$VERSION/jenkins.war -O $JENKINS_WAR fi if [ ! -e "$JENKINS_WAR_SHA" ]; then wget https://ftp.yz.yamagata-u.ac.jp/pub/misc/jenkins/war-stable/$VERSION/jenkins.war.sha256 -O $JENKINS_WAR_SHA fi #curl -L -o $JENKINS_WAR https://updates.jenkins.io/download/war/$VERSION/jenkins.war # Read the expected SHA-256 hash from the jenkins.war.sha256 file expected_hash=$(cut -d ' ' -f 1 $JENKINS_WAR_SHA) # Compute the actual SHA-256 hash of the jenkins.war file actual_hash=$(sha256sum $JENKINS_WAR | cut -d ' ' -f 1) # Compare the expected hash with the actual hash if [ "$expected_hash" == "$actual_hash" ]; then echo "SHA-256 hash verification succeeded: $actual_hash" else echo "SHA-256 hash verification failed!" echo "Expected: $expected_hash" echo "Actual: $actual_hash" exit 1 fi # Jenkins 컨테이너로 파일 복사 echo "copy jenkins.war to container" docker cp $JENKINS_WAR $JENKINS_CONTAINER_NAME:/usr/share/jenkins # Jenkins WAR 파일 소유권 변경 echo "change ownership of jenkins.war" docker exec $JENKINS_CONTAINER_NAME chown jenkins:jenkins /usr/share/jenkins/jenkins.war # Jenkins 컨테이너 재시작 echo "restart container" docker restart $JENKINS_CONTAINER_NAME

# 버전코드 코드 수정 과제 https://gitlab.slowplat.com/frontend/slowtalk/-/merge_requests/258