Github Actions CI 소요시간 단축시키기 (Gradle 빌드)

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..

  • format_list_bulleted DevOps(AWS, Docker, Linux, etc)/Docker
  • · 2024. 4. 20.
  • textsms
스프링부트 + Github Actions + Docker 사용 시 빌드 에러 해결

스프링부트 + 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 ..

  • format_list_bulleted DevOps(AWS, Docker, Linux, etc)/Docker
  • · 2024. 4. 15.
  • textsms
4. 도커 빌드와 빌드 컨텍스트

4. 도커 빌드와 빌드 컨텍스트

1. 도커의 이미지를 만드는 방법 : 커밋과 빌드 도커의 이미지를 생성하는 방법은 크게 두 가지가 있다. 커밋과 빌드이다. 커밋은 생성된 컨테이너를 바탕으로 이미지를 만드는 방법을 말한다. 빌드는 커밋으로 기반으로 하되, 좀 더 자동화된 방식이라고 할 수 있으며 이미지 생성에 많이 쓰이는 방법이다. 이미지를 만들 때는 반드시 생성된 컨테이너를 바탕으로 커밋을 해야 한다. 이전 포스팅에서 언급하였듯이 이미지는 레이어 구조이기 때문에 필요한 기능을 추가할 경우, 새로운 레이어가 추가되는데 이 또한 커밋하여 새로운 이미지로 만들 수 있다. 이 이미지 방식은 치명적인 단점이 있는데, 바로 커밋을 할 때마다 새로운 컨테이너를 만들어야 한다. 따라서 10개의 커밋을 해야한다면, 하나의 커밋을 진행할 때마다 컨테이너..

  • format_list_bulleted DevOps(AWS, Docker, Linux, etc)/Docker
  • · 2024. 2. 9.
  • textsms
3. 도커의 레지스트리와 이미지

3. 도커의 레지스트리와 이미지

1. 도커의 레지스트리 도커의 이미지는 경량화되어있기 때문에(레이어 구조로 되어있기 때문) 네트워크를 통해 파일을 공유하기 편하다. 개발자가 가장 많이 사용하는 공간 중 하나인 깃허브와 같이 도커의 이미지도 공유할 수 있는 레지스트리가 있다. 직접 설치하는 레지스트리 : HARBOR, 도커 프라이빗 레지스트리 클라우드용 레지스트리 : AWS ECR, Azure ACR, Docker Hub 우리는 도커의 이미지를 바탕으로 컨테이너를 실행할 때, 다음과 같은 명령어를 입력한다. (예시 : Nginx) docker run -d -p 80:80 --name mynginx nginx -d를 입력할 경우, 해당 컨테이너를 실행시킨 상태에서 다른 명령어 프로그램을 사용할 수 있다. -p를 입력할 경우, 컨테이너와 호..

  • format_list_bulleted DevOps(AWS, Docker, Linux, etc)/Docker
  • · 2024. 2. 8.
  • textsms
2. 도커

2. 도커

1) 도커는 컨테이터 생성을 도와주는 소프트웨어 도커를 사용하면 CPU와 메모리의 할당량이 각각 격리된 컨테이터라는 환경으로 구분할 수 있다. 이것이 가능한 이유는 리눅스 커널의 cgroups, namespace 기능이 사용되기 때문이다. cgroups : CPU, 메모리, 디스크, 네트워크 자원을 할당하여 완전히 격리된 가상 공간을 제공한다. namespace : 파일시스템, 사용자 계정 등을 호스트 OS(하드웨어에 설치된 OS)와 분리시킨다. 도커를 활용하면 이러한 리눅스 커널 기능들을 활용한 격리 공간, 컨테이너를 쉽게 생성 및 관리하도록 돕는다. 이전 포스팅에서 언급한 전가상화, 반가상화와는 다르게 하드웨어에 설치된 OS가 한 개밖에 없다. 기존의 가상화 기술에서는 호스트 OS(하드웨어에 설치된 ..

  • format_list_bulleted DevOps(AWS, Docker, Linux, etc)/Docker
  • · 2024. 1. 25.
  • textsms
1. 가상화 기술

1. 가상화 기술

1) 가상화 의미 가상화(Virtualization)는 서버에 독립된 OS들을 설치하고 운영할 수 있는 시스템을 말한다. 물론 가상화는 쓰이는 분야에 따라 의미가 조금씩 다르다. 어쨌든 한정된 자원을 활용하여 여러 논리적인 시스템을 구성(그 반대도 포함)하는 것이 가상화의 핵심이다. 백엔드에게 있어서 가상화는 친숙하며 필수적인 존재이다. 가상화된 서버를 대여하고, 가상화 된 여러 OS를 다룸으로써 효율적인 비용으로 가용성을 높일 수 있기 때문이다. 2) 서버 가상화 종류 가상화 중에서도 서버를 가상화하는 방법은 여러가지가 있지만 크게 두 가지로 나누어보았다. 먼저, 하드웨어를 가상화하는 것으로 하드웨어 에뮬레이션이라고 부른다. 이는 하드웨어라는 물리적인 장치 위에 여러 가상화된 하드웨어를 소프트웨어로 구..

  • format_list_bulleted DevOps(AWS, Docker, Linux, etc)/Docker
  • · 2024. 1. 25.
  • textsms