CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Kubernetes @ OVH - Traefik en DaemonSets

kubernetes traefik ovh daemonset

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 80/443 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.

Web, Ops & Data - Décembre 2018

python grafana aws confluence licence opensource traefik windows openssh cloud etcd cncf vault hashicorp test kubernetes load-balancer metallb chrome edge

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

Web, Ops & Data - Novembre 2018

ansible ara docker dive hdfs cloud storage ubuntu grafana traefik nginx java elastic virtualbox browser feature-policy timescaledb 3 dns quic

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.

Voxxeddays Microservices Paris

microservice voxxeddays cloud distributed systems ddd bounded context

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. 1/6 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.

Web, Ops & Data - Octobre 2018

ansible test ssh tls php molecule rolespec iac cli postgres redis certificats vault hashicorp training firefox cookie redhat ibm

J’ai eu le plaisir et l’opportunité de participer à la réalisation de l’épisode 10 de Dev’Obs, le magazine du DevOps, pendant lequel nous avons parlé de formation, d’innovation et des tests dans la mouvance Infrastructure As Code.

Acquisition

Automatisation

  • Mitogen for Ansible : extension pour Ansible qui permettrait d’accélérer Ansible via une optimisation de la connexion à l’hôte distant. “Expect a 1.25x - 7x speedup and a CPU usage reduction of at least 2x, depending on network conditions, modules executed, and time already spent by targets on useful work. Mitogen cannot improve a module once it is executing, it can only ensure the module executes as quickly as possible.”
  • Molecule : molelcule est un framework pour Ansible permettant de tester les rôles/playbooks au travers de linter (syntaxe yaml, python, etc), mais aussi de réaliser des tests unitaires, de valider l’omnipotence d’une tâche, etc. A tester, mais vous ne devriez plus avoir de mauvaises surprises à l’exécution d’un playbook et ainsi mettre fin au cycle “run, break, fix” que l’on a trop souvent avec Ansible.
  • Ansible to adopt molecule and ansible-lint projects : les projets molecule et ansible-lint vont passer sous l’organisation Ansible sur Github et ont pour objectif d’accroitre la qualité des playbooks ansible. Cela fait apparamment partie aussi d’un objectif RedHat de péréniser les ressources liées au projet tout en étendant l’écosystème.
  • The release of Red Hat Ansible Engine 2.7 : Pas de révolution dans cette version, essentiellement des améliorations de perfomances/stabilité/connectivité. Il faudra une version python 2.7+ ou 3.5+ pour qu’Ansible fonctionne correctement.
  • Reboot Plugin for Linux in Ansible 2.7 : Avec l’arrivée de cette version 2.7 arrive également officiellement le module reboot. Il permet ainsi de piloter des playbooks pour lesquels un reboot est nécessaire (mise à jour de noyau, etc).
  • 12 Factor CLI Apps : le principe des 12 factors apps appliqué aux outils en ligne de commande. Il y a pas mal de bonnes idées (et donc de travail à faire) pour améliorer ses scripts.

(No)SQL

  • [RELEASE] Redis 5 is out! : l’annonce de la version 5.0 de la base Redis vient de sortir avec pas moins de 19 nouveautés listées. Si les Streams sont la principale nouveauté de cette version, de nombreuses améliorations ont été apportées à la base. La montée de version se veut compatilbe à 99%, il y a néanmoins quelques incompatibilités.
  • PostgreSQL 11 Released! : la version 11 de la base Postgres vient de sortir - ce que j’ai retenu de cette version majeure, c’est le support du catch-all dans le partitionning (si une donnée ne correspond à aucune clé de partitionnement, alors le catch-all récupère cette donnée) et la capacité à mettre à jour ces clés de partitionnement. D’autres nouveautés sont également intéressantes, je vous laisse le soin de les lire. Une traduction française de l’annonce est disponible sur le blog de Loxodata.

Sécurité

  • Around 62% of all Internet sites will run an unsupported PHP version in 10 weeks : Pour les sites développés en PHP, à compter de janvier 2019, il faudra être minimum en version de PHP 7.1 pour avoir les mises à jour de sécurité - le support de PHP 5.6 et 7.0 se finit à la fin de l’année.
  • Extended Validation Certificates are Dead : le bandeau avec l’intitulé de l’organisme propriétaire du certificat est en train de disaparaitre des navigateurs. Il ne sert donc plus à rien d’en acheter un.
  • Removing Old Versions of TLS : TLS 1.0 et 1.1 ne seront plus supportés en mars 2020 dans les navigateurs. Dès aujourd’hui, ces deux versions ne représentant que ~1% du traffic observé par les navigateurs, il peut être judicieux de n’utiliser que du TLS 1.2+ et voir s’il n’y a pas quelques vieux programmes à mettre à jour d’ici là…
  • Announcing the HashiCorp Learn Platform for HashiCorp Vault : pour ceux qui veulent se faire la main sur Vault et mieux gérer leurs secrets applicatifs, Hashicorp vient de lancer une plateforme gratuite et avec des contenus sous licence libre (un dépot sera prochainement mis à disposition) pour se former à leur outil Vault.
  • Firefox 63 Lets Users Block Tracking Cookies - Firefox va incorporer un mécanisme expérimental de gestion des cookies pour limiter le pistage inter sites. A activer selon vos préférences.
16 17 18 19 20