Github Actions 빌드 산출물 다운로드 시 주의할 점
필자는 Github Actions의 @actions/upload-artifact와 @actions/download-artifact 를 활용하여 각 작업 간 빌드 산출물을 공유할 수 있도록 하였다. 이를 통해, 산출물을 빌드하는 작업과 해당 산출물을 통해 도커 이미지를 빌드하고 푸시하는 작업을 분리할 수 있다. 다만 해당 명령어를 사용하는 데 있어서 주의해야 할 점이 있다. 1. download-artifact의 path는 아티팩트가 저장되는 경로필자는 처음에 다음과 같이 작성했었다. 이렇게 작성한 의도는 다음과 같았다.이전 job에서 빌드한 *.jar 파일을 업로드하였고, 해당 파일을 다운로드 받는다.다운로드 받은 *.jar 파일을 ./build/libs 폴더에 app.jar라는 이름으로 저장한다.하지만..
- DevOps(AWS, Docker, Linux, etc)/CI,CD
- · 2024. 6. 26.
AWS의 VPC, 서브넷, 보안그룹에 대해서
RDS와 EC2를 연결하는 과정에서 https://developer111.tistory.com/52 해당 게시글을 참고하였다.RDS의 보안그룹을 생성하고, EC2가 속한 VPC 및 서브넷 ID를 참고하는 부분이 자연스럽게 받아들여지지 않았다.그만큼 보안그룹과 서브넷 그리고 VPC에 대한 개념이 정확하게 정리되어 있지 않다는 뜻이기에 해당 내용들을 정리해보았다. 필자가 의문을 가졌던 점은 다음과 같다.EC2와 RDS가 각각 다른 보안그룹을 갖는 이유DB 서브넷 그룹을 생성할 때, 모든 가용영역을 추가하는 이유해당 작업의 목적은 EC2가 RDS에 접근하기 위함이다. 따라서 RDS는 퍼블릭 주소를 갖고 있지 않기에 RDS 자체에 보안그룹이 설정될 필요가 있다고 판단했다. 먼저 AWS에서 보안그룹이 어떠한 역할..
- DevOps(AWS, Docker, Linux, etc)/AWS
- · 2024. 6. 21.
Github Actions CI 소요시간 단축시키기 (Gradle 빌드)
1. gradlew 명령어 (build vs bootJar) gradlew bootJar는 실행가능한 jar 파일을 만드는데 필요한 작업들만 수행하고 있다. 위 그림과 같이 build 작업은 bootJar 작업 이외에도 test, check, assemble 같은 작업들이 포함된다. (check는 test에 의존적인 작업으로 test가 수행된 후에 진행됨) 따라서 이처럼 CI 워크플로우 동작시 시간차이가 발생하게 된다. 하지만 bootJar에는 test 작업이 포함되지 않는다. 모든 test를 통과해야만 실행가능한 jar 파일을 만들어야 한다면 bootJar를 test에 의존적인 작업으로 만들면 된다. 이는 build.gradle을 통해 추가할 수 있다. // build.gradle에 추가 bootJar..
- DevOps(AWS, Docker, Linux, etc)/Docker
- · 2024. 4. 20.
스프링부트 + Github Actions + Docker 사용 시 빌드 에러 해결
1. 기존에 사용하던 방식 소개 # 소스 빌드용 Base 이미지(Maven, Gradle에 호환되는 JDK 이미지) FROM amazoncorretto:17-alpine3.19 as build WORKDIR /app # 의존성을 가져오기 위해 필요한 파일만 우선 복사 COPY gradle gradle COPY build.gradle settings.gradle ./ COPY gradlew ./ RUN chmod +x ./gradlew # Gradle 빌드 명령어 실행 (CI/CD 환경에서 일관된 빌드를 위해 데몬 프로세스 실행 X) RUN ./gradlew dependencies --no-daemon COPY src src # 스프링부트 프로젝트를 Jar 파일로 빌드 RUN ./gradlew clean ..
- DevOps(AWS, Docker, Linux, etc)/Docker
- · 2024. 4. 15.
4. 도커 빌드와 빌드 컨텍스트
1. 도커의 이미지를 만드는 방법 : 커밋과 빌드 도커의 이미지를 생성하는 방법은 크게 두 가지가 있다. 커밋과 빌드이다. 커밋은 생성된 컨테이너를 바탕으로 이미지를 만드는 방법을 말한다. 빌드는 커밋으로 기반으로 하되, 좀 더 자동화된 방식이라고 할 수 있으며 이미지 생성에 많이 쓰이는 방법이다. 이미지를 만들 때는 반드시 생성된 컨테이너를 바탕으로 커밋을 해야 한다. 이전 포스팅에서 언급하였듯이 이미지는 레이어 구조이기 때문에 필요한 기능을 추가할 경우, 새로운 레이어가 추가되는데 이 또한 커밋하여 새로운 이미지로 만들 수 있다. 이 이미지 방식은 치명적인 단점이 있는데, 바로 커밋을 할 때마다 새로운 컨테이너를 만들어야 한다. 따라서 10개의 커밋을 해야한다면, 하나의 커밋을 진행할 때마다 컨테이너..
- DevOps(AWS, Docker, Linux, etc)/Docker
- · 2024. 2. 9.
3. 도커의 레지스트리와 이미지
1. 도커의 레지스트리 도커의 이미지는 경량화되어있기 때문에(레이어 구조로 되어있기 때문) 네트워크를 통해 파일을 공유하기 편하다. 개발자가 가장 많이 사용하는 공간 중 하나인 깃허브와 같이 도커의 이미지도 공유할 수 있는 레지스트리가 있다. 직접 설치하는 레지스트리 : HARBOR, 도커 프라이빗 레지스트리 클라우드용 레지스트리 : AWS ECR, Azure ACR, Docker Hub 우리는 도커의 이미지를 바탕으로 컨테이너를 실행할 때, 다음과 같은 명령어를 입력한다. (예시 : Nginx) docker run -d -p 80:80 --name mynginx nginx -d를 입력할 경우, 해당 컨테이너를 실행시킨 상태에서 다른 명령어 프로그램을 사용할 수 있다. -p를 입력할 경우, 컨테이너와 호..
- DevOps(AWS, Docker, Linux, etc)/Docker
- · 2024. 2. 8.