사무실 스택 운영

설치가 끝난 뒤 관리자가 볼 것과, 문제가 생겼을 때 할 일입니다. 설치는 사무실 스택 설치를 봅니다.

언제 무엇을 보나

언제	어디서	정상
매일 아침	관리자 › 시스템 상태 › 설치 구성 · 연결 상태에서 연결 확인	모두 녹색
매일	같은 화면 아래 반복 작업 실행 이력	성공률 100% 에 가까움
매주	백업 결과 `cat <백업 폴더>/last-result.txt`	「성공」, 날짜가 24시간 안
매주	바깥 접속 기록 `sudo sh deploy/onprem/egress-check/report.sh 7d`	모르는 상대가 없음
분기 · 장비 교체 때	복원 리허설(`deploy/onprem/backup/README.md`)	직원 수 · 메시지 수가 백업과 같음

연결 확인은 단추를 누를 때만 바깥 서버에 묻습니다. 메일은 보내지 않습니다.

빨강 · 노랑일 때

확인할 것(설치 구성)

문구	할 일
시스템 메일이 시험 메일함으로 가 실제로는 아무에게도 가지 않습니다	설치 2단계 명령에 `SMTP_HOST` 등 메일 서버 값을 넣어 다시 돌리고 앱을 다시 띄웁니다
메일 서버가 정해지지 않아 시스템 메일을 보내지 못합니다	새 버전을 넣은 뒤라면 아래 「새 버전 넣기」의 `--add-missing` 을 돌리고 앱과 정기 작업을 다시 띄웁니다. 그래도 남으면 위와 같습니다
작업 공간 방식이 Docker 가 아니어서 직원 작업 공간이 열리지 않습니다	설치 2단계를 다시 돌립니다(설정 파일에 `SANDBOX_PROVIDER=docker` 가 들어갑니다). 공급사에 알립니다
모델이 사무실 모델 서버가 아니라 Claude 로 연결되어 있습니다	측정 기준선이 아니면 2단계를 `LLM_MODE` 없이 다시 돌립니다
사무실 모델 서버 주소나 모델 이름이 없습니다	2단계에 `LLM_LOCAL_BASE_URL` · `LLM_LOCAL_MODELS` 를 줍니다
빌드한 버전(커밋)을 알 수 없습니다	앱을 띄울 때 `APP_GIT_SHA=$(git rev-parse HEAD)` 를 붙여 다시 빌드합니다
연동 암호화 키 · 정기 작업 키가 없어 …	비밀 파일(`app.secrets.env`)이 지워졌거나 바뀌었습니다. 비밀 묶음에서 되살리고 공급사에 알립니다. 새로 만들면 저장된 연결 정보를 열 수 없습니다
Zulip 수신기 키가 없어 …	2단계를 다시 돌리면 키를 만듭니다. 그 뒤 앱과 수신기를 다시 띄웁니다

연결 상태

줄	문구	볼 곳 · 할 일
메일 서버	접속 · 로그인하지 못했습니다	메일 서버 주소 · 포트 · 계정 · 비밀번호, 허용 목록에 메일 서버가 있는지. 앱 기록 `docker logs daiops-onprem-app-1 2>&1 \| grep email`
대화 · 보조 모델 서버	접속 키가 맞지 않습니다	비밀 파일의 `LLM_LOCAL_API_KEY` 와 모델 서버 키가 같은지. 고친 뒤 `up -d app`
대화 · 보조 모델 서버	설정한 모델이 서버 목록에 없습니다	모델 서버에 올라간 모델 이름과 `LLM_LOCAL_MODELS` 가 같은지
대화 · 보조 모델 서버	모델 서버에 닿지 못했습니다	모델 서버가 켜져 있는지, 허용 목록에 그 IP · 포트가 있는지
데이터베이스 · 로그인 서비스 · 파일 저장소	응답이 없습니다 · 오류 응답	`cd deploy/onprem/supabase/upstream && docker compose ps` 에서 healthy 가 아닌 것을 `docker compose logs <이름>` 으로 봅니다
Zulip 수신기	N분 동안 연락이 없습니다	`docker logs daiops-onprem-zulip-receiver-1`. 멈췄으면 설치 6단계의 `up -d zulip-receiver`
Zulip 수신기	앱이 켜진 뒤 아직 연락이 없습니다	앱을 다시 띄운 직후면 1분 뒤 다시 확인합니다
Zulip 에서 매니저 찾기	매니저를 Zulip 에서 찾지 못했습니다	그 매니저의 Zulip 「내 메일 주소를 볼 수 있는 사람」을 조직의 모든 사람으로, DAIOps 계정 메일과 Zulip 메일이 같은지
정기 작업	반복 업무 · 작업 대기열이 N분 동안 성공하지 않았습니다	`docker logs daiops-onprem-cron-1`. 컨테이너가 멈췄으면 `up -d cron`
사내 MCP 문	사내 MCP 서버 N개 중 M개가 응답하지 않습니다	그 서버가 켜져 있는지, 허용 목록에 그 IP · 포트가 있는지, https 면 루트 인증서를 `MCP_GATE_CA_FILE` 로 줬는지. 문 기록 `docker logs daiops-onprem-mcp-gate-1`. 그 서버를 일부러 꺼 두었으면(예: 쓰지 않는 기간의 대시보드) 빨강이 맞는 판정입니다
웹 검색	인터넷 페이지를 열지 못했습니다	웹을 켰을 때만 나오는 줄입니다. 바깥 접속 허용 목록에 확인 주소(기본 example.com)와 직원이 열 사이트가 있는지. 고객 망에서 example.com 이 막혀 있으면 `LOCAL_WEB_CHECK_URL` 로 열 수 있는 주소를 줍니다
웹 검색	검색 서버에 닿지 못했습니다	`LOCAL_WEB_SEARCH_URL` 의 검색 서버가 켜져 있는지, JSON 응답(`format=json`)을 켰는지
직원 연결	다시 연결이 필요한 직원 연결이 N개 있습니다	해당 직원 설정 › 연동 서비스에서 「다시 연결」. 메일 · 일정 · Zulip 비밀번호나 키가 바뀐 경우가 많습니다

사내 MCP 서버 붙이기

직원이 사내 시스템을 도구로 쓰게 하려면 그 시스템의 MCP 서버를 설치 설정에 등록하고, 직원 설정에서 같은 이름 · 주소로 등록합니다.

설치 2단계 명령에 DOCKER_SANDBOX_MCP_FORWARDS=<이름>=<IP>:<포트> 를 더해 다시 돌립니다. https 면 <이름>=https://<서버 이름>:<포트> 로 적고, 사내 인증서면 MCP_GATE_CA_FILE=<루트 인증서 파일> 도 줍니다. 여러 개는 콤마로 잇습니다(최대 5개)
그 IP · 포트를 바깥 접속 허용 목록(deploy/onprem/egress-check/egress-allow.conf)에 넣습니다. 빠져 있으면 1단계가 경고합니다
앱과 사내 MCP 문을 다시 띄웁니다: docker compose --env-file deploy/onprem/compose.env -f deploy/onprem/compose.yml up -d app mcp-gate
직원 설정 › 외부 MCP 서버에서 이름은 1단계의 이름, 주소는 그 서버의 실제 주소(예: http://10.0.0.5:8080/mcp)를 그대로 적습니다. 매니저가 승인하면 붙습니다
연결 확인의 「사내 MCP 문」 줄이 녹색인지 봅니다

나중에 1단계의 대상을 바꾸면 그 서버는 붙지 않습니다. 4단계를 새 주소로 다시 하고 다시 승인합니다.

웹 검색 켜기

사무실 스택은 기본으로 인터넷에 닿지 않고, 직원은 웹 검색 · 웹 페이지 열기를 하지 않습니다. 직원 지시문에도 「인터넷에 닿지 않는다」는 안내가 들어갑니다. 고객이 인터넷 일부를 허용할 때만 켭니다.

설치 2단계 명령에 LOCAL_WEB_TOOLS=on 을 더해 다시 돌립니다. 검색까지 쓰려면 사내 검색 서버(SearXNG 등, JSON 응답을 켠 것) 주소를 LOCAL_WEB_SEARCH_URL=http://<검색 서버>:8080/search 로 함께 줍니다. 주지 않으면 페이지 열기만 켜집니다
직원이 열 사이트와 확인 주소(기본 example.com)를 바깥 접속 허용 목록에 넣습니다
앱을 다시 띄웁니다: docker compose --env-file deploy/onprem/compose.env -f deploy/onprem/compose.yml up -d app
관리자 › 시스템 상태 「확인할 것」에 「웹 검색이 켜져 있습니다」가 보이고, 연결 확인의 「웹 검색」 줄이 녹색인지 봅니다

켜도 사내 주소는 열지 않습니다. 사설 대역 · 루프백 · 메타데이터 주소(169.254), 점 없는 사내 이름(supabase · app 같은 설치 안 이름), .local · .internal · .lan 은 거절하고, 다른 주소로 넘어갈 때마다 다시 확인합니다. 한 페이지는 2MB · 15초까지만 가져옵니다.

끌 때는 LOCAL_WEB_TOOLS=off 로 1 · 3단계를 합니다.

https 와 사내 인증서

다른 PC(행사 부스의 노트북 등)에서 앱을 쓰거나 말로 입력 · 회의 녹음을 쓰려면 앱을 https 로 엽니다. 브라우저는 https 주소에서만 마이크를 엽니다. 우리가 만든 사내 인증서를 쓰므로 그 인증서를 노트북마다 한 번 믿게 해야 합니다.

켜기(앱 서버에서)

앱 서버 이름을 정합니다(예: daiops.booth). 노트북의 hosts 파일에 <앱 서버 IP> daiops.booth 한 줄을 넣으면 장비를 옮겨도 주소가 그대로입니다
Supabase 주소를 https 로 바꾸고 다시 띄웁니다: PUBLIC_URL=https://daiops.booth:8443 SITE_URL=https://daiops.booth sh deploy/onprem/supabase/init.sh 뒤 cd deploy/onprem/supabase/upstream && docker compose up -d --wait
설치 2단계 명령에 HTTPS_HOST=daiops.booth 를 더해 다시 돌립니다. 처음이면 사내 루트 인증서(deploy/onprem/https-front/ca/root.crt)가 생깁니다
앱을 다시 빌드해 띄웁니다(설치 3단계 명령)
방화벽에서 사내망 쪽 443 · 8443 을 엽니다

노트북에 믿게 하기(노트북마다 한 번)

Windows: root.crt 를 두 번 눌러 「인증서 설치」 → 「로컬 컴퓨터」 → 「모든 인증서를 다음 저장소에 저장」 → 「신뢰할 수 있는 루트 인증 기관」
macOS: root.crt 를 두 번 눌러 키체인에 넣고, 그 인증서를 열어 「신뢰」 → 「이 인증서 사용 시」를 「항상 신뢰」로
브라우저를 다시 열고 https://daiops.booth 가 경고 없이 열리는지 봅니다

이 인증서는 daiops.booth 와 사내 IP 대역에만 쓸 수 있게 묶여 있어, 다른 사이트 인증서로는 쓸 수 없습니다.

행사 · 시험이 끝나면 노트북에서 이 인증서를 지웁니다.

Windows: 「컴퓨터 인증서 관리」 → 「신뢰할 수 있는 루트 인증 기관」 → 「인증서」에서 「DAIOps office root」를 삭제
macOS: 키체인 접근에서 「DAIOps office root」를 삭제

장비를 옮길 때(예: 앱 서버를 다른 장비로)

옛 장비의 deploy/onprem/https-front/ca/ 폴더를 새 장비의 같은 자리로 옮깁니다(USB 등, 메일 · 메신저로 보내지 않습니다). 옮긴 뒤 옛 장비의 폴더는 지웁니다
새 장비에서 켜기 2~5단계를 합니다. 이름이 같으면 노트북은 손댈 것이 없습니다. 이름이 바뀌면 노트북 hosts 줄만 고칩니다

루트 인증서 열쇠(root.key)는 이 폴더 밖으로 내보내지 않고 백업 묶음에도 넣지 않습니다. 잃으면 폴더를 지우고 3단계를 다시 해 새로 만든 뒤 노트북에 다시 믿게 합니다.

앱을 다시 띄우기 · 새 버전 넣기

새 버전을 넣을 때는 설정 파일에 이번 버전이 새로 읽는 줄부터 덧붙입니다. 있는 줄(모델 서버 주소 등)은 그대로 둡니다.

sh deploy/onprem/init-app.sh --add-missing
APP_GIT_SHA=$(git rev-parse HEAD) docker compose --env-file deploy/onprem/compose.env -f deploy/onprem/compose.yml up -d --build app cron zulip-receiver

덧붙인 줄 이름이 찍힙니다. 덧붙인 값은 이번 버전의 기본값이라, 메일 서버를 정하지 않았으면 시험 메일함으로 붙습니다. 그때는 설치 2단계를 메일 서버 값과 함께 다시 돌립니다.

화면이 1~2분 열리지 않습니다. 데이터는 그대로입니다. 끝나면 연결 확인을 한 번 누릅니다.

공급사에 연락할 때

다음을 함께 보냅니다. 비밀번호 · 키는 보내지 않습니다(화면에도 「있음 · 없음」만 나옵니다).

설치 구성 · 연결 상태 카드 화면 사진(연결 확인을 누른 뒤)
문제가 생긴 시각
빨강인 줄에 적힌 「볼 곳」의 기록 마지막 50줄(docker logs --tail 50 <컨테이너 이름>)

이전사무실 스택 설치 다음 개요