Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Dodawanie niestandardowej wtyczki
Możesz dodawać do mikrobramy nowe funkcje i możliwości, tworząc niestandardowe wtyczki. Niestandardowe wtyczki umożliwiają automatyczną interakcję z żądaniami i odpowiedziami, które przechodzą przez mikrobramę.
W tej sekcji dowiesz się, jak tworzyć pakiety i wdrażać wtyczki w instancji Edge Microgateway działającej w klastrze Kubernetes.
W pozostałej części tej sekcji zakładamy, że umiesz pisać i konfigurować wtyczki w standardowej konfiguracji Edge Microgateway. Jeśli nie jest, przeczytaj artykuł o tworzeniu wtyczek niestandardowych.
Pakowanie wtyczek
Aby spakować niestandardowe wtyczki, wykonaj te czynności:
Napisz i przetestuj wtyczkę zgodnie ze wskazówkami z artykułu Tworzenie prostej wtyczki.
Umieść kod wtyczki w odpowiedniej strukturze katalogu. Katalogi wtyczek muszą mieć określoną strukturę. Poniższy przykład pokazuje strukturę, której należy przestrzegać, gdzie
response-uppercase
irequest-headers
to nazwy folderów zawierających niestandardowy kod wtyczki (te nazwy są tylko przykładami, nazwy folderów mogą się różnić):plugin | |-- plugins | |- response-uppercase | |- index.js | |- package.json |- request-headers | | - index.js | - package.json
cd
do folderuplugin
.W folderze
plugin
skompresuj cały folderplugins
:zip -r plugins.zip plugins/
Tworzenie obrazu Dockera
- W tym samym katalogu, w którym znajduje się plik ZIP, utwórz nowy plik o nazwie
Dockerfile
. Dodaj ten kod do pliku
Dockerfile
i zapisz plik:FROM gcr.io/apigee-microgateway/edgemicro:latest RUN apt-get install unzip COPY plugins.zip /opt/apigee/ RUN chown apigee:apigee /opt/apigee/plugins.zip RUN su - apigee -c "unzip /opt/apigee/plugins.zip -d /opt/apigee" EXPOSE 8000 EXPOSE 8443 ENTRYPOINT ["entrypoint"]
Utwórz nowy obraz Dockera Edge Microgateway ze swoimi wtyczkami i prześlij go do rejestru Dockera. Możesz użyć dowolnego rejestru, takiego jak
docker.io
lubgcr.io
:docker build -t edgemicroplugins .
docker tag edgemicroplugins container-registry/your-project/edgemicroplugins
docker push container-registry/your-project/edgemicroplugins
Na przykład:
docker build -t edgemicroplugins .
docker tag edgemicroplugins gcr.io/my-project/edgemicroplugins
docker push gcr.io/my-project/edgemicroplugins
Aktualizowanie konfiguracji Edge Microgateway
Dodaj wtyczki do pliku konfiguracji Edge Microgateway. Plik konfiguracyjny znajdziesz tutaj:
$HOME/.edgemicro/org-env-config.yaml
Na przykład:
$HOME/.edgemicro/myorg-test-config.yaml
W poniższej przykładowej konfiguracji dodano niestandardową wtyczkę response-uppercase
.
Wtyczka oauth
była już domyślnie dostępna.
edgemicro:
...
plugins:
sequence:
- oauth
- response-uppercase
Zaktualizuj klaster Kubernetes
Ostatnim krokiem jest zastosowanie zmiany konfiguracji w klastrze Kubernetes. Kubernetes pobierze nowy obraz z kodem wtyczki przekazanym do rejestru kontenerów i użyje go we wszystkich nowo utworzonych podach.
Jeśli wdrożysz Edge Microgateway jako usługę
Użyj polecenia edgemicroctl
, aby wstrzyknąć zaktualizowaną konfigurację Edge Microgateway:
Zaktualizuj wdrożenie Edge Microgateway o nowy obraz. Na przykład:
kubectl apply -f <(edgemicroctl -org=your_organization -env=your_environment -key=configuration_key -sec=configuration_secret -conf=config_file_path -img=container-registry/your_project_name/image_name:latest)
gdzie:
your_organization
– organizacja Apigee podana w poleceniuedgemicro configure
.your_environment
– środowisko określone w poleceniuedgemicro configure
.configuration_key
– klucz zwrócony z poleceniaedgemicro configure
.configuration_secret
– obiekt tajny zwrócony przez polecenieedgemicro configure
.config_file_path
– ścieżka do pliku konfiguracji Edge Micro zwróconego przez polecenieedgemicro configure
.container-registry
– rejestr Dockera, do którego został przekazany obraz. Na przykładgcr.io
lubdocker.io
.your_project_name
– nazwa projektu repozytorium Dockera, w którym został umieszczony obraz Dockera.image_name
– nazwa przesłanego obrazu Dockera.
Przykład:
kubectl apply -f <(edgemicroctl -org=jdoe -env=test -key=f2d2eaa52b758493d00cec656e574ac947bee1d701c5c5f3295e5eaa39a3b -sec=0c38cda3fac6c59152f15657052ba1728f8003c1a763cf08da2a -conf=/Users/jdoe/.edgemicro/apigeesearch-test-config.yaml -img=gcr.io/jdoe-project/edgemicroplugins:latest)
Przetestuj wtyczkę. Wywołaj ten interfejs API, aby sprawdzić, czy uzyskujesz oczekiwane działanie. Na przykład w przypadku wtyczki „odpowiedź wielkimi literami” tekst odpowiedzi jest konwertowany na wielkie litery, jak pokazano poniżej:
curl $GATEWAY_IP -H 'x-api-key:3eqeedJRFLlCshwWBiXq4xKFoH1Se3xR'
Dane wyjściowe:
HELLO WORLD
Ręczne wstrzyknięcie nowej konfiguracji
Wstrzykiwanie ręczne to prosty sposób, który polega na wstrzyknięciu nowej konfiguracji z poziomu wiersza poleceń.
Uruchom to polecenie:
kubectl apply -f <(edgemicroctl -org=your_org -env=your_env -key=your_key -sec=your_secret -conf=config_file_path -img=container-registry/your_project_name/image_name:latest -svc=service_deployment_file)
gdzie:
your_org
– organizacja Apigee podana w poleceniuedgemicro configure
.your_env
– środowisko określone w poleceniuedgemicro configure
.your_key
– klucz zwrócony z poleceniaedgemicro configure
.your_secret
– obiekt tajny zwrócony przez polecenieedgemicro configure
.config_file_path
– ścieżka do pliku konfiguracji Edge Micro zwróconego przez polecenieedgemicro configure
.container-registry
– rejestr Dockera, do którego został przekazany obraz. Na przykładgcr.io
lubdocker.io
.your_project_name
– nazwa projektu repozytorium Dockera, w którym został umieszczony obraz Dockera.image_name
– nazwa przesłanego obrazu Dockera.service_deployment_file
– ścieżka do pliku wdrożeniowego usługi, do której będą miały zastosowanie wtyczki. Na przykład:samples/helloworld/helloworld.yaml
.
Na przykład:
kubectl apply -f <(edgemicroctl -org=myorg -env=test-key=0e3ecea28a64099410594406b30e54439af5265f8 -sec=e3919250bee37c69cb2e5b41170b488e1c1d -conf=/Users/jdoe/.edgemicro/myorg-test-config.yaml -img=gcr.io/myproject/edgemicroplugins:latest -svc=samples/helloworld/helloworld.yaml)
Przetestuj wtyczkę. Wywołaj interfejs API usługi, aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami. Na przykład w przypadku wtyczki „odpowiedź wielkimi literami” tekst odpowiedzi jest konwertowany na wielkie litery, jak widać poniżej:
curl $GATEWAY_IP -H 'x-api-key:3eqeedJRFLlCshwWBiXq4xKFoH1Se3xR'
Dane wyjściowe:
HELLO WORLD
Wprowadzanie zmian w konfiguracji Edge Microgateway
W niektórych przypadkach może być konieczne zmodyfikowanie konfiguracji Edge Microgateway. Możesz na przykład dodać nową wtyczkę do Edge Microgateway lub zmienić parametr konfiguracji. Ta sekcja wyjaśnia, jak wprowadzać i stosować zmiany konfiguracji w Edge Microgateway działających w Kubernetes.
Utwórz plik konfiguracji
secret.yaml
w następujący sposób:apiVersion: v1 kind: Secret metadata: name: mgwsecret type: Opaque data: mgorg: EDGEMICRO_ORG mgenv: EDGEMICRO_ENV mgkey: EDGEMICRO_KEY mgsecret: EDGEMICRO_SECRET mgconfig: EDGEMICRO_CONFIG
Określ zakodowaną w formacie base64 wartość
EDGEMICRO_ORG
,EDGEMICRO_ENV
,EDGEMICRO_KEY
,EDGEMICRO_SECRET
:echo -n "your-org" | base64 | tr -d '\n'
echo -n "your-org-env" | base64 | tr -d '\n'
echo -n "your-mg-key" | base64 | tr -d '\n'
echo -n "your-mg-secret" | base64 | tr -d '\n'
Wprowadź zmiany w pliku konfiguracji Edge Microgateway dla swojej organizacji i środowiska:
$HOME/.edgemicro/your_org-your_env-config.yaml
Zakoduj dwukrotnie zawartość pliku konfiguracyjnego w Base64:
cat $HOME/.edgemicro/org-env-config.yaml | base64 | tr -d '\n' | base64 | tr -d '\n'
Zastosuj zmiany do Kubernetes w przestrzeni nazw, w której działa Twoja usługa.
kubectl apply -f secret.yaml -n
Te nowe zmiany nie są automatycznie wychwytywane przez istniejące pody mikrobram, ale nowe pody je otrzymają. Możesz usunąć istniejący pod, aby wdrożenie utworzyło nowy pod, który odbierze zmianę.
Przykładowa usługa
Poniższy przykład pokazuje, jak zaktualizować wdrożenie usługi za pomocą nowego
Pobierz pody.
kubectl get pods
Przykładowe dane wyjściowe:
NAME READY STATUS RESTARTS AGE edge-microgateway-57ccc7776b-g7nrg 1/1 Running 0 19h helloworld-6987878fc4-cltc2 1/1 Running 0 1d
Usuń poda
edge-microgateway
.kubectl delete pod edge-microgateway-57ccc7776b-g7nrg
Przykładowe dane wyjściowe:
pod "edge-microgateway-57ccc7776b-g7nrg" deleted
Pobierz pody ponownie. Nowy pod uruchomi się i pobierze zmiany w konfiguracji.
kubectl get pods
Przykładowe dane wyjściowe:
NAME READY STATUS RESTARTS AGE edge-microgateway-57ccc7776b-7f6tc 1/1 Running 0 5s helloworld-6987878fc4-cltc2 1/1 Running 0 1d
Skalowanie wdrożenia
W tej sekcji wyjaśnimy, jak za pomocą zasad skalowania Kubernetes można skalować wdrożenia.
Skalowanie wdrożenia usługi
Sprawdź wdrożenia:
kubectl get deployments
Przykładowe dane wyjściowe:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE edge-microgateway 1 1 1 1 18h helloworld 1 1 1 1 1d
Dane wyjściowe wskazują, że wdrożono 1 replikę.
Skaluj wdrożenie od 1 do dowolnej liczby replik. W tym przykładzie usługa
edge-microgateway
jest skalowana.kubectl scale deployment edge-microgateway --replicas=2
(Opcjonalnie) Jeśli chcesz użyć autoskalowania, użyj tego polecenia:
kubectl autoscale deployment edge-microgateway --cpu-percent=50 --min=1 --max=10
Sprawdź wdrożenia, aby sprawdzić, czy skalowanie jest włączone:
kubectl get deployments
Przykładowe dane wyjściowe:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE edge-microgateway 2 2 2 2 18h helloworld 1 1 1 1 1d
Zmieniono stan, aby uwzględnić 2 repliki.
Sprawdź pody:
kubectl get pods
Przykładowe dane wyjściowe:
NAME READY STATUS RESTARTS AGE edge-microgateway-57ccc7776b-g7nrg 1/1 Running 0 18h edge-microgateway-57ccc7776b-rvfz4 1/1 Running 0 41s helloworld-6987878fc4-cltc2 1/1 Running 0 1d
Dane wyjściowe wskazują, że obie repliki są uruchomione.
Używanie przestrzeni nazw na potrzeby wielu konfiguracji Edge Microgateway
W klastrze Kubernetes możesz wdrożyć i skonfigurować wiele instancji usług Edge Microgateway. W tym przypadku możesz skonfigurować każdą instancję mikrobramy z własnym zestawem wtyczek i parametrów. Na przykład:
- Usługa Edge Microgateway A wymaga tylko wtyczki do zatrzymywania skoku.
- Usługa Edge Microgateway Service B wymaga limitu i wtyczki protokołu OAuth, ale nie wymaga zwiększenia interwału.
Aby rozwiązać ten problem, użyj przestrzeni nazw Kubernetes. Możesz na przykład wdrożyć usługę Edge Microgateway A w przestrzeni nazw foo
, a usługę Edge Microgateway B w przestrzeni nazw bar
.
W poniższym przykładzie mikrobrama Edge skonfigurowana w organizacji OrgA
została wdrożona jako usługa w przestrzeni nazw foo
przy użyciu opcji -n
:
kubectl apply -f <(edgemicroctl -org=myorgA -env=test-key=0e3ecea28a64099410594406b30e54439af5265f8 -sec=e3919250bee37c69cb2e5b41170b488e1c1d -conf=/Users/joed/.edgemicro/orgA-test-config.yaml -svc=samples/helloworld/helloworld.yaml) -n foo
Podobnie w poniższym przykładzie mikrobrama Edge skonfigurowana w organizacji OrgB
jest wdrożona jako usługa w przestrzeni nazw bar
przy użyciu opcji -n
:
kubectl apply -f <(edgemicroctl -org=myorgB -env=test-key=0e3ecea28a64099410594406b30e54439af5265f8 -sec=e3919250bee37c69cb2e5b41170b488e1c1d -conf=/Users/joed/.edgemicro/orgB-test-config.yaml -svc=samples/helloworld/helloworld.yaml) -n bar