우노

들어가기 앞서, 해당 포스트에선, Istio의 트래픽 구조와 트래픽 주요 컴포넌트인 Gateway, Virtual Service, Destination Rule에 대해서 간단히 다뤄보겠습니다. 예제 코드는 https://istio.io/latest/docs/examples/bookinfo/ 를 참고했습니다. Istio 트래픽 구조 실습 환경엔 Istio가 사전 설치되어 있다고 가정하겠습니다. Istio 설치 시, 외부 IP가 할당된 LoadBalancer 타입의 Service가 자동으로 생성됩니다. istio-system이라는 Namespace의 istio-ingressgateway라는 Service로 생성됩니다. 따라서, 상단 그림에선 생략되어 있지만, Client는 istio-ingressgatewa..

들어가기 앞서, cloud run은 여러개의 동일한 컨테이너를 생성할 수 있으며, 자체적으로 로드밸런싱 기능을 가지고 있습니다. 하지만, 여러 컨테이너를 구동하고 있을 경우, 로드밸런싱으로 인해 클라이언트와 컨테이너의 세션이 불일치하는 에러가 발생할 수 있습니다. 이때, session affinity 또는 minimum/maximum instances 조절을 통해 해당 문제를 해결할 수 있습니다. session affinity session affinity는, 클라이언트의 요청을 동일한 컨테이너로 라우팅할지를 정하는 기능입니다. 기본적으로 세션 어피니티는 사용 설정되어 있지 않으므로, 다음과 같이 동일한 클라이언트의 요청이 다양한 컨테이너 인스턴스에서 처리될 수 있습니다. 하지만, 세션 어피니티를 사용한..

resolver란? DNS 서버는, 도메인에 따른 실제 IP 주소를 반환해주는 역할을 합니다. nginx config 파일 내부에 특정 도메인을 작성했다면, DNS 서버를 통해 해당 도메인이 실제로 어떤 IP 주소를 가지고 있는지 알아야합니다. 따라서, resolver를 통해 nginx가 어떤 DNS 서버를 사용할지를 정할 수 있습니다. 예를 들어, 로컬에 있는 DNS 서버를 사용하겠다면 127.0.0.1을, 특정 통신사의 DNS 서버를 사용하겠다면 168.126.63.1 (KT 기본 DNS 서버)를 사용할 수 있습니다. 참고 https://elvanov.com/2312 https://tilnote.io/pages/63bbd869c78a5bca41f7e9be

들어가기 앞서, Terraform은 아래와 같이 kubernetes provider를 선언할 수 있습니다. provider "kubernetes" { config_path = "~/.kube/config" config_context = "my-context" } 이때, 클러스터 액세스 정보를 담은 kubeconfig 파일이 필요합니다. 만약, kubeconfig 파일에 클러스터 액세스 정보가 없을 경우, 아래와 같은 에러가 발생하게 됩니다. Error: Provider configuration: cannot load Kubernetes client config 따라서, 해당 포스트에선 kubeconfig 파일 작성을 위한 사전 작업에 대해서 다뤄보겠습니다. kubeconfig 파일에 클러스터 연결 정보 ..

SKT 기본 DNS 서버 : 219.250.36.130 보조 DNS 서버 : 210.220.163.82 KT 기본 DNS 서버 : 168.126.63.1 보조 DNS 서버 : 168.126.63.2 LG 기본 DNS 서버 : 164.124.101.2 보조 DNS 서버 : 203.248.252.2 구글 (Google Public) 기본 DNS 서버 : 8.8.8.8 보조 DNS 서버 : 8.8.4.4 참고 https://overcode.tistory.com/entry/통신사별-DNS-서버-아이피-주소-SKT-KT-LG-구글

들어가기 앞서, 해당 포스트에선, Google Cloud SDK(gcloud) 계정 추가 및 변경 방법에 대해서 다뤄보겠습니다. gcloud 설치 및 config 설정이 이미 존재한다는 가정하에 진행하겠습니다. gcloud 계정 추가 gcloud init 기존 config 설정이 존재한다면, 위와 같은 내용들이 출력됩니다. 2를 눌러, 계정 추가(Create a new configurations)를 진행합니다. config 이름을 설정합니다. 1을 눌러, 기존 GCP 계정의 프로젝트를 추가합니다. 이후, Project, Region, Zone 을 설정합니다. gcloud 계정 확인 gcloud config configurations list IS_ACTIVE가 True인 계정이 현재 계정입니다. gclo..

웹 서버와 웹 어플리케이션 서버의 구조 웹 서버 클라이언트가 정적 데이터(HTML, CSS, etc)를 요청하면, 앞단에서 빠르게 제공하는 역할을 합니다. 클라이언트가 동적 데이터를 요청하면, WAS에 요청을 보내고, WAS가 처리한 데이터를 클라이언트에게 전달하는 역할을 합니다. 웹 서버 종류로는 NGINX, APACHE 등이 있습니다. 웹 어플리케이션 서버 클라이언트가 요청한 동적 데이터(DB 조회, 다양한 로직 기반 컨텐츠, etc)를 처리하는 역할을 합니다. 웹 어플리케이션 서버 종류로는 아파치 톰캣, 제우스, 제티(Jetty), 레진(Resin) 등이 있습니다. WAS가 Web Server의 모든 기능을 수행하면 되는 거 아닌가? Web Server는 왜 사용하는가? 정적, 동적 데이터 처리 서..

인증(Authentication)과 인가(Authorization)의 차이 인증 단계에서는, 사용자의 신원을 확인합니다. 인가 단계에서는, 신원이 확인된 사용자에게 리소스에 액세스할 수 있는 권한을 부여합니다. OpenID Connect(OIDC)와 OAuth 2.0의 차이 OpenID Connect(OIDC) Oauth 2.0을 포함하여 인증과 인가를 모두 포괄하는 확장 인증 프로토콜이며, 주로 인증(본인 증명)에 초점을 맞추고 있습니다. 한 사이트에서 로그인하면 다른 사이트에서도 로그인 되는 SSO(Single Sign-On) 기능 구현을 위한 대표적인 수단으로 사용됩니다. OAuth 2.0 권한 부여 프레임워크로, 인가(데이터에 대한 액세스 권한 부여)에 초점을 맞추고 있습니다. OAuth 2.0 ..

요약 CMD 컨테이너를 생성할 때만 실행됩니다. (docker run) 컨테이너 생성 시, 추가적인 명령어에 따라 설정한 명령어를 수정할 수 있습니다. ENTRYPOINT 컨테이너를 시작할 때마다 실행됩니다. (docker start) 컨테이너 시작 시, 추가적인 명령어 존재 여부와 상관 없이 무조건 실행됩니다. CMD, ENTRYPOINT 명령어 작성 방법 CMD ["", "", ""] CMD ENTRYPOINT ["", "", ""] ENTRYPOINT CMD 예제 Dockerfile FROM ubuntu CMD ["/bin/echo", "Before"] docker run 실행 (추가 명령어가 없을 때) docker run --name # Before docker run 실행 (추가 명령어가 있을 ..

들어가기 앞서, 모든 HTTP 응답 코드는 5개의 클래스로 구분됩니다. 상태 코드의 첫 번째 숫자는 응답 클래스를 의미하며, 다음과 같습니다. 1xx (정보): 요청을 받았으며 프로세스를 계속한다. 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다. 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다. 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다. 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다. 해당 포스트에선, 개인적으로 주로 확인하는 HTTP 상태 코드에 대해서 정리합니다. 4xx (요청 오류) 403 (Forbidden, 금지됨) 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을..