o2o-site-AEO/deploy.sh
Mina Choi 45cc80b60a [chore] deploy: 배포 시 origin/main 하드 리셋 — fetch 성공에만 건다
배포 서버의 작업트리는 main 의 사본이지 작업 공간이 아니다. pull(--ff-only)은
force-push 가 나면 막히고, 서버에서 손댄 흔적도 남는다.

- deploy.sh: git pull → fetch + reset --hard origin/$BRANCH.
  ★ fetch 실패 시 리셋하지 않는다. 킹서버엔 gitea 자격증명이 없어 fetch 가 죽는데,
  그 상태의 origin/main 은 낡은 ref 다 — 실측 HEAD=9b4fe40 / origin/main=4871e50,
  믿고 리셋하면 한 커밋 롤백되고 빌드는 성공한다. 조용히 틀리는 종류다.
- git clean 은 넣지 않는다. .env·nginx/site.conf 는 추적되지 않는 파일이라 clean 이 지운다.
- DEPLOY_BRANCH 로 대상 브랜치를 바꿀 수 있다(기본 main).

킹서버에서 실행 검증: fetch 실패 → 리셋 건너뜀, HEAD 9b4fe40 유지,
solution-site 재생성 정상. bash -n 통과.
2026-09-01 10:20:12 +09:00

127 lines
5.5 KiB
Bash
Executable File

#!/usr/bin/env bash
# 배포 — 코드를 당기고, 지정한 서비스만 다시 빌드해 갈아끼운다.
#
# ./deploy.sh 전체
# ./deploy.sh solution-backend 그 서비스만
# ./deploy.sh solution-backend solution-worker 여럿
#
# 서비스명 대신 컨테이너명(o2o-web4ai-solution-backend)으로 불러도 받는다.
set -euo pipefail
cd "$(dirname "$0")"
PREFIX=o2o-web4ai
# api·worker·api-admin 은 이미지 한 벌(o2o-web4ai-backend)을 나눠 쓴다.
BACKEND_SVCS=(solution-backend solution-worker admin-backend)
BRANCH=${DEPLOY_BRANCH:-main}
PULL=1
ONLY=0
TARGETS=()
usage() {
cat <<'USAGE'
사용법: ./deploy.sh [옵션] [서비스...]
옵션
--no-pull 코드를 당기지 않는다(디스크에 있는 코드 그대로 빌드)
--only 백엔드 형제 서비스를 함께 갈아끼우지 않는다 (아래 ★ 참고)
-h, --help
환경변수
DEPLOY_BRANCH 기본 main. 다른 브랜치를 배포할 때만 쓴다
서비스: solution-backend · solution-worker · solution-frontend · solution-site
admin-backend · admin-frontend (프로필 admin, 기본 기동에서 빠져 있다)
o2o-web4ai-solution-backend 처럼 컨테이너명으로 적어도 된다
★ solution-backend·solution-worker·admin-backend 는 이미지가 한 벌이다. 하나를 빌드하면 나머지도 새 이미지로
갈아끼워야 한다 — 안 그러면 옛 코드로 도는 컨테이너가 남는데, 셋 다 "살아 있음" 이라
화면상으로는 배포가 끝난 것처럼 보인다. --only 는 그걸 알고 건너뛸 때만 쓴다.
USAGE
}
while [ $# -gt 0 ]; do
case "$1" in
--no-pull) PULL=0 ;;
--only) ONLY=1 ;;
-h|--help) usage; exit 0 ;;
-*) echo "모르는 옵션: $1" >&2; usage >&2; exit 2 ;;
*) TARGETS+=("${1#"$PREFIX"-}") ;; # 컨테이너명으로 불러도 받는다
esac
shift
done
ALL_SVCS=$(docker compose config --services)
for t in ${TARGETS+"${TARGETS[@]}"}; do
grep -qx "$t" <<<"$ALL_SVCS" || {
echo "그런 서비스가 없다: $t" >&2
echo "있는 것: $(tr '\n' ' ' <<<"$ALL_SVCS")" >&2
exit 2
}
done
# ── 코드 ────────────────────────────────────────────────────────────
# 배포 서버의 작업트리는 main 의 **사본**이지 작업 공간이 아니다. 그래서 머지(pull)가 아니라
# origin/$BRANCH 로 하드 리셋한다 — 밖에서 force-push 가 나도 --ff-only 로 막히지 않고,
# 서버에서 누가 손댄 흔적이 다음 배포까지 살아남지 않는다.
#
# ★ fetch 가 실패하면 **리셋하지 않는다.** 이 서버엔 gitea 자격증명이 없어 fetch 가 죽는데,
# 그 상태의 origin/$BRANCH 는 마지막으로 fetch 된 낡은 ref 다.
# 실측(2026-09-01 킹서버): HEAD=9b4fe40 인데 origin/main=4871e50 — 믿고 리셋하면 한 커밋
# 롤백된다. 그러고도 빌드는 성공하고 컨테이너는 뜬다. 조용히 틀리는 종류다.
#
# ★ git clean 은 하지 않는다. .env 와 nginx/site.conf 는 추적되지 않는 파일이고 서버마다
# 다르다 — reset --hard 는 이 둘을 건드리지 않지만 clean 은 지운다.
if [ "$PULL" = 1 ]; then
echo "▶ git fetch origin $BRANCH"
if git fetch --prune origin "$BRANCH" 2>&1; then
DIRTY=$(git status --porcelain)
if [ -n "$DIRTY" ]; then
echo " ! 작업트리 변경을 버린다:"
sed 's/^/ /' <<<"$DIRTY"
fi
echo "▶ git reset --hard origin/$BRANCH"
git reset --hard "origin/$BRANCH"
else
echo " ! fetch 실패 — 리셋을 건너뛰고 디스크에 있는 코드 그대로 간다." >&2
echo " origin/$BRANCH 가 낡았을 수 있어 그걸로 리셋하면 배포가 조용히 롤백된다." >&2
echo " (밖에서 밀어넣었으면 이대로 두면 되고, 자동화하려면 gitea 배포키를 건다)" >&2
fi
fi
echo "▶ 지금 코드: $(git log --oneline -1)"
# ── 대상 정하기 ─────────────────────────────────────────────────────
if [ ${#TARGETS[@]} -eq 0 ]; then
SVCS=() # 빈 인자 = compose 가 전부로 해석한다
echo "▶ 대상: 전체"
else
SVCS=("${TARGETS[@]}")
# 백엔드 하나를 건드리면 같은 이미지를 쓰는 형제도 함께 갈아끼운다.
if [ "$ONLY" = 0 ]; then
for t in "${TARGETS[@]}"; do
for b in "${BACKEND_SVCS[@]}"; do [ "$t" = "$b" ] || continue
for sib in "${BACKEND_SVCS[@]}"; do
printf '%s\n' "${SVCS[@]}" | grep -qx "$sib" || {
SVCS+=("$sib")
echo " + $sib — 같은 이미지를 쓴다(옛 코드로 남지 않게 함께 간다)"
}
done
done
done
fi
echo "▶ 대상: ${SVCS[*]}"
fi
# ── 빌드 · 교체 ─────────────────────────────────────────────────────
# build 절이 없는 서비스(node:24-alpine · nginx:alpine)는 build 가 조용히 건너뛴다.
echo "▶ build"
docker compose build ${SVCS+"${SVCS[@]}"}
echo "▶ up -d"
docker compose up -d --force-recreate ${SVCS+"${SVCS[@]}"}
echo
docker compose ps
echo
echo "로그: ./log.sh"