천천히 꾸준히 성장하기

회사에서 뭔가 Internal 서버의 정체를 알게되었는데, 아는 언니(멋있는 언니 완전 짱)가 자기 회사는 BFF패턴을 쓴다고 했던 게 생각이 났다. 우리 회사도 서버를 위한 서버를 두는 느낌으로 일맥상통하는 것 같다. 보통 회사들이 BFF 패턴을 많이 쓰는 것 같기도 하고 그런거 같아서, 찾아보니까 거의 다 쓴다. BFF (Backend For Frontend) 프론트엔드에 표현될 데이터를 위한 백엔드 즉, 프론트엔드 데이터에 대한 책임을 백엔드가 가진다. 즉, BFF는 단순히 데이터를 제공하는 것에서 나아가 프론트엔드 친화적으로 데이터를 제공한다. 화면에 보이는 데이터를 가공하는 책임은 서버가 지고, 프론트엔드는 UI를 그리는데 집중한다. 여러 조건에 대한 처리는 서버가 처리하고 프론트엔드에 보일 데..

난 처음에 인수 테스트 = API 테스트 인 줄 알았다. 근데, 사수님이 인수테스트는 다양하게 쓰인다고, 실제 유저가 하는 테스트가 인수테스트에 가깝고 내가 알고 있던 인수 테스트는 시스템 테스트에 가깝다고 말씀 주셨다. 의미가 궁금해져서 이를 찾아보게 되었다. 소프트웨어 개발 단계 소프트웨어 개발 단계에 따른 테스트는 소프트웨어 개발 단계의 순서와 짝을 이루어 테스트를 진행해나가는 방법이다. 여기서 생각했던 시스템 테스트가 내가 RestAssured로 개발했던 테스트이고, 인수 테스트는 실제 유저가 원하는 대로 잘 동작하는지 보는 테스트이다. 시스템 테스트 시스템 전체가 정상적으로 작동하는 지를 체크하는 시스템 테스트이다. 모듈이 모두 통합된 후 사용자의 요구 사항들을 만족하는지 테스트하는 것이다. 즉..

CH7 강의 끝! 쿠버네티스 공부 방향성 document를 본다. 쿠버네티스의 dns 정보 조회한다. (Domain Name System 정보 조회) kubenetes dns query 검색 결론은 뭐 랩과 공식문서를 보라.. 후속강의 “그림으로 배우는 쿠버네티스” 이당 쿠버네티스에 대한 이해 쿠버네티스 오브젝트들을 코드로 이해하기 쿠버네티스의 요소 별 구성 및 관리법

kubectl 쉽게 쓰는 법 배시 자동 완성 : k만 입력하면 kubectl을 쉽게 설정할 수 있다. k .. 배쉬 셸에 별명 지어 주기 alias k=kubectl alias ka = ‘ kubectl apply -f ‘ Alias keq = ‘ kubectl exec …’ 와 같이 지어줄 수 있다. 쿠버네티스 업그레이드 버전 업그레이드 계획을 수립한다 → kudeadm 업그레이드 → kubelet 업그레이드 → 업그레이드 완료를 확인한다. 그냥 대충 보고 나중에 다시 찾아봐야 겠다. kubectl get nodes kubeadm upgrade plan yum upgrade kuberadm-1.25.1 -y // kubeadm 업그레이드 kubeadm version kubeadm upgrade appl..

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) 오픈 소스 프로젝트 → 리눅스가 대표적인 시스템. 동일한 형태를 띠는 게 쿠버네티스이다. 배포 종류 관리형 쿠버네티스. : 많은 부분 관리할 필요가 없다. 설치형 쿠버네티스: 랜처나 오픈 쉬프트 → 이미 패키지화 되어있다. (배포용) 구성형 쿠버네티스 : 베어메탈 등 여러 가지 요구사항에 맞지 않고, 자유롭게 요구사항 하고 싶거나 교육용 정도. ..

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