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.

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ędzie oc 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

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ść.
  • 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:

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.

O projekcie

3scale Multitenant Automated Provisioning

Zainstaluj
ansible-galaxy install gpe_mw_ansible.3scale_multitenant
Licencja
Unknown
Pobrania
221
Właściciel
Ansible roles to support RHT middleware labs