이 글은 코드를 GitHub에 올리기만 하면
Docker 이미지가 자동으로 GHCR에 등록되는 흐름를 직접 만들어보는 따라하기 글이다.

0. 전체 흐름 미리 보기

우리가 만들 구조는 이렇다.

이제 하나씩 따라가 보자.

1⃣ GitHub에서 앱용 Repository 만들기

먼저 GitHub 에서 컨테이너로 배포할 앱 전용 레포지토리를 만든다.

Repository 생성

1. GitHub 접속

2. New repository 클릭

3. 아래처럼 설정

• Repository name: my-first-ghcr-app

• Public (처음엔 공개가 편함)

• Add a README 체크

생성 버튼 클릭

2⃣ 최소한의 앱과 Dockerfile 준비

예시: 아주 간단한 웹앱 구조

index.html

<h1>Hello GHCR 👋</h1> <p>This app is running from a container.</p>

Dockerfile

FROM nginx:alpine COPY index.html /usr/share/nginx/html/index.html

지금은 **“컨테이너가 된다”**는 게 핵심이라
앱은 최대한 단순하게 시작한다.

3⃣ GitHub Actions로 자동 빌드 설정하기

이제 핵심 단계다.
push 하면 자동으로 GHCR에 이미지가 등록되도록 설정한다.

.github/workflows/docker.yml 생성

docker.yml

name: Build and Push to GHCR

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and Push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.actor }}/my-first-ghcr-app:latest

커밋 & 푸시

4⃣ GHCR에 이미지가 자동 등록되는 순간

푸시가 끝나면:

1. GitHub → Actions 탭

2. 워크플로우 실행 확인

3. 성공하면

GHCR 확인 경로

• GitHub 프로필

• Packages 탭

• my-first-ghcr-app 패키지 생성됨

이미지 주소는 이렇게 된다:

ghcr.io/깃허브아이디/my-first-ghcr-app:latest

5⃣ 이 이미지, 어디서든 실행 가능

이제 이 이미지는:

• 시놀로지 Container Manager

• 개인 서버

• VPS

• 로컬 Docker

어디서든 실행 가능하다.

docker pull ghcr.io/아이디/my-first-ghcr-app:latest docker run -d -p 8080:80 ghcr.io/아이디/my-first-ghcr-app:latest

6⃣ 왜 이 방식이 좋은가

이 구조의 핵심 장점은 딱 3가지다.

1. GitHub = 코드 + 이미지의 기준점

2. 빌드 자동화 (사람 손 안 탐)

3. 시놀로지 배포와 자연스럽게 연결

“이미지를 어디에 저장할까?”라는 고민이 사라진다.

#GitHub #GHCR #Docker #GitHub Actions, #CI/CD
#Synology #시놀로지 도커 #배포 자동화
#개인 서버 #홈서버

결론부터 한 줄로 정리하면

Synology의 Container Manager는 Docker CLI 위에 얹힌 “관리 UI”이고,
실제 Docker 엔진은 리눅스 백그라운드에서 그대로 돌아가고 있다.

전체 구조 한 번에 보기

1⃣ Docker CLI와 Container Manager의 관계

Docker CLI

• docker ps, docker run, docker compose up

• 진짜 Docker를 직접 조작하는 도구

• SSH 접속해서 실행

• 표준 Docker 환경과 동일

Container Manager

• DSM 웹에서 클릭으로 관리

• 내부적으로는 Docker API를 호출

• CLI 명령을 대신 실행해주는 관리자

즉,

Container Manager = docker 명령을 대신 쳐주는 GUI

2⃣ “Docker는 어디에 존재할까?”

Synology에서 Docker는 이렇게 관리됩니다.

실제 Docker 위치

• DSM 내부 리눅스 OS

• dockerd 데몬이 백그라운드에서 상시 실행

• Synology가 빌드·패키징한 Docker 엔진

사용자가 직접 보는 건

• Docker 엔진 자체

• Container Manager UI

• SSH로 접근한 Docker CLI

3⃣ Container Manager가 하는 일 (정확히)

Container Manager는 새로운 컨테이너 시스템이 아닙니다.

모두 Docker CLI로도 100% 동일하게 제어 가능

4⃣ CLI로 만든 컨테이너, UI에서 보일까?

보입니다. 완벽하게.

docker run -d -p 3000:3000 my-app

• Container Manager → 컨테이너 목록에 바로 표시

• 중지 / 재시작 / 로그 확인 가능

반대로도 마찬가지입니다.

UI에서 만든 컨테이너 = CLI에서도 동일하게 존재

5⃣ Docker Compose는 어떻게 관리될까?

Synology의 Project 기능은 사실상:

Docker Compose 관리 전용 UI

내부 동작

• docker-compose.yml 저장

• docker compose up/down 실행

• 컨테이너들을 하나의 프로젝트 단위로 묶어 관리

차이점

6⃣ Synology가 “Docker를 통제”하고 있을까?

아니요. Docker는 표준 Docker입니다.

다만,

• DSM에 맞게 패키징

• 권한 / 볼륨 경로를 Synology 방식으로 관리

• GUI 중심 운영을 권장

그래서 느낌은 이렇습니다.

Docker는 완전히 열려 있는데
Synology가 안전한 울타리(UI) 를 씌워둔 상태

7⃣ 언제 CLI를 쓰고, 언제 UI를 쓸까?

Container Manager가 좋은 경우

• 서비스 운영

• 상태 확인

• 재시작, 로그 확인

• NAS 관리 목적

Docker CLI가 필요한 경우

• 자동 배포 (CI/CD)

• GitHub Actions 연동

• 스크립트 기반 관리

• 복잡한 compose 구성

• 개발자 워크플로우

실전에서는 둘 다 씁니다.

핵심 정리

• Docker는 DSM 내부 리눅스에서 정상적으로 실행

• Container Manager는 Docker 위에 얹힌 관리 UI

• CLI UI는 같은 Docker 엔진을 공유

• 컨테이너는 하나의 실체, 접근 방법만 다름