티스토리 뷰

개발/인프라

Harbor의 리버스 프록시 문제...

애쿠 2023. 3. 15. 16:59

이직 전 마지막 작업..

이 작업이 이직 전 마지막 작업이다.

슬프게도 성공적으로 마무리된 것을 보고 나오진 못했다.

Harbor 앞에 별도의 reverse proxy를 두고 내부적으로 redirect해서 사용하는 방식으로 인프라를 구축하는 건데 문제가 생겼기 때문이다.

Harbor의 reverse proxy

Harbor는 reverse proxy가 nginx를 사용한다.

nginx 쪽에서 외부 연결을 받아주고 내부의 component들에게 전달한다.

문제는 사내 서버는 Apache Httpd를 별도의 reverse proxy를 사용하고 있다는 점이다.

그래서 아래와 같은 구조로 동작하도록 구성해야했다.

Apache Httpd에서 Redirect 설정을 하고 nginx에서 다시 뿌리도록 구성해야했다.

이렇게 설정하고 redirecting을 위해 apache httpd에 추가 설정을 한다.

RewriteCond %{REQUEST_URI} ^/harbor/(.*)$
RewriteRule "^/harbor/?(.*)$" "https://[hostname]:[https port]/$1" [P]

이러면 [apache httpd에 설정된 url]/harbor로 요청이오면 harbor nginx로 요청이 들어오게 되고, 별도의 엔드포인트가 없으므로 포털로 가게된다.

브라우저에서 저 url로 접근을 하면

이런식으로 loading... 만 출력한다.

왜 이런가 알아보면, 문제는 nginx에서 리다이렉팅 시킬 때 발생했다.

해결법?

nginx가 harbor의 리버스 프록시 역할을 하기 때문에 요청을 받은 후, harbor 엔진 내부 core, portal 등의 component로 요청을 전달한다.

이 때 portal까지는 정상적으로 요청이 들어가게 되는데 portal에서 다른 리소스를 요청할 때 문제가 발생한다.

수정해야 될 것을 중심으로 정리해보자.

harbor-portal conatiner의 디폴트 /etc/nginx/nginx.conf 파일

location / {
         try_files $uri $uri/ /index.html;
     }

아래와 같이 수정한다.

location /harbor {
         try_files $uri $uri/ /index.html;
     }

harbor-portal conatiner의 디폴트 /usr/share/nginx/html/index.html 파일

<head>
    <meta charset="utf-8">
    <title>Harbor</title>
    <base href="/">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="icon" type="image/x-icon" href="favicon.ico?v=2">
<link rel="stylesheet" href="styles.701dc5ee3007bd83bfa4.css"></head>

아래와 같이 변경

```bash
<head>
    <meta charset="utf-8">
    <title>Harbor</title>
    <base href="/harbor/">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="icon" type="image/x-icon" href="favicon.ico?v=2">
<link rel="stylesheet" href="styles.701dc5ee3007bd83bfa4.css"></head>

정리해보면, harbor-portal에 진입 한 다음 리소스를 요청할 때 [apache httpd에 설정된 url]/xxxx로 재요청해서 발생한 문제들이다.

때문에 리소스를 요청하는 위치에서 /harbor로 재요청할 수 있게 수정해주면 된다.

이러면 harbor portal 페이지로 정상 진입이 가능해진다.

그런데 그 다음에도 문제가 발생하는데, 로그인이 안된다.

왜냐?

위 설정은 portal 진입하는데 필요한 리소스를 가져오는 곳만 /harbor로 가져올 수 있게 설정했기 때문이다.

nginx container로 진입해서 /etc/nginx/nginx.conf 파일을 열어보면 이유를 알 수 있는데, 여기서 추가적인 api들을 요청하는데 또 다시 redirecting을 해준다.

location / {
  proxy_pass http://portal/;
  proxy_set_header Host $http_host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # When setting up Harbor behind other proxy, such as an Nginx instance, remove the below line if the proxy already has similar settings.
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_cookie_path / "/; HttpOnly; Secure";

  proxy_buffering off;
  proxy_request_buffering off;
}

location /c/ {
  proxy_pass http://core/c/;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # When setting up Harbor behind other proxy, such as an Nginx instance, remove the below line if the proxy already has similar settings.
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_cookie_path / "/; Secure";

  proxy_buffering off;
  proxy_request_buffering off;
}

location /api/ {
  proxy_pass http://core/api/;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # When setting up Harbor behind other proxy, such as an Nginx instance, remove the below line if the proxy already has similar settings.
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_cookie_path / "/; Secure";

  proxy_buffering off;
  proxy_request_buffering off;
}

~~사실 여기에도 portal로 접근하는 url이 있다.~~

로그인 요청을 날릴 때 /c/로 요청하게 되는데 이 부분을 /harbor/c/로 요청하도록 하면 정상 동작할 수도 있다... 아마...

(안해봄)

왜 안해봤는가?

사이드 이펙트가 엄청나게 터질 것이라 예상되고 앞으로 쭉 사용할 예정인데, 유지보수에도 큰 문제가 있으리라 판단했다.

그래서 apahce httpd랑 떨어져서 사용할 수 있도록 별도의 포트포워딩 요청을 해뒀다.

포트포워딩이 완료되면 https://[apache httpd에 설정된 url]/[별도로 지정한 port] 로 요청이 들어오면 nginx의 디폴트로 설정된 경로인 / 경로로 라우팅이 된다.

그렇게 되면, 내부적으로 /harbor로 돌릴 필요 없이 정상 동작할 것이라 예상된다.

이 방법이 harbor 홈페이지에서 가이드 해주는 방식이기도 하다.

마치며

nginx에서 모든 경로를 redirect해서 테스트했을 때 정상동작한다면, 해볼만한 가치가 있는 작업이라고는 생각한다.

사내 서버의 내부 정책을 모두 준수할 수 있기 때문이다.

다만, 나는 그렇게 하진 않을 것 같다.

간단한 방법이 다른 있는데 너무 돌아가기는 노가다 작업이기 때문이다...

그리고 인수인계 했을 떄 누가 관리할건데...?

'개발 > 인프라' 카테고리의 다른 글

AWS EC2에서 Jenkins 자동배포 구축하기(2) (2)	2023.05.08
AWS EC2에 MySQL Docker 띄우고 사용하기 (0)	2023.03.29
Harbor : Private Container Registry 설치하기 (1)	2023.03.15
AWS EC2에서 Jenkins 자동배포 구축하기 (1) (1)	2023.01.26
웹서버와 WAS의 차이 정리 (1)	2023.01.26

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2024/12 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

글 보관함

개발과 일상