Web, Ops & Data - Mai 2020


27/05/2020 docker ovh openstack fedora harbor registry traefik maesh percona mysql operator devops timescaledb grafana kubernetes terraform iac cert-manager devops raspberrypi

Le mois prochain, dans le cadre d’InfluxDays London, j’aurai le plaisir de présenter un talk sur le passage d’un monitoring Bare Metal vers un monitoring dans un monde Kubernetes avec Telegraf et InfluxDB.

Cloud

Container & orchestration

  • How To Install Docker On Fedora 32 Or 31 (And Alternatives) : Même si l’utilisation de podman est recommandée en lieu et place de docke-ce depuis Fedora 31, il peut être nécessaire de vouloir utiliser docker-ce sous Fedora. Avec Fedora 32, il faut en plus des cgroups v1 à activer, il y a une règle firewall à ajouter pour que vos conteneurs aient accès au réseau / à internet.
  • Harbor 2.0 : Version 2.0 de la registry Harbor qui permet d’héberger aussi des charts Helm. Pour la partie scan de vulnérabilités, le produit Clair de Quay a été remplacé par Aqua Trivy
  • Announcing Maesh 1.2 : la solution de Service Mesh de Containous basée sur Traefik sort en 1.2 ; elle se base sur Traefik 2.2 et apporte donc le support de l’UDP au niveau reverse proxy. Cette version permet aussi des améliorations au niveau ACL, gestion de la configuration et gestion des middlewares par service.
  • Introduction to Percona Kubernetes Operator for Percona XtraDB Cluster
  • Cert-manager v0.15 and beyond
  • CDK for Kubernetes : AWS vient de sortir un “Cloud Development Kit” permettant de manipuler et déployer des ressources kubernetes en python, typescript ou javascript.

DevOps

IoT

Time Series

Web, Ops & Data - Janvier 2019


30/01/2019 machine learning python recaptcha flink alibaba cloud mongodb aws documentdb postgres test iac kubernetes ingress clusterip loadbalancer volume persistent volume claim nodeport logstash python pip virtualenv pipenv pyenv

Cloud

Container et orchestration

  • APIServer dry-run and kubectl diff : Un des soucis majeurs avec Kubernetes est l’écriture de fichiers YAML où la moindre faute peut s’insérer très rapidement et à l’insu de son auteur. Le billet présente les efforts fait pour ajouter un mode “dry run” qui simule les modifications et retourne l’objet qui aurait du être créé. Dans la même veine, un kubectl diff montrera les différences entre la ressource existante et celle décrite dans la nouvelle version du fichier yaml.
  • 9 Kubernetes Security Best Practices Everyone Must Follow : rien de transcendental mais une petite piqure de rappel après la faille majeure découverte en fin d’année.
  • Kubernetes NodePort vs LoadBalancer vs Ingress? When should I use what? : billet synthétique sur les avantages et inconvénients d’utiliser un service de type ClusterIP, NodePort, LoadBalancer ou Ingress. Sachant que l’on peut combiner LoadBalancer & Ingress !.
  • Why Is Storage On Kubernetes So Hard? : Les données, c’est tout sauf stateless et le stockage distribué c’est pas facile non plus. Le billet revient sur les logiques de stockages sous Kubernetes (PV, PVC), la couche d’interface de stockage CSI et sur des solutions comme Ceph ou Rook.
  • Stateful Kubernetes with Saad Ali - Software Engineering Daily : une présentation globale des Volumes, Persistent Volume, Persistent Volume Claims et des StorageClass sous Kubernetes et de l’évolution de la gestion du stockage sous k8s
  • Kubernetes Podcast - #36 Rook : une présentation de Rook, un opérateur k8s de gestion de stockage (Ceph, NFS, etc).

Data

IDE

Infrastructure (as Code)

  • Tester son code d’infrastructure avec Terratest : le billet présente terratest, un outil en go qui permet de tester du code Terraform, des templates Packer ou encore des images Docker. La conclusion montre qu’il n’est pas parfait certes mais peut être intéressant.
  • Infrastructure as (real) code : Faire de l’IaC, ce n’est pas que rédiger des fichiers YAML. Le billet montre comment on pourrait avoir de l’IaC avec du vrai code (du go en l’occurence). Avoir un vrai langage et un moteur de template semble en effet plus complet que juste du YAML pour lequel les validateurs sont assez faibles et la probabilité d’écrire une faute assez importante.
  • Reactive planning is a cloud native pattern : Le reactive planning tiendrait dans l’idée que pour une action donnée, il va y avoir un plan et que ce plan est constitué d’une multitude de petites étapes. Chaque étape informant la/les précédentes et voire globalement sur l’état de l’étape en cours et peut décider des étapes suivantes.

Langages

  • Why you should use pyenv + Pipenv for your Python projects : Une solution propre pour mieux gérer ses versions de python installées sur son poste / sur un serveur avec pyenv et pipenv (mix de pip et virtualenv) pour gérer les dépendances. A tester !
  • Pipenv: promises a lot, delivers very little : le billet nuance les propos autour de pipenv comme le nouveau gestionnaire officiel (autopromu) et fait le point sur l’outil.
  • shiv : Shiv permet de packager des applications python en une seule archive zip avec toutes les dépendances incluses. Disponible pour Windows / Linux / OSX, il faut néanmoins builder sur l’OS Cible pour que cela fonctionne - pas de “build one, run everywhere”.

Logs

(No)SQL

Web, Ops & Data - Octobre 2018


31/10/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.

Instancier un cluster de machines sur Scaleway avec Terraform


18/04/2017 terraform scaleway infrastructure as code iac

Objectifs

Pour pouvoir tester différentes solutions, il peut être utile de pouvoir créer rapidement une infrastructure chez un fournisseur tiers. Pour cela nous allons nous appuyer sur la solution Terraform, dont l’objectif est de pouvoir gérer une insfrastructure via du code qui permet de décrire cette infrastructure et les règles associées (dans la tendance Infrastructure as Code).

Cela se fera chez Scaleway mais cela peut se faire chez d’autres fournisseurs tant qu’un provider Terraform existe.

Nous allons nous appuyer sur l’intégration Terraform/Scaleway pour créer un cluster de 3 machines.

Pré-requis

  • Un compte chez Scaleway
  • Avoir créé un token (via Account > Credentials)
  • Avoir terraform sur son PC ; version 0.9.2 dans mon cas.

Créer un ficheir cluster-3.tf dans un dossier vide. Il est important qu’il soit vide car Terraform prend en compte tous les fichiers .tf qu’il rencontre dans le répertoire courant.

Il faut commencer par déclarer notre provider ; je fournis les infos de key & token, ainsi que le datacenter où je souhaite lancer mon cluster :

provider "scaleway" {
  organization = "<access key>"
  token        = "<token>"
  region       = "par1"
}

Je déclare ensuite des data, que l’on peut assimiler à des variables à ce stade :

  • le bootscript est une option de démarrage, notamment au niveau du noyau, d’un serveur chez Scaleway,
  • l’image est l’OS voulu, ici une version Ubuntu Xenial en 64 bits.
data "scaleway_bootscript" "latest" {
  architecture = "x86_64"
  name_filter  = "stable"
}

data "scaleway_image" "ubuntu" {
  architecture = "x86_64"
  name         = "Ubuntu Xenial"
}

Ensuite, je définis une politique de sécurité en 2 étapes :

  • Je déclare la politique de sécurité,
  • J’y ajoute les différentes règles : ici on autorise par défaut ssh, http et https.
resource "scaleway_security_group" "cluster_default" {
  name        = "cluster_default"
  description = "Allow SSH, HTTP, HTTPS traffic"
}

resource "scaleway_security_group_rule" "ssh_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 22
}

resource "scaleway_security_group_rule" "http_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 80
}

resource "scaleway_security_group_rule" "https_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 443
}

Je pourrais donc me connecter en ssh, http et https sur l’ensemble de mon cluster une fois qu’il sera initialisé.

Je déclare ensuite une IP et je l’associe au serveur qui l’utilisera :

resource "scaleway_ip" "cluster-master_ip" {
  server = "${scaleway_server.cluster-master.id}"
}

Enfin, je déclare mon serveur qui va reprendre l’ensemble des informations précédentes, ainsi que quelques informations spécifique comme le type d’instance (type) ou encore le volume additionnel (volume) attaché au serveur. Il y a des directives scaleway_volume ou scaleway_volume_attachment mais l’API Scaleway ne permet pas de les utiliser pour ce type de serveur.

resource "scaleway_server" "cluster-master" {
  name           = "cluster-master"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

Sur le même modèle, nous allons instancier les 2 autres noeuds de notre cluster :

resource "scaleway_ip" "cluster-node1_ip" {
  server = "${scaleway_server.cluster-node1.id}"
}

resource "scaleway_server" "cluster-node1" {
  name           = "cluster-node1"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

resource "scaleway_ip" "cluster-node2_ip" {
  server = "${scaleway_server.cluster-node2.id}"
}

resource "scaleway_server" "cluster-node2" {
  name           = "cluster-node2"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

Vous pouvez déjà valider qu’il n’y a pas d’erreur de syntaxe avec

↪ terraform fmt
cluster-3.tf

Si pas d’erreur, alors il ne retourne que le nom du fichier ou rien si commande déjà exécutée.

Ensuite vous pouvez regarder ce qu’il va se passer avec terraform plan. Cela vous sort un diff de ce qui va être réalisé (ou changé s’il y a mise à jour du plan)

Dans notre cas :

↪ terraform plan

[...]

+ scaleway_ip.cluster-master_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-master.id}"

+ scaleway_ip.cluster-node1_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node1.id}"

+ scaleway_ip.cluster-node2_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node2.id}"

+ scaleway_security_group.cluster_default
    description: "Allow SSH, HTTP, HTTPS traffic"
    name:        "cluster_default"

+ scaleway_security_group_rule.http_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "80"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_security_group_rule.https_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "443"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_security_group_rule.ssh_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "22"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_server.cluster-master
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

+ scaleway_server.cluster-node1
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node1"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

+ scaleway_server.cluster-node2
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node2"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

Plan: 10 to add, 0 to change, 0 to destroy.

Pour provisionner l’infrastructure, il ne vous reste plus qu’à faire terraform apply.

↪ terraform apply
data.scaleway_bootscript.latest: Refreshing state...
data.scaleway_image.ubuntu: Refreshing state...
scaleway_security_group.cluster_default: Creating...
  description: "" => "Allow SSH, HTTP, HTTPS traffic"
  name:        "" => "cluster_default"
scaleway_security_group.cluster_default: Creation complete (ID: 06b93dc3-...2beffd62)
scaleway_security_group_rule.ssh_accept: Creating...
  action:         "" => "accept"
  direction:      "" => "inbound"
  ip_range:       "" => "0.0.0.0/0"
  port:           "" => "22"
  protocol:       "" => "TCP"
  security_group: "" => "06b93dc3-9a8b-4022-80bf-e9172beffd62"
scaleway_server.cluster-master: Creating...

[...]

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Vous pouvez consulter l’ensemble des informations de votre infrastructure avec la commande terraform show.

Il ne vous reste plus qu’à vous connecter sur vos serveurs, faire les actions dont vous avez besoin.

Supposons que nous ayons besoin d’un 4ème noeud, il suffirait de rajouter dans le fichier cluster-3.tf :

resource "scaleway_ip" "cluster-node3_ip" {
  server = "${scaleway_server.cluster-node3.id}"
}

resource "scaleway_server" "cluster-node3" {
  name           = "cluster-node3"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"

  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

On peut valider notre changement avec terraform plan :

↪ terraform plan

[...]

+ scaleway_ip.cluster-node3_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node3.id}"

+ scaleway_server.cluster-node3
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node3"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "06b93dc3-9a8b-4022-80bf-e9172beffd62"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"


Plan: 2 to add, 0 to change, 0 to destroy.

Puis de mettre à jour le cluster avec terraform apply

↪ terraform apply

[...]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Enfin, comme toutes les choses ont une fin, vous pouvez détruire l’ensemble de l’infrastructure créé via terraform destroy.

↪ terraform destroy

[...]

Destroy complete! Resources: 14 destroyed.

J’espère que cette introduction à Terraform vous donnera des idées ; les éditeurs de code modernes fournissent souvent des plugins pour la syntaxe et les snippets terraform. Scaleway reste assez limité en tant que provider terraform. Si vous regardez le provider AWS, vous pouvez interagir avec énormément de services AWS (pour ne pas dire tous) : VPC, EC2, ELB, RDS, etc.

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes traefik ansible elasticsearch influxdb kafka postgres grafana timeseries python aws redis sécurité mysql tick cloud ovh cassandra helm terraform warp10 swarm telegraf test timescaledb chronograf docker-compose résilience architecture confluent ksql log machine-learning microservice prometheus rancher serverless spark angularjs api cert-manager cncf container devops git gitlab graphql hashicorp iac java javascript monitoring opensource operator optimisation ptsm raspberrypi service-mesh stream windows arm bilan csp cérénit dns documentation elastic flux gcp hpkp ingress jenkins kafka-streams kapacitor kibana lambda lean licence maintenance microsoft mobile nginx npm orientdb perspective redhat rest rethinkdb reverse-proxy s3 sauvegarde scaleway sql ssh agile apm automatisation azure bash big-data certificat ci/cd cli cluster containerd continous-delivery continous-integration cookie dashboard deployment diff fluxlang framework gdpr grav hsts http/3 https hypriot hébergement influxace influxdata istio json k3s kubedb lets-encrypt linux load-balancer maesh meetup molecule mongodb percona performance php pip pipeline postgresql reaper registry replication rook rpi rsyslog scale secrets société solr sre systemd tls vault virtualenv vscode vue.js wagtail yarn accessibilité akka alerte alibaba amazon-emr anonymisation anthos apache-pulsar ara audit bastion beam beat bigdatahebdo bounded-context branche brigade browser buildkit cahier-des-charges cassandra-reaper cd cdc centralisation-de-logs ceph certificats chart checklist chrome ci cloud-init cloud-native cloud-storage clusterip cnab cockroachdb code codeurs-en-seine confluence conftest consul continous-deployment coreos cors covid19 cqrs crash cron crontab csrf css curl d3.js daemonset data-pipelining data.gouv.fr datacenter dataviz date ddd debezium debian delta deprek8 desktop devoxx distributed-systems dive docker-app docker-hub docker-registry docker-swarm documentdb dokcer draft drop-in déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd event-sourcing faas facebook faisabilité falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd forecast formation foundation frontend fsync fullstack github gitlab-ci gke glacier glowroot google google-cloud-next gpu grid géospatial hacker hadoop haproxy harbor hdfs header html html5 http hue ia iaac ibm immutable incident index influxcloud influxdays infrastructure-as-code ingénierie inspec jq jquery jwt k3d k8s k9s kotlin kubeadm kubecon kubectl laravel linky liste-de-diffusion loadbalancer logstash logstatsh loi longhorn mailing-list management mariadb message metallb micro-service mot-de-passe multi-cloud médecine métrique newsletter nodeport nomad nosql null object-storage observabilité opa opendata openebs openmetrics openshit openssh openstack openweb over-engineering packaging pandas partiql password persistent-volume-claim pipenv pod portainer prediction prescience publicité pubsub push pyenv quasardb quay queue quic ram rambleed raml react recaptcha recherche redistimeseries reindex reinvent reliability responsive revocation revue-de-code rkt rolespec root rpo rto runc rwd scalabilité scanner schema sdk search select serverless-architecture service-account service-worker sha1 sharding shell shipyard sidecar souveraineté-numérique spinnaker spécifications sri ssh-agent ssl statistique superset sympa syslog-ng test-unitaire tidb tiers timer timezone training travail tsl ubuntu unikernel unit ux vendredi victoria-metrics vie-privée virtualbox virtualisation vitess vm vnc volume voxxeddays vpc web yubikey

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)