modelmapper (dto to entity, entity to dto)
쓰는 이유 1. 일일이 매핑시키지 않아도 된다는 편리함
쓰는 이유 1. 일일이 매핑시키지 않아도 된다는 편리함
삽질의 원인 loadbalancer가 똑바로 동작하지 않았음(ㅋㅋ) broker는 일반적으로 외부에서 접근할 수 없음. 그래서 loadbalancer 내지는 nodeport로 얘를 열어줬어야 했는데 내가 그냥 해놓고 "?? 포트만 열어주면 되겠지?" 하고 원숭이마냥 무지성을 실현한 결과 삽질로 이어짐 그리고 그걸 내가 몰랐음 이건 별로 안 웃긴 부분 설치 방법 helm inspect values bitnami-aks/kafka 를 사용하면 bitnami-aks/kafka의 values.yaml 파일에 들어가는 값을 확인할 수 있다. 복사해서 별도의 values.yaml 파일을 생성한다. 그리고 다음 내용들을 수정해야한다. externalAccess.enabled=true externalAccess.ser..
입문 얼레벌레 Helm으로 설치하는 법 helm install myapp myapp 커스터마이징 helm search repo redis kubectl get pods kubectl get pods --all-namespaces kubectl describe pod myapp-59dfcd78fc-wmmpv -n myapp helm install -f values.yaml mongodb bitnami-aks/mongodb helm list --all kubectl get all 포트포워딩 kubectl port-forward mongodb-778bb6678b-j7g78 27018:27017 kubectl port-forward redis-master-0 6379:6379 kubectl port-forwar..
성능 측정 중 고려할 점 적절한 근거 자료가 갖추어야 하는 내용은 다음과 같다. 비슷한 수준의 버전(모두 최신인 게 가장 best) 환경에서 비교가 이루어졌는가? 우리가 지향하는 개발 환경과 적합 내지는 유사한 환경에서 비교가 이루어졌는가? 유사한 작업을 수행하는 환경(return success만 수행하는 등)에서 비교가 이루어졌는가? 그리고 비교 분석에 추가할 내용으로 권장받은 내용은 다음과 같다. 문서화 지향적인 환경에서 개발을 진행할 수 있는가? 일일이 yaml 파일을 작성한다든지 하지 않아도 Swagger API 리스트 등이 출력되는가? 그게 아니라면 어떤 식으로 작업해야 하는가? 혹은 기타 API 명세 자동화 등을 지원하는가? Unit Test를 지원하는 방식이 있는가? 가령 Jest 등에 대해..
URL 이번 건 직접 읽고 이해하고 정리하는 게 목표니까 좀 자유롭게 글을 써보도록 하자. URL, Uniform Resource Locator는 자원이 사용하는 프로토콜, 주소, 포트, 위치를 명시하는 웹 주소다. 이 친구를 브라우저 주소 표시줄에 입력하기만 하면 그와 연관된 리소스를 데려올 수 있는 것이다! 그럼 url의 예시를 들어보자. 가령 express-generator로 hello express를 띄우는 사이트를 허겁지겁 만든다고 하면 기본 주소는 다음과 같다. 좀 더 복잡해질 수도 있다. 이건 mozilla에 나온 복잡한 것의 예시다! 여기까지만 일단 보고 이 친구들을 나눠보는 시간을 갖자. 이 친구들도 기능들이 오밀조밀 모인 거니까... 다 떼어내서 보려면 정말 한도 끝도 없다. Schem..
프로토콜에 있어 TCP/IP가 표준은 아닐지언정 약간 생태계 독점을 하고 있는 느낌인가 본데 왜..............TCP/IP 4계층을 OSI 7계층과 비교하는 게 금기시되는 일인지 모르겠다 OSI 생태계에 harm을 끼친다는데 아무래도 ISO에서 표준을 지정했는데 TCP/IP가 또 레이어 빚어온 그런 분위기인가? 싶다. TCP/IP 레이어도 짚고 넘어가면 좋겠지만 그걸 OSI 7계층과 병행하기에는 문서상으로 너무 어그러질 것 같다는 생각이 들어서 일단은 OSI 7계층을 짚고 나중에 천천히 톺아보는 것이 좋을 것 같다....그리고 지엽적인 문제를 너무 자주 짚어서 뭐 하나 배우는데 시간이 너무 많이 걸린다...ㅠㅠ NAVER D2 일단 IP도 체크섬 같은 걸로 받은 데이터가 옳은지 아닌지를 검증하기..
TCP/IP 중에서 IP protocol이 해당하는 계층. end-to-end 통신이 네트워크 층의 메인 기능이고, IP의 목적은 첫째로는 호스트 간의 통신, 네트워크가 복잡해도 최종 수신지까지 패킷을 전달하는 것이다. 호스트 IP주소를 갖고 있는 기기. ...인데 여기서 경로 제어??를 하지 않는 것. 이걸 라우팅이라고 한다고 함.... 그래서 라우터는 호스트에 해당하지 않는다고 한다. 패킷? 데이터를 한 방에 보내줄 수만 있다면 정말 행복하겠지만...네트워크는 다른 컴퓨터들과도 통신을 진행해야 하고 혹여 에러라도 생기면 처음부터 다시 전송을 시작해야 한다. 하나의 컴퓨터와 통신을 할 때 한 번에 데이터를 전송하려 하면 다른 컴퓨터들은 영겁의 시간을 견뎌야 한다. 그래서 데이터를 쪼개서 이걸 전송하게 ..
데이터 링크는 뭔데? 기본적으로 데이터 링크는 물리적으로 연결된 매체들의 통신에 사용되는 프로토콜이나 구체적인...통신 수단을 의미하는 용어다. MAC(Media Access Control Address)은 뭔데? IP가 네트워크에 사용되는 주소라면 MAC은 물리적인 위치(다만 데이터 링크에 연결되어 있다는 전제 하에)의 노드를 식별한다는 전제 하에 사용되는 고유 식별자다. MAC 주소도 규격화가 되어있고 여기선 IEEE802.3을? 사용한다. 구체적인 정책을 살펴보는 것보다도 가볍게 훑고 가자면 FDDI, ATM, 무/유선 랜, 블루투스 등에서 모두 다른 MAC 주소를 사용한다. MAC 주소는 절댓값으로 선언된 16진수 2자리의 6쌍으로 구성되어 있다. 근데 동일한 데이터 링크만 아니면 특별히 문제는 ..