gpe_mw_ansible.3scale_multitenant
3scale_multi-tenant
Przegląd
Ten zestaw narzędzi tworzy jednolity, centralny menedżer API 3scale w jednym namespace OCP.
Zestaw ten należy wykonać tylko raz na klaster OCP.
Umożliwia również zarządzanie (tj. tworzenie/usuwanie) konfigurowalną liczbą najemców API w instalacji menedżera API 3scale.
Ten rolę można wykorzystać w następujących okolicznościach:
Szkolenia z prowadzeniem instruktora, Hackathony i warsztaty:
- Przy X liczbie uczestników w szkoleniu wymagających 3scale, tworzy się jeden centralny, wielo-najemcowy menedżer API Red Hat 3scale, gdzie każdy uczestnik ma przydzielonego swojego najemcę.
- Uczestnik otrzymuje dane do logowania jako administrator swojego najemcy.
- Ta metoda może być bardziej pożądana niż alternatywa, w której każdy uczestnik tworzy własnego menedżera API 3scale.
Wydajność Red Hat 3scale
- Kilka celów nauczania może obejmować:
- Demonstracja wdrożenia 3scale na OCP.
- Integracja z zewnętrznym dostawcą SMTP do wysyłania wiadomości e-mail i ułatwienia procedury rejestracji użytkowników.
- Wywołanie REST API administracyjnego 3scale za pomocą tokenów OAuth2 dostępu i odnowienia.
- Kilka celów nauczania może obejmować:
Wymagania wstępne
Wersja 3scale wdrażana w tym laboratorium (v2.4) działa na OpenShift Container Platform 4.8.
- Ta wersja OpenShift powinna być już zainstalowana przed wykonaniem tej roli Ansible.
Używając wersji narzędzia
oc
odpowiadającej Twojemu docelowemu klastrze OCP, upewnij się, że narzędzieoc
jest już uwierzytelnione jako administrator klastra.Ta rola Ansible wymaga zainstalowania modułów Pythona lxml i openshift na docelowym hoście wykonującym tę rolę Ansible, tj.:
# dnf install python3-lxml # dnf install python3-openshift
Menedżer API
Rola Ansible opisana w tej sekcji może wdrożyć menedżera API 3scale przy użyciu szablonów OpenShift.
Znane Problemy
- Menedżer API na OCP zgodnym z FIPS. Planowane rozwiązanie: 3scale 2.12
Wymagania zasobów
Ta rola Ansible pozwala na wdrożenie 3scale o różnych rozmiarach w oparciu o wartość poniższej zmiennej Ansible: is_production.
Wykorzystanie zasobów: is_production = true
- Kwota klastra dla CPU i RAM jest domyślnie ustawiona dość wysoko:
- Limit CPU: 30 rdzeni
- Limit RAM: 30 Gi
- Limity CPU i RAM zdefiniowane w szablonie menedżera API 3scale są również ustawione dość wysoko.
- Te domyślne ustawienia są dość wysokie, aby umożliwić dużą wydajność.
- Kwota klastra dla CPU i RAM jest domyślnie ustawiona dość wysoko:
Wykorzystanie zasobów: is_production = false
- To jest domyślna wartość.
- Zasoby potrzebne do wdrożenia 3scale maleją do około 12 Gi RAM i 6 CPU.
Dostawcy SMTP
Zarejestruj się u dostawcy SMTP, aby umożliwić menedżerowi API 3scale wysyłanie e-maili.
W 3scale ustawienia SMTP są konfigurowane globalnie i wykorzystywane przez wszystkich najemców API.
Kilku dostawców SMTP z darmowymi planami, z którymi ta rola Ansible została przetestowana, przedstawiono poniżej:
- SocketLabs: Obecnie oferuje darmowy plan, który pozwala na 2000 e-maili miesięcznie.
- SendGrid: Obecnie oferuje darmowy plan, który pozwala na 100 e-maili dziennie.
Zmienne środowiskowe
Wszystkie zmienne środowiskowe są opcjonalne.
Jeśli nie określono żadnych zmiennych środowiskowych, to zostanie wdrożony kontrolny menedżer API 3scale, który wymaga przynajmniej jednego PVC RWX i nie integruje się z dostawcą SMTP.
Menedżer API zostanie wdrożony w następującym namespace: 3scale-mt-api0.
amp_master_passwd
- Opcjonalne. Domyślna wartość = master.
master_access_token
- Opcjonalne. Domyślna wartość = wtqhhsly.
default_tenant_access_token
- Opcjonalne. Domyślna wartość = 3832cnj371woiduh.
is_production
- Opcjonalne. Domyślna wartość = false.
use_rwo_for_cms
- Opcjonalne. Domyślna wartość = false.
- Kontrolny menedżer API 3scale składa się z systemu zarządzania treścią (CMS), który zazwyczaj jest skalowany w celu poprawy wydajności w środowisku produkcyjnym.
- Ten CMS wymaga dostępu ReadWriteMany dla odpowiadającego mu PVC "system-storage".
- W wdrożeniu menedżera API na OCP 4.* przy użyciu AWS EBS do przechowywania, dostęp ReadWriteMany nie jest dostępny.
- W takim przypadku ustaw tę zmienną środowiskową na: true.
- Umożliwia to modyfikację szablonu kontrolnego menedżera API 3scale, aby wskazywał ReadWriteOnce (a nie ReadWriteMany).
- Jeżeli ustawisz to na true, nie próbuj tworzyć więcej niż jednej repliki kontenera system-app.
Konfiguracje SMTP, aby umożliwić menedżerowi API wysyłanie e-maili
- E-maile są szeroko wykorzystywane w różnych procesach rejestracji w portalu dewelopera 3scale.
- Integracja między dostawcą SMTP a 3scale odbywa się globalnie dla całego menedżera API.
smtp_userid
- Opcjonalne. Domyślnie jest null. Jeśli null, integracja między menedżerem API 3scale a dostawcą SMTP nie zostanie skonfigurowana.
smtp_host
smtp_port
smtp_authentication
smtp_passwd
smtp_domain
adminEmailUser
- Opcjonalne. Domyślna wartość = jdoe.
adminEmailDomain
- Opcjonalne. Domyślna wartość = redhat.com.
RESUME_CONTROL_PLANE_GWS
- Opcjonalne. Domyślna wartość = true.
- Menedżer API 3scale zawiera domyślnie bramkę stagingową i produkcyjną.
- Te dwa GWs zazwyczaj nie są używane do stosowania polityk API do żądań, ponieważ "plany danych" (ta zwana: bramki) są zazwyczaj wdrażane w innym środowisku.
- Niemniej jednak, bramka stagingowa jest potrzebna przez aplikację webową dostawcy systemu do szczegółów polityk bramki API.
- W związku z tym domyślna wartość to: true.
OCP_AMP_ADMIN_ID
- Opcjonalne. Domyślna wartość = api0.
- Użytkownik OCP, który jest właścicielem namespace OCP, w którym znajduje się menedżer API.
- Kwota klastra jest przypisana do tego użytkownika.
- UWAGA: ten użytkownik OCP nie musi koniecznie istnieć.
Wykonanie
Provisioning Menedżera API:
$ ansible-playbook playbooks/apimanager.yml
Zobacz wszystkie trasy menedżera API w namespace 3scale-mt-api0:
$ oc get route -n 3scale-mt-api0
Opcjonalnie: Usuń Menedżera API:
$ ansible-playbook playbooks/apimanager.yml -e ACTION=uninstall
Najemca API
Podczas wdrażania menedżera API 3scale tworzony jest domyślny najemca.
W razie potrzeby, rola Ansible opisana w tej sekcji może utworzyć dodatkowych najemców.
Zmienne środowiskowe
Wszystkie zmienne środowiskowe są opcjonalne.
Jeśli nie podano żadnych zmiennych środowiskowych, to zostanie utworzony pojedynczy najemca (nazywany: ocp01) w menedżerze API z administracyjnym użytkownikiem najemcy: api01/admin. Odpowiednie bramy również zostaną utworzone w namespace zwanym: ocp01.
orgName
- Opcjonalne: Domyślna wartość = ocp01.
- Określa nazwę najemcy, jak i nazwę namespace, w którym odpowiadające bramy będą wdrażane.
- Przydatne, jeśli celem jest stworzenie jednego najemcy o konkretnej nazwie.
tenant_admin_user_name_base
- Opcjonalne. Domyślna wartość = api.
- Bazowa nazwa użytkowników API, którzy będą administratorami swoich najemców API (i administratorami swoich bram API).
- Jeżeli pożądane nazwy użytkowników API to: api01, api02, api03, ..., to wartość tej zmiennej powinna być: "api".
tenantAdminPasswd
- Opcjonalne. Domyślna wartość = admin.
create_gws_with_each_tenant
- Opcjonalne. Domyślna wartość = true.
- Jeśli jest prawdą, to dla każdego odpowiadającego najemcy w tym samym klastrze OCP, w którym znajduje się menedżer API, zostanie utworzony projekt OCP z bramkami API.
ocp_user_name_base
- Opcjonalne. Domyślna wartość = ocp.
- Określa bazową nazwę użytkowników OCP, którzy będą mieli dostęp do odpowiednich projektów związanych z zarządzaniem API.
- Jeżeli nazwy użytkowników OCP to: user01, user02, user03, ..., to wartość tej zmiennej powinna być: "user".
START_TENANT
- Opcjonalne. Domyślna wartość = 1.
END_TENANT
- Opcjonalne. Domyślna wartość = 1.
use_padded_tenant_numbers
- Opcjonalne. Domyślna wartość = true.
- Przy tworzeniu sekwencyjnych ogólnych najemców określa, czy nazwy najemców powinny zawierać wypełniony numer, czy nie, tj.: ocp01, ocp02,... lub ocp1, ocp2,....
- Domyślna wartość to true, co odpowiada domyślnemu używaniu wypełnionych numerów w: repozytorium GitHub.
Wykonanie
Wdrażanie:
$ ansible-playbook playbooks/api_tenant.yml
Po zakończeniu wdrażania najemcy, na końcu standardowego wyjścia Ansible zobaczysz komunikaty podobne do następujących:
ok: [localhost] => { "msg": [ "tenant_output_dir: /home/jbride/provisioning_output/3295.openshift.opentlc.com/tenants_3scale-mt-api0", "tenant_provisioning_log_file = /home/jbride/provisioning_output/3295.openshift.opentlc.com/tenants_3scale-mt-api0/tenant_provisioning.log", "tenant_provisioning_results_file = /home/jbride/provisioning_output/3295.openshift.opentlc.com/tenants_3scale-mt-api0/tenant_info_file_1_2.txt", "start and end tenants = 1 2", "create API Gateways for each tenant = true" ] }
Plik tenant_provisioning_results_file zawiera szczegóły dotyczące poświadczeń i adresy URL każdego utworzonego najemcy.
- Jest to plik z tabulowanym rozdzielaczem, który można zaimportować do Google Arkuszy lub LibreOffice Calc.
Bramki API
Jeśli twój menedżer API oraz najemcy są już wdrożeni i potrzebne są odpowiednie bramki apicast dla tego najemcy, to ta rola Ansible będzie przydatna.
Zmienne środowiskowe
threescale_tenant_admin_accesstoken
- Wymagane.
- Wartość tej zmiennej podczas tworzenia najemcy 3scale: ADMIN_ACCESS_TOKEN.
- Alternatywnie, nowy token dostępu można utworzyć z interfejsu administracyjnego najemcy 3scale: Ikona zębatki -> Ustawienia osobiste -> Tokeny -> Tokeny dostępu -> Dodaj token dostępu.
- Alternatywnie może to być "Klucz API dostawcy" twojego administratora najemcy 3scale.
threescale_tenant_admin_hostname
- Wymagane.
- URL trasy administrator dostawcy docelowego najemcy 3scale.
- np.: t1-admin.apps.cluster-4663.4663.sandbox758.opentlc.com.
gw_namespace
- Opcjonalne. Domyślna wartość = user1-gw.
threescale_version
- Opcjonalne. Domyślna wartość = 3scale-2.10.0-GA-jbride.
- Inne tagi są wymienione tutaj.
Wykonanie:
- Wdrożenie bramek apicast
$ ansible-playbook playbooks/api_gw.yml \ -e threescale_tenant_admin_accesstoken=$threescale_tenant_admin_accesstoken \ -e threescale_tenant_admin_hostname=$threescale_tenant_admin_hostname
Ustawienia Ansible
Zainstaluj tę rolę lokalnie
$ ansible-galaxy install gpe_mw_ansible.3scale_multitenant --force -p $HOME/.ansible/roles
Utwórz playbook:
$ echo " - hosts: all become: false gather_facts: False vars_files: roles: - gpe_mw_ansible.3scale_multitenant " > /tmp/3scale_multitenant.yml
Provisioning menedżera API 3scale
Namespace OCP dla aplikacji 3scale wielonajemczej będzie należeć do następującego użytkownika: {{OCP_AMP_ADMIN_ID}}.
{{OCP_AMP_ADMIN_ID}} uzyska kwotę klastra, aby zarządzać limitami i zasobami przypisanymi do 3scale.
Wykonaj:
# Provisioning menedżera API $ ansible-playbook playbooks/apimanager.yml \ -e"use_rwo_for_cms=$use_rwo_for_cms" \ -e"smtp_port=$smtp_port" \ -e"smtp_authentication=$smtp_authentication" \ -e"smtp_host=$smtp_host" \ -e"smtp_userid=$smtp_userid" \ -e"smtp_passwd=$smtp_passwd"
Po około 5 minutach, wdrożenie menedżera API powinno zostać zakończone.
Menedżer API to obszerna aplikacja z wieloma komponentami, które są uruchamiane w uporządkowanym sposób.
- W związku z tym, Ansible wprowadza się w pętlę oczekiwania na każdym etapie procesu wdrażania.
Nazwane najemcy
Alternatywnie do możliwości tworzenia sekwencji ogólnych najemców, można stworzyć nazwanego najemcę na indywidualnej podstawie.
orgName=openbanking-prod
ocpAdminId=ocp01 # nazwa użytkownika OCP, który ma dostęp do odpowiadających projektów związanych z zarządzaniem API.
tenantAdminId=api01 # nazwa użytkownika API, który będzie administratorem swoich najemców API (i administrator domowych bram API).
create_gws_with_each_tenant=true # jeżeli prawda, wtedy projekt OCP z bramkami API będzie tworzony dla każdego odpowiadającego najemcy w tym samym klastrze OCP, w którym cyfrowy menedżer API się znajduje.
gw_project_name=$orgName-gw
$ ansible-playbook -i localhost, -c local /tmp/3scale_multitenant.yml \
-e"ACTION=tenant_mgmt" \
-e"API_MANAGER_NS=$API_MANAGER_NS" \
-e"adminEmailUser=$adminEmailUser" \
-e"adminEmailDomain=$adminEmailDomain" \
-e"create_gws_with_each_tenant=$create_gws_with_each_tenant" \
-e"orgName=$orgName" \
-e"ocpAdminId=$ocpAdminId" \
-e"tenantAdminId=$tenantAdminId" \
-e"gw_project_name=$gw_project_name" \
-e"rht_service_token_user=$rht_service_token_user" \
-e"rht_service_token_password=$rht_service_token_password"
Poświadczenia użytkownika najemcy
Każdy najemca jest wyposażony w użytkownika, który ma uprawnienia administracyjne do tego najemcy.
Identyfikatory użytkowników i hasła są generowane przy użyciu poniższych zmiennych Ansible, które znajdują się w defaults/main.yml
:
- Użytkownik admina najemcy: {{ tenant_admin_user_name_base }} (tj. api01, api02, api03, ..., api10).
- Hasło admina najemcy: {{ tenantAdminPasswd }}.
Stan WILDCARD_DOMAIN API Menedżera
Może wystąpić sytuacja, w której DNS pierwotnie wdrożonego menedżera API zmienia się. W szczególności, wartość parametru WILDCARD_DOMAIN używanego w pierwotnym wdrożeniu twojego menedżera API przestaje być prawidłowa.
Przykład sytuacji, w której może to wystąpić, to Ravello, gdzie pierwotne wdrożenie menedżera API 3scale byłoby rejestrowane jako Ravello Blueprint. W momencie uruchomienia z tego Ravello blueprint tworzona jest aplikacja Ravello, a rzeczywisty DNS uruchomienia jest stosowany. Ten DNS stosowany do czasu uruchomienia aplikacji będzie różny od DNS pierwotnie używanego podczas tworzenia blueprint.
Aby skorygować problemy dotyczące tego stanu, należy:
- Zaktualizuj wszystkie trasy w namespace swojego menedżera API.
- Zaktualizuj przestarzałe adresy URL w tabeli system.accounts w bazie danych system-mysql menedżera API.
- Zmień wartość zmiennej THREESCALE_SUPERDOMAIN w configmapie: system-environment.
Przykłady, jak wprowadzić powyższe zmiany, znajduje się tutaj.
ansible-galaxy install gpe_mw_ansible.3scale_multitenant