- Docker
- for 배포(소프트웨어 수송)의 편리화 -> 리눅스 컨테이너 기술 -> docker로 상용화
- 컨테이너 방식으로 어플리케이션을 실행 = 실행 환경에 구애받지 않고 어플리케이션 실행
- 컨테이너 : 프로세스(어플리케이션), 네트워크(IP), 파일시스템(터미널)을 독립적으로 소유
- 의존성 충돌 해결(버전 등)
- 개발 환경과 배포 환경의 일치
- 쉬운 수평 확장
- 쉬운 서버 배포(image와 컨테이너의 1:N 관계)
- 로컬 포트 번호:컨테이너 포트 번호
- image
- 설계서
- registry/repository:tag
- 이미지 없어도 컨테이너 실행하면 자동으로 pull 됨.
- image 만드는 방법
- 실행한 컨테이너를 이미지로 commit
- Dockerfile(image base + 파일)을 build
- 로컬 파일과 docker image를 연결하는 방법
- Docker Compose로 여러 이미지(컨테이너)를 한 번에 실행하기
- 각각의 컨테이너에서 웹, 서버, DB 실행 가능
- docker-compose.yml 만들어서 설정하여 이용
- docker-compose up -d
- 컨테이너(docker)와 VM(가상 머신) 차이점
- VM은 OS 반드시 설치해야하며, 컴퓨터 자원 많이 필요.
- 컨테이너는 호스트 OS의 커널(Kernel)을 공유
- docker의 주 목적 : 컨테이너 안에서 독립적으로 어플리케이션 실행
- 삽질 기록
- dto에 @builder 만 쓰고, @NoArgsConstructor, @AllArgsConstructor 안 붙였더니, 역직렬화 안 돼서 InvalidDefinitionException 남. 까먹지 말자!
# Exception : Type definition error:
[simple type, class CoffeeOrderWebApp.practice.coffee.dto.CoffeeDto$postDto];
nested exception is com.fasterxml.jackson.databind.exc.
InvalidDefinitionException:
Cannot construct instance of `CoffeeOrderWebApp.practice.coffee.dto.CoffeeDto$postDto
` (no Creators, like default constructor, exist):
cannot deserialize from Object value
(no delegate- or property-based Creator)
- 토란님 덕에 JUnit test 애너테이션이 조금 정리가 되었다.
- @Mock은 @InjectMocks를 통해 주입할 일이 있을 때 사용하면 좋다. 특히 서비스 계층 테스트할 때!
- @MockBean은 @MockBean(JpaMetamodelMappingContext.class)을 통해 매핑을 사용한다.
- 서비스 계층 테스트의 경우, 통신이 아닌 로직 테스트라 스프링부트 설정이 불필요하므로, 좀 더 가벼운 @ExtendWith(MockitoExtension.class) 테스트 애너테이션을 사용하자.
- @DataJpaTest JPA repository 테스트에 사용하며, 테스트 후 데이터가 리셋됨.
- 하지만, 레포지토리도 테스트할 게 있는지 의문이다. 대부분 JPA 로직을 그대로 사용하므로,,
- CoreMatchers도 잘 활용하자. https://hamcrest.org/JavaHamcrest/javadoc/1.3/org/hamcrest/CoreMatchers.html
<느낀 점>
오늘 페어 실습도 즐거웠다!
dockerfile로 이미지 만드는 게 처음에 이해가 잘 안 되었는데, 페어님께서 잘 설명해주셔서 이해가 되었다. 이번에도 페어운 쩔었고,, 너무 감사하다 :)
저녁에는 오늘 공부했던 거 다시 보고, 만들던 주문 시스템의 JUnit 테스트를 작성했다.
내일은 API문서 만들어야지.
주말에는 QnA 게시판 만들기와 Security 적용을 시작해야겠다.
곧 프로젝트 시작이 다가와서 발등에 불 떨어진만큼, 나름대로 힘내서 할 수 있는 것을 하자.