Skip to content

태그: proxy

총 15개의 글이 있습니다.

SSL passthrough

Only way to have ssl passthrough is by using a stream host. And Nginx can't run a stream on the same port as other proxies. It's one stream per port, and a port with a stream attached can't have any other proxies attached. We can work around this by routing all HTTPS traffic through this single stream, which in turn forwards it either to the ssl passthrough server or back to nginx itself on a

Contour is an Envoy based ingress controller. And it is an open source Kubernetes ingress controller providing the control plane for the Envoy edge and service proxy. Contour supports dynamic configuration updates and multi-team ingress delegation out of the box while maintaining a lightweight profile. Getting Started with Contour Let's look at three ways to install Contour using Contou

Contour CRD 설치

Install Contour: Use the appropriate command for your cluster manager to install Contour. For example, using kubectl for Kubernetes: bash kubectl apply -f This command downloads and applies the Contour manifest file, which includes the necessary resources for Contour's installation. Verify Contour installation: Check that the

Envoy is a high performance C++ distributed proxy designed for single services and applications, as well as a communication bus and “universal data plane” designed for large microservice “service mesh” architectures. Built on the learnings of solutions such as NGINX, HAProxy, hardware load balancers, and cloud load balancers, Envoy runs alongside every application and abstracts the networ

The listener discovery service (LDS) is an optional API that Envoy will call to dynamically fetch listeners. Envoy will reconcile the API response and add, modify, or remove known listeners depending on that is required. The semantics of listener updates are as follows: Every listener must have a unique name. If a name is not provided, Envoy will create a UUID. Listeners that are to be synamical

xDS configuration

Envoy is architected such that different types of configuration management approaches are possible. The approach taken in a deployment will be dependent on the needs of the implementor. Simple deployments are possible with a fully static configuration. More complicated deployments can incrementally add more complex dynamic configuration, the downside being that the implementor must provide one or

location 블록은 Nginx에서 정의되어 있는 웹사이트의 특정 URL 을 조작하는데 사용되는 블록이다. Server 블록마다 Location 을 지정해줄 수 있으며, Location 을 여러 번 정의할 수 있다. location은 URI 경로의 일부인 prefix string이거나 정규식 표현이 될 수 있다. 예시 bash // nginx.conf server { location /images/ { root /data; } location / { proxy_pass http://www.example.com; } } 위와 같이 server 내부에 표시해준다. 위의 코드는 첫 번째 location context와 일치하는 패

nginx에서 https를 적용하기 위해 certbot과 Let's encrypt를 사용해보자. 일단 nginx를 아래와 같이 설정해준다. bash server { listen 80; server_name your.domain.com; location / { proxy_pass http://192.168.XXX.XXX; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } } 1. certbot 설치 bas

1. nginx 컨테이너 실행 jsx sudo docker run --name nginx -d -p 80:80 nginx 1. nginx bash 들어가서 conf 파일 열기 jsx docker exec -it nginx bash vi /etc/nginx/conf.d/default.conf 1. 원하는 도메인, 포트 설정해넣기 예시 jsx server { listen 80; listen [::]:80; server_name domain.aliens-dms.com; location / { proxy_pass http://ip:8080; } } 1. nginx reload로 적용 j

NGINX Ingress Basic Auth

NGINX Ingress에서 설정을 해주면 어플리케이션 레벨에서, 혹은 Ingress 레벨에서 서비스 인증과정을 거치도록 할 수 있다. ingress를 통해 인증을 설정하는 방법을 두가지 알아보자. ![image]( Static User Static User는 미리 basic auth로 인증할 유저 리스트를 생성하고 해당 리스트에 포함된 인원만 인증될 수 있게 하는 방법이다. 별다른 추가 작업 없이 사용자

nginx 명령어

Nginx 시작 bash sudo systemctl start nginx Nginx 시작 (systemd 없이 Linux 배포를 실행하는 경우) bash sudo service nginx start Nginx 중지 bash sudo systemctl stop nginx sudo service nginx stop Nginx 다시 시작 bash sudo systemctl restart nginx sudo service nginx restart Nginx reroad (새 설정을 적용해야할 떄) bash sudo systemctl reload nginx sudo service nginx reload Nginx 구성 테스트 설

Nginx를 설치한다. 원하면 이미지로 띄울 수도 있다. bash $ sudo apt update $ sudo apt install nginx 설정 파일 생성 $ cd /etc/nginx/conf.d $ vim default.conf default.conf 파일을 생성하고 아래와 같이 원하는 설정 내용을 적어준다. bash server { listen 80; server_name your.domain.com; location / { proxy_pass http://192.168.XXX.XXX; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-

sites available

bash ubuntu@:~/ cd /etc/nginx `/etc/nginx`의 경로에서 nginx에 대한 기본적인 설정을 진행할 수 있다. 그 중 프록시 관련 설정을 할 때 bash /etc/nginx/sites-enabled 라는 폴더에서 직접적으로 설정이 가능하고 유저는 저 폴더에 있는 설정파일을 직접적으로 수정하지 않고 bash /etc/nginx/sites-available 의 폴더에서 여러 설정파일들을 생성한 뒤 symlink 기능을 이용해서 그 파일들 중 원하는 설정을 선택적으로 `sites-enabled`폴더에 동기화해서 적용할 수 있다. 다음은 sites-available에 만든 설정파일을 sites-enabled에 symlink 시킬 수

리버스 프록시

클라이언트 요청을 대신 받아 내부 서버로 전달해주는 것을 리버스 프록시(Reverse Proxy)라고 한다. 리버스 프록시가 필요한 이유 로드 밸런싱 : Nginx는 클라이언트의 요청을 프록시 서버에 분산하기 위해 로드 밸런싱을 수행하여 성능, 확장성 및 신뢰성을 향상시킬 수 있다. 캐싱 : Nginx를 역방향 프록시로 사용하면 미리 렌더링된 버전의 페이지를 캐시하여 페이지 로드 시간을 단축할 수 있다. 서버의 응답에서 수신한 콘텐츠를 캐싱하고 이 콘텐츠를 사용하여 매번 동일한 콘텐츠를 프록시 서버에 연결할 필요 없이 클라이언트에 응답하는 방식으로 구현하는게 가능해진다. SSL 터미네이션 : Nginx는 클라이언트와의 연결에 대한 SSL endpoint 역할을 할 수 있다. 압축 : 프록시 서

Reverse Proxy vs. Ingress Controller vs. API Gateway

Reverse Proxy You can think of the reverse proxy as that old-school phone operator, you know, back when there used to be call centers and phone operators. Back then, when someone was picking up the phone, they were connected to a call center, the caller stated the name and the address of the person they wanted to call, and the phone operator connected them. A reverse proxy does a similar job by