IT LAB

모듈과 함수는 소프트웨어를 구성하는 빌딩 블록이며, API는 이 블록들을 끼워 맞추는 연결부다. 이런 API를 이해하기 쉽고 사용하기 쉽게 만드는 일은 중요하며 어렵다. 그래서 API를 개선하는 방법을 새로 깨달을 때마다 그에 맞게 리팩터링 해야한다. 11. 1 질의 함수와 변경 함수 분리하기 목표 : “부수 효과” 없애기 겉보기 부수 효과가 전혀 없이 값을 반환해주는 함수를 추구해야 함 Get함수 안에 set이 같이 있는 경우 11. 2 함수 매개변수화하기 두 함수의 로직이 아주 비슷하고 단지 리터럴 값만 다르다면? 하나의 함수로 만들고 중복 없애기 매개변수로 boolean값을 써서 제어에 쓰는 경우 아님 11.3 플래그 인수 제거하기 호출할 수 있는 함수들이 무엇이고 어떻게 호출해야 하는지를 이해하기..

조건부 로직을 이해하기 쉽고 깔끔하게 만들어야 프로그램의 전체 코드가 복잡하지 않게된다. 10.1 조건문 분해하기 조건, 분기 모두 함수로 추출해버려 가독성 높이기 왜 이 코드가 실행되는 지 모를때가 많음 10.2 조건식 통합하기 비교하는 조건은 다르지만 그 결과로 수행하는 동작은 똑같은 코드들이 있다. 이럴 때 and나 or연산자를 사용하여 여러 개의 비교 로직을 하나로 합칠 수 있다. 간단한 여러 조건문을 하나의 복잡한 조건문으로 통합하기 부수효과에 유의하기 10.3 중첩 조건문을 보호 구문으로 바꾸기 보호 구문 : 한쪽만 정상이라면 비정상 조건을 if로 검사한 다음, 조건이 참이면 함수에서 빠져나온다. if절과 else절에 똑같은 무게를 두어, 코드를 읽는 이에게 양 갈래가 똑같이 중요하다는 뜻을 ..

데이터 구조에 집중한 리팩터링 9.1 변수 쪼개기 변수 1개당 역할은 하나이다 역할이 둘 이상인 변수가 있다면 쪼개야 한다. (여러 용도로 쓰인 변수는 코드를 읽는 이에게 커다란 혼란을 줌) 같은 역할에 여러 번의 할당은 필요할 때도 있다 -> 루프변수, 수집변수 9.2 필드 이름 바꾸기 점진적으로 안전하게 바꾸기 9.3 파생 변수를 질의 함수로 바꾸기 9.4 참조를 값으로 바꾸기 객체 내부를 수정하던 것을, 값 객체 통채 하나로 바꾸기 ( 불변 데이터이므로 외부에 건네주는 경우 등 나중에 그 값이 바뀌어 내부에 영향 끼치지 않음 ) 새로운 속성을 담은 객체로 기존 내부 객체를 통채로 대체 값 객체 - 불변 : setter없이 constructor 만으로 9.5 값을 참조로 바꾸기 데이터를 갱신해야 할 ..

지금까지는 프로그램 요소를 생성 혹은 제거하거나 이름을 변경하는 리팩터링을 다뤘다. 여기에 더해 요소를 다른 컨텍스트(클래스나 모듈 등)로 옮기는 일 역시 리팩토링의 중요한 축이다. 8.1 함수 옮기기 함수가 자신이 속한 모듈 A보다 다른 모듈 B를 더 많이 참조한다면 모듈성을 높이기 위해 서로 연관된 요소들을 함께 묶고, 요소 사이의 연결 관계를 쉽게 찾고 이해할 수 있도록 해야 함. 함수를 옮길 시에 대상 함수의 현재 컨텍스트와 후보 컨텍스트를 둘러보면 도움이된다. 8.2 필드 옮기기 데이터 구조가 적절치 않음을 깨달으면 곧바로 수정하기 (어떤 레코드를 넘길 때마다 또 다른 레코드의 필드도 함께 넘기고 있다면 데이터 위치를 옮겨야 할 것) 필드 캡슐화 => 필드값을 외부에서 변경하지 못하게 할 시 사..

13.1 인증 사용자가 쿠버네티스의 API에 접근하려면 인증이 필요함. 외부에서 접속시 TLS 인증이 적용되어있음. 접속하려면 kube-apiserver에 있는 인증서와 클라이언트에 있는 인증서 사이의 검증을 통과해야함. -> 인증되지 않은 클라이언트가 kube-apiserver에 접속하지 못하게 하려는 것 쿠버네티스는 접속시에 사용자 계정과 서비스 계정으로 인증을 요청함. 사용자 계정은 별도의 외부 인증 시스템에 있는 사용자 정보를 연결해 사용함 서비스 계정은 쿠버네티스가 직접 관리하는 사용자 계정이며 시크릿이 할당되어있어 비밀번호 역할을 함 kubectl의 config 파일에 있는 TLS 인증 정보 구조 확인하기 Kube-apiserver와 통신할 때 기본 인증 방법으로 TLS를 사용함. TLS는 통..

12. 1 노드 셀렉터 파드가 클러스터 안 어떤 노드에서 실행될 지를 키-값 쌍으로 결정함. 노드에서도 레이블 설정이 가능한데 보통 노드의 환경(os, arch 등)을 적어둠. 노드에 레이블 추가 ‘ kubectl label nodes “노드이름” 레이블키=레이블값 ’ 파드에 노드셀렉터 설정 spec.nodeSelector 에 키값을 설정함 -> 해당 레이블을 가진 노드에 실행될 것임을 설정할 수 있음. 12.2 어피니티와 안티 어피니티 노드 어피니티 노드셀렉터와 비슷하게 노드의 레이블 기반으로 파드를 스케줄링함. spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution : 스케줄링하는 동안 꼭 필요한 조건 .nodeSelecto..

11.1 시크릿 만들기 내장 시크릿 쿠버네티스 클러스터 안에서 쿠버네티스 API에 접근 시 사용됨 (serviceAccount 계정의 비밀번호 역할로 쓰임) 사용자 정의 시크릿 사용자가 만든 시크릿 명령으로 시크릿 만들기 ‘Kubectl create secret’ ‘kubectl create secret generic “시크릿 이름” ‘ (—from-literal=키=값) ' kubectl create secret docker-registry(시크릿타입) private-reg-cred(이름) --docker-username=(dock_user) --docker-password=(dock_password) --docker-server=(myprivateregistry.com:5000) --docker-em..

10.1 컨피그맵 사용하기 .data 실제 사용하려는 환경 값을 넣음 ‘ kubectl create configmap webapp-config-map --from-literal=APP_COLOR=darkblue ‘ : 컨피그맵 생성 ( —from-literal : .data (키:값) 설정 ) 10.2 컨피그맵 설정 중 일부만 불러와서 사용하기 containers[].env[].name 필드에 DEBUG_LEVEL이라는 환경 변숫값을 설정함 containers[].env[].valueFrom 필드값은 어디에서 가져올 것인지를 정하며 configMapKeyRef 필드는 어떤 컨피그맵이 어떤 키를 가져올지 지정함. 10. 3 컨피그맵 설정 전체를 한꺼번에 불러와서 사용하기 spec.containers[].e..

9.1 레이블 키-값 으로 구성. 메타데이터로 설정 가능. 컨트롤러들이 파드를 관리할 때 자신이 괄니해야 할 파드를 구분하는 역할. 노드에도 설정 가능하므로 자원 할당시에 할당할 노드를 구분하여 사용가능. 특정 레이블을 선택 시, 레이블 셀렉터를 사용함. 명령어 1. —selector “키=값” 해당 레이블 값을 가진 것들 출력 (—no-headers : 헤더값 미출력) ( wc -l : 행 수 출력 ) 2. —show-labels : 파드들의 모든 레이블 출력 3. ' Kubectl label node “노드이름” “키:값” ' 노드에 레이블 설정 9.2 에너테이션 키-값 쌍으로 구성하며 레이블처럼 사용자가 설정할 수 있음. 에너테이션은 쿠버네티스 시스템이 필요한 정보들을 담았으며, 쿠버네티스 클라이언..

8.1 인그레스의 개념 클러스터 외부에서 안으로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙 모음 외부에서 접근해야 할 URL을 사용할 수 있도록 하고, 트래픽 로드밸런싱, SSL 인증서 처리, 도메인 기반 가상 호스팅 제공 실제로 동작시키는 것은 인그레스 컨트롤러 직접 인그레스에 인그레스 컨트롤러(ingress-nginx)를 연동해야 함 Metadata.annotations : 인그레스 설정시 사용하는 필드. 하위필드의 설정은 컨트롤러에 따라 다름. spec.rules[] : 규칙 지정하기 host : 요청받을 주소 http.paths[] : 경로 backend.serviceName : 처리할 서비스의 이름 backend.servicePort : 서비스 포트 8.2 ingress-nginx 컨트롤러..