Проблемы с маршрутизацией на Angular + Kubernetes + Nginx - PullRequest
Новая
       7

Проблемы с маршрутизацией на Angular + Kubernetes + Nginx

1 голос
/ 18 января 2020

В проекте, над которым я сейчас работаю, я сталкиваюсь с множеством проблем, связанных с маршрутизацией. Я думаю, что это проблема конфигурации, и любой, имеющий подобный опыт, может поделиться своим опытом ..

Обзор проекта:

Angular Проект SPA Docker Контейнер развернут на Kubernetes Кластер (в облаке Google) , работающий на nginx сервере. Хранилище кода и процесс сборки находятся в Azure Git Репо

Проект прекрасно собирается и работает на локальном компьютере.

Сведения о проекте:

1. Детали проекта Angular SPA:

простой angular проект с простым ванилью Angular Bootstrap использует RoutingModule для навигации между различными формами. Имеет 2 формы (одна защищена, а другая открыта, подробности позже) структура 
         Devops/
             src/
                  index.html
                  app/
                      app-routing.module.ts
                      app.component.ts
                      app.component.html
                      home/
                        home.component.html
                        home.component.ts
                      dashboard/
                        dashboard.component.html
                        dashboard.component.ts


В app-routing.module.ts все маршруты устанавливаются там, где все пути отображаются на соответствующие компоненты. Также по умолчанию установлен домашний компонент.
В соответствии со стандартной настройкой индекс. html имеет следующий тег и значение, определенные по умолчанию
<base href="/">
Во время процесса сборки пространство имен и имя приложения сохраняются в переменной среды ( ENVVALUES ).


2. Сведения о Kubernetes

Допустим, в kubernetes доменом является www.xcompany.com, мое пространство имен - MaxxD , а развернутое приложение - Devops , тогда URI к размещенному сайту будет www.xcompany.com/maxxd/devops. Это настроено таким образом. Кроме того, в соответствии со стандартами Kubernetes, веб-страница проверки работоспособности также должна присутствовать для определения доступности и работоспособности капсулы. Путь к странице здоровья: www.xcompany.com/maxxd/devops/api/health


3. NGinx Подробно

* nginx Настройки, связанные с *, сохраняются в файле конфигурации с именем default.conf. Ниже приводится содержимое: 

server {
    listen       80;
    server_name  localhost;

    location ${ENVVALUES}/ {
        alias   /usr/share/nginx/html/;
        index  index.html index.htm;

        #try_files $uri $uri/ index.html
    }

    location  /api/health/ {
        alias   /usr/share/nginx/html/health/;
        index  health.html;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

}

Как мы видим, добавляется имя домена по умолчанию. с ENVVALUES , который содержит информацию о пространстве имен и имени приложения («MaxxD / Devops»)


3. Docker Подробности

Docker Сборка является многоэтапной, состоящей из 2 шагов. На первом этапе файлы копируются из репозитория Code на сервер сборки, а затем запускается сборка ng На втором этапе файлы Dist перемещаются в образ nginx, где nginx Conf файл изменен и затем запущен.


Ниже приводится содержимое DockerFile: 

### STAGE 1: Build ###
# We label our stage as ‘builder’
FROM node as builder

# Create the working folder
RUN mkdir -p /usr/src/app

# We define our current path inside of the container
WORKDIR /usr/src/app

# We copy both the package.json and the package.lock.json into the image
COPY package*.json /usr/src/app/

# run npm install to install Angular CLI
RUN npm install @angular/cli -g

# run npm install to install all dependencies of the project
RUN npm ci

# copy all file from repo to build machine
COPY . /usr/src/app/

## Build the angular app in production mode and store the artifacts in dist folder
RUN ng build --prod

### STAGE 2: Setup ###
FROM nginx
# Expose the port 80 of the running container 
EXPOSE 80

## Copy our default nginx config
COPY conf/default.conf /etc/nginx/conf.d/

## Remove default nginx website
RUN rm -rf /usr/share/nginx/html/*

## From ‘builder’ stage copy over the artifacts in dist folder to default nginx public folder
COPY --from=builder /usr/src/app/dist/devops /usr/share/nginx/html

## From ‘builder’ stage copy over the artifacts in dist folder to default nginx public folder
COPY --from=builder /usr/src/app/health /usr/share/nginx/html/health


CMD /bin/bash -c "envsubst < /etc/nginx/conf.d/default.conf > /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"

На последнем шаге nginx conf файл изменяется, и ENVVALUES транспонируется со значением "{namespace / AppName}" .

Проблема

После развертывания в кластер kubernetes мы увидел, что индекс. html загружается, но с пустым экраном. В окне отладки chrome мы увидели вспомогательные файлы, такие как. css,. js, и все изображения выдавали 404, даже несмотря на то, что домашняя па показывала правильное URI.
Потеряв немало времени на устранение неполадок, мы поняли, что это проблема маршрутизации, для которой необходимо было задать для базового href значение "./" вместо значения по умолчанию "/".
Сайт стал доступен после этого, и все компоненты были доступны для навигации.

Нам пришлось защитить сайт от несанкционированного доступа, и для этого мы использовали Okta Authorization .
Все необходимые зависимости для Okta были установлены и конфигурации завершены.

При локальном запуске мы обнаружили, что после успешной аутентификации перенаправление не работает должным образом. Неявный / обратный вызов, который сопоставлен с «OktaCallbackComponent», не загружался peroperly.

Он показывал ошибку и снова был связан со значением, установленным в базовом теге href.
Мы изменили его обратно на «/», и весь процесс аутентификации и перенаправления на защищенные разделы работал абсолютно нормально.
Но теперь, после нового развертывания, на сайте снова возникли те же проблемы, связанные с маршрутизацией.



Так что, если мы установим значение Base href в значение "/ ", то сайт отлично работает локально, но не в Кубернетесе.
Но, если установить «./», он загружает незащищенные файлы локально, не загружает защищенные файлы (из-за неявного / обратного вызова компонента Okta, как обсуждалось выше), где, как в Kubernetes, он загружает незащищенные файлы, но как Как и в случае локального экземпляра, после успешной аутентификации перенаправление Okta implcit / callback не работает успешно.



Я знаю, что это связано с nginx маршрутизацией и тем, как сервер обрабатывает URL-адреса и загружает соответствующие разделы. Но не представляю, что можно изменить, чтобы получить желаемый результат. Я перепробовал множество комбинаций идей, поделенных в inte rnet, но ни одна из них не сработала до сих пор. Не должно быть слишком сложным, потому что большинство использует стандартные рекомендации по реализации. Моя основная линия разрешения состоит в том, чтобы найти способ запустить веб-сайт с базовым href, установленным на значение по умолчанию ("/")

Другое наблюдение: Даже когда кажется, что маршрутизация работает, она доступна только через root. То есть «www.xcompany.com/MaxxD/DevOps/», тогда как c автоматически перенаправляет на «www.xcompany.com/MaxxD/DevOps/home» на основании определенных правил маршрута. Но если я добавлю «www.xcompany.com/MaxxD/DevOps/home» непосредственно в адресную строку, то получу 404 ..



Любая помощь очень ценится

...