update README.md

This commit is contained in:
2026-07-01 05:14:22 +00:00
parent 57377e849f
commit 527cf4549e

101
README.md
View File

@@ -168,34 +168,7 @@ Claude Code / Codex / Gemini 가 사내 AI 게이트웨이를 쓰려면 **본인
> 키는 본인 워크스페이스 안에만 저장되고, 코드/깃에는 올라가지 않습니다. > 키는 본인 워크스페이스 안에만 저장되고, 코드/깃에는 올라가지 않습니다.
> 게이트웨이 주소(`https://litellm.bok.or.kr`)는 이미 설정돼 있으니 건드릴 필요 없습니다. > 게이트웨이 주소(`https://litellm.bok.or.kr`)는 이미 설정돼 있으니 건드릴 필요 없습니다.
---
## 6. Git(Gitea) 사용 — 최초 1회 승인
코드 저장소는 사내 **Gitea**(https://gitea.bokdev.in)입니다. 토큰 입력 없이 자동 인증됩니다.
1. 터미널에서 처음 `git clone` / `git push` 등을 하면, **Gitea 승인 화면**으로 안내됩니다.
- 또는 Coder 화면의 **`Gitea`** external auth 항목에서 **Authorize** 를 미리 눌러도 됩니다.
2. 한 번 **Authorize(승인)** 하면, 이후로는 비밀번호 입력 없이 clone/push 가 됩니다.
예:
```bash
cd ~/projects
## 만약 새로운 repo를 다운로드 하고 싶을 경우
git clone https://gitea.bokdev.in/<org>/<repo>.git
## 사용예
git clone https://gitea.bokdev.in/playground/sample.git
## 새로운 버전으로 동기화
cd ~/projects/sample
git add .
git pull
# gitea 행번 / 비밀번호
```
---
## 7. 새 프로젝트 시작하기 (sample 복사) ## 7. 새 프로젝트 시작하기 (sample 복사)
`~/projects/sample` 은 바로 돌려볼 수 있는 Node 예제이며 **읽기 전용 참조**입니다. `~/projects/sample` 은 바로 돌려볼 수 있는 Node 예제이며 **읽기 전용 참조**입니다.
@@ -230,7 +203,6 @@ npm install # 처음 1회: 필요한 라이브러리 설치 (이걸
> LiteLLM 키만은 프로젝트가 아니라 워크스페이스 전체 공용이라 `~/.env`(5번 `update-litellm-key`)에서 관리합니다. > LiteLLM 키만은 프로젝트가 아니라 워크스페이스 전체 공용이라 `~/.env`(5번 `update-litellm-key`)에서 관리합니다.
## 8. 개발하기 ## 8. 개발하기
- **코드 편집**: 왼쪽 파일 목록에서 파일(예: `src/server.js` 또는 `index.js`)을 눌러 수정 → **Ctrl+S 로 저장**. - **코드 편집**: 왼쪽 파일 목록에서 파일(예: `src/server.js` 또는 `index.js`)을 눌러 수정 → **Ctrl+S 로 저장**.
@@ -272,20 +244,10 @@ claude
> 세부 절차를 몰라도 됩니다 — **원하는 걸 자연어로 말하면** bkit이 알맞은 흐름을 골라 줍니다. > 세부 절차를 몰라도 됩니다 — **원하는 걸 자연어로 말하면** bkit이 알맞은 흐름을 골라 줍니다.
---
## 9. 로컬에서 실행하고 브라우저로 확인하기 ## 9. 로컬에서 실행하고 브라우저로 확인하기
코드를 바로 실행해 동작을 확인하는 단계입니다(가장 빠름). 코드를 바로 실행해 동작을 확인하는 단계입니다.
> **배포 전, 점점 "실제 배포에 가깝게" 4단계로 검증합니다.**
> | 단계 | 무엇으로 | 무엇을 확인 | 어디서 |
> |---|---|---|---|
> | **10. 소스 실행** | `npm run dev` | 코드 로직 (가장 빠름) | 워크스페이스 |
> | **11. 컨테이너 빌드** | `podman build`+`run` | 이미지가 제대로 빌드/기동되는지 | 워크스페이스 |
> | **12. Git push** | `git push` | 배포에 쓸 코드를 저장소에 올림 | Gitea |
> | **13. 배포** | Kubero(포털) | 실제 서비스로 빌드/기동 | Kubero |
> 앞 단계가 통과하면 뒤 단계도 거의 그대로 됩니다(같은 코드). 막히면 **앞 단계로 돌아가** 고치세요.
**1) 실행** **1) 실행**
```bash ```bash
@@ -324,59 +286,8 @@ curl 127.0.0.1:3000/s3 # 버킷명 + 파일목록 일부
``` ```
> `"ok": false` + `error` 가 보이면 그 메시지가 원인입니다. 이 임시 URL은 본인만 접근 가능하고 워크스페이스를 끄면 사라집니다. **미리보기용**이며 정식 배포는 13번입니다. > `"ok": false` + `error` 가 보이면 그 메시지가 원인입니다. 이 임시 URL은 본인만 접근 가능하고 워크스페이스를 끄면 사라집니다. **미리보기용**이며 정식 배포는 13번입니다.
---
## 10. 컨테이너로 빌드해서 확인하기 (podman) — 배포 전 점검 ## 10. Gitea(git)에 올리기
9번은 코드를 그냥 실행한 것이고, 실제 배포(Coolify)는 **Dockerfile 로 컨테이너를 빌드**해서 띄웁니다.
배포 전에 **같은 방식(컨테이너)으로 한 번 돌려보면** 배포 후 문제를 미리 잡을 수 있습니다.
(Coolify 도 똑같은 `Dockerfile` 을 쓰므로, **여기서 빌드가 되면 12번 배포 빌드도 거의 됩니다.**)
**1) 빌드**
```bash
cd ~/projects/<본인 프로젝트>
podman build -t myapp . # 현재 폴더의 Dockerfile 로 이미지 빌드
```
(`docker build ...` 도 동일하게 동작합니다 — 실제 런타임이 podman 일 뿐입니다.)
**빌드 로그 읽는 법** — 한 줄씩 `STEP 1/9`, `STEP 2/9` … 식으로 진행됩니다(이게 Dockerfile 의 각 명령). 마지막에
```
COMMIT myapp
Successfully tagged localhost/myapp:latest
<이미지ID>
```
가 보이면 **빌드 성공**입니다. 빌드된 이미지는 `podman images` 로 확인할 수 있습니다.
- **실패하면** 빨간 `Error:` 줄과 **몇 번째 STEP 에서 멈췄는지**를 보세요. 가장 흔한 건 `npm ci`/`npm install` 단계 실패(=의존성 문제, `package.json` 확인)입니다.
**2) 실행**
```bash
podman run --rm -p 3000:3000 --env-file .project-env myapp # 빌드한 이미지를 컨테이너로 실행
# 또는 (빌드+실행 한 번에): podman compose up --build
```
- `--env-file .project-env` 로 DB/S3 값을 컨테이너에 넣어줍니다(이게 없으면 컨테이너 안에서 `/db`·`/s3` 가 실패합니다).
- 기동되면 9번과 똑같이 `sample listening on :3000` 이 보입니다.
**3) 동작 확인** — 컨테이너 접속 확인은 **`127.0.0.1`** 로 하세요(`localhost` 가 간혹 안 잡힙니다). 기대 응답은 9번 표와 동일합니다:
```bash
curl 127.0.0.1:3000/healthz # {"ok":true}
curl 127.0.0.1:3000/db # {"ok":true,"now":"2026-..."}
curl 127.0.0.1:3000/s3 # {"ok":true,"bucket":"coolify-user-data",...}
```
- 브라우저로 보려면 9번과 동일하게 **PORTS 패널 → Forward Port 3000 → Open in Browser**(`https://<자동생성>.coder.bokdev.in`).
- 확인이 끝나면 터미널에서 **Ctrl+C** 로 컨테이너를 멈춥니다(`--rm` 이라 자동 삭제됨).
* 종료되지 않는 경우
```bash
podman ps
podman stop {이름 또는 ID}
```
- 빌드/실행 권한은 워크스페이스에 이미 설정돼 있습니다(별도 설정 불필요).
> 여기서 **빌드 성공 + 3개 엔드포인트 모두 `ok:true`** 면 Coolify 배포도 거의 그대로 됩니다. 안 되면 코드/Dockerfile 을 먼저 고치세요.
---
## 11. Gitea(git)에 올리기
`new-project` 로 만든 폴더는 아직 git 저장소가 아닙니다(`.git` 없음). 아래처럼 올립니다. `new-project` 로 만든 폴더는 아직 git 저장소가 아닙니다(`.git` 없음). 아래처럼 올립니다.
(배포(12번)는 Gitea repo 를 받아서 빌드하므로, 배포 전에 반드시 올려야 합니다.) (배포(12번)는 Gitea repo 를 받아서 빌드하므로, 배포 전에 반드시 올려야 합니다.)
@@ -408,13 +319,15 @@ git push -u origin main
--- ---
## 12. 배포하고 확인하기 (Kubero) ## 11. 배포하고 확인하기 (Kubero)
> 현재 kubero 자동 빌드는 연동되지 않아 kubero에서 직접 pipeline 제작 후 레포지토리를 등록해두어야합니다.
배포는 **Kubero**가 담당합니다. 좋은 소식: 3번에서 **"생성 직후 Kubero 로 배포"를 켰다면 배포 통로가 이미 자동으로 설정**돼 있습니다. 그래서 개발자가 할 일은 사실상 **`git push`(12번)** 뿐입니다. 배포는 **Kubero**가 담당합니다. 좋은 소식: 3번에서 **"생성 직후 Kubero 로 배포"를 켰다면 배포 통로가 이미 자동으로 설정**돼 있습니다. 그래서 개발자가 할 일은 사실상 **`git push`(12번)** 뿐입니다.
### 자동 배포 (TODO: 현재 안됨) ### 자동 배포 (TODO: 현재 안됨)
1. 12번처럼 **`git push`** 합니다. 1. **`git push`** 합니다.
2. Kubero가 변경을 감지해 **자동으로 다시 빌드·배포**합니다(환경변수도 사번 기준으로 **자동 주입** — 직접 넣을 필요 없음). 2. Kubero가 변경을 감지해 **자동으로 다시 빌드·배포**합니다(환경변수도 사번 기준으로 **자동 주입** — 직접 넣을 필요 없음).
3. 잠시 후 아래 주소로 확인합니다: 3. 잠시 후 아래 주소로 확인합니다:
``` ```
@@ -428,7 +341,7 @@ git push -u origin main
![배포된 앱](images/08-deployed-app.png) ![배포된 앱](images/08-deployed-app.png)
### 나중에 배포 (3번에서 deployNow 를 껐던 경우) ### 나중에 배포
- 개발이 끝난 뒤 포털의 **"AI DEV 앱 만들기"** 흐름에서 배포 옵션을 켜 실행하거나, **Kubero**(https://kubero.bokdev.in) 화면에서 해당 앱의 빌드를 실행합니다. - 개발이 끝난 뒤 포털의 **"AI DEV 앱 만들기"** 흐름에서 배포 옵션을 켜 실행하거나, **Kubero**(https://kubero.bokdev.in) 화면에서 해당 앱의 빌드를 실행합니다.
- 한 번 배포되어 통로가 연결된 뒤에는, 이후 `git push` 시 **자동 재배포**됩니다. - 한 번 배포되어 통로가 연결된 뒤에는, 이후 `git push` 시 **자동 재배포**됩니다.