Angular - Как да четете информация за околната среда по време на изпълнение за CI / CD

Ако използвате NGINX като уеб сървър и Kubernetes за внедряването

Снимка на Тим Гоув на Unsplash

Angular предоставя опции за конфигуриране по време на изграждане, което означава, че трябва да дефинирате различни файлове на околната среда за всяка среда, а Angular приема подходяща конфигурация, докато изграждате проекта, като предоставя --configuration flag на ng build. Можете да разгледате тази статия за четене на информация за околната среда по време на изграждане.

Но методологията с дванадесет фактора и днешните стратегии на DevOps предполагат, че трябва да изградим веднъж и да работим навсякъде, което означава, че ще имате само един шанс да предоставите конфигурационен файл. Ъгловите опции за конфигурация не са достатъчни. Трябва да предоставите информация за конфигурация или обкръжение по време на изпълнение. В тази публикация ще видим как можем да постигнем това и да прочетем конфигурационните настройки или информацията за околната среда по време на изпълнение.

  • Примерен проект
  • Проблемът, пред който сме изправени
  • Решение
  • изпълнение
  • Как да се отстрани грешката
  • резюме
  • заключение

Примерен проект

Ето един примерен проект за демонстрацията. Можете да го клонирате и стартирате на вашата машина.

// клониране на проекта git clone https://github.com/bbachi/angular-envread-runtime.git
// за локално развитие npm инсталирайте npm start

Това е прост Angular проект, който зарежда конфигурационния файл app.config.json от папката / properties.

Използваме APP_INITIALIZER, за да заредим този app.config.json файл преди зареждане и да използваме тези настройки. Ето файловете app.module.ts и app.service.ts.

След като заредите настройките и можете да прочетете тези настройки в app.component.ts като по-долу.

Въз основа на конфигурацията можете да видите цвета на заглавката, заглавието и таблицата. Например, ако това е среда за разработка, заглавният цвят е черен, а заглавието - разработка. Можете да видите подобен екран като по-долу.

екран за развитие

Ако промените backgroundColor и заглавието съответно на червено и производство. Можете да видите екран както по-долу.

производствен екран

Проблемът, пред който сме изправени

Дванадесет-факторната методология подсказва, че трябва да изградим веднъж стартиране навсякъде, но в този случай ние изграждаме за всяка среда. За простота, ние обмисляме само две среди за развитие и производство. Тъй като ние обслужваме приложението Angular с NGINX и можем да предоставим конфигурация само в момент на изграждане, а не във времето на изпълнение. Ние дори не можем да предоставим променливи на околната среда при пускане, тъй като и браузърът не чете тези променливи.

Преминаване на конфигурация по време на изграждане

Ние изграждаме за всяка среда, защото трябваше да предадем специфична за околната среда информация по време на изграждане. Трябва да намерим начин, по който да предадем тази информация по време на изпълнение. Ако преминем по време на изпълнение всичко, което трябва да изградим веднъж и да стартираме навсякъде, както виждаме по-долу на диаграмата.

Преминаване на конфигурация по време на изпълнение

Решение

Нека да видим как можем да разрешим този проблем. Един от начините за решаване на това е да прочетете URL адреса на браузъра с прозореца location.href и да поставите цялата конфигурация в приложението и да заредите подходяща конфигурация въз основа на някаква конкретна част от URL адреса като dev, prod и т.н.

Ако използвате Java или Nodejs с приложението Angular, можем да получим тази конфигурационна форма на сървъра, преди да зареждате приложението с APP_INITIALIZER. Но как да направим това, ако използваме NGINX като уеб сървър?

Можем да използваме конфигурационната карта Kubernetes за инжектиране на конфигурация в обема на Pods, който е монтиран в папката / usr / share / nginx / html / properties, така че приложението Angular да го получи преди зареждане на приложението с помощта на APP_INITIALIZER. Нека да разгледаме диаграмата по-долу, за да разберем по-добре.

Конфигурация на четене по време на изпълнение с помощта на configmap

изпълнение

Нека реализираме решението с обекта Kubernetes configMap. Обектът ConfigMap прави контейнерите ви преносими чрез отделяне на конфигурация от тях. Ето как работи.

Първото нещо, което трябва да направим, е да изградим изображението на докера и да го прехвърлим към DockerHub. Ето многоетапния Dockerfile, който изгражда приложението Angular на първия етап и взема тези статични активи и го поставя в главната папка на NGINX.

Това са инструкциите за изграждане на изображението на Docker и натискането му към DockerHub. Всъщност можете да го видите на DockerHub в следното изображение. Това е публично изображение, което можете директно да го издърпате от системния регистър.

// изграждане на docker на image build -t bbachin1 / envdemo.
// списък на изображения на докер изображения
// влезте и го натиснете към docker hub docker вход docker push bbachin1 / envdemo
Докер хъб

Сега трябва да създадем обекти за внедряване, обслужване и конфигурация. ние поставяме всички тези обекти в един файл, наречен manifest.yml. Първо създаваме Configmap с необходимия config.json. Ако погледнете обекта за внедряване, Kubernetes изважда горното изображение bbachin1 / envdemo от Docker Hub и създава 5 реплики. И накрая, имаме сервизен обект с тип Nodeport, който излага на външния свят.

Ние заредихме конфигурационната карта в обема, който е монтиран на пътя / usr / share / nginx / html / properties / folder. Ние създаваме всички тези обекти в развитието на пространството от имена.

Ето инструкциите за създаване на обекти и проверка на тях.

// създаване на обекти kubectl create -f manifest.yml
// изтриване на обекти kubectl изтриване -f manifest.yml
// получи разгръщане kubectl получи разгръщане -n разработка
// получи услугата kubectl получи svc -n развитие
// получавам шушулки kubectl получавам po -n развитие

Вземете публичния адрес на Kubernetes от тази команда kubectl клъстер-информация и вземете пристанището от сервизния обект kubectl получи svc -n разработка и достъп до приложението, изпълнявано в пространството от имена на разработка с този адрес http: // : / appui

пристанище за обслужване и публичен адрес

В горния случай можете да получите достъп до приложението на http://192.168.64.6:31935/appui Уверете се, че сте преминали от https на http. Забележете, че цялата конфигурация е заредена от конфигурационната карта, като заглавието backgroundColor, заглавието и т.н.

Изпълнение на внедряването в Minikube

Нека създадем производственото внедряване от файла manifest-prod.yml и следваме горните стъпки, за да стартирате приложението във вашия локален.

// създаване на обекти kubectl create -f manifest-prod.yml
// изтриване на обекти kubectl delete -f manifest-prod.yml
// получи разгръщане kubectl get разгъване -n производство
// получи услугата kubectl получи svc -n продукция
// получавам шушулки kubectl получавам по -n производство

Услугата в производственото пространство на имена работи на порт 31633.

услугата работи на порт 31633Изпълнение на внедряването в Minikube

Как да се отстрани грешката

Това са някои от възможностите за отстраняване на грешки, ако имате някакъв проблем с прилагането на това решение.

Първо, трябва да проверим дали конфигурационната карта е създадена по правилния начин и в правилното пространство на имената.

// проверете дали configmap е създаден или не kubectl получите cm -n развитие
// проверете данните в конфигурационната карта kubectl описва cm -n развитие

След като потвърдите конфигурационната карта. След това можете да проверите монтирания обем, който се зарежда с конфигурационната карта.

// получи един от pod kubectl get po -n развитие
// exec в един от pod kubectl exec -it / bin / sh -n развитие # cd / usr / share / nginx / html / envapp / активи # cat app.config.json
app.config.json

резюме

  • Angular предоставя опции за конфигуриране по време на изграждане, което означава, че трябва да дефинирате различни файлове на околната среда за всяка среда.
  • Трябва да изградим веднъж пускането навсякъде е препоръчителната стратегия.
  • Не можем да използваме опцията Angular Environment, ако искаме да изградим веднъж и да разгърнем навсякъде, тъй като трябва да осигурим отделна конфигурация за всяка среда.
  • Configmap предоставя решение за отделяне на конфигурацията от работещите контейнери.
  • Ако обслужвате вашето Angular приложение с NGINX и се нуждаете от начин за преминаване на конфигурация по време на изпълнение, ConfigMaps е най-лесното решение.
  • Трябва да заредите конфигурационната карта в обема, който може да бъде монтиран на хост пътя и Angular да вземе JSON от този път.
  • Можете да изтриете съществуващата конфигурационна карта и да пресъздадете една, а промените могат да бъдат отразени в изпълняващия се контейнер, без да рестартирате шушулките.

заключение

Използвайте Configmaps, ако искате да отделите конфигурацията от контейнерите си и да инжектирате подходяща конфигурация по време на изпълнение.