연결 중 WK

개요

등록된 에이전트를 REST API 로 훑는다 · 이벤트는 SSE 로 수신
/agent 에이전트 개요

연결도

콘솔 → 에이전트 → 모듈. 그리는 것은 소유 관계다

전체 에이전트

/agents 목록
에이전트는 자기가 어느 매니저에 속하는지 모릅니다. 관계는 이 콘솔에만 있습니다 — 여기서 지우면 관리가 끊길 뿐 에이전트와 그 모듈은 계속 돕니다. 등록 정보(주소·토큰)는 이 콘솔의 디스크에만 남습니다.

에이전트 목록

—

/agent/:id —

기본 정보

사람이 정하는 값 · 설정에서 온다

보고된 관측값 · 에이전트가 알려준다

EC2 인스턴스

연결 관계

에이전트와 모듈의 연결 상태를 확인합니다

이 에이전트의 모듈

등록한 모듈과 PM2 목록을 이름으로 맞춰 본 결과다

드레인

인스턴스 정지 준비
선택한 모듈을 정상 종료합니다. ready: true 가 admin 이 ec2:StopInstances 를 호출해도 된다는 신호입니다 — 에이전트는 AWS 를 직접 부르지 않습니다. 모르는 이름이 섞이면 ready: false 입니다(fail closed).

멈출 모듈 · 명시적으로 선택해야 한다

PM2 는 SIGINT 를 보내고 ecosystem 의 kill_timeout 만큼 기다린 뒤 SIGKILL 합니다. 앱이 SIGINT 를 처리하지 않으면 처리 중인 작업은 끊깁니다.

준비 중

에이전트 자신의 자원 사용과 상태를 시간 축으로 보는 화면입니다. 지금 에이전트가 수집하는 것은 상태 한 장(PM2 연결 여부·모듈 수)뿐이라, 만들 수 있는 것은 현황판이지 추이 차트가 아닙니다. 추이를 원하면 저장·롤업·리텐션을 먼저 정해야 하고, 그건 별개 결정입니다.

준비 중

에이전트 자신의 로그입니다. 모듈의 로그는 모듈 상세의 로그 탭이 담당합니다 — 둘을 섞으면 무엇을 보는지 흐려집니다. 에이전트는 pino 로 stdout 에 쓰고 있어, systemd journal 이나 파일 중 어디서 읽을지부터 정해야 합니다.

모듈

에이전트가 관리하는 PM2 프로세스
/agent/modules 모듈

모듈

에이전트 자신은 PM2 밖에서 돌기 때문에 목록에 없다

템플릿

config 를 작성할 때 쓰는 출발점 — 이 콘솔에만 있다
/agent/templates 템플릿
템플릿은 새 config 의 출발점일 뿐입니다. 배포하고 나면 연결이 끊깁니다 — 템플릿을 고쳐도 이미 배포된 config 는 바뀌지 않습니다. 에이전트는 템플릿을 알지 못하고, 이 목록은 이 콘솔에만 있습니다.

파일 템플릿

config 를 작성할 때 출발점으로 쓴다
템플릿은 이 콘솔을 돌리는 머신의 디스크에 평문으로 저장됩니다 (admin-dev/data/templates.json). 저장소에는 올라가지 않으므로 다른 사람과 공유되지 않고, 이 콘솔을 버리면 함께 사라집니다. JWT_SECRET 같은 비밀값은 넣지 말고 자리표시자만 두십시오.

—

/agent/modules/:name —

이벤트

에이전트의 PM2 이벤트 버스(launchBus)에서 SSE 로 즉시 전달된다 — 폴링이 아니다
/events이벤트

프로세스 이벤트 · 명령 로그

배포

GitHub Actions 의 수동 실행을 여기서 누릅니다
/deploy배포
실행은 GitHub 이 합니다. 배포 로직은 각 레포의 워크플로에 그대로 있고, 콘솔이 꺼져 있어도 Actions 탭에서 똑같이 돌릴 수 있습니다. 입력 폼도 콘솔이 정하지 않고 워크플로가 선언한 workflow_dispatch.inputs 를 읽어 그립니다 — 그래서 워크플로에 입력이 늘어도 이 화면은 고치지 않습니다.

배포 파이프라인

모듈 하나가 레포의 워크플로 하나다

로그

아직 만들지 않은 메뉴입니다
/logs로그

준비 중

에이전트가 PM2 로그를 흘려보내는 화면입니다. 자리를 먼저 잡아두어, 나중에 넣을 때 정보구조가 흔들리지 않게 했습니다.

이미 있는 것launchBus 의 log:out/log:err 를 구독하면 된다. WS 스트림이 이미 있어 추가 인프라가 필요 없다
먼저 정할 것백프레셔 정책. admin 이 못 따라갈 때 무엇을 버릴지 정하지 않으면 에이전트 메모리가 샌다
범위온디맨드 tail 로 시작한다. 전역 검색은 로그 파이프라인이 필요하고 그건 별개 결정이다

내용


  

  

    이 콘솔이 배포한 내용입니다 — 호스트에서 직접 고쳤다면 다를 수 있습니다.
    
    
  





  

    
배포 대상 설정

    
    
    
  

  

    
    

      
      
이 파일이 운영 배포의 대상을 정합니다. 여러 레포의 워크플로가 함께 읽으므로,
      고치면 이 저장소 밖의 배포에도 영향이 갑니다. 저장 전에 사본을 남깁니다
      (.bak-<시각>) — git 에는 이력이 없으니 그 사본이 되돌릴 유일한 자리입니다.

    


    

    


    

      

        
        
        
        
        
      

      
      최상위 키가 환경입니다. TARGETS 는 접속 정보,
      SECRETS 는 키페어 이름 → GitHub Secret 이름입니다.
      모듈 키가 곧 systemd 유닛 이름이고, 쓰지 않는 환경도 {} 로 둬야 합니다.
    


    

      
      

    

  

  

    
    
    
    
  




  

    
파이프라인 등록

    
    
  

  

    

      
등록은 장부일 뿐입니다. 여기 적는다고 배포가 되지 않고, 지운다고
      이미 나간 배포가 되돌려지지 않습니다. 입력 항목은 적지 않습니다 —
      워크플로에서 읽어 옵니다.

    

    

      
      
      이 목록에서 부를 이름입니다. 레포 이름과 같을 필요는 없습니다.
    

    

      
      
    

    

      
      
    

    

      
      
      파일 이름만 적습니다 — .github/workflows/ 는 떼고.
      그 워크플로에 workflow_dispatch 가 있어야 수동으로 돌릴 수 있습니다.
    

    

      
      
      배포 모달을 열었을 때 미리 골라 둘 브랜치입니다. 그 자리에서 바꿀 수 있습니다.
    

    

      
      
    

  

  

    
    
    
    
  




  

    
배포

    
    
    
  

  

    

      
      
      이 브랜치의 코드가 나갑니다. 입력 항목도 이 브랜치의
      워크플로 파일에서 읽으므로, 브랜치를 바꾸면 폼이 다시 그려집니다.
    


    
워크플로를 읽는 중…


    
    


    

    

    

      
      

    

  

  

    
    
    
    
  




  

    
실행

    
    
    
  

  

    
읽는 중…

  

  

    
    
    GitHub 에서 보기
    
  




  

    
로그

    
    
    
  

  

    

      

      
      
      
      
      
    

    

    

  

  

    
    
    
  




  

    
배포

    
    
  

  

    

      
      
배포는 파일을 쓰는 것까지입니다. 이 모듈은 여전히 옛 설정으로 돕니다 —
      반영은 배포 뒤 재시작으로 따로 지시합니다.

    

    

      
      
—

    

    

      
      
      파일명만 적습니다 — 경로는 쓸 수 없습니다. 같은 파일에 또 배포하면 버전이 하나 오릅니다.
    

    
    

      
      

        
        
        
      

      
      
    

  

  

    
    
    
    
  




  

    
모듈 등록

    
    
  

  

    

      
등록한 모듈만 관리 대상입니다. 목록은 이 장부가 정하고, PM2 는 각 줄에 상태만 채웁니다 —
      그래서 앱이 PM2 목록에서 사라져도 줄은 남아 누락으로 드러납니다.
      등록 자체가 앱을 띄우지는 않습니다. 아래 경로가 그 다음 일(배포·기동)을 가능하게 합니다.

    

    

      
      
—

    

    

      
      
      ecosystem 의 name 과 정확히 같아야 합니다.
      한 글자만 달라도 누락 한 줄과 미등록 한 줄이 한 쌍으로 생깁니다.
    

    
    

      
      
      에이전트 호스트에서 이 모듈이 놓인 디렉터리의 절대경로입니다.
    

    

      
      
      config 를 쓸 디렉터리입니다. current 링크를 쓰는 배치라면
        기동은 .../current 에서 하고 config 는 .../shared 에 써야
        다음 배포에 살아남습니다. 그럴 때만 적습니다.
    

    

      
      
      위 두 디렉터리가 함께 쓰는 파일명입니다 — 경로는 쓸 수 없습니다.
    

    

      
      
기동 대상은 모듈 위치, 배포 대상은 배포 위치(비우면 모듈 위치)에 시작 config 파일명을 붙인 경로입니다.

    

    

      
      
      이 모듈이 듣는 포트입니다. 적어 두면 목록의 열기 버튼으로 바로 띄웁니다
      (—). PM2 는 앱의 포트를 알려주지 않아 사람이 적는 수밖에 없습니다.
      포트를 열지 않는 워커라면 비워 두십시오.
    

    

      
      
      적으면 열기 버튼이 포트 주소 대신 이 주소로 갑니다.
      페이지가 하위 경로에 있거나 https·프록시를 쓸 때 적습니다.
      http:// 또는 https:// 로 시작해야 합니다.
    

    

      
      
    

    
  

  

    
    
    
    
  




  

    
에이전트 등록

    
    
  

  

    

      
에이전트의 REST API 주소와 토큰을 입력하면 이 콘솔이 그 주소로 붙습니다.
      에이전트 쪽에는 아무 설정도 필요 없습니다 — 자기가 등록됐다는 사실조차 모릅니다.

    

    

      
      
      콘솔에서 부를 이름입니다. 에이전트가 보고하는 agent id 와 달라도 됩니다.
    

    

      
      
      에이전트의 HTTP_HOST:HTTP_PORT. 이 콘솔에서 닿아야 합니다.
    

    

      
      
      
      비워 두면 미지정입니다 — 숨지 않고 자기 칩으로 보입니다.
      prod·stg·dev 는 배포 화면과 같은 색을 받습니다.
      모듈은 이 값을 호스트에서 물려받습니다.
    

    

      
      
      에이전트의 API_TOKEN 과 같아야 합니다.
      이 콘솔의 디스크에 평문으로 저장되니 저장소에 올리지 마십시오.
    

    

  

  

    
    
    
    
    
  




  

    
템플릿 만들기

    
    
  

  

    

      
      
    

    

      
      
    

    

      
      

    

    

      
      
      비밀값은 넣지 마십시오 — 저장소에 평문으로 커밋됩니다.