PPAK

개인 프로젝트를 진행하면서 코드 변경 사항을 테스트, 빌드하고 빠르게 배포하고자 간단한 CI/CD 를 구축할 필요가 있었다. 파이프라인을 무엇으로 구축해볼까... 하다가 관성적으로 Jenkins 가 먼저 떠올랐는데, 살짝 지루할 것 같기도 했고 개념적으로만 이해하던 Github Actions 을 이번 기회에 직접 써볼까 해서 사용하게 되었다. 이번에 Github Actions 를 도입하면서 내가 확인해보고 싶었던 것들은 아래 두 가지고 1. Github Acitons workflow 작성 방법의 간결함 (-> 문법이 익숙하지 않은 동료들에게 설명하기 쉬운가) 2. Github Actions 을 통한 파이프라인(workflow) 구축 속도 및 확장성 (-> 파이프라인을 추상적으로 구축하기 쉬운가) 이것 외..

이번 포스팅에서는 Hazelcast를 프로젝트에서 사용하면서 정리한 내용을 간단하게 적고, 내가 겪은 Hazelcast 관련 문제에 대한 상황과 해결(?)한 방법을 설명하고자 한다. 본 포스팅에서는 Hazelcast 환경을 구축하는 방법, 클러스터를 배포하는 방법을 다루지 않는다. Hazelcast는 IMDG를 지원하는 분산 메모리 시스템이다. Redis 역시 클러스터링 기술을 통해 IMDG를 지원하지만 대용량 트래픽 환경에서 Hazelcast가 더 유리한 점이 많다고 한다. (아래 특징을 통해 확인) 다만, Redis에 비해 늦게 출시되고 사용자가 적은탓인지 레퍼런스가 매우 부족했고, 공식문서를 살펴보며 대부분 개발했다. 아래에 자료조사를 통해 얻게된 Hazelcast의 특징에 대해서 기술하겠지만, 내..

현재 기존에 진행하던 프로젝트에서 예측되는 문제를 찾고 기술적으로 보완하는 리팩토링 과정을 거치고 있다. 그 중 이웃사이 프로젝트의 긴급호출 기능의 요구사항은 아래와 같다. 1. 긴급 호출 요청 시 같은 단지 내 주민들에게 알림이 간다. 1-1. 긴급 요청 알림을 통해 요청자의 위치 정보를 파악할 수 있다. 2. 긴급 호출 요청은 단지 내 주민이 수락할 수 있다. 2-1. 수락 시 단지 내 주민들에게 수락 완료 알림이 간다. +(미정) 추후에 긴급 호출 요청 데이터를 분석하여 단지 내 발생하는 문제들의 통계를 낸다. 단순하다? 긴급 호출 기능은 굉장히 단순하다. 단순한 요청을 분석하여 같은 단지 내 주민들에게 알림을 보내주면 되기 때문이다. 때문에 기존의 아키텍처를 살펴보면 위와 같이 서버와 STOMP ..

기존에 진행하던 이웃사이 프로젝트에서 Jenkins 를 통한 CI/CD 를 구축했었다. 그 덕분에 개발 간에 팀원들은 단순히 깃허브에 코드를 올리는 것 만으로도 서로 작업한 내용을 원격서버에 반영되었고, 직접 배포를 하는 과정을 생략함으로써 전체적인 개발 피로를 줄일 수 있었다. 관련포스팅 [CI/CD] Git Webhook 을 통한 Jenkins-Spring Boot 빌드, 배포 자동화 이전 포스트 에서는 Docker 위에서 Jenkins 개발환경을 셋팅하였다. 본 포스트에서는 실제로 Jenkins project 를 생성하여 빌드 스크립트를 구축하고 Git Webhook 을 이용해 개발자가 빌드 버튼을 매번 누르 ppaksang.tistory.com 문제점 기존의 CI/CD 인프라를 살펴보면, 분명 J..

이전 포스트 에서 Jenkins 에서 SpringBoot 이미지를 생성하고, 컨테이너를 생성하는 과정을 생략했다. 이번 포스트에서는 직접 Dockerfile 을 작성하고, 이미지 빌드를 하는 과정을 살펴보겠다. Dockerfile #SpringBoot 구동에 필요한 jdk11 FROM openjdk:11 #변수 생성(상대 경로로 작성) ARG JAR_FILE=build/libs/*.jar #(추가할 파일 : 이름) -> Docker 컨테이너 내부에 생성된다. COPY ${JAR_FILE} app.jar #(image 의 container 에서 필요한 저장소 경로) VOLUME /tmp #(도커 컨테이너 내부에서 몇번 포트로 돌 것인가) EXPOSE 8081 #(실행할 명령어, 컨테이너 내부에 생성될 경로..

이전 포스트 에서는 Docker 위에서 Jenkins 개발환경을 셋팅하였다. 본 포스트에서는 실제로 Jenkins project 를 생성하여 빌드 스크립트를 구축하고 Git Webhook 을 이용해 개발자가 빌드 버튼을 매번 누르는 것이 아닌 Github 의 develop 브렌치에 push 되었을 때 빌드가 되도록 자동화를 할 생각이다 프로젝트에서 백엔드의 개략적인 시스템 아키텍쳐가 나왔다. 초기 AWS 를 사용할 예정이였으나 최근 GCP 에서 제공하는 쿠버네티스 엔진을 이리저리 만져보다가 프로젝트 2차 챌린지로 쿠버네티스 환경 구축을 하면 좋을 것 같아서 사전에 플랫폼에 좀 친숙해지기 위해서 GCP 로 배포하기로 마음먹었다. 실제로 이전 포스팅 의 환경 또한 현재 GCP VM 에 구축한 상황이다. 시스..

이번 팀 프로젝트를 준비하면서 CI/CD 환경 구축을 해봐야겠다고 마음을 먹었다. 우선은 Jenkins 이미지를 생성하고 컨테이너를 생성하는 과정에서 중요한 부분을 정리하고자 본 글을 작성한다. 들어가기에 앞서서, 쓰게될 글을 간단하게 요약을 하면 Local Machine (실제 배포과정에선 EC2 인스턴스?) 의 Docker 를 통해 Jenkins Image 를 생성하고 실행하는 것이 전부인데 그 과정에서 1. Jenkins Image 생성을 위한 Dockerfile 작성 2. DooD (Docker out of Docker) 방식 적용 3. 가상 tty 로 Container 에 접근해 파일 수정 을 수행할 예정이다. Jenkins Image 생성을 위한 Dockerfile, Shell Script 작..