이번에는 아래와 같은 구조의 CI/CD를 만들어보도록 할 것이다GitHub ───────────▶ GitHub Actions ├─(app.zip 업로드)──────────────▶ S3 └─(배포 트리거)───────────────▶ CodeDeploy │ └─(배포 지시)──▶ EC2(Agent)먼저 GitHub Actions로 빌드한 파일을 S3에 업로드 하고 빌드가 완료되면 CodeDeploy에게 배포하라고 지..

이전에는 서버를 실행하는 EC2에서 직접 git pull을 받고 빌드과정을 진행한 후에 서버를 실행했었다.이번에는 빌드작업은 Github Actions의 runner 내부에서 진행하고 이 빌드된 파일만 서버로 전달하여 서버 내에서 실행만 진행하는 과정으로 CI/CD를 구축해보도록 하자.초기 서비스는 단순하게 시작하고 실제 사용량과 문제가 드러날 때 필요한 만큼만 확장한다. 처음부터 대규모 아키텍처를 꾸리면 개발·운영이 복잡해져 속도와 비용이 증가하므로 확장 필요성이 확인될 때 고도화하는 것이 효율적이다그렇기에 해당 방식은 초기 서비스에 적절한 방법이라고 할 수 있겠다. 1. 기존 서비스 제거먼저 EC2에 돌아가고 있는 서비스와 프로젝트는 제거해주자.lsof -i :8080 => 서비스 구동 확인만약 실행..

Github Actions의 환경변수는 실행중인 셀, 프로세스가 참조하고 있는 key-value 쌍의 데이터이다.이 환경변수는 runner의 OS 환경변수, Actions가 제공하는 컨텍스트 기반의 값, 워크플로에서 선언하는 env, 런타임에 파일로 주입하는 env 등이 존재한다. 각각 범위의 순서대로 Workflow → Job → Step → 셀 런타입에 동적으로 주입 하는 순서로 우선순위는 반대로 좁은 우선순위가 우선되고 이는 Step → Job → Workflow → runner OS → 셀 런타입 주입값 순서대로 가진다. 여기서 우리가 볼 건 Workflow, Job, Step, 런타임 주입 이다. 환경 변수는 내부적으로 env라는 명령어를 통해서 할당해서 사용되는데 보다보면 그러면 왜 outpu..

OutputGithub Actions에서는 Job간에 직접적인 변수의 공유가 되지 않는다.그렇기에 다른 Job에서 값을 갖고 오기위해서 Output이라는 것을 사용하는데 Output은 앞 단계(Step, Job 등)가 계산한 값을 뒤 단계가 쓰도록 전달하는 공식적인 통로이다.CI파이프 라인은 보통 단계가 나뉘어져 있고 앞에서 만든 결과(버전, 경로, 계산값, 지정한 옵션 등)를 다음 단계가 알아야하는 경우가 많고 그걸 해결하기 위해서 output이라는 기술을 사용한다. 여기서 output은 세가지의 방향성을 볼 수 있는데 이는 각각 step → 동일 job의 stepjob → 다른 job재사용 단위의 output (Composite Action / Reusable Workflow) 과 같이 사용 된다. ..

Artifact아티팩트는 워크 플로우의 Job의 Step에서 만든 결과물을 파일로 저장하고 같은 워크플로우의 다른 Job에 넘겨 사용하거나 실행이 끝난 뒤 사람이 다운로드 해서 확인하거나 다른 워크플로우의 잡에서 받아서 후속 작업을 하도록 하는 저장물이다.이는 Job끼리는 병렬로 실행되며 각자 다른 러너에 의해서 실행되기에 파일이 연속적으로 유지되지 않기 때문에 사용되는 기술이다.업로드 : upload-artifact아티팩트는 업로드라는 것을 통해서 원하는파일을 저장하여 하나의 아티팩트로 만들어준다.이때 이 업로드는 Job의 Step에서 이뤄지며 uses에 actions/upload-artifact@버전 을 사용해서 아티팩트를 만든다.uses: actions/upload-artifact@v4 이 업로드 ..

프로젝트를 하다보면 Github에 올리지 않으면서 관리되어야 할만한 정보들이 담긴 파일들이 존재한다.그런 파일들은 .gitignore를 통해서 Github에 올라가지 않도록 설정이 가능한데 이 파일이 아예 프로그램에서 사용되지 않는게 아니기 때문에 빌드할때 사용되기 위해서 Github Actions에서 직접 주입하는 형태로 구현한다. 먼저 application.properties를 보자.위와 같이 application.properties같은 경우는 DB에 대한 정보들을 담고 있고 이걸 통해서 우리의 프로젝트의 DB에 모두 접근이 가능하다.이런 보안적인 문제들이 존재하기 때문에 이를 우리는 workflow에서 주입해서 사용하도록 할 것이다. 우선 .gitignore에 application.propertie..