목표 이전 편에서 작성한 내용에 CI/CD를 추가해보자 소스 위치, 버전 정보를 저장소에서 가져오자 release 브랜치에 push가 발생하면 docker 이미지로 배포할 수 있도록 하자 배포 버전은 커밋ID를 넣을 수 있도록 하자 배포하는 이미지의 크기를 줄이자 여정 컨테이너와 프로젝트 간 의존성 제거 docker 이미지를 Registry에 등록 각 Dockerfile마다 Container Registry에 등록하여 이미지를 pull할 수 있도록 등록 💡 아래 코드는 프로젝트 메뉴 > Packages and registries > Container Registry에서 확인! # Gitlab의 Private image hub에 저장할 수 있도록 로그인 docker login registry.gitlab...

지적과 댓글은 언제나 환영합니다! 도커 삽질 개선하기 이전편 요약 이전 편 도커 삽질하기 에서는 단순 리눅스 컨테이너를 생성해서 직접 명령어를 타이핑하면서, 컨테이너의 상태를 변경하였다. 그 결과, 컨테이너가 재부팅되면 대부분의 데이터와 상태가 소실되어 같은 과정을 반복해야 했다. 목표 도커 컨테이너 설정을 간소화, 자동화해보자 공통 설정 분리 → env 파일 생성 DB에 대한 dockerfile 작성 → 이미지 생성 Package(서브도메인B, 지원도메인D)에 대한 dockerfile 작성 → 이미지 생성 docker-compose를 이용해서 실행 여정 env 파일로 설정 분리 # DB Configuration TZ=Asia/Seoul DB_HOST=0.0.0.0 # 외부 DB와 연결하고 싶을 때 DB..

지적과 댓글은 언제나 환영합니다! 들어가기에 앞서.. 본 게시글은 MSA 형태로 구성된 서비스를 하나씩 도커라이징(dockerizing)하는 게시물입니다. 도커 명령어를 배우는 초심자 입장에서 작성한 글로 삽질했던 시간 순서대로 작성하였습니다. 중급자 이상 분들은 필요한 명령어만 골라서 사용하시면 됩니다. 현재 상황 현재 가지고 있는 MSA 형태의 어플리케이션의 구조는 아래와 같다. 서비스 별로 실행파일이 분리가 되어 API 요청으로 통신하고 있긴 하지만, 실행 시, 같은 디렉토리 내에서 상대위치 참조를 하고 있다. 즉, 물리적으로 분리가 어려운 상태이다. 따라서, 단계적, 점진적으로 도커라이징하고자 한다. 목표 이번 글에서는 최소한의 분리를 하려고 한다. 어플리케이션(MSA를 통째로) 과 DB를 각각 ..

지적과 댓글은 언제나 환영합니다! 의존성 주입이란? 스프링에서 지원하는 핵심 프로그래밍 모델 중 하나로 말 그대로 의존관계를 외부에서 결정해주는 디자인 패턴이다. 의존관계? 의존관계는 쉽게 이야기하자면 한 쪽이 변경되면 다른 한쪽도 변경되는 관계로 말할 수 있다. public class Customer{ // 초기모델 private final int id; // 고유 ID private final String grade; // 회원 등급 private final DiscountPolicy discountPolicy; // 할인정책 } public class Customer{ // 변경 후 모델 private final int id; private final String grade; private fina..

지적과 댓글은 언제나 환영합니다! 변경사항을 Docker로 자동 배포하기 변경사항을 감지하고 배포하려면 CI/CD 파이프라인 구축을 먼저 알아야한다. CI/CD 파이프라인을 구축하는 방법은 버전 관리 플랫폼별로 다르다. 대표적으로 Github Action, Gitlab, Terraform 등이 있으나 Github Action으로 진행해보도록 하겠다. Github Action을 이용한 CI/CD Github는 사용자가 CI/CD 도구를 직접 통합해야 한다. 선택지로 Jenkins, CircleCI, TravisCI 등이 있다 필자는 현재 이 블로그도 Github Action으로 자동 배포하고 있다. 그 때의 빌드 스크립트를 재활용해보자. 자세한 설명은 주석을 참고하자. # 알아두기 중간중간 보이는 secr..

지적과 댓글은 언제나 환영합니다! 어플리케이션을 Docker로 배포하기 이번 실습편에서는 아래 3가지 단계를 통해 도커를 찍먹해볼 것이다. Docker 이미지 만들기 만든 이미지를 실행해보기 변경사항을 자동으로 배포하기(심화편) 1. Docker 이미지 만들기 Docker 컨테이너는 Docker 이미지를 기반으로 실행된다. 우리가 만든 어플리케이션을 Docker 이미지로 직접 만들어보자. 우선, 어플리케이션을 빌드한 결과물을 가지고 있어야한다. 필자는 IntelliJ에서 Spring Boot 어플리케이션을 Jar파일로 만들것이다. 만드는 방법은 필자가 정리한 글에서 확인할 수 있다. (만약, 다른 언어나 플랫폼이라면 자신의 프로젝트에 맞게 빌드 결과물을 얻고 다음 단계를 진행하자.) 2. 만든 이미지를 ..

지적과 댓글은 언제나 환영합니다! 이 글은 3편의 시리즈물로 제작하였다. 개념편 : Docker가 뭐길래!? 실습편 : 어플리케이션을 Docker로 배포하기 심화편 : 변경사항을 Docker로 자동 배포하기 시작해보자! Docker가 뭐길래!? 도커, 도커, 도커, 도커 컴퓨터 업계에 종사하는 이들이라면, 메아리로도 한번쯤은 들어본 적 있는 이름이다. 도커가 뭔지 몰라도 아래 장점을 한번만 읽어보도록 하자. 도커는 소프트웨어 전달 주기를 가속한다. 도커 컨테이너는 변화하는 환경에 신속히 대응, 투입할 수 있고, 필요 시 이전 버전으로 신속히 롤백할 수 있다. 도커 컨테이너는 애플리케이션이 실행해야 하는 모든 것을 캡슐화하기 때문에 애플리케이션이 환경들 사이에서 손쉽게 이동할 수 있다. 도커 런타임이 설치..

지적과 댓글은 언제나 환영합니다! 이 글은 박재성님의 자바 플레이그라운드 with TDD, 클린코드 강의를 바탕으로 작성되었습니다. TDD TDD를 하는 이유 디버깅 시간을 줄여준다. 동작하는 문서 역할을 한다. 변화에 대한 두려움을 줄여준다. TDD 프로세스 실패하는 테스트를 구현한다. 테스트가 성공하도록 프로덕션 코드를 구현한다. 프로덕션 코드와 테스트 코드를 리팩토링한다. (테스트 코드도 중복이 발생할 수 있기 때문) TDD 원칙 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다(미래까지 걱정 X) TDD 방법론 (필수는 아님!) 큰 갈래에서..

지적과 댓글은 언제나 환영합니다! 개요 공학자로써 단어의 정의는 굉장히 중요하다. 오늘은 논쟁이 굉장히 많은 주제이자, 헷갈리기 쉬운 주제인 REST와 REST API, RESTful API에 대해 알아보도록 하자. 범위 정의를 살펴보기에 앞서 범위를 살펴보고 가자. 위 그림을 기준으로 살펴보면 REST는 어떠한 큰 범주이고, RESTful API는 완전히 REST에 속한 것으로 보인다. 반면, HTTP API는 REST API랑 유사하다고 적혀있고 REST, RESTful API와 일부 공통점이 있어보인다. 그렇다면 각각 어떤 정의길래 위와 같은 그림이 나오는 것일까? 정의 요약하면 다음과 같다. REST : 분산 하이퍼미디어 시스템을 위한 아키텍쳐 요소를 추상화 한 것. RESTful API : RE..

지적과 댓글은 언제나 환영합니다! 들어가기에 앞서 프로세스(Process)와 쓰레드(Thread)의 차이를 설명하기에 앞서 프로그램(Program)의 정의를 짚고 넘어가자. 어떤 문제를 해결하기 위해 컴퓨터에게 주어지는 처리 방법과 순서를 기술한 일련의 명령문의 집합체. (국어표준대사전) 그렇다. 프로그램은 명령문의 집합체이다. 코드의 덩어리일뿐 아직 실행되지 않은 상태이다. 이 상태를 정적(static)인 상태라고 한다. 반대로, 동적(Dynamic)인 상태도 있다. 실행시, 메모리에 프로그램이 적재되는 것을 동적인 상태라고 한다. 그리고 이렇게 동적인 상태에 있는 프로그램을 *프로세스라고 한다. *P.S 스케줄러 입장에서는 작업(task)라고 부르기도 한다. 운영체제와 프로세스 프로세스는 프로그램이 ..