새 버전을 올린 뒤 서비스가 요청을 받을 준비가 됐는지 확인하고 싶을 때가 있습니다. 얼쑤에서는 팀 채팅에서 정해진 명령을 실행하면 서버가 답한 시각과 점검 결과를 표로 받을 수 있게 했습니다. 채팅 명령이 서버까지 이어지는 만큼, 어떤 입력을 받을지와 서버에서 무엇을 실행할지를 각각 정했습니다.
채팅 명령을 세 가지 질문으로 나누기
두 서버에 각각 서버 자원, 컨테이너, 준비 상태를 보는 세 가지 명령을 두었습니다. 디스크가 얼마나 남았는지와 특정 앱이 요청을 받을 수 있는지는 다른 곳에서 읽어야 합니다.
| 보고 싶은 것 | 어떤 질문에 답하나 |
|---|---|
| 서버 자원 | 서버 전체의 메모리와 디스크가 얼마나 남았나? |
| 컨테이너 | 어떤 앱이 실행 중이고 메모리를 얼마나 쓰나? |
| 준비 상태 | 정해진 서비스 주소가 응답하나? 마지막 복원 시험은 어떤 결과였나? |
채팅에서 슬래시 명령을 보내면 중계 프로그램이 등록된 명령과 인증값, 요청이 들어온 채널을 확인합니다. 중계는 명령 자체로 대상 서버와 점검 종류를 결정합니다. 서버 주소나 실행할 프로그램을 채팅에서 따로 입력할 수 없습니다.
서버에서도 같은 범위로 제한하기
중계는 점검 전용 SSH 연결로 대상 서버에 접속합니다. 서버는 이 접속에 정해진 프로그램만 실행하게 하는 SSH의 강제 명령을 적용합니다. 그 프로그램이 점검 종류 세 가지 중 하나인지 다시 검사합니다. 일반 셸 접속과 파일 전송, 포트 포워딩은 전용 접속에서 차단합니다. 조회에 관리자 권한이 필요할 때도 전용 계정에 포괄 권한을 주지 않고 정해진 수집 명령만 허용합니다.
팀 채팅 → 중계에서 명령과 채널 확인 → 전용 SSH
→ 서버에서 점검 종류 확인 → 결과를 표로 게시
한 번의 조회가 계속 기다리면 채팅에서도 결과를 받을 수 없습니다. 접속과 수집에 제한 시간을 두고 동시에 실행할 점검의 개수도 제한했습니다. 운영 확인에서는 두 서버의 세 가지 명령을 각각 실행해 총 여섯 결과가 채팅에 돌아오는 것을 확인했습니다.
막아야 할 요청을 두 곳에서 확인
채팅의 중계와 서버의 SSH 제한은 서로 다른 입력을 처리합니다. 중계에서는 로컬 HTTP 서버를 열고 허용되지 않은 채널, 틀린 인증값, 명령 필드가 두 번 들어간 요청을 보냈습니다. 세 경우 모두 거절 안내를 반환했고 점검 실행을 제출한 횟수는 0이었습니다. 응답의 HTTP 상태는 200이었으므로, 거부 여부는 상태 코드와 별도로 응답 문구와 실행 제출 기록을 확인했습니다.
| 확인한 위치 | 보낸 입력 | 확인한 결과 |
|---|---|---|
| 중계의 로컬 HTTP 검사 | 다른 채널, 틀린 인증값, 중복 명령 필드 | 거절 안내, 실행 제출 0회 |
| 서버의 점검 전용 SSH 접속 | 임의 명령, 추가 인자, 빈 명령, SFTP | 종료 상태 64로 거부 |
| 같은 전용 접속 | 포트 포워딩, 허용 목록 밖의 sudo 실행 | 각각 종료 상태 255와 1로 거부 |
SSH 결과는 전용 접속을 구성했을 때 기록한 운영 검증입니다. 정해진 세 종류의 점검이 성공하는 경우도 같은 제한 환경에서 확인했습니다.
응답에 확인 범위를 남기기
점검 표에는 수집 시각을 표시합니다. 지난 메시지를 열었을 때는 당시 결과를 보고 있는 셈입니다. 준비 상태의 ‘정상’은 표에 적힌 검사를 통과했다는 뜻입니다. 백업 항목에 마지막 복원 시험이 성공했다고 나오면 이전 시험의 결과를 읽은 것입니다. 새 복원 시험이 필요하면 별도로 실행해야 합니다.
비슷한 기능을 만들 때는 채팅의 명령 목록부터 정하고, 서버에서도 그 목록에 해당하는 작업만 실행하게 제한할 수 있습니다. 답변에 대상, 수집 시각, 검사한 항목을 같이 남기면 다음 사람이 표를 보고 무엇을 추가로 확인할지 결정할 수 있습니다.
댓글
댓글과 반응은 GitHub 계정으로 로그인해 남길 수 있어요.