국비교육을 끝내고 취업 전 개인프로젝트를 시작했다.
프로젝트를 시작하기 전에 빠르게 배포를 하기 위해서 깃허브 액션의 파이프라인을 구축하고
도커 swarm으로 무중단배포를 하는 방향으로 3일간 세팅을 시작하여 세팅이 끝나 이렇게 정리를 해보려고 한다.
리액트를 로컬환경에서 셋팅하는 글은 이전글에서 써놨으니 깃허브액션부터 정리하겠다.
깃허브 액션을 연동하기 위해서는 개발툴과 git을 연동시킬 필요가 있다(intellij 기준)
우선 깃허브의 레포주소를 추가해줘야한다.
보통 git bash에서
git remote add origin [브랜치 이름]
이렇게 사용이 가능하지만


여기서 추가도 가능하다.
이렇게 깃허브레포의 Https주소를 추가했다면 코드를 추가해줘야 한다.
보통 git bash로 파일을 push 하는 프로세스로는
1. git init
2. git pull origin main
3. git add.
git add는 인텔리제이의 add를 사용하는 것을 추천한다.

윈도 기준에서 Ctrl + Alt + A로 add가 가능하다.
여기서 깃허브 레포에 파일이 올라가는 구조를 설명하자면
깃허브에는
Working Directory : 로컬파일
Staging Area : git add로 인해서 push를 했을 때 깃허브 레포로 올라가는 파일들
Repository : 깃허브 레포지토리
이렇게 있다.
만약 git bash로 git add. 를 하여 전체폴더의 변경사항을 스캔한다면 코드변화를 정확하기 인식하지 못하는 것 같았다.
그렇기에 무조건 개발툴에서 git add기능을 사용하길 바란다.
4. git commit -m '커밋내용'
5. git push origin [브랜치]
이런 순서로 올릴 것이다.
하지만 처음 파일을 올리면 깃허브 레포에는 ReadMe파일 하나밖에 없기 때문에
refusing to merge unrelated histories
이러한 오류가 생길 것이다.
그렇기에 git bash를 열어서
git pull origin 브런치명 --allow-unrelated-histories
이렇게 pull을 하여 강제로 파일을 불러온다.
추가로
Updates were rejected because a pushed branch tip is behind its remote counterpart.
push를 할 때 이런 오류가 뜰 수도 있을 것이다.
이럴 땐
git push --set-upstream origin [브랜치]
이렇게 강제 push로 해결할 수 있다.
이렇게 소스코드를 깃허브 레포에 올렸다면 이제 깃허브액션을 만들어야 한다.
파일을 올린 깃허브 레포로 들어가서
메뉴 중 Action을 클릭한다.

들어가면 이렇게 템플릿이 나와있을 건데 지금 올리는 건 템플릿이 없기 때문에
Set up a workflow yourself를 클릭한다.
들어가면 workflows 스크립트를 쓰는 페이지가 나올 건데
name: Docker
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
# 도커 메타
- name: Docker meta
id: docker_meta
uses: crazy-max/ghaction-docker-meta@v1
with:
images: tripgago-front
tag-semver: |
{{version}}
{{major}}.{{minor}}
# 도커 빌드 관련 셋업
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
# 도커이미지 빌드하고 허브로 푸쉬
- name: Build Docker image
run: |
docker build -t ${{ secrets.PROJECT_NAME }} .
docker tag ${{ secrets.PROJECT_NAME }} ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
docker login -u ${{ secrets.DOCKERHUB_USERNAME }} -p ${{ secrets.DOCKERHUB_TOKEN }}
docker push ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
이렇게 프런트 부분(리액트) 부븐을 올린다.
간단히 설명한다면
name: Docker
on:
push:
branches: [main]
이건 레포 브랜치의 main에 push이벤트가 생기면 액션을 실행시킨다는 뜻이다.
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
runs-on이라는 게 있을 건데 깃허브액션은 깃허브에서 제공하는 runner이라는 우분투 가상머신에서 CI/CD를 실행한다.(여기서는 CI만 실행)
그 runner을 지정하는 부분이다.
# 도커 메타
- name: Docker meta
id: docker_meta
uses: crazy-max/ghaction-docker-meta@v1
with:
images: tripgago-front
tag-semver: |
{{version}}
{{major}}.{{minor}}
이건 도커의 메타데이터를 저장하는 부분인데 크게 중요하다고는 생각하지 않는다.
# 도커 빌드 관련 셋업
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
# 도커이미지 빌드하고 허브로 푸쉬
- name: Build Docker image
run: |
docker build -t ${{ secrets.PROJECT_NAME }} .
docker tag ${{ secrets.PROJECT_NAME }} ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
docker login -u ${{ secrets.DOCKERHUB_USERNAME }} -p ${{ secrets.DOCKERHUB_TOKEN }}
docker push ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
이 부분에서는 빌드셋업을 하고 도커빌드를 실행한다.
깃허브 레포파일구조는

workflows에 파이프라인 스크립트가 있고
config/nginx에 default.conf(나중에 설명)이 있다.
여기서 가장 중요한 것이 Dockerfile인데
FROM node:16 AS builder
# set working directory
WORKDIR /app
COPY package.json .
COPY package-lock.json .
RUN npm install .
RUN npm install react-bootstrap
# Copies everything over to Docker environment
COPY . .
RUN npm run build
#Stage 2
FROM nginx:latest
COPY config/nginx/default.conf /etc/nginx/conf.d/default.conf
RUN rm -rf ./usr/share/nginx/html/*
COPY --from=builder app/build /usr/share/nginx/html
EXPOSE 3000
ENTRYPOINT ["nginx", "-g", "daemon off;"]
이렇게 되어있다.
npm install와 npm ci가 있을 건데 깃허브 액션에서는 ci가 먹히지 않기 때문에 (npm을 설치하는 점에서는 다르지만 몇 가지 차이점이 있다) 꼭 npm install을 하기 바란다.
부트스트랩을 사용한다면 도커빌드를 할 때 무조건 설치를 해야 하기 때문에 설치도 같이 실행한다.
그리고 빌드 후
가장 아래에 네트워크 구조가 있을 것인데 이건 프런트에서 백을 연결하기 위해 nginx프락시를 작동시킬 수 있게
nginx를 설정하고 실행하게 명령어를 지정해 놓는다.
이렇게 파이프라인을 통할 때 도커빌드를 하고 DockerHub에 private로 이미지가 올라간다.

# 기본 서버 설정: 모든 다른 요청을 거부합니다.
server {
listen 80 default_server;
server_name _;
return 444;
}
server {
listen 80;
server_name 도메인;
location / {
proxy_pass http://client:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
간단하게 만들어서 단순하긴 하지만 대충 구조를 보면 리액트와 부트는 각각 3000, 8080 포트를 사용한다.(각 노드는 다 외부접속 불가)
유저가 도메인의 80 포트로 접근을 하면 모든 노드는 같은 도커 네트워크로 묶어져 있기 때문에 도커컨테이너이름인
client:3000(리액트 영역)을 반환해 준다(docker swarm에서는 추가 설정이 필요)
그럼 다음글에서는 백엔드 부분에서 api로 요청하는 부분에 대해서 설명해 보도록 하겠다.
'SpringBoot' 카테고리의 다른 글
리액트 + 스프링 부트 깃허브액션 (nginx프록시, 백엔드 파이프라인) (0) | 2023.10.21 |
---|---|
스프링부트+리액트 처음겪을수 있는 오류와 해결법 (1) | 2023.10.16 |
국비교육을 끝내고 취업 전 개인프로젝트를 시작했다.
프로젝트를 시작하기 전에 빠르게 배포를 하기 위해서 깃허브 액션의 파이프라인을 구축하고
도커 swarm으로 무중단배포를 하는 방향으로 3일간 세팅을 시작하여 세팅이 끝나 이렇게 정리를 해보려고 한다.
리액트를 로컬환경에서 셋팅하는 글은 이전글에서 써놨으니 깃허브액션부터 정리하겠다.
깃허브 액션을 연동하기 위해서는 개발툴과 git을 연동시킬 필요가 있다(intellij 기준)
우선 깃허브의 레포주소를 추가해줘야한다.
보통 git bash에서
git remote add origin [브랜치 이름]
이렇게 사용이 가능하지만


여기서 추가도 가능하다.
이렇게 깃허브레포의 Https주소를 추가했다면 코드를 추가해줘야 한다.
보통 git bash로 파일을 push 하는 프로세스로는
1. git init
2. git pull origin main
3. git add.
git add는 인텔리제이의 add를 사용하는 것을 추천한다.

윈도 기준에서 Ctrl + Alt + A로 add가 가능하다.
여기서 깃허브 레포에 파일이 올라가는 구조를 설명하자면
깃허브에는
Working Directory : 로컬파일
Staging Area : git add로 인해서 push를 했을 때 깃허브 레포로 올라가는 파일들
Repository : 깃허브 레포지토리
이렇게 있다.
만약 git bash로 git add. 를 하여 전체폴더의 변경사항을 스캔한다면 코드변화를 정확하기 인식하지 못하는 것 같았다.
그렇기에 무조건 개발툴에서 git add기능을 사용하길 바란다.
4. git commit -m '커밋내용'
5. git push origin [브랜치]
이런 순서로 올릴 것이다.
하지만 처음 파일을 올리면 깃허브 레포에는 ReadMe파일 하나밖에 없기 때문에
refusing to merge unrelated histories
이러한 오류가 생길 것이다.
그렇기에 git bash를 열어서
git pull origin 브런치명 --allow-unrelated-histories
이렇게 pull을 하여 강제로 파일을 불러온다.
추가로
Updates were rejected because a pushed branch tip is behind its remote counterpart.
push를 할 때 이런 오류가 뜰 수도 있을 것이다.
이럴 땐
git push --set-upstream origin [브랜치]
이렇게 강제 push로 해결할 수 있다.
이렇게 소스코드를 깃허브 레포에 올렸다면 이제 깃허브액션을 만들어야 한다.
파일을 올린 깃허브 레포로 들어가서
메뉴 중 Action을 클릭한다.

들어가면 이렇게 템플릿이 나와있을 건데 지금 올리는 건 템플릿이 없기 때문에
Set up a workflow yourself를 클릭한다.
들어가면 workflows 스크립트를 쓰는 페이지가 나올 건데
name: Docker
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
# 도커 메타
- name: Docker meta
id: docker_meta
uses: crazy-max/ghaction-docker-meta@v1
with:
images: tripgago-front
tag-semver: |
{{version}}
{{major}}.{{minor}}
# 도커 빌드 관련 셋업
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
# 도커이미지 빌드하고 허브로 푸쉬
- name: Build Docker image
run: |
docker build -t ${{ secrets.PROJECT_NAME }} .
docker tag ${{ secrets.PROJECT_NAME }} ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
docker login -u ${{ secrets.DOCKERHUB_USERNAME }} -p ${{ secrets.DOCKERHUB_TOKEN }}
docker push ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
이렇게 프런트 부분(리액트) 부븐을 올린다.
간단히 설명한다면
name: Docker
on:
push:
branches: [main]
이건 레포 브랜치의 main에 push이벤트가 생기면 액션을 실행시킨다는 뜻이다.
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
runs-on이라는 게 있을 건데 깃허브액션은 깃허브에서 제공하는 runner이라는 우분투 가상머신에서 CI/CD를 실행한다.(여기서는 CI만 실행)
그 runner을 지정하는 부분이다.
# 도커 메타
- name: Docker meta
id: docker_meta
uses: crazy-max/ghaction-docker-meta@v1
with:
images: tripgago-front
tag-semver: |
{{version}}
{{major}}.{{minor}}
이건 도커의 메타데이터를 저장하는 부분인데 크게 중요하다고는 생각하지 않는다.
# 도커 빌드 관련 셋업
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
# 도커이미지 빌드하고 허브로 푸쉬
- name: Build Docker image
run: |
docker build -t ${{ secrets.PROJECT_NAME }} .
docker tag ${{ secrets.PROJECT_NAME }} ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
docker login -u ${{ secrets.DOCKERHUB_USERNAME }} -p ${{ secrets.DOCKERHUB_TOKEN }}
docker push ${{ secrets.DOCKERHUB_USERNAME }}/${{ secrets.PROJECT_NAME }}:latest
이 부분에서는 빌드셋업을 하고 도커빌드를 실행한다.
깃허브 레포파일구조는

workflows에 파이프라인 스크립트가 있고
config/nginx에 default.conf(나중에 설명)이 있다.
여기서 가장 중요한 것이 Dockerfile인데
FROM node:16 AS builder
# set working directory
WORKDIR /app
COPY package.json .
COPY package-lock.json .
RUN npm install .
RUN npm install react-bootstrap
# Copies everything over to Docker environment
COPY . .
RUN npm run build
#Stage 2
FROM nginx:latest
COPY config/nginx/default.conf /etc/nginx/conf.d/default.conf
RUN rm -rf ./usr/share/nginx/html/*
COPY --from=builder app/build /usr/share/nginx/html
EXPOSE 3000
ENTRYPOINT ["nginx", "-g", "daemon off;"]
이렇게 되어있다.
npm install와 npm ci가 있을 건데 깃허브 액션에서는 ci가 먹히지 않기 때문에 (npm을 설치하는 점에서는 다르지만 몇 가지 차이점이 있다) 꼭 npm install을 하기 바란다.
부트스트랩을 사용한다면 도커빌드를 할 때 무조건 설치를 해야 하기 때문에 설치도 같이 실행한다.
그리고 빌드 후
가장 아래에 네트워크 구조가 있을 것인데 이건 프런트에서 백을 연결하기 위해 nginx프락시를 작동시킬 수 있게
nginx를 설정하고 실행하게 명령어를 지정해 놓는다.
이렇게 파이프라인을 통할 때 도커빌드를 하고 DockerHub에 private로 이미지가 올라간다.

# 기본 서버 설정: 모든 다른 요청을 거부합니다.
server {
listen 80 default_server;
server_name _;
return 444;
}
server {
listen 80;
server_name 도메인;
location / {
proxy_pass http://client:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
간단하게 만들어서 단순하긴 하지만 대충 구조를 보면 리액트와 부트는 각각 3000, 8080 포트를 사용한다.(각 노드는 다 외부접속 불가)
유저가 도메인의 80 포트로 접근을 하면 모든 노드는 같은 도커 네트워크로 묶어져 있기 때문에 도커컨테이너이름인
client:3000(리액트 영역)을 반환해 준다(docker swarm에서는 추가 설정이 필요)
그럼 다음글에서는 백엔드 부분에서 api로 요청하는 부분에 대해서 설명해 보도록 하겠다.
'SpringBoot' 카테고리의 다른 글
리액트 + 스프링 부트 깃허브액션 (nginx프록시, 백엔드 파이프라인) (0) | 2023.10.21 |
---|---|
스프링부트+리액트 처음겪을수 있는 오류와 해결법 (1) | 2023.10.16 |