Poursuivons notre article autour de l'orchestration de Rancher sur un cluster GKE. Après avoir mis en place une solution de monitoring assez facilement, voyons comment nous allons mettre en place un ou plusieurs services depuis Rancher en s'appuyant sur Helm. Notre cluster Kubernetes a été crée précédemment, il comporte 3 nodes et assez de CPU et de RAM pour déployer et scaler nos apps.

Déployer une app depuis rancher - Wordpress

Pourquoi Wordpress ?

J'en parle finalement assez peu souvent sur ce blog, préférant des moteurs de sites plus light et moins complexe (Base de données notamment). Puis, WP est présent dans le catalogue Helm sur Rancher.

Nous nous rendons donc dans "system" puis "apps", ensuite cliquez sur launch et cherchez Wordpress comme ceci :

Ensuite sur la page de configuration de l'application, modifiez les lignes vous concernant, à savoir nom d'utilisateur (admin par exemple) et son mot de passe, ainsi que les mots de passe des BDD inhérentes (MariaDb) et autres services.

Ensuite déployer, au bout de quelques secondes, Wordpress devrait apparaître comme "active".

Une fois ceci fait, il va falloir mettre en place un service de load balancing pour ouvrir notre service vers l'extérieur avec un DNS choisi et éventuellement un certificat TLS fonctionnel pour que votre site diffuse de l'https sur le web.

Depuis votre terminal, vous allez ajouter un Load Balancer et nous allons utiliser Nginx. Il faut au préalable installer Helm et le configurer. Après un "gcloud init" si besoin pour vous repositionner depuis votre fenêtre du terminal dans Google Cloud, saississez les commandes suivantes :

$ kubectl create serviceaccount tiller --namespace=kube-system
serviceaccount "tiller" created

Puis :

$ kubectl create clusterrolebinding tiller-admin --serviceaccount=kube-system:tiller --clusterrole=cluster-admin
clusterrolebinding.rbac.authorization.k8s.io "tiller-admin" created

Création du Tiller :

$ helm init --service-account=tiller
$HELM_HOME has been configured at /Users/myaccount/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

helm repo update

Le tiller est crée sur le cluster, après avoir mise à jour les repositories, installez Nginx Ingress :

helm install stable/nginx-ingress --name quickstart

Pour trouver l'adresse IP externe :

kubectl --namespace default get services -o wide -w quickstart-nginx-ingress-controller

Ok, nous disposons d'un service d'ingress et d'une adresse IP externe pour diffuser nos services sur le web. désormais nous allons faire pointer WP vers le load balancing nouvellement crée.

Pour commencer, rendez-vous dans la section "workloads" puis sélectionnez "load balancing", ensuite cliquez sur "add ingress".

Choisissons un nom à notre ingress, puis un hostname valide, pour cela ne pas oublier d'enregistrer un A record depuis votre zone DNS valide pour pointer l'adresse IP externe obtenue sur votre cluster (cf. ci-dessus), et le sous-domaine choisi. Pour moi ce sera wp.gsagnard.fr. Ne pas oublier de compléter la zone "target" avec le port souhaité de votre service, ici le port 80 et le service "wordpress-wordpress".

Résultat 

Et voilà, vous disposez d'un service pointant sur un ingress Nginx fonctionnel avec votre DNS, ce qui donne en web :

et :

WP défault

Vous pouvez également constater qu'il est possible de monitorer depuis Rancher vos pods et autres services K8s :

De l'HTTPS ? oh que oui !

Fournir des certificats aux charges de travail de Rancher avec Rancher 2 et leur maintenance nécessite beaucoup d'efforts. Un conteneur avec certbot installé doit être temporairement lié au domaine souhaité (load balancing) pour permettre la vérification de domaine par Let's Encrypt. De plus, les certificats doivent être mis à jour manuellement et régulièrement.

La gestion des certificats peut être automatisée avec cert-manager . Les certificats peuvent être facilement configurés à l'aide du "Contrôleur de gestion des certificats" à l'aide de kubectl. La mise à jour des certificats est alors automatisée.

Cet article présente les paramètres minimum absolus nécessaires à la création d'un certificat.

installation

Pour installer Cert Manager, le catalogue "Helm Stable" doit être activé dans le Rancher sous "Global" -> "Catalogues".

Dans le projet Rancher souhaité, l'application "cert-manager" peut ensuite être sélectionnée et démarrée sous "Catalogue d'applications".

Ce qui donne au bout de quelques minutes :

Configuration

Pour effectuer la configuration, Rancher CLI et Kubectl doivent être installés.

Nous voulions avoir les certificats générés dans tout le cluster ( ClusterIssuer ).

Comme validation, nous choisissons la méthode HTTP01.

Le domaine pour lequel nous voulons générer un certificat s'appelle www.wp.gsagnard.fr dans cet exemple, c'est-à-dire l'adresse de notre site Wordpress.

Étape 1: Créer un clusterIssuer

Un ClusterIssuer doit être créé. Pour cela, nous créons un fichier clusterIssuer.yaml:

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-issuer
  namespace: default
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: cert@www.example.com
    privateKeySecretRef:
      name: letsencrypt-cluster
    http01: {}

Pensez à modifier la ligne email en y ajoutant votre email.

Le ClusterIssuer est généré avec

$ rancher kubectl create -f clusterIssuer.yaml

Vérifiez si le ClusterIssuer est créé correctement:

$ rancher kubectl describe clusterissuer letsencrypt-issuer

Étape 2: Créer un certificat

Un objet de certificat doit être créé. Nous stockons la configuration dans un fichier nommé certificate.yaml:

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: example-com
  namespace: default
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-issuer
    kind: ClusterIssuer
  commonName: www.example.com
  dnsNames:
  - example.com
  - www.example.com
  acme:
    config:
    - http01:
        ingressClass: nginx
      domains:
      - example.com
      - www.example.com

Bien penser à modifier vos lignes "domains" et "dns" par vos propres données, pour moi wp.gsagnard.fr

Transférer la configuration à Rancher:

$ rancher kubectl create -f certificate.yaml

Vérifiez le certificat:

$ rancher kubectl describe certificate example-com

Ce qui donne pour moi :

MBP-de-admin:~ admin$ kubectl describe certificate wp.gsagnard.fr
Name:         wp.gsagnard.fr
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2019-07-31T11:34:20Z
  Generation:          4
  Resource Version:    1878305
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/default/certificates/wp.gsagnard.fr
  UID:                 2354936a-b387-11e9-833c-42010a840184
Spec:
  Acme:
    Config:
      Domains:
        wp.gsagnard.fr
        www.wp.gsagnard.fr
      Http 01:
        Ingress:        
        Ingress Class:  nginx
  Common Name:          www.wp.gsagnard.fr
  Dns Names:
    wp.gsagnard.fr
    www.wp.gsagnard.fr
  Issuer Ref:
    Kind:       ClusterIssuer
    Name:       letsencrypt-issuer
  Secret Name:  wp.gsagnard.fr-tls
Status:
  Acme:
    Order:
      URL:  https://acme-v02.api.letsencrypt.org/acme/order/62464923/812548273
  Conditions:
    Last Transition Time:  2019-07-31T11:35:14Z
    Message:               Certificate issued successfully
    Reason:                CertIssued
    Status:                True
    Type:                  Ready
    Last Transition Time:  <nil>
    Message:               Order validated
    Reason:                OrderValidated
    Status:                False
    Type:                  ValidateFailed
Events:
  Type    Reason          Age    From          Message
  ----    ------          ----   ----          -------
  Normal  CreateOrder     7m11s  cert-manager  Created new ACME order, attempting validation...
  Normal  DomainVerified  6m36s  cert-manager  Domain "www.wp.gsagnard.fr" verified with "http-01" validation
  Normal  DomainVerified  6m23s  cert-manager  Domain "wp.gsagnard.fr" verified with "http-01" validation
  Normal  IssueCert       6m23s  cert-manager  Issuing certificate...
  Normal  CertObtained    6m20s  cert-manager  Obtained certificate from ACME server
  Normal  CertIssued      6m20s  cert-manager  Certificate issued successfully

Étape 3: Utiliser le certificat

Une fois la configuration du Cert-Manager réussie, le certificat doit être visible sous "Ressources" -> "Certificats". Il apparaît avec le nom que nous avons entré sous "secretName" du fichier certificate.yml. Aucun paramètre n'est visible dans les détails du certificat. C'est correct pour la première fois. Cert Manager et Rancher 2.0 ne peuvent pas résoudre le problème mieux.

Sous "Workloads" -> "Load Balancing" -> Dans l'entrée souhaitée sous "Certificats SSL / TLS", le nouveau certificat généré peut être sélectionné. Sous "Hosts", vous devez en outre entrer les mêmes noms d'hôte que vous avez configurés pour la génération du certificat.

Et qui donne en web :

Avec d'autres services ? aucun soucis

On peut évidemment reproduire ce schéma à l'infini sur notre cluster en prod' en déployant plusieurs autres applications vers le web tout en les sécurisant en https grâce à Cert-Manager. Rancher va nous permettre l'orchestration de ces services en limitant le nombre d'opérations manuelles dans le terminal notamment.

Par exemple avec Ghost :

on commence par un workload dans le namespace souhaité du cluster

Ne pas oublier :

  • créer un A record dans votre zone DNS pour le sous-domaine choisi
  • y copier l'adresse IP publique du cluster

On crée un deuxième fichier de certificat identique au premier mais avec une dénomination différente du fichier, par exemple certif.yaml, et sans oublier de modifier les domains et DNS correspondants.

MBP-de-admin:~ admin$ kubectl create -f certificate.yml

Et on cherche la description du certificat au bout de quelques minutes :

MBP-de-admin:~ admin$ kubectl describe certificate example-com
Name:         example-com
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2019-08-02T16:03:21Z
  Generation:          3
  Resource Version:    2564247
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/default/certificates/example-com
  UID:                 0cfefc75-b53f-11e9-833c-42010a840184
Spec:
  Acme:
    Config:
      Domains:
        example.gsagnard.fr
        www.example.gsagnard.fr
      Http 01:
        Ingress:        
        Ingress Class:  nginx
  Common Name:          www.example.gsagnard.fr
  Dns Names:
    example.gsagnard.fr
    www.example.gsagnard.fr
  Issuer Ref:
    Kind:       ClusterIssuer
    Name:       letsencrypt-issuer
  Secret Name:  example-com-tls
Status:
  Acme:
    Order:
      URL:  https://acme-v02.api.letsencrypt.org/acme/order/62464923/824941461
  Conditions:
    Last Transition Time:  2019-08-02T16:04:48Z
    Message:               Certificate issued successfully
    Reason:                CertIssued
    Status:                True
    Type:                  Ready
    Last Transition Time:  <nil>
    Message:               Order validated
    Reason:                OrderValidated
    Status:                False
    Type:                  ValidateFailed
Events:
  Type    Reason          Age    From          Message
  ----    ------          ----   ----          -------
  Normal  CreateOrder     6m35s  cert-manager  Created new ACME order, attempting validation...
  Normal  DomainVerified  5m21s  cert-manager  Domain "www.example.gsagnard.fr" verified with "http-01" validation
  Normal  IssueCert       5m21s  cert-manager  Issuing certificate...
  Normal  CertObtained    5m18s  cert-manager  Obtained certificate from ACME server
  Normal  CertIssued      5m18s  cert-manager  Certificate issued successfully

Et au bout de quelques secondes, le certificat apparait dans Rancher, que l'on peut alors attribuer à notre load balancing Ghost nouvellement crée comme pour Wordpress précédemment.

Conclusion

Voici un exemple assez simple à mettre en place pour orchestrer vos services tout en les monitorant à l'aide des outils fournis par Kubernetes et Rancher. Nous verrons dans la troisième et dernière partie, comment déployer d'autres services qui peuvent s'avérer utiles pour l'analyse de nos sites.