Routage HTTP

Le routage HTTP ainsi que la gestion du nom de domaine public de l’application et la couche TLS sont gérés par un reverse-proxy.

En effet, le workflow ne permet pas d’exposer publiquement vos conteneurs : les instances Docker ne tournent pas sur un serveur public.

Bearstech met en place le reverse-proxy qui a une IP publique et communique avec vos conteneurs sur les ports définis dans le docker-compose. Nous pouvons utiliser Nginx, Apache ou HAProxy pour se charger du routage HTTP, ainsi que de la répartition de charge, quand il y a plusieurs instances d’un même service avec les mêmes règles.

Définir le domaine #

Pour spécifier l’url finale qui vous permet de joindre votre applications, il suffit de mentionner le domaine à utiliser en argument dans l’appel au service de déploiement : script: deploy my-super-site.com (dans le cas d’un environnement mono-site, pas besoin de le spécifier)

Gestion des certificats #

Pour le reste (aliases, certificats SSL…) le workflow permet d’utiliser les variables d’environnement de Gitlab:

• DEPLOY_ALIASES: domains utilisés comme aliases (les redirections adéquates sont à gérer dans votre .htaccess)
• DEPLOY_TLS_MODE: mode TLS (none, letsencrypt ou manual), defaut à none (certificat snakeoil)
• DEPLOY_TLS_CERTIFICATE: certificat à utiliser si TLS_MODE est défini à manual (defaut à /etc/ssl/certs/DOMAIN.TLD.crt)
• DEPLOY_TLS_KEY: fichier clef à utiliser si TLS_MODE est défini à manual (defaut à /etc/ssl/private/DOMAIN.TLD.key)
• DEPLOY_TLS_CHAIN: chaîne de certificats à utiliser si TLS_MODE est défini à manual (defaut à /etc/ssl/certs/DOMAIN.TLD.chain)