worldi 의 성장일기

api, etcd, c-m, shed, k-proxy 등이 있다. 오브젝트는 추구하는 상태를 기술해 둔 것이다. 오브젝트가 원하는 상태 : 추구하는 상태가 현재 상태랑 맞아 들어가는 것을 말한다. 추구하는 상태(spec)과 status를 확인 kubectl get pods kubectl edit deployment del-deploy // 상태 편집 // replicas = 9에서 3 으로 변경한다. // 파드가 3으로 줄어든다. 추구하는 상태 -> 현재 상태랑 맞아 들어간다. kubectl get pods // 3개 쿠버네티스의 기본 오브젝트 파드, 서비스, 네임스페이스, 볼륨 등이 있다. 파드 위의 화면에 있는 오브젝트들 기본 단위로 파드로 만들어짐. 서비스 이전 강의에서 노드 포트, 로드밸런서로 만..

쿠버네티스 파드에 문제가 생겼다면 (GKE에서 실습 됨) 파드를 실수로 지웠다면? 파드만 배포된 경우, 문제가 생긴다. 파드는 단일 객체이다. 디플로이먼트 형태로 배포된 파드는 괜찮다. 파드가 지워지게 되면 파드를 다시 만든다. 쿠버네티스가 파드를 대하는 자세 죽을 수도있지.. 라고 생각함. 그리고, 파드 옮길 때 실제로 옮기는게 아니라, 파드를 삭제하고 만든다. kubectl apply -f ~/_Lecture_k8s_starter.kit/ch4/4.1 // 두개의 yaml에 대한 deployment 만든다. kubectl get pods kubectl delete pod del-pod //파드를 지운다. kubectl get pods // 파드가 지워진다. kubectl delete pod del-d..

쿠버네티스 이루는 것들 구역을 나누는 네임 스페이스 (Namespace) default, kube-system, metal-system : 호실로 생각하면 된다. 서로의 구역이 나뉘어 져있다. kubectl get pods -n kube-system 네이티브 쿠버네티스 구성 요소 확인 eks에서도 쿠버네티스 구성 노드가 있는 것을 확인할 수 있다. 이는 aks나 gke도 마찬가지이다. 3사에서 차이 많이 있다. 그런 구성 요소들을 보여주지 않는다. 숨겨져 있는 마스터 노드가 관리하고 있다. 쿠버네티스 기본 철학 MSA로 구성되어 있다. 하는 일들이 개별적으로 나뉘어져 있다. API 서버는 움직이지 않는다. 모든 것을 감시만 한다. 모든 상태 값의 중심에 있다. Controller Manager가 파드를 ..

애플리케이션 배포 (NGINX) 마스터 노드 실제로 마스터 노드에 kubectl 명령어 설치함. 워커 노드에 애플리케이션을 배포 애플리케이션의 단위는 파드이다. 이는 컨테이너의 집합을 말한다. 파드 배포를 실습한다. kubectl run nginx --image=nginx kubectl get pod // 이미지 생성된 것을 확인 kubectl get pod -o wide // ip 확인 curl 172.16.132.1 쿠버네티스 클러스터 외부에서 배포한 파드 접속하기 외부에서 접속하려면 어떻게 해야하지? 호스트 환경에서 172대의 ip로 접속해? ping과 curl 명령어로 확인해 보면, 접속이 불가능한 것을 알 수 있다. 즉, 쿠버네티스 클러스터가 다음과 같은 문에 둘러싸여 있다. 문 통과해야지 외부..

도커 보통 가상화 환경이랑 비교한다. 가상화 환경 : 운영체제를 가상 머신에다가 설치하는 것. 컨테이너 환경 : 하이퍼 바이저를 제외 하고, 운영체제 위에다가 컨테이너들을 올림. 쿠버 네티스 구글의 보그 시스템을 CNCD 재단에다가 기부했다. 쿠버 네티스가 CNCF 에서 관리 되고 있다. 벤더의 종속성이 없다. → 의존성이 생긴다. (Vender-Neutral) 오픈 소스 프로젝트 → 리눅스가 대표적인 시스템. 동일한 형태를 띠는 게 쿠버네티스이다. 배포 종류 관리형 쿠버네티스. : 많은 부분 관리할 필요가 없다. 설치형 쿠버네티스: 랜처나 오픈 쉬프트 → 이미 패키지화 되어있다. (배포용) 구성형 쿠버네티스 : 베어메탈 등 여러 가지 요구사항에 맞지 않고, 자유롭게 요구사항 하고 싶거나 교육용 정도. ..

언제 육각형 아키텍처를 사용해야 할까? 언제 계층형 아키텍처 스타일을 사용할까? 도메인이 왕이다. 육각형 아키텍처의 특징은 다음과 같다. 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치다. 따라서 도메인 주도 설계 방식과 잘어울린다. 영속성이나 다른 기술에 대해 신경 쓸 이유가 없기 때문이다. 첫 지표로, 도메인 코드가 애플리케이션에서 중요한지 안한지를 따져야 한다. 경험이 여왕이다. 다른 아키텍처 스타일을 작은 모듈부터 시도해보자! 개념에 익숙해지고, 스타일에 익숙해져라. 그때그때 다르다. 응.. 말그대로, 아키텍처 스타일은 그때그때 달라.. 소프트웨어의 종류, 도메인 코드의 역할, 팀의 경험에 따라서도 다르다.

소프트웨어는 하드웨어에 비해 쉽게 변경할 수 있기 때문에, 어떤 떄는 지름길을 먼저 취하고 나중에 고치는 것이 더 경제적일 수 있다. 지름길은 깨진 창문과 같다. 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기 쉽다. 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기 쉽다. 지름길을 많이 사용한 코드에서 또 다른 지름길을 추가하기 쉽다. → 레거시 코드 일 수록, 코드 품질이 낮아진다. 깨끗한 상태로 시작할 책임 소프트웨어 프로젝트는 대개 큰 비용이 들고 장기적인 노력을 필요로 하기 때문에 깨진 창문을 막아야 한다. 의도적인 지름길에 대해서는 세심하게 기록해두어야 한다. 유스케이스 간 모델 공유하기 유스케이스 간에 입출력 모델을 공유하게 되면 유스케이스들 사이에 결합이 ..

규모가 커질 수록 아키텍처가 서서히 무너지게 된다. 계층 간의 경계가 약화되고, 코드는 테스트하기 어려워진다. 새로운 기능을 구현하는데 점점 더 많은 시간이 든다. 경계와 의존성 경계를 강제한다는 것은 의존성이 올바른 방향을 향하도록 강제하는 것이다. 계층 경계를 넘는 의존성은 항상 안쪽 방향으로 향해야 한다. 따라서 이러한 의존성 규칙을 강제하는 방법을 알아보자! 방법 1 : 접근 제한자. public, protected, private, default(package-private) 제한자가 존재한다. 여기서 default 제한자가 중요하다. 왜냐하면 자바 패키지를 통해, 클래스들을 응집적인 모듈로 만들어 주기 때문에, 모듈 내에 있는 클래스들은 서로 접근 가능 하지만, 패키지 바깥에서는 접근할 수 없..

모든 의존성은 안쪽으로, 애플리케이션의 도메인 코드 방향으로 향해야한다. → 도메인 코드가 바깥 계층의 변경으로부터 안전하다. 유스케이스는 인터페이스만 알아야 하고, 런타임에 구현을 제공받는다. ⇒ 생성자를 통해 객체를 전달 받기 때문에 실제 객체 대신 목으로 전달할 수 있고, 격리된 단위 테스트를 생성하기 쉬워진다. 그렇다면 객체 인스턴스를 생성할 책임은 누구에게 있을까? 모든 클래스에 대한 의존성을 가지는 설정 컴포넌트가 있어야 한다. 다음과 같이 중립적인 설정 컴포넌트는 인스턴스 생성을 위해 모든 클래스에 접근 가능하다. 설정 컴포넌트의 책임과 역할 웹 어댑터 인스턴스 생성, HTTP 요청 → 웹 어댑터 전달 보장 유스케이스 인스턴스 생성, 웹어댑터에 유스케이스 인스턴스 제공 영속성 어댑터 인스턴스..

매핑하지 않기 전략 (No Mapping) 웹, 애플리케이션, 영속성 계층 모두에서 도메인 모델을 입출력 모델로 쓰는 것이다. 이는, 단일 책임 원칙을 위반한다. 절대로 쓰면 안되는 건 아니고, 간단한 CRUD 유스케이스 같은 경우, 모든 계층이 정확히 같은 구조의, 같은 정보를 필요로 한다면 괜찮다. 양방향 매핑 전략 각 계층이 전용 모델을 가진 매칭 전략을 양방향 매핑 전략이라고 한다. 각 어댑터가 해당 모델을 도메인 모델로, 도메인 모델을 해당 모델로 매핑할 책임을 가지고 있다. 모두 양방향으로 매핑한다. 장점 각 계층이 전용 모델을 변경하더라도, 다른 계층에는 영향이 없다. 웹이나 영속성 관심사로 오염되지 않는 깨끗한 도메인 모델로 이어진다. 매핑하지 않기 전략 다음으로 간단한 전략이다. 단점 보..