이전 시간에 이어 가벼운 실습을 진행해보려고 한다. 위 이미지와 같은 아주 기본적인 프로세스를 Jenkins Pipeline을 통해 구성해볼 것이다. Spring Boot가 실행되는 컨테이너를 DinD 환경으로 구성하면 더 좋았을 것 같으나... 애플 실리콘 칩과 도커의 호환 문제인지 모르겠지만 자꾸 이상한 에러가 발생해서 그냥 단순 가상환경에서 도커 없이 jdk로만 서버 애플리케이션을 실행하는 것으로 구성해보았다.그럼 거두절미하고 바로 시작해보자!도커 컨테이너 준비시작하기 전에 배포 연습을 할 스프링부트 프로젝트를 아무거나 깃허브에 올려두자!가상 서버 도커 컨테이너 준비 (CentOS 8 + Openjdk 17.0.2)도커 이미지 pull & 컨테이너 실행docker run --privileged --..

CI/CD란?CI/CD는 개발자 및 팀에 의해서 개발된 결과물에 대해 지속적인 통합과 지속적인 배포를 하는 프로세스를 말한다.CI/CD는 개발된 애플리케이션을 통합하고 빌드, 테스트, 배포에 이르기까지 전 과정에 대한 자동화 처리를 담당하게 된다.CI(Continuous Integration) = 지속적인 통합작업된 코드의 컴파일, 테스트, 패키징 작업의 자동화를 의미한다가끔 배포하는 것이 아닌, 지속적으로 작은 단위로 계속해서 배포해야 함을 강조개발 생산성 향상, 빠른 문제 발견 및 수정, 코드 품질 향상(테스트 필수)CD(Continuous Delivery / Deployment)CI에 의해 패키지된 결과물을 검증하고 다시 개발 서버, 테스트 서버 또는 운영 서버로 배포하는 작업을 한다.최종 배포를 ..

웹서버(Web Server)란?웹 서버(web server)는 HTTP 또는 HTTPS를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)를 전송해주는 서비스 프로그램을 말한다. 주된 기능은 콘텐츠를 제공하는 것이지만, 클라이언트로부터 콘텐츠를 전달받는 것도 웹 서버의 기능에 속한다. 이러한 기능은 파일 업로드를 포함하여 클라이언트에서 웹 폼을 수신하기 위해 사용된다. 웹서버의 종류로는 Apache, NGINX, IIS, GWS 등이 있다. 웹서버가 꼭 필요한 것은 아니다. 단순히 Client와 WAS만으로도 상호작용하는데 문제가 없으며, 웹 서버 없이 배포된 서비스도 매우 많다. 그럼에도 불구하고 웹 서버를 사용하는 이유는 무엇일까? 그것은 웹 서버가 제공해주는 다양한 기능들이 ..

외부 - Pod 통신 by ServiceService 객체는 Pod의 디폴트 내부 IP 대신, 변경되지 않는 안정적인 IP를 제공해준다⇒ 외부에서 Pod로의 접근을 가능하게 해준다ClusterIP(기본값)Pod들이 클러스터 내부의 다른 리소스들과 통신할 수 있도록 해주는 가상의 클러스터 전용 IP클러스터 내부에서만의 통신을 가능하게 하며, 로드밸런싱을 제공해준다.클러스터 외부에서는 통신이 불가능하다NodePort클러스터 외부에서 서비스에 접근할 수 있도록, 각 워커 노드의 특정 포트를 개방한다.클러스터 내부로 들어온 트래픽을 특정 Pod로 연결하기 위한 ClusterIP 역시 자동으로 생성해준다⇒ NodePort는 ClusterIP의 기능을 기본으로 포함한다Service가 생성되면 쿠버네티스는 30000..

우리는 애플리케이션에서 생성되어 계속해서 사용되기 위해 손실되어서는 안되는 데이터들을 보통 데이터베이스 혹은 파일에 저장한다. 이러한 데이터는 컨테이너가 재시작 후에도 살아남아있어야 하는데, 이를 위해 존재하는 것이 '볼륨(Volume)'이다. 쿠버네티스를 사용할 때, 컨테이너를 실행하는 주체는 우리가 아니라 쿠버네티스이다. 우리는 docker run이나 docker-compose와 같은 명령을 실행하지 않는다. 즉, 이전까지 사용했던 '-v' 플래그 등을 통한 볼륨 추가는 사용할 수 없다. 그 대신, 컨테이너에 볼륨을 추가할 수 있도록, 쿠버네티스를 구성해야 한다.Kubernetes 볼륨쿠버네티스는 컨테이너 안에 볼륨을 마운트 시킬 수 있다.ex) deployment.yml과 같은 구성 파일을 작성할 ..

쿠버네티스는 여러 종류의 ‘객체’와 함께 동작하며, 이러한 객체들은 특정 명령을 통해 생성할 수 있다. 그리고 그 객체에 명령을 내려 무언가를 수행할 수 있다. 쿠버네티스 객체를 ‘명령적 방식’과 ‘선언적 방식’으로 생성할 수 있는데, 여기서는 선언적 방식만을 다루겠다. 명령적 방식은 명령어를 모두 외워야 하고, 게속 반복해서 명령을 내려야 한다는 점이 불편하다. 반면, 선언적 방식은 단순히 쿠버네티스 설정 파일을 만든 후, 이를 적용하는 명령어만 실행해주면 된다는 점에서 편리하다. 실무에서도 이 방식을 주로 사용한다.docker만 사용했을 때, run & build 명령어를 반복적으로 사용하고 관리하는 데에 어려움이 있어서 docker-compose를 사용했던 것처럼, 쿠버네티스에서도 명령적 방식에서의..

Kubernetes를 사용하는 이유쿠버네티스를 사용하지 않고 ECS와 같은 특정 클라우드 서비스에서 제공하는 컨테이너 매니징 서비스를 이용하여 배포하는 것도 방법이다. 하지만, 이는 다음과 같은 단점이 있다해당 서비스에 대한 깊이 있는 학습이 필요하고, 의존도가 높아지게 된다⇒ 타 서비스로의 전환이 어렵다결국엔 도커 컴포즈에 작성된 내용을 각 인스턴스로 띄우고 별개로 관리하는 형태가 된다⇒ 관리 포인트가 증가하여 유지보수가 어렵다하지만, 쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션 표준 도구로써 특정 서비스에 고정되지 않고 컨테이너 자동 배포, 관리, 헬스 체크, 오토 스케일링, 로드 밸런서, 모니터링 기능을 제공한다. 이를 정의한 쿠버네티스 설정 파일만 작성해주면 된다!Kubernetes란..

Docker ComposeDocker Compose를 왜 사용하는가?도커 컴포즈가 없다면 우리는 여러 컨테이너들에 대한 다양한 설정들을 유지하기 위해 매우 긴 docker run 명령어와 docker build 명령어를 각 이미지 혹은 컨테이너마다 관리해야 할 것이다. 하나의 명령어에는 볼륨, 네트워크, 실행 모드, 컨테이너명, 환경 변수 등등 각종 옵션을 제공하기 위해 계속해서 태그들이 붙어 매우 길어져있는 상태일 것이다. 큰 규모의 서비스에서는 수많은 컨테이너를 사용할 것인데 이렇게 긴 명령어를 관리하는 것은 매우 복잡할 것이다.이러한 문제를 해결하기 위해 사용되는 것이 Docker Compose라는 오케스트레이션 명령 집합이다.Docker Compose란 무엇인가?도커 컴포즈는 단일 혹은 다수의 d..

Case 1: WWW 통신 컨테이너기본적으로 컨테이너는 WWW에 요청을 보낼 수 있다. 도커화된 애플리케이션 내부에서 별다른 설정이나 코드 변경 없이 웹 API 및 웹 페이지와 통신할 수 있다.Case 2: '컨테이너 - 로컬 호스트 머신' 통신컨테이너와 우리 호스트 머신의 다른 애플리케이션이 통신하는 방법에 대해 알아보자. 기본적으로 도커화된 애플리케이션이 실행되고 있고, 이 애플리케이션이 localhost와 통신을 하려고 할때, 'localhost'를 그대로 명시하면 통신을 할 수 없다. 대신에 host.docker.internal 도메인을 사용하면 된다. 컨테이너를 띄우기 위한 별다른 설정은 필요없다. 도메인만 변경해주면 된다. 이 특수 도메인은 도커에 의해 인식된다. 그리고 도커 컨테이너 내부에서..

다양한 종류의 데이터도커에는 다양한 종류의 데이터가 있다.Application(Code + Environment)개발자가 직접 작성하여 제공하는 것코드와 전체 환경이 빌드 단계에서 이미지에 추가됨 by Dockerfile이미지 빌드 시 변경되지 않고 '고정'됨, 변경 시 재빌드 필요 -> Read-onlyTemporary App Data(e.g. entered user input)애플리케이션이 실행되는 동안 생성된 데이터로, 일시적으로 관리될 필요가 있는 데이터(삭제되어도 됨)실행 중인 컨테이너로부터 fetched, produced메모리, 데이터베이스, 일시적인 파일 등으로 저장됨주기적으로 cleared 됨일시적인 Read + Write 전용이므로 이미지가 아닌 컨테이너에 저장됨(이미지는 Read-onl..