CérénIT

L’objectif est de s’appuyer sur Cert-Manager pour la génération et le stockage des certificats Let’s Encrypt qui seront utilisés par Traefik. L’idée est de stocker ces certificats sous la forme de secrets et de ne plus avoir à provisionner un volume pour les stocker.

Installons déjà cert-manager :

# Create a namespace for cert-manager
kubectl create ns cert-manager
# Install cert-manager via helm
helm install \
    --name cert-manager \
    --namespace cert-manager \
    stable/cert-manager

Nous allons ensuite devoir créer un Issuer dans chaque namespace pour avoir un générateur de certificats propre à chaque namespace. Cela est notamment du au fait que Traefik s’attend à ce que le secret et l’ingress utilisant ce secret soient dans le même namespace.

cert-manager/issuer.yml:

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: user@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable HTTP01 validations
    http01: {}

Puis créons le “issuer” dans la/les namespace(s) voulu(s) :

# Create issuer in a given namespace
kubectl create -n <namespace> -f issuer.yml

Notre contexte de déploiement utilisant Traefik comme ingress, je remets ci-dessous la configuration que j’utilise avec les ajustements nécessaires pour l’utilisation de cert-manager. Il n’est en effet plus possible et il devient désormais inutile de déclarer la section “acme” dans traefik.toml. J’ai aussi supprimé la redirect automatique http vers https, il faudra la gérer au niveau des ingress.

Créons le namespace traefik :

# Create namespace
kubectl create ns traefik
# Change context to this namespace so that all commands are by default run for this namespace
# see https://github.com/ahmetb/kubectx
kubens traefik

Commençons par traefik/rbac.yml - le fichier défini le compte de service (Service Account), le rôle au niveau du cluster (Cluster Role) et la liaison entre le rôle et le compte de service (Cluster Role Binding)

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-ingress-controller
  namespace: traefik
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: traefik

Ensuite, pour Traefik, j’ai besoin d’un fichier traefik.toml avec la configuration que je mets à disposition sous la forme d’une ConfigMap dans un fichier traefik/traefik-toml-configmap.yml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-conf
data:
  traefik.toml: |
    defaultEntryPoints = ["http", "https"]

    logLevel = "INFO"

    insecureSkipVerify = true

    [entryPoints]
      [entryPoints.http]
        address = ":80"
      [entryPoints.https]
        address = ":443"
        [entryPoints.https.tls]
      [entryPoints.api]
        address = ":8080"

    [api]
    entryPoint = "api"
    dashboard = true
    debug = false

    [kubernetes]

Le dashboard est à protéger par une authentification pour éviter tout accès non souhaité. Je l’ai supprimé de la configuration par simplicité.

Je peux donc enfin déployer Traefik via le fichier traefik/traefik-deployment.yml :

---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-controller
  labels:
    k8s-app: traefik-ingress-lb
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: traefik-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:1.7.7
        name: traefik-ingress-lb
        volumeMounts:
        - mountPath: /config
          name: traefik-config
        ports:
        - name: http
          containerPort: 80
        - name: admin
          containerPort: 8080
        - name: secure
          containerPort: 443
        args:
        - --configfile=/config/traefik.toml
      volumes:
        - name: traefik-config
          configMap:
            name: traefik-conf

Nous déployons donc :

  • Traefik en Deployment
  • Les ports 80, 443 et 8080 sont définis
  • La configuration est une ConfigMap

Pour permettre au cluster d’accéder aux différents ports, il faut définir un service via le fichier traefik-service-clusterip.yml :

---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-clusterip
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin
    - protocol: TCP
      port: 443
      name: secure
  type: ClusterIP

Et pour avoir un accès de l’extérieur, il faut instancier un load-balancer via le fichier traefik/traefik-service-loadbalancer.yml

kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-lb
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 443
      name: secure
  type: LoadBalancer

Pour donner l’accès au dashboard via une url sécurisée par un certificat Let’s Encrypt, il faut déclarer un Ingress, dans le fichier traefik/traefik-api-ingress.yml :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    traefik.ingress.kubernetes.io/redirect-entry-point: https
    traefik.ingress.kubernetes.io/redirect-permanent: "true"
    ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/ssl-temporary-redirect: "false"
  name: traefik-web-ui
spec:
  rules:
  - host: traefik.k8s.cerenit.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-ingress-service-clusterip
          servicePort: admin
  tls:
  - secretName: traefik-cert

L’idée est donc de rentre le dashboard accessible via l’url traefik.k8s.cerenit.fr.

La section tls de l’ingress indique le nom du secret contenant le certificat du site que nous n’avons pas encore créé.

Les annotations permettent de faire une redirection http vers https systématique.

Il ne nous reste plus qu’à créer le certificat via le fichier traefik/certificate.yml

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: traefik-cert
spec:
  secretName: traefik-cert
  issuerRef:
    name: letsencrypt-prod
  commonName: traefik.k8s.cerenit.fr
  acme:
    config:
    - http01:
        ingressClass: traefik
      domains:
      - traefik.k8s.cerenit.fr

Il ne reste plus qu’à faire pour instancier le tout :

kubectl create -f traefik/

Pour la génération du certificat, il conviendra de vérifier la sortie de

kubectl describe certificate traefik-cert

Name:         traefik-cert
Namespace:    traefik
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Creation Timestamp:  2019-01-27T19:49:10Z
  Generation:          1
  Resource Version:    5392945333
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/traefik/certificates/traefik-cert
  UID:                 9d7bac06-226c-11e9-8901-daa66ba82679
Spec:
  Acme:
    Config:
      Domains:
        traefik.k8s.cerenit.fr
      Http 01:
        Ingress:
        Ingress Class:  traefik
  Common Name:          traefik.k8s.cerenit.fr
  Issuer Ref:
    Name:       letsencrypt-prod
  Secret Name:  traefik-cert
Status:
  Acme:
    Order:
      URL:  https://acme-v02.api.letsencrypt.org/acme/order/50348094/290143012
  Conditions:
    Last Transition Time:  2019-01-27T19:49:52Z
    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     58m   cert-manager  Created new ACME order, attempting validation...
  Normal  DomainVerified  58m   cert-manager  Domain "traefik.k8s.cerenit.fr" verified with "http-01" validation
  Normal  IssueCert       58m   cert-manager  Issuing certificate...
  Normal  CertObtained    58m   cert-manager  Obtained certificate from ACME server
  Normal  CertIssued      58m   cert-manager  Certificate issued successfully

Et voilà - maintenant que le problème des certificats est corrigé, je vais pouvoir passer dans un contexte de déploiement multi-nodes.

Pour faire suite au billet sur le déploiement de Traefik sous la forme d’un DaemonSet chez OVH, j’ai profité de la sortie en mode beta des Load Balancers pour revoir ma copie :

  • Déploiement de Traefik sous la forme d’un Deployment plutôt qu’un DaemonSet,
  • Intégration des Load Balancers,
  • Utilisation d’un namespace “traefik” plutôt que de tout mettre dans kube-system.

Par simplicité, je n’ai toujours qu’une node en plus du master fourni par OVH. Cela m’évite la problématique du stockage distribué des certificats. Cela fera l’objet d’un autre billet.

Créons le namespace traefik :

# Create namespace
kubectl create ns traefik
# Change context to this namespace so that all commands are by default run for this namespace
# see https://github.com/ahmetb/kubectx
kubens traefik

Commençons par traefik/rbac.yml - le fichier défini le compte de service (Service Account), le rôle au niveau du cluster (Cluster Role) et la liaison entre le rôle et le compte de service (Cluster Role Binding)

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-ingress-controller
  namespace: traefik
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: traefik

Ensuite, pour Traefik, j’ai besoin d’un fichier traefik.toml avec la configuration que je mets à disposition sous la forme d’une ConfigMap dans un fichier traefik/traefik-toml-configmap.yml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-conf
data:
  traefik.toml: |
    defaultEntryPoints = ["http", "https"]

    logLevel = "INFO"

    insecureSkipVerify = true

    [entryPoints]
      [entryPoints.http]
        address = ":80"
        [entryPoints.http.redirect]
          entryPoint = "https"
      [entryPoints.https]
        address = ":443"
        [entryPoints.https.tls]
      [entryPoints.api]
        address = ":8080"

    [acme]
    email = "contact@cerenit.fr"
    storage = "/acme/acme.json"
    entryPoint = "https"
    onHostRule = true
    [acme.httpChallenge]
      entryPoint = "http"

    [api]
    entryPoint = "api"
    dashboard = true
    debug = false

    [kubernetes]

Le dashboard est à protéger par une authentification pour éviter tout accès non souhaité. Je l’ai supprimé de la configuration par simplicité.

Ensuite, pour stocker mes certificats, il me faut un volume que je défini via le fichier traefik/traefik-certificates-pvc.yml :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: traefik-certificates
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: cinder-classic

1 Go pour des certificats, c’est clairement trop mais il n’est pas possible pour le moment d’avoir un stockage plus réduit.

Je peux donc enfin déployer Traefik via le fichier traefik/traefik-deployment.yml :

---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-controller
  labels:
    k8s-app: traefik-ingress-lb
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: traefik-ingress-lb
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik:1.7.7
        name: traefik-ingress-lb
        volumeMounts:
        - mountPath: /config
          name: traefik-config
        - mountPath: /acme
          name: certificates
        ports:
        - name: http
          containerPort: 80
        - name: admin
          containerPort: 8080
        - name: secure
          containerPort: 443
        args:
        - --configfile=/config/traefik.toml
      volumes:
        - name: traefik-config
          configMap:
            name: traefik-conf
        - name: certificates
          persistentVolumeClaim:
            claimName: traefik-certificates

Nous déployons donc :

  • Traefik en Deployment
  • Les ports 80, 443 et 8080 sont définis
  • La configuration est une ConfigMap
  • Les certificats sont à déployer dans un volume

Pour permettre au cluster d’accéder aux différents ports, il faut définir un service via le fichier traefik-service-clusterip.yml :

---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-clusterip
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin
    - protocol: TCP
      port: 443
      name: secure
  type: ClusterIP

Et pour avoir un accès de l’extérieur, il faut instancier un load-balancer via le fichier traefik/traefik-service-loadbalancer.yml

kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service-lb
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 443
      name: secure
  type: LoadBalancer

Pour donner l’accès au dashboard via une url sécurisée par un certificat Let’s Encrypt, il faut déclarer un Ingress, dans le fichier traefik/traefik-api-ingress.yml :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-web-ui
spec:
  rules:
  - host: traefik.k8s.cerenit.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-ingress-service
          servicePort: admin

Il ne nous reste plus qu’à faire :

# Create k8s ressources for traefik
kubectl create -f traefik/
# Watch service to get IPs
kubectl get svc -w

Une fois votre IP obtenue, il suffit de faire pointer votre entrée DNS vers cette IP ou de tester via :

curl -H "Host: traefik.k8s.cerenit.fr" https://xxx.xxx.xxx.xxx/

Pour l’obtention du certificat Let’s Encrypt, il faut que votre enregistrement DNS soit à jour préalablement. Sinon vous aurez un certificat autosigné par Traefik en attendant.

Dès lors, vous pouvez accéder au dashboard de Traefik via l’url définie. Pour donner accès à d’autres sites, il faut déclarer d’autres ingress sur le même modèle et le tour est joué.

Comparativement au dernier tutoriel :

  • Nous n’exposons plus le port 8080 au niveau de l’hôte,
  • Nous respectons plus les guidelines kubernetes à savoir de donner accès à une ressource via un service de type Load-Balancer ou NodePort
  • Nous utilisons une seule IP externe et nous appuyons sur les ingress pour mutualiser le load balancer et éviter d’avoir une IP publique par service à exposer
  • Nous ne sommes pas sur d’avoir un pod traefik par noeud mais nous gagnons en flexibilité - il faudra jouer avec les replicas dès qu’on ajoutera des nodes dans le cluster.

Il reste encore le problème des stockage des certificats à résoudre pour passer à un contexte multi-nodes. Ce sera l’objet d’un prochain billet avec idéalement l’intégration de Traefik avec cert-manager (plutôt que de devoir déployer une base clé/valeur comme etcd ou consul pour y stocker les infos de traefik).

N’hésitez pas à me faire part de vos retours.

Sortant de la formation Déployer ses applications avec Kubernetes animée par Jérome Petazzoni - slides - j’ai voulu mettre en oeuvre différents enseignements. OVH proposant un service kubernetes managé en version beta basé sur une infrastructure Openstack, j’en ai profité pour jouer un peu avec.

En parcourant la documentation disponible et le canal gitter, on note que :

  • La version de kubernetes est la version 1.11.3
  • Les services de type Load Balancer ne sont pas encore supportés - cela devrait arriver prochainement
  • Il faut en attendant passer par un NodePort pour accéder aux applications.

J’ai voulu donc voir comment déployer Traefik sur mon cluster qui ne contient qu’une seule node pour me facilier la gestion des volumes. En effet, la classe de stockage “cinder” ne supporte pas un accès depuis plusieurs nodes (ReadOnlyMany ou mieux ReadWriteMany) mais seulement depuis une node (ReadWriteOnce).

C’est donc clairement sous-optimal comme configuration mais ça permet de se faire la main à un prix raisonnable et sans trop se casser la tête. Dans le cadre d’un vrai déploiement, il faudrait trouver une solution de stockage plus intéressante pour les données de traefik (en l’occurence les certificats).

L’idée est donc de déployer Traefik sous la forme d’un DaemonSet et de mapper les ports 80443 de chaque node du cluster.

Pour se faire, Traefik founi un exemple de DaemonSet que j’ai largement repris.

Commençons par traefik/rbac.yml - le fichier défini le compte de service (Service Account), le rôle au niveau du cluster (Cluster Role) et la liaison entre le rôle et le compte de service (Cluster Role Binding)

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: traefik-ingress-controller
  namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - endpoints
      - secrets
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - extensions
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: kube-system

Ensuite, pour Traefik, j’ai besoin d’un fichier traefik.toml avec la configuration que je mets à disposition sous la forme d’une ConfigMap dans un fichier traefik/traefik-toml-configmap.yml :

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-conf
  namespace: kube-system
data:
  traefik.toml: |
    defaultEntryPoints = ["http", "https"]

    insecureSkipVerify = true

    [entryPoints]
      [entryPoints.http]
        address = ":80"
        [entryPoints.http.redirect]
          entryPoint = "https"
      [entryPoints.https]
        address = ":443"
        [entryPoints.https.tls]
      [entryPoints.api]
        address = ":8080"

    [acme]
    email = "contact@cerenit.fr"
    storage = "/acme/acme.json"
    entryPoint = "https"
    onHostRule = true
    [acme.httpChallenge]
      entryPoint = "http"

    [api]
    entryPoint = "api"
    dashboard = true
    debug = false

Le dashboard est à protéger par une authentification pour éviter tout accès non souhaité. Je l’ai supprimé de la configuration par simplicité.

Ensuite, pour stocker mes certificats, il me faut un volume que je défini via le fichier traefik/traefik-certificates-pvc.yml :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: traefik-certificates
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi
  storageClassName: cinder-classic

1 Go pour des certificats, c’est clairement trop mais il n’est pas possible pour le moment d’avoir un stockage plus réduit.

Je peux donc enfin déployer Traefik via le fichier traefik/traefik-ds.yml :

---
kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
  name: traefik-ingress-controller
  namespace: kube-system
  labels:
    k8s-app: traefik-ingress-lb
spec:
  template:
    metadata:
      labels:
        k8s-app: traefik-ingress-lb
        name: traefik-ingress-lb
    spec:
      hostNetwork: true
      serviceAccountName: traefik-ingress-controller
      terminationGracePeriodSeconds: 60
      containers:
      - image: traefik
        name: traefik-ingress-lb
        volumeMounts:
        - mountPath: /config
          name: traefik-config
        - mountPath: /acme
          name: certificates
        ports:
        - name: http
          containerPort: 80
          hostPort: 80
        - name: https
          containerPort: 443
          hostPort: 443
        - name: admin
          containerPort: 8080
          hostPort: 8080
        securityContext:
          capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
        args:
        - --kubernetes
        - --logLevel=INFO
        - --configfile=/config/traefik.toml
      volumes:
        - name: traefik-config
          configMap:
            name: traefik-conf
        - name: certificates
          persistentVolumeClaim:
            claimName: traefik-certificates
---
kind: Service
apiVersion: v1
metadata:
  name: traefik-ingress-service
  namespace: kube-system
spec:
  selector:
    k8s-app: traefik-ingress-lb
  ports:
    - protocol: TCP
      port: 80
      name: web
    - protocol: TCP
      port: 8080
      name: admin
    - protocol: TCP
      port: 443
      name: https

Nous déployons donc :

  • Traefik en DaemonSet
  • Les ports 80, 443 et 8080 sont ouverts au niveau de l’hôte
  • La configuration est une ConfigMap
  • Les certificats sont à déployer dans un volume

A partir de ce moment là, vous avez accès au dashboard via http://<node ip>:8080/

Pour améliorer un peu les choses, nous pouvons vouloir donner accès au dashboard via une url et sécurisé par un certificat Let’s Encrypt.

Pour se faire, il faut déclarer un Ingress, dans le fichier traefik/traefik-api-ingress.yml :

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: traefik-web-ui
  namespace: kube-system
spec:
  rules:
  - host: traefik.k8s.cerenit.fr
    http:
      paths:
      - path: /
        backend:
          serviceName: traefik-ingress-service
          servicePort: admin

Il ne nous reste plus qu’à faire :

kubectl create -f traefik/
ingress.extensions/traefik-web-ui created
persistentvolumeclaim/traefik-certificates created
daemonset.extensions/traefik-ingress-controller created
service/traefik-ingress-service created
serviceaccount/traefik-ingress-controller created
clusterrole.rbac.authorization.k8s.io/traefik-ingress-controller created
clusterrolebinding.rbac.authorization.k8s.io/traefik-ingress-controller created

Dès lors, vous pouvez accéder au dashboard de Traefik via l’url définie.

Nous arrivons au bout de ce tutoriel permettant de jouer rapidement avec Traefik sous la forme d’un DaemonSet. Le contenu est criticable et améliorable par bien des aspects :

  • Il faudrait ne pas exposer le port 8080 de Traefik au niveu de la node et n’y accéder que via le service,
  • Le stockage des certificats est à améliorer dans un contexte multi-nodes

N’hésitez pas à me faire part de vos retours.

Cloud

  • AWS Re:Invent 2018 : Difficle de passer à coté des annonces d’AWS - AWS re:Invent 2018 - Jour 1, AWS re:Invent 2018 - Jour 2, AWS re:Invent - Jour 3, AWS re:Invent - Jour 4 : le résumé des sorties de la conférence AWS re:Invent 2018 par le cabinet Ippon.
  • #9 - Quentin Adam - Horacio Gonzales - Steven Le-Roux - La guerre du cloud : dans cet épisoide du podcast databuzzword, il est question de guerre du cloud, du multi-cloud, d’AWS et de ses “partenariats” et du cloud chinois et russe.
  • Episode 63 : “Re-Invent le Cloud” : L’épisode 63 de BigDataHebdo s’intéresse aussi aux annonces de la conférence d’AWS et discute aussi d’AWS et du monde de l’opensource.
  • License Changes for Confluent Platform : la sortie de l’offre Kafka managé n’a pas plus à Confluent. A l’instar de Redis et MongoDB, c’est au tour de Confluent d’adopter une licence plus restrictive pour les fournisseurs de cloud dans le cadre de la distribution de sa platforme Confluent. La licence de Kafka est inchangé, cela concerne l’API Rest, la Schema REgistry, KSQL et des connecteurs confluent.
  • Copyleft and community licenses are not without merit, but they are a dead end : Paul Dix, le CTO D’InfluxData donne son avis sur les changements de licences en cours. Un point intéressant est que ce changement de license vers des licences de type “Community” va surtout pénaliser les développeurs en créant une incertitude autour du mode de collaboration/contribution et peuvent aussi chercher à créer un monopole pour les services SasS créés par l’éditeur du produit. Oui il est dommage qu’AWS par ex ne contribue pas à Kafka/Confluent dans le cadre de son offre managée, mais par la même occasion Confluent se crée un monopole de fait sur l’offre SaaS autour de KSQL. Est-ce vraiment mieux ? En ce sens, Paul préfère alors soit du tout open ou tout fermé - mais que la solution du milieu n’est pas si idéale que ça (surtout pour des couches basses des produits sur lequel nous sommes censés bâtir quelque chose).
  • We need Sustainable Free and Open Source Communities : Pour finir sur une note plus optimiste, l’auteur cherche à renverser la conversation en regardant comment créer des communautés soutenables et faire en sorte que la licence permette de soutenir la communauté. Pas sur que les libristes les plus convaincus n’y voient pas une atteinte aux libertés du logiciel justement : “Any commercial activity around the software must further the sustainability of the community, and the potential for commercial benefit must be available to all. The incentives in any commercial model must bend away from the creation of proprietary downstream software”

Container et orchestration

  • Introducing Traefik Enterprise Edition : le reverse proxy Traefik voit apparaitre une version Entreprise qui se veut plus distribuée avec l’apparition d’un “data plane” qui gère les connexions et joue le rôle de reverse proxy et un “control plane” qui coordonne le bon fonctionnement des noeuds.
  • CNCF to Host etcd : la base clé/valeur distribuée etcd et qui sert notamment de datastore pour kubernetes va être hébergé par la CNCF. Elle fut développée initiallement par CoreOS, désormais propriété de Red Hat (et donc IBM).
  • [Podcast] PodCTL – Kube Security, Kube 1.13 and KubeCon :
  • MetalLB : MetalLB propose de fournir un service de type load balancer prévu pour cluster Kubernetes dans un contexte bare metal (ie non cloud).
  • MetalLB, with David Anderson : Episode du Kubernetes Podcast sur MetalLB avec son auteur pour une présentation de la solution.

Dataviz

  • Grafana v5.4 Released : une version de consolidation avec des améliorations sur la temporisation des alertes avant de l’émettre. D’autres améliorations sur l’intégration Google Stackdriver, l’éditeur de requêtes MySQL et des améliorations sur les panels et des préférences d’équipes.

Langages

Il ne me reste plus qu’à vous souhaiter de bonnes fêtes de fin d’année et à vous retrouver l’année prochaine pour de nouvelles aventures.

Méthodologie

  • Infliger de l’aide : Quand une personne demande de l’aide et qu’on n’y met pas d’empathie, on peut alors lui infliger de l’aide - Je pense que je vais reprendre ce concept et l’appliquer.

Sécurité

Tests

Web

Windows

Automatisation / DevOps

  • L’inversion du modèle de connexion d’Ansible avec Ansible-pull : killer feature ? - l’article revient sur une fonctionnalité méconnue d’Ansible de pouvoir fonctionner en mode pull (la machine cible récupère le playbook à exécuter) plutôt qu’en mode push (la machine sur laquelle est installée Ansible se connecte à la machine cible pour exécuter le contenu du playbook). Au-delà des limitations, cela peut avoir son intérêt dans quelques cas précis, mais pas la peine d’envisager de basculer complètement en mode pull. Si c’est ce que vous recherchez, alors changez d’outil.
  • ARA Project : Il s’agit d’une surcouche à Ansible qui permet de stocker dans une base le résultat de l’exécution des playbooks et avoir ainsi une visualisation plus agréable et aussi disposer d’un historique d’exécution. A tester… Ne prenez pas peur si vous voyez que le projet est dans l’organisation Gtihub d’Openstack, il n’y a aucune dépendance à Openstack.

Container

  • Introducing Docker Engine 18.09 : Docker 18.09 est (enfin) sorti. Pour rappel, le rythme des releases est maintenant de 2 versions / an en Mars et Septembre (au lieu de 4 / an). Les améliorations semblent surtout être sous le capot avec la poursuite des intégrations de containerd et surtout buildkit. Il faudra aller du coté des release notes pour avoir plus de détail. Si vous vous connectez à distance à votre démon docker, vous pouvez maintenant le faire au travers d’une connexion ssh.
  • dive : c’est un outil qui permet d’explorer les images docker, les layers dans le but de découvrir des moyens d’optimiser la taille de ses images. Un score d’efficacité est d’ailleurs indiqué.

Cloud

  • HDFS vs. Cloud Storage: Pros, cons and migration tips : un article assez équilibré par les équipes de GCP (Cloud Google) sur les cas d’usages ou il vaut mieux utiliser un stockage cloud ou HDFS (la solution de stockage d’un cluster Hadoop).
  • Mark Shuttleworth reveals Ubuntu 18.04 will get a 10-year support lifespan : à l’occasion de l’Openstack Summit, Mark Shuttleworth (le CEO de Canoncial) a annoncé que la version LTS Ubuntu 18.04 serait supportée pendant 10 ans (au lieu de 5 ans) pour tenir compte des besoins de ses clients cloud et IoT. Il viste aussi clairement les clients de Red Hat, habitués à ce cycle de support.
  • Traefik — Spoiler Season — Episode 1 : Traefik avait annoncé une phase de refonte de son code suite à la sortie de la version 1.7. Le billet présente les changements à venir avec une réorganisation des composants internes et de leur ordre d’exécution.
  • nginxconfig.io : un petit générateur de configuration pour nginx. Il est basique mais il fait le job.

Dataviz

  • Grafana v5.3 Stable released! : Support de la datasource Google Stackdriver, Mode TV amélioré, des rappels sur les alertes (si une alerte est levée, une notification de rappel toutes les X minutes), un éditeur de requêtes pour Postgres, et plein d’autres améliorations.

Langages

  • Java.Next : un billet de synthèse sur les évolutins du langage Java en terme de versionning, d’apports de ces différentes versions et de la nouvelle politique de support d’Oracle (et les alternatives qui vont bien)
  • Python in RHEL 8 : Python3 par défaut dans RHEL8 - Intéressant, ils font l’impasse sur la PEP 394 qui dit que python == python2 pour le motif de ne pas se tirer une balle dans le pied et qu’il y a alternatives --set python /usr/bin/python3 pour ça.

NoSQL

  • Elastic Stack 6.5.0 Released : la version 6.5 de la stack Elastic vient de sortir - des points intéressants : le module APM gère maintenanat les applications Java & Go, Elasticsearch supporte (en alpha) les drivers ODBC permettant ainsi de requêter ES depuis Excel (!!), Kibana se dote d’une notion d’Espaces (Spaces) pour segmenter les usages et les dashboard avec une notion de permissions, Logstash a un runner (experimental) en java plutôt qu’en ruby, Beats se dote de capacités autour du serverless et de l’auto-enregistrement auprès d’ES/Kibana.

Sécurité

  • Une faille 0day dans VirtualBox : Comment vous protéger ? : une faille au niveau de la pile réseau permet de remonter à la machine hôte via la VM. Pas besoin de désinstaller VirtualBox dans l’heure si vous faites des choses normales avec vos VMs. Si vous êtes chercheur en sécurité, là par contre, vaut mieux prendre des précautions supplémentaires pour que votre malware reste dans la VM (si infectée).
  • URLs are hard, let’s kill them : réflexion autour des urls et de leur disparition partielle dans les navigateurs mobiles notamment et de ce que cela peut avoir comme implications.
  • A new security header: Feature Policy : à l’image des Content Security Policy (CSP), la directive Feature-Policy indique au navigateur les fonctionnalités nécessaires pour le bon fonctionnement du site et désactiver les autres.
  • RFC 8484: DNS Queries over HTTPS (DoH) : cette RFC décrit comment requêter des DNS via le protocole HTTPS plutôt qu’en UDP ou TCP simple sur le port 53. DNS Over HTTPS (DoH) un objectif de lutter contre la censure, au filtrage DNS mais aussi de permettre aux applications web en javascript et tournant dans le navigateur, et ce en respectant CORS. Attention toutefois en utilisant DoH, dans la mesure où c’est sur HTTP(s), il y a quand même plus d’informations qui circulent (user agent, etc) - il faut donc bien choisir son client.

Time series databases

  • TimescaleDB 1.0 is Production Ready : la version 1.0 de TimescaleDB est sortie avec notamment une intégration de Grafana et de Prometheus et pas mal d’amélioration de la base de code.

Web

  • HTTP/3 : HTTP/3 est la prochaine version de HTTP qui utilise le protocole QUIC pour le transport. Quic a pour objectif de remplacer TCP sur de l’UDP. Commitstrip a publié un billet à ce sujet.
  • Some notes about HTTP/3 : ce billet permet d’approfondir HTTP/3, QUIC et la couche de transport sous-jacente, les limites actuelles et les réponses que QUIC apporte.

J’ai participé à la première édition de Voxxeddays Microservices Paris qui a eu lieu du 29 au 31 oct, sous la forme de deux jours de conférences et un jour de workshop. Je ne suis allé qu’aux deux jours de conférences.

Globalement :

  • Je crois que c’est la première conférence tech où je vois autant de femmes témoigner - après recomptage, il n’y en avait que 8 sur 45 speakers, mais 2 des 3 keynoters étaient des femmes. 16 c’est encore peu mais c’est mieux que d’habitude. L’assistance m’a aussi paru plus féminine que d’habitude. Le mardi, la majorité des conférences auxquelles j’ai assisté étaient assurées par des femmes.
  • Deux journées denses avec des formats de conférences variées (15/25/45 minutes) et des sujets variés également (Techno, Retours d’exéprience, Architecture, Problématiques, etc).

Sur les keynotes qui devaient articuler le passé, le présent et le futur des microservices :

Distant past of microservices - Ken Finnigén (Red Hat)

  • Tout n’est que système distribué au final - les microservices n’en sont qu’une variante, après SOA, après le client/serveur, etc.
  • Il y a un cycle des systèmes distribués : gestion toute imbriquée (“embedded”), passage par des librairies, puis des middlewares et enfin par de la gestion d’environnement (et de ses variables). Il est donc probable que l’on revienne vers du tout en un prochainement. Même s’il y a des améliorations incrémentables d’un cycle à l’autre, on reste sur la même boucle.
  • “Old is the new new” - il faudrait cesser de réinventer la roue pour la simple raison que nous pouvons le faire. il faudrait plutôt chercher à résoudre des problèmes qui n’ont pas encore été résolu. Cela me fait penser aux nouveaux langages ou frameworks qui se créent sans tenir (trop) compte des langages précédents : ils se retrouvent au final à devoir traiter les mêmes problèmes que leurs prédécesseurs et sans forcément trouver une réponse plus satisfaisante.
  • Réflexion autour de la notion de “quescient state” comme prochain but à atteindre.

The endless now : distributed systems and teams - Bridget Kromhout

  • C’est dommage que l’oratrice ait forcément voulu raccrocher des technologies et des outils à son propos car cela a nuit à son message. Je n’ai pas vu la raison ou l’intérêt de mentionner ces outils.
  • Le propos était d’appliquer les principes du CAP sur les équipes et les systèmes :
    • “Consistency” : les containers ont apporté cette reproductabilité des déploiements
    • “Avilability” : les outils d’orchestration répondent à ce besoin et à cette gestion de la disponibilité de nos applications
    • “Fault/Partition tolerance” : il faut travailler sur les effets du bus factor, la loi de Conway et la communication entre les équipes pour éviter la dépendance à une personne et développer la résilience de l’équipe et du système.

Preparing for a future microsdervices journey - Susanne Kaiser

Ma keynote préférée - l’oratrice reparcourt tout ce qui fait un micro-service et les bonnes pratiques associées :

  • Pour un simple/petit micro-service, il faut bien avoir en tête tout l’écosystème que l’on emmène avec soi (solutions et infrastructure cloud, CI/CD, etc)
  • Parcours des bonnes pratiques et des “cloud native citizen principles”
  • Elle prone le focus sur notre coeur d’activité et d’externaliser le reste en ayant recours à des services managés. Toutefois, elle fait une très belle remarque en rappelant qu’il ne faut pas négliger la charge cognitive liée à ces services managés. Ils résolvent des problèmes et font gagner du temps mais ne sont pas neutres pour autant (ex: les primitives de Kubernetes et d’un service mesh comme Istio)

Pour les conférences, celles que j’ai préféré :

Hexagonal at scale with DDD and microservices ! - Cyrille Martare (Arolla)

  • L’orateur rappelle que les microservices requiert une approche DDD puis les principes de DDD en eux même. Il rajoute que les architectures 3 tiers, par couche, par technologie ou encore que le découpage par entités ne vont pas créer de bons microservices et ne sont pas dans une approche DDD. Il faut donc définir avec le métier les fameux domaines et leurs frontières (“bounded context”). L’orateur a alors parcouru les différents heuristiques permettant de les définir.
  • Si nous avons été habitués à avoir une approche DRY (Don’t reapeat yourself”), dans une approche DDD et Microservices, cela perd son sens. Il vaut mieux accepter de la duplication de données afin d’avoir du code moins couplé et donc avoir une meilleure indépendance des microservices entre eux.

Microservices Lessons Learned - Susanne Kaiser

Dans la continuité de sa Keynote, Suzanne fait un bilan de ce qu’elle a pu faire et de comment il aurait fallu le faire. Je vous invite à voir son talk et récupérer les slides.

Coté Outils…

Quelques outils qui m’ont semblé intéressants :

  • Jenkins X : l’idée est de déployer sur un cluster Kubernetes un noeud maitre Jenkins et un Nexus (ou autre produit de stockage d’artefacts) et ensuite d’instancier les agents Jenkins à la volée pour vos besoins de CI/CD.
  • Teeid ou l’ancien site : solution permettant de définir une ou plusieurs bases virtuelles au dessus d’une base existante. Cela peut être pratique dans le cadre de la sortie d’un monolithe vers des microservices. L’idée est de permettre au micro-service d’avoir la nouvelle vue tout en conservant l’ancien système.
  • Micronaut se veut un framework java minimaliste pour être adapté aux microservices mais sans affecter la productivité des développeurs. Il est développé par l’équipe qui a réalisé Grails. Il se veut plus léger/performant que Microprofile qui est en gros la version microservice du framework JEE. Micronaut serait plus proche de Vertx.
  • Strimzi : Il s’agit d’un projet Red Hat pour fournir un Cluster Kafka à déployer sur Kubernetes ou Openshift
  • Debezium : Plateforme de Change Data Capture (CDC) - Elle est basée sur Kafka et Kafka Connect. Elle permet de récupérer les changements de vos bases MySQL/Postgres/MongoDB sous forme d’événements et de les communiquer à qui de droit en mode streaming.
  • gRPC : si vous n’avez pas besoin d’une API REST, que vous manipulez plutôt des RPC que des ressources (REST), que vous n’êtes pas dans un contexte CRUD, alors gRPC peut être fait pour vous.
  • Dependency Check et Dependency Track sont deux projets de l’OWASP permettant d’analyser vos dépendances et de surveiller les vulnérabilités de votre base de code. Ils s’intègrent notamment avec Jenkins.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch postgres kafka ansible grafana traefik python aws influxdb mysql tick cloud sécurité redis chronograf swarm test cassandra hashicorp microservice ovh serverless spark terraform angularjs cncf confluent container graphql javascript log opensource rancher stream windows api architecture arm csp devops dns docker-compose documentation elastic hpkp iac java kapacitor kibana lambda lean licence microsoft npm orientdb rest rethinkdb reverse-proxy service-mesh sql ssh timescaledb agile apm azure bash big-data bilan certificat cli cluster continous-delivery cookie cérénit fluxlang gcp gdpr git grav hsts https hypriot ingress istio json ksql lets-encrypt linux load-balancer machine-learning mobile monitoring nginx perspective php pip prometheus redhat replication rsyslog scale scaleway solr systemd telegraf vault virtualenv vue.js wagtail yarn accessibilité akka alerte alibaba amazon-emr anonymisation ara automatisation bastion beam beat bounded-context branche brigade browser buildkit cdc cert-manager certificats checklist chrome cloud-init cloud-native cloud-storage clusterip cockroachdb code codeurs-en-seine confluence consul containerd continous-integration coreos cors cqrs crash cron crontab csrf css curl d3.js daemonset dashboard data-pipelining dataviz date ddd debezium debian deployment desktop devoxx distributed-systems dive docker-app docker-registry documentdb dokcer draft drop-in ebs ec2 edge elassandra electron elk engineering etcd event-sourcing facebook falcor feature-policy feed filebeat firebase firefox fish flash flask fleet flink fluentd flux foundation framework frontend fsync fullstack github glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop hdfs header helm html html5 http http/3 hue ia iaac ibm immutable incident index infrastructure-as-code ingénierie inspec jq jquery jwt k3d k3s k8s k9s kubeadm kubecon kubedb laravel liste-de-diffusion loadbalancer logstash logstatsh loi mailing-list management mariadb message metallb micro-service molecule mongodb mot-de-passe multi-cloud médecine newsletter nodeport nomad nosql null openmetrics openshit openssh openweb operator over-engineering packaging pandas password performance persistent-volume-claim pipenv portainer publicité push pyenv queue quic raml react reaper recaptcha recherche reindex reinvent responsive revocation revue-de-code rkt rolespec root rpi rpo rto runc rwd s3 search secrets select serverless-architecture service-worker sha1 sharding shell shipyard société spinnaker sre sri ssh-agent ssl statistique superset sympa syslog-ng test-unitaire tidb tiers timer timeseries timezone tls training travail ubuntu unikernel unit ux vie-privée virtualbox vitess vm vnc volume voxxeddays vpc

Syndication

Atom