Aller au contenu principal

Exposition et domaines

Disponible

Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.

Ajoutez ingress à un service pour le rendre joignable en HTTPS depuis Internet. Sans rien préciser, il répond sur https://<service>-<app>.<tenant>.dev.stackngo.app/ avec un certificat obtenu automatiquement.

Prérequis​

  • Un service de kind deployment qui déclare au moins un port TCP.
  • Rien côté DNS : votre zone <tenant>.dev.stackngo.app est déjà servie par la plateforme.

Étapes​

1. Exposer le service​

web.yml
apiVersion: deploy.stackngo.io/v1alpha1
kind: App
metadata:
name: web
spec:
services:
web:
image: nginxinc/nginx-unprivileged:1.27
ports: ["8080"]
ingress: { port: 8080 } # https://web-web.<tenant>.dev.stackngo.app/
healthcheck: { http: /, port: 8080 }
sng apply web.yml

En ligne de commande : sng app create web --image nginxinc/nginx-unprivileged:1.27 --port 8080 --ingress (ou --ingress=8080 pour choisir le port parmi plusieurs).

2. Attendre le certificat​

sng app describe web
App : web
Statut : prête
SERVICE KIND IMAGE PHASE URL DETAIL
web deployment nginxinc/nginx-unprivileged:1.27 Ready https://web-web.<tenant>.dev.stackngo.app/ Reconciled 1/1 prêts

Un service exposé n'est Ready qu'une fois ses conteneurs prêts et son certificat HTTPS émis (en général moins d'une minute après). Entre les deux, il reste en Progressing avec la raison CertificatePending :

SERVICE KIND IMAGE PHASE URL DETAIL
web deployment nginxinc/nginx-unprivileged:1.27 Progressing https://web-web.<tenant>.dev.stackngo.app/ CertificatePending Le certificat HTTPS de l'App est en cours d'émission

Quand le service passe Ready, son URL répond avec un certificat valide. Les services qui dépendent de lui (dependsOn) démarrent sans attendre le certificat.

Vérification​

curl -sI https://web-web.<tenant>.dev.stackngo.app/

HTTP/2 200, certificat Let's Encrypt valide.

Les champs de ingress​

ChampDéfautRôle
portpremier port TCP de portsport du service qui reçoit le trafic ; doit figurer dans ports
path/préfixe de chemin servi (/api sert /api et tout ce qui est dessous)
domain<service>-<app>.<tenant>.dev.stackngo.appnom d'hôte, parmi ceux que vous avez le droit d'utiliser

Un service exposé reste joignable par les autres services de l'App sur ses ports ; depuis Internet, seul le port de ingress est ouvert.

Choisir un nom d'hôte​

Votre zone par défaut​

Chaque tenant possède la zone <tenant>.dev.stackngo.app. Vous pouvez y choisir n'importe quel nom à un seul niveau : shop.<tenant>.dev.stackngo.app, api-v2.<tenant>.dev.stackngo.app.

ingress: { port: 8080, domain: shop.<tenant>.dev.stackngo.app }

Remplacez <tenant> par le nom de votre tenant (sng config show). Un nom sous la zone d'un autre client, ou un domaine de la plateforme, est refusé dès l'apply :

Error: ingress.domain "…" : réservé à la plateforme ou à un autre client

Un autre domaine, le vôtre, se déclare comme domaine apporté.

Noms réservés​

status.<tenant>.dev.stackngo.app est réservé à vos pages de statut. Un service qui le demande passe Failed, raison DomainNotAllowed (réservé à la plateforme (status pages)).

Vos propres domaines​

Bêta

Fonctionnalité en cours de déploiement. L'interface décrite ici est celle de la prochaine livraison : elle peut encore évoluer, et n'est pas forcément activée sur votre tenant.

Activée progressivement sur les tenants.

Avec les domaines apportés, vous servirez une App sous un domaine qui vous appartient (www.exemple.fr, ou l'apex exemple.fr). Vous pouvez déclarer le domaine avant que sa zone soit prête : le service attend, puis se publie seul. Dans cette version, les règles évoluent aussi pour votre zone par défaut :

  • un nom à toute profondeur sous <tenant>.dev.stackngo.app devient permis (a.b.<tenant>.dev.stackngo.app), l'apex de la zone restant exclu ;
  • un domaine apporté est utilisable à son apex ou dessous dès que sa zone est publiée (le certificat suit une fois la zone Active) ;
  • quelques noms techniques réservés au fonctionnement de la plateforme (notamment ceux qui commencent par _) sont refusés partout, en plus de status.<zone par défaut>.

Le mode d'emploi complet : Domaines sur une App.

TLS automatique​

Chaque adresse exposée reçoit un certificat Let's Encrypt, renouvelé par la plateforme. Rien à configurer. HTTP sans TLS n'est pas proposé : l'URL affichée dans status est toujours en https://.

Conflits de nom d'hôte (HostConflict)​

Un nom d'hôte appartient à un seul tenant, et dans un tenant, un couple hôte + chemin appartient à une seule App :

SituationRésultat
Le même hôte est déjà servi par un autre tenantservice Failed, HostConflict : le host … est déjà utilisé …
Une autre App de votre tenant sert déjà cet hôte sur le même pathFailed, HostConflict : <host><path> est déjà servi …
Une autre App de votre tenant sert cet hôte sur un autre pathaccepté : deux Apps peuvent se partager un hôte par chemin
Deux services de la même App sur le même hôte et le même cheminnon détecté : lequel répond n'est pas défini ; donnez-leur des path différents
Le nom est déjà publié dans le DNS par quelqu'un d'autre (un DNSRecord du même nom, par exemple)service Failed, DNSConflict : Le nom de domaine … est déjà utilisé : l'App n'est pas joignable à cette adresse tant qu'il n'est pas libéré

Correction : changez le nom du service, de l'App, le domain ou le path, puis sng apply. Pour DNSConflict, vous pouvez aussi libérer le nom (supprimer l'enregistrement qui le porte) : le service se rétablit de lui-même, sans nouveau sng apply.

Retirer l'exposition​

Supprimez ingress du manifeste et appliquez, ou sng app patch web --ingress-port 0. En moins d'une minute, l'adresse ne répond plus et son certificat est retiré.

Pour aller plus loin​

  • Le nom d'hôte est comparé en minuscules ; écrivez-le en minuscules.
  • path est un préfixe : /api capte /api/v1/users. Pour servir plusieurs services sous un même hôte, donnez à chacun le même domain et un path différent.
  • Un service job ou cronjob ne peut pas être exposé (le schéma refuse ingress).

Voir aussi​