Vytvoření kontroleru příchozího přenosu dat se statickou veřejnou IP adresou ve službě Azure Kubernetes Service (AKS)

Kontroler příchozího přenosu dat je softwarový software, který poskytuje reverzní proxy, konfigurovatelné směrování provozu a ukončení protokolu TLS pro služby Kubernetes Services. Kubernetes příchozí prostředky se používají ke konfiguraci pravidel příchozího přenosu dat a tras pro jednotlivé služby Kubernetes. Pomocí řadiče příchozího přenosu dat a pravidel příchozího přenosu dat se dá jedna IP adresa používat ke směrování provozu do několika služeb v clusteru Kubernetes.

V tomto článku se dozvíte, jak nasadit řadič Nginx příchozího přenosu do clusteru Azure Kubernetes Service (AKS). Kontroler příchozího přenosu dat je nakonfigurovaný se statickou veřejnou IP adresou. Projekt Správce certifikátů se používá k automatickému generování a konfiguraci certifikátů, které umožňují šifrování . Nakonec se dvě aplikace spouští v clusteru AKS, z nichž každá je přístupná přes jednu IP adresu.

Můžete také:

• Vytvoření základního kontroleru příchozího přenosu dat s připojením k externí síti
• Povolit doplněk směrování aplikace HTTP
• Vytvoření kontroleru příchozího přenosu dat, který používá vaše vlastní certifikáty TLS
• Vytvořte kontroler příchozího přenosu dat, který pomocí šifry umožňuje automaticky generovat certifikáty TLS s dynamickou veřejnou IP adresou.

Než začnete

V tomto článku se předpokládá, že máte existující cluster AKS. Pokud potřebujete cluster AKS, přečtěte si rychlý Start AKS a použijte Azure CLI nebo Azure Portal.

Tento článek používá Helm 3 k instalaci kontroleru Nginx pro příchozí přenos dat na podporovanou verzi Kubernetes. Ujistěte se, že používáte nejnovější verzi Helm a máte přístup k úložištím Nginx a jetstack Helm. Kroky popsané v tomto článku nemusí být kompatibilní s předchozími verzemi grafu Helm, NGINX pro příchozí nebo Kubernetes.

Další informace o konfiguraci a použití Helm najdete v tématu install Applications with Helm in Azure Kubernetes Service (AKS). Pokyny k upgradu najdete v dokumentaci k instalaci Helm.

Tento článek také vyžaduje, abyste spustili Azure CLI verze 2.0.64 nebo novější. Verzi zjistíte spuštěním příkazu az --version. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.

Kromě toho tento článek předpokládá, že máte existující cluster AKS s integrovaným ACR. Další informace o vytvoření clusteru AKS s integrovaným ACR najdete v tématu ověřování pomocí Azure Container Registry ze služby Azure Kubernetes Service.

Import imagí používaných grafem Helm do ACR

V tomto článku se používá graf Helm kontroleru Nginxpříchozího přenosu dat, který spoléhá na tři image kontejneru. Použijte az acr import k importu těchto imagí do ACR.

REGISTRY_NAME=<REGISTRY_NAME>
CONTROLLER_REGISTRY=k8s.gcr.io
CONTROLLER_IMAGE=ingress-nginx/controller
CONTROLLER_TAG=v1.0.4
PATCH_REGISTRY=docker.io
PATCH_IMAGE=jettech/kube-webhook-certgen
PATCH_TAG=v1.5.2
DEFAULTBACKEND_REGISTRY=k8s.gcr.io
DEFAULTBACKEND_IMAGE=defaultbackend-amd64
DEFAULTBACKEND_TAG=1.5
CERT_MANAGER_REGISTRY=quay.io
CERT_MANAGER_TAG=v1.5.4
CERT_MANAGER_IMAGE_CONTROLLER=jetstack/cert-manager-controller
CERT_MANAGER_IMAGE_WEBHOOK=jetstack/cert-manager-webhook
CERT_MANAGER_IMAGE_CAINJECTOR=jetstack/cert-manager-cainjector

az acr import --name $REGISTRY_NAME --source $CONTROLLER_REGISTRY/$CONTROLLER_IMAGE:$CONTROLLER_TAG --image $CONTROLLER_IMAGE:$CONTROLLER_TAG
az acr import --name $REGISTRY_NAME --source $PATCH_REGISTRY/$PATCH_IMAGE:$PATCH_TAG --image $PATCH_IMAGE:$PATCH_TAG
az acr import --name $REGISTRY_NAME --source $DEFAULTBACKEND_REGISTRY/$DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG --image $DEFAULTBACKEND_IMAGE:$DEFAULTBACKEND_TAG
az acr import --name $REGISTRY_NAME --source $CERT_MANAGER_REGISTRY/$CERT_MANAGER_IMAGE_CONTROLLER:$CERT_MANAGER_TAG --image $CERT_MANAGER_IMAGE_CONTROLLER:$CERT_MANAGER_TAG
az acr import --name $REGISTRY_NAME --source $CERT_MANAGER_REGISTRY/$CERT_MANAGER_IMAGE_WEBHOOK:$CERT_MANAGER_TAG --image $CERT_MANAGER_IMAGE_WEBHOOK:$CERT_MANAGER_TAG
az acr import --name $REGISTRY_NAME --source $CERT_MANAGER_REGISTRY/$CERT_MANAGER_IMAGE_CAINJECTOR:$CERT_MANAGER_TAG --image $CERT_MANAGER_IMAGE_CAINJECTOR:$CERT_MANAGER_TAG

Vytvoření kontroleru příchozího přenosu dat

Ve výchozím nastavení se kontroler NGINX příchozího přenosu dat vytvoří pomocí nového přiřazení veřejné IP adresy. Tato veřejná IP adresa je statická jenom pro životní cyklus řadiče příchozího přenosu dat a při odstranění a opětovném vytvoření kontroleru se ztratí. Běžným požadavkem na konfiguraci je poskytnout řadiči příchozí sítě NGINX stávající statickou veřejnou IP adresu. Pokud se kontroler příchozího přenosu odstraní, statická veřejná IP adresa zůstane. Tento přístup vám umožní v rámci životního cyklu vašich aplikací používat existující záznamy DNS a konfigurace sítě konzistentním způsobem.

Pokud potřebujete vytvořit statickou veřejnou IP adresu, nejprve pomocí příkazu AZ AKS show načtěte název skupiny prostředků clusteru AKS.

az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv

V dalším kroku vytvořte veřejnou IP adresu s metodou statického přidělení pomocí příkazu AZ Network Public-IP Create . Následující příklad vytvoří veřejnou IP adresu s názvem myAKSPublicIP ve skupině prostředků clusteru AKS, kterou jste získali v předchozím kroku:

az network public-ip create --resource-group MC_myResourceGroup_myAKSCluster_eastus --name myAKSPublicIP --sku Standard --allocation-method static --query publicIp.ipAddress -o tsv

Teď nasaďte Nginx a vstupní graf s Helm. Pro přidání redundance se nasadí dvě repliky kontrolerů příchozího přenosu dat NGINX s parametrem --set controller.replicaCount. Pokud chcete mít v clusteru AKS k dispozici více než jeden uzel, zajistěte, aby bylo možné plně využít více uzlů.

Popisek IP adresy a DNS

Do vydaných verzí musíte předat dva další parametry, takže kontroler příchozího přenosu dat (Helm) bude mít na paměti, že obě statické IP adresy nástroje pro vyrovnávání zatížení budou přiděleny službě příchozího řadiče domény a popisek názvu DNS, který se použije u prostředku veřejné IP adresy. Aby certifikáty HTTPS správně fungovaly, použije se k nakonfigurování plně kvalifikovaného názvu domény pro IP adresu kontroleru příchozího přenosu názvů DNS.

1. Přidejte --set controller.service.loadBalancerIP parametr. Zadejte vlastní veřejnou IP adresu vytvořenou v předchozím kroku.
2. Přidejte --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name" parametr. Zadejte popisek názvu DNS, který se použije pro veřejnou IP adresu vytvořenou v předchozím kroku. Tento popisek vytvoří název DNS formuláře. <LABEL>.<AZURE REGION NAME>.cloudapp.azure.com

Kontroler příchozího přenosu dat je potřeba naplánovat také v uzlu Linuxu. V uzlech Windows Serveru by se kontroler příchozího přenosu dat neměl spouštět. Selektor uzlů se specifikuje pomocí parametru --set nodeSelector, aby plánovači Kubernetes oznámil, že má spustit kontroler příchozího přenosu dat NGINX v uzlu Linuxu.

Aktualizujte následující skript s použitím IP adresy vašeho kontroleru příchozího přenosu dat a jedinečného názvu , který byste chtěli použít pro předponu plně kvalifikovaného názvu domény.

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

# Set variable for ACR location to use for pulling images
ACR_URL=<REGISTRY_URL>
STATIC_IP=<STATIC_IP>
DNS_LABEL=<DNS_LABEL>

# Use Helm to deploy an NGINX ingress controller
helm install nginx-ingress ingress-nginx/ingress-nginx \
    --namespace ingress-basic --create-namespace \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.image.registry=$ACR_URL \
    --set controller.image.image=$CONTROLLER_IMAGE \
    --set controller.image.tag=$CONTROLLER_TAG \
    --set controller.image.digest="" \
    --set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.admissionWebhooks.patch.image.registry=$ACR_URL \
    --set controller.admissionWebhooks.patch.image.image=$PATCH_IMAGE \
    --set controller.admissionWebhooks.patch.image.tag=$PATCH_TAG \
    --set controller.admissionWebhooks.patch.image.digest="" \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set defaultBackend.image.registry=$ACR_URL \
    --set defaultBackend.image.image=$DEFAULTBACKEND_IMAGE \
    --set defaultBackend.image.tag=$DEFAULTBACKEND_TAG \
    --set defaultBackend.image.digest="" \
    --set controller.service.loadBalancerIP=$STATIC_IP \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-dns-label-name"=$DNS_LABEL

Když se pro kontroler příchozího přenosu NGINX vytvoří služba Vyrovnávání zatížení Kubernetes, vaše statická IP adresa se přiřadí, jak je znázorněno v následujícím příkladu výstupu:

$ kubectl --namespace ingress-basic get services -o wide -w nginx-ingress-ingress-nginx-controller

NAME                                     TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE   SELECTOR
nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.74.133   EXTERNAL_IP     80:32486/TCP,443:30953/TCP   44s   app.kubernetes.io/component=controller,app.kubernetes.io/instance=nginx-ingress,app.kubernetes.io/name=ingress-nginx

Zatím se nevytvořila žádná pravidla příchozího přenosu dat, takže pokud přejdete na veřejnou IP adresu, zobrazí se 404 výchozí stránka NGINX adaptéru pro příjem dat. Pravidla příchozího přenosu dat jsou nakonfigurovaná v následujících krocích.

Pomocí dotazu na plně kvalifikovaný název domény na veřejné IP adrese můžete ověřit, že je popisek názvu DNS použit následujícím způsobem:

az network public-ip list --resource-group MC_myResourceGroup_myAKSCluster_eastus --query "[?name=='myAKSPublicIP'].[dnsSettings.fqdn]" -o tsv

Kontroler příchozího přenosu dat je teď přístupný prostřednictvím IP adresy nebo plně kvalifikovaného názvu domény.

Instalace nástroje cert-manager

Kontroler příchozího přenosu dat NGINX podporuje ukončení protokolu TLS. Existuje několik způsobů, jak načíst a nakonfigurovat certifikáty pro protokol HTTPS. V tomto článku se dozvíte, jak používat Správce certifikátů, který umožňuje automatické šifrování generování certifikátů a funkcí správy.

Pokud chcete nainstalovat kontrolér správce certifikátů do clusteru s podporou Kubernetes RBAC, použijte následující helm install příkaz:

# Label the cert-manager namespace to disable resource validation
kubectl label namespace ingress-basic cert-manager.io/disable-validation=true

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install cert-manager jetstack/cert-manager \
  --namespace ingress-basic \
  --version $CERT_MANAGER_TAG \
  --set installCRDs=true \
  --set nodeSelector."kubernetes\.io/os"=linux \
  --set image.repository=$ACR_URL/$CERT_MANAGER_IMAGE_CONTROLLER \
  --set image.tag=$CERT_MANAGER_TAG \
  --set webhook.image.repository=$ACR_URL/$CERT_MANAGER_IMAGE_WEBHOOK \
  --set webhook.image.tag=$CERT_MANAGER_TAG \
  --set cainjector.image.repository=$ACR_URL/$CERT_MANAGER_IMAGE_CAINJECTOR \
  --set cainjector.image.tag=$CERT_MANAGER_TAG 

Další informace o konfiguraci Správce certifikátů najdete v projektu správce certifikátů.

Vytvoření vystavitele clusteru certifikační autority

Než bude možné certifikáty vystavit, správce certifikátů vyžaduje prostředek vystavitele nebo ClusterIssuer . Tyto Kubernetes prostředky jsou identické ve fungování, ale Issuer fungují v jednom oboru názvů a ClusterIssuer fungují napříč všemi obory názvů. Další informace najdete v dokumentaci vystavitele správce certifikátů .

Vytvořte Vystavitel clusteru, například cluster-issuer.yaml , pomocí následujícího ukázkového manifestu. Aktualizujte e-mailovou adresu platnou adresou z vaší organizace:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: user@contoso.com
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
    - http01:
        ingress:
          class: nginx
          podTemplate:
            spec:
              nodeSelector:
                "kubernetes.io/os": linux

K vytvoření vystavitele použijte kubectl apply příkaz.

kubectl apply -f cluster-issuer.yaml --namespace ingress-basic

Výstup by měl vypadat podobně jako v tomto příkladu:

clusterissuer.cert-manager.io/letsencrypt-staging created

Spustit ukázkové aplikace

Je nakonfigurovaný kontroler příchozího přenosu dat a řešení správy certifikátů. Teď spustíme dvě ukázkové aplikace v clusteru AKS. V tomto příkladu se Helm používá k nasazení dvou instancí jednoduché aplikace Hello World.

Pokud chcete zobrazit kontroler příchozího přenosu v akci, spusťte dvě ukázkové aplikace v clusteru AKS. V tomto příkladu můžete použít kubectl apply k nasazení dvou instancí jednoduché aplikace Hello World .

Vytvořte soubor AKS-Hello. yaml a zkopírujte ho do následujícího příkladu YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld
spec:
  replicas: 1
  selector:
    matchLabels:
      app: aks-helloworld
  template:
    metadata:
      labels:
        app: aks-helloworld
    spec:
      containers:
      - name: aks-helloworld
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "Welcome to Azure Kubernetes Service (AKS)"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: aks-helloworld

Vytvořte soubor . yaml s příchozím demo a zkopírujte do něj následující příklad YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ingress-demo
  template:
    metadata:
      labels:
        app: ingress-demo
    spec:
      containers:
      - name: ingress-demo
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        env:
        - name: TITLE
          value: "AKS Ingress Demo"
---
apiVersion: v1
kind: Service
metadata:
  name: ingress-demo
spec:
  type: ClusterIP
  ports:
  - port: 80
  selector:
    app: ingress-demo

Spusťte dvě ukázkové aplikace pomocí kubectl apply :

kubectl apply -f aks-helloworld.yaml --namespace ingress-basic
kubectl apply -f ingress-demo.yaml --namespace ingress-basic

Vytvoření trasy příchozího přenosu dat

Obě aplikace jsou teď spuštěné v clusteru Kubernetes, ale nakonfigurují se se službou typu ClusterIP . Aplikace proto nejsou přístupné z Internetu. Pokud je chcete zpřístupnit veřejnosti, vytvořte Kubernetes prostředek příchozího přenosu dat. Prostředek příchozího přenosu dat konfiguruje pravidla, která směrují provoz do jedné z těchto dvou aplikací.

V následujícím příkladu je přenos do adresy https://demo-aks-ingress.eastus.cloudapp.azure.com/ směrován do služby s názvem aks-helloworld . Provoz na adresu https://demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two je směrován do ingress-demo služby. Aktualizujte hostitele a hostitele na název DNS, který jste vytvořili v předchozím kroku.

Vytvořte soubor s názvem hello-world-ingress.yaml a zkopírujte ho do následujícího příkladu YAML.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-staging
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  tls:
  - hosts:
    - demo-aks-ingress.eastus.cloudapp.azure.com
    secretName: tls-secret
  rules:
  - host: demo-aks-ingress.eastus.cloudapp.azure.com
    http:
      paths:
      - path: /hello-world-one(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld
            port:
              number: 80
      - path: /hello-world-two(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: ingress-demo
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: aks-helloworld
            port:
              number: 80

Pomocí příkazu vytvořte prostředek příchozího přenosu dat kubectl apply .

kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic

Výstup by měl vypadat podobně jako v tomto příkladu:

ingress.extensions/hello-world-ingress created

Ověřit objekt certifikátu

V dalším kroku se musí vytvořit prostředek certifikátu. Prostředek certifikátu definuje požadovaný certifikát X. 509. Další informace najdete v tématu certifikáty pro správcecertifikátů.

Správce certifikátů pravděpodobně pro vás automaticky vytvořil objekt certifikátu pomocí příchozího překrytí, které se automaticky nasazuje pomocí nástroje CERT Manager od verze v 0.2.2. Další informace najdete v dokumentaci ke vstupnímu překrytí.

Chcete-li ověřit, zda byl certifikát vytvořen úspěšně, použijte kubectl describe certificate tls-secret --namespace ingress-basic příkaz.

Pokud byl certifikát vystavený, zobrazí se výstup podobný následujícímu:

Type    Reason          Age   From          Message
----    ------          ----  ----          -------
  Normal  CreateOrder     11m   cert-manager  Created new ACME order, attempting validation...
  Normal  DomainVerified  10m   cert-manager  Domain "demo-aks-ingress.eastus.cloudapp.azure.com" verified with "http-01" validation
  Normal  IssueCert       10m   cert-manager  Issuing certificate...
  Normal  CertObtained    10m   cert-manager  Obtained certificate from ACME server
  Normal  CertIssued      10m   cert-manager  Certificate issued successfully

Test konfigurace příchozího přenosu dat

Otevřete webový prohlížeč s plně kvalifikovaným názvem domény vašeho kontroleru Kubernetes příchozího přenosu dat, například https://demo-aks-ingress.eastus.cloudapp.azure.com .

Jak tyto příklady používají letsencrypt-staging , vydaný certifikát TLS/SSL není v prohlížeči důvěryhodný. Přijměte výzvu k zadání upozornění, abyste mohli pokračovat v používání aplikace. Informace o certifikátu zobrazí tento falešný certifikát x1 pro Intermediate , který je vydaný pomocí zašifrování. Tento falešný certifikát indikuje cert-manager správné zpracování žádosti a obdržel certifikát od poskytovatele:

Když změníte šifrování tak, aby se prod místo toho používal staging důvěryhodný certifikát vydaný pomocí šifry, jak je znázorněno v následujícím příkladu:

Ukázková aplikace se zobrazí ve webovém prohlížeči:

Nyní přidejte cestu /Hello-World-Two k plně kvalifikovanému názvu domény, například https://demo-aks-ingress.eastus.cloudapp.azure.com/hello-world-two . Zobrazí se druhá ukázková aplikace s vlastním názvem:

Vyčištění prostředků

Tento článek používá Helm k instalaci komponent příchozího přenosu dat, certifikátů a ukázkových aplikací. Když nasadíte graf Helm, vytvoří se několik prostředků Kubernetes. Tyto prostředky zahrnují lusky, nasazení a služby. Chcete-li vyčistit tyto prostředky, můžete buď odstranit celý vzorový obor názvů, nebo jednotlivé prostředky.

Odstranění ukázkového oboru názvů a všech prostředků

Chcete-li odstranit celý vzorový obor názvů, použijte kubectl delete příkaz a zadejte název oboru názvů. Všechny prostředky v oboru názvů jsou odstraněny.

kubectl delete namespace ingress-basic

Odstranit prostředky jednotlivě

Další možností je podrobnější přístup k odstranění jednotlivých vytvořených prostředků. Nejdřív odeberte prostředky certifikátu:

kubectl delete -f certificates.yaml
kubectl delete -f cluster-issuer.yaml

Teď seznam vydaných verzí Helm pomocí helm list příkazu. Vyhledejte grafy s názvem Nginx- příchozí a CERT-Manager , jak je znázorněno v následujícím příkladu výstupu:

$ helm list --all-namespaces

NAME                    NAMESPACE       REVISION        UPDATED                        STATUS          CHART                   APP VERSION
nginx-ingress           ingress-basic   1               2020-01-11 14:51:03.454165006  deployed        nginx-ingress-1.28.2    0.26.2
cert-manager            ingress-basic   1               2020-01-06 21:19:03.866212286  deployed        cert-manager-v0.13.0    v0.13.0

Odinstalujte verze pomocí helm uninstall příkazu. Následující příklad odinstaluje nasazení NGINX příchozího přenosu a nasazení Správce certifikátů.

$ helm uninstall nginx-ingress cert-manager -n ingress-basic

release "nginx-ingress" deleted
release "cert-manager" deleted

Dále odeberte dvě ukázkové aplikace:

kubectl delete -f aks-helloworld.yaml --namespace ingress-basic
kubectl delete -f ingress-demo.yaml --namespace ingress-basic

Odstraňte vlastní obor názvů. Použijte kubectl delete příkaz a zadejte název vašeho oboru názvů:

kubectl delete namespace ingress-basic

Nakonec Odeberte statickou veřejnou IP adresu vytvořenou pro kontroler příchozího přenosu dat. Zadejte název skupiny prostředků clusteru MC_ získané v prvním kroku tohoto článku, například MC_myResourceGroup_myAKSCluster_eastus:

az network public-ip delete --resource-group MC_myResourceGroup_myAKSCluster_eastus --name myAKSPublicIP

Další kroky

Tento článek obsahuje některé externí komponenty, které se AKS. Další informace o těchto komponentách naleznete na následujících stránkách projektu:

• Helm CLI
• Kontroler NGINX pro příchozí přenosy
• cert-manager

Můžete také:

• Vytvoření základního kontroleru příchozího přenosu dat s připojením k externí síti
• Povolit doplněk směrování aplikace HTTP
• Vytvoření kontroleru příchozího přenosu dat, který používá interní privátní síť a IP adresu
• Vytvoření kontroleru příchozího přenosu dat, který používá vaše vlastní certifikáty TLS
• Vytvoření kontroleru příchozího přenosu dat s dynamickou veřejnou IP adresou a konfigurací šifry pro automatické generování certifikátů TLS