CérénIT

Cron et Crontab sont dans un bateau…

Il fut un temps où pour programmer le lancement des actions, notre meilleur ami était “cron” et la “crontab”. Outre la syntaxe et l’organisation de la crontab peu mémorisable, les tâches cron restaient complexes à déployer et à monitorer dans leur exécution. Si le fait d’avoir des répertoires plus génériques comme /etc/cron.{d,hourly,daily,weekly,monthly} ont un peu amélioré la partie exploitabilité/déployabilité, ils offraient assez peu de souplesses pour une plannification fine des tâches. De nombreux serveurs ont donc eu un mix de crontab classique et de ce format pendant des années.

Debian 9.0 (mais d’autres aussi comme Archlinux par ex) a fait le choix dans le cadre de son adoption de systemd de ne plus proposer un logiciel de type cron mais de s’appuyer sur l’implémentation interne à systemd, à savoir les “timers”. C’est une unité (unit) spéciale de systemd qui est controllée et supervisée par systemd et qui s’exécute selon une configuration temporelle donnée.

Voyons comment passer de cette crontab :

0 4 * * * /path/to/scripts/backup.sh >> /var/log/backup.log 2>&1

… ou de /etc/cron.daily/mybackup.sh appelant le même script à son équivalent sous un timer systemd.

Implémentation d’un timer systemd.

Si vous gérez déjà vos services via systemd, vous avez déjà utilisé des “unit” systemd de type “service”. Ces “unit” permettent de définir un process et son mode d’éxécution.

Pour implémenter un “timer” sous systemd, il va nous falloir un fichier “service”.

Pour notre tâche à planifier, nous allons avoir au final 3 fichiers :

  • Le script à exécuter ; c’est votre script /path/to/scripts/backup.sh ; il est inchangé par rapport à précédemment.
  • Le fichier “service” qui va dire quel script exécuter
  • Le fichier “timer” qui va indiquer quand il doit être exécuté.

A noter que par convention, les fichiers service et timer doivent avoir le même nom (foo.service, foo.timer).

Pour le fichier service, une base simple est la suivante :

/etc/systemd/system/mybackup.service :

[Unit]
Description=My Daily Backup

[Service]
Type=simple
ExecStart=/path/to/scripts/backup.sh
StandardError=journal

Je fournis une description à mon service, indique que c’est un process de type simple, le chemin vers mon script et je rajoute que le flux d’erreur est envoyé dans le journal. Pour plus d’information, se reporter à la doc des services et des exécutions.

Attention néanmoins, il ne faut pas de section [Install] car le script va être piloté par le fichier timer.

Ensuite, il nous faut un fichier “timer” :

/etc/systemd/system/mybackup.timer :

[Unit]
Description=My Daily Backup

[Timer]
# Define a calendar event (see `man systemd.time`)
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Au-delà de la description, les lignes importantes sont la section [Timer] et [Install] :

  • OnCalendar permet d’indiquer l’occurrence et la fréquence d’exécution du script. Il y a les abréviations classiques (daily, weekly, etc) mais vous pouvez avoir des choses plus complexes comme "Mon,Tue *-*-01..04 12:00:00" - voir systemd.time
  • Persistent va forcer l’exécution du script si la dernière exécution a été manquée suite à un reboot de serveur ou autre événement.
  • Enfin, la section Install va créer la dépendance pour que votre “timer” soit bien exécuté et pris en compte par systemd.

Il ne reste plus qu’à activer le timer et le démarrer :

systemctl enable mybackup.timer
systemctl start mybackup.timer

Gestion et suivi d’un timer

Pour voir la liste des “timers” actifs sur votre serveur, la date de leur dernière et prochaine exécution :

systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Mon 2018-01-29 17:25:59 CET  2h 27min left Sun 2018-01-28 22:20:35 CET  16h ago      apt-daily.timer              apt-daily.service
Tue 2018-01-30 06:36:33 CET  15h left      Mon 2018-01-29 06:37:35 CET  8h ago       apt-daily-upgrade.timer      apt-daily-upgrade.service
Tue 2018-01-30 09:25:48 CET  18h left      Mon 2018-01-29 09:25:48 CET  5h 33min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

et accéder aux logs de vos “timers” :

journalctl -f -u apt-daily
-- Logs begin at Tue 2018-01-23 13:50:12 CET. --
Jan 28 22:20:35 codb2d9 systemd[1]: Starting Daily apt download activities...
Jan 28 22:20:35 codb2d9 systemd[1]: Started Daily apt download activities.

En cas de modification du .timer ou du .service, ne pas oublier de faire un system daemon-reload pour que la version actualisée de vos fichiers soit prise en compte par systemd.

Passé la petite prise en main de ce nouveau cadre d’exécution, elle me semble plus simple et surtout plus facile à intégrer dans des chaines de déploiements pilotées par Ansible ou autre.

Rien de tel que la finalisation du bilan de cette première année d’activité pour faire un petit bilan sur l’année écoulée et les perspectives pour 2018.

Bilan 2017

Il est positif, tant d’un point de vue comptable que d’activité.

D’un point de vue comptable, cela donne :

  • cela donne 100 K€ de CA réalisé,
  • 20 K€ de résultat après impôts
  • et l’équivalent de 160 - 170 jours facturés.

C’est clairement un succès. En reprenant mes prévisions et hypothèses d’activité de début d’année dernière, je suis dans la fourchette haute.

D’un point de vue activité, c’est plus contrasté :

  • le permier semestre fut l’opportunité de travailler avec de petites structures et sur des projets intéressants. Mais l’effet élection présidentielle a aussi créé un certain attentisme, diminuant le nombre de sollicitations, mettant fin plus tôt que prévu à certains projets et rendant l’appel de charges de Juillet un peu stressant.
  • Une mission à compter de mi-juin a permis de stabiliser la situation et de se remettre à flot.
  • Une propsition pour rejoindre une autre structure en cours de création en fin d’année a permis de se poser pas mal de questions sur mes aspirations et sur ma façon de travailler.

Un autre objectif que je m’étais donné en démarrant cette aventure était de contribuer en retour aux communautés Open Source. Profitant de l’écosystème open source, il est de notre devoir d’entreprise de contribuer à cet écosystème. Ce fut chose faite avec le sponsoring (modeste) des Rencontres Django à Toulon et ma partipation à l’édition 2017 de Codeurs En Seine où j’ai pu parler de la plateforme TICK et de Grafana.

Au final, une année riche en enseignements à de multiples niveaux (personnel, professionel, gestion d’une entreprise, etc)

Perspectives 2018

2018 commence bien avec une première mission intéressante et des sujets en cours de réflexion. Voici quelques objectifs que je me suis fixé :

  • Rester indépendant et développer CérénIT. Si l’année dernière, la question de rejoindre d’autres structures en tant que salarié s’est posée plusieurs fois, elle ne se pose plus. Seule celle de rejoindre une autre structure en tant qu’associé peut subsister sous réserve de certains critères.
  • D’un point de vue positionnement, se limiter à deux grandes activités. D’une part l’architecture et la direction technnique. D’autre part, l’automatisation et l’industrialisation dans une perspective de mise en place de pratiques DevOps/SRE.
  • Réflexion autour d’une logique de mentorat, d’accompagnement et de partage de connaissances avec des projets idéalement portés par des femmes pour favoriser la diversité dans notre milieu.

Pour atteindre ces objectifs, il y a quelques pistes :

  • Ne pas travailler 5/5j pour pouvoir dégager un peu de temps pour me former à différentes technologies ou pouvoir faire autre chose (mentorat & co ?). Si d’un point de vue facturation, cela peut paraitre contre-productif, c’est investir sur l’avenir pour obtenir de nouvelles missions, pouvoir augmenter progressivement mon TJM ou simplement avoir la satisfaction de contribuer à d’autres projets.
  • Continuer à contribuer en retour aux communautés open source
  • Continuer à postuler à des conférences (DevoxxFR, BreizhCamp, etc)
  • Continuer à aller à des conférences (Paris Serverless Conf, etc)
  • (Re)prendre contact avec des initiatives comme Led by Her, Start Her ou d’autres projets favorisant la diversité dans la tech.

Si certains sujets vous interpellent ou si vous avez des contacts à me suggérer, n’hésitez pas à me contacter.

Comme il est encore temps, j’en profite pour vous souhaiter à tou(te)s une bonne année 2018 et au plaisir de vous rencontrer, voire de collaborer ensemble.

Accessibilité

  • L’accessibilité n’est pas un luxe : un bon billet de rappel sur la nécessité et la relative facilité d’appliquer les bonnes pratiques d’accessibilité, y compris en utilisant les derniers frameworks à la mode.

Automatisation

AWS:ReInvent 2017

Cloud

  • EC2Instances.info Easy Amazon EC2 Instance Comparison (code source : un site permettant de comparer (plus) facilement les types d’instances EC2 chez AWS.
  • AWS GDPR Center : AWS met à disposition des ressources pour voir comment ils répondent aux objectifs de la GDPR qui s’applique à compter de Mai prochain et en quoi les plateformes cloud contribuent ou pas à ces efforts. Google Cloud a aussi son centre, tout comme Azure.
  • Servers.LOL : devriez-vous instancier une vm EC2 ou bien utiliser AWS Lambda ? Ce petit configurateur vous aide à prendre la “bonne” décision.

Elasticsearch

  • Elastic Stack 6.0 Upgrade Guide : un petit assistant mis à disposition par Elastic pour vous accompagner dans la migration vers Elastic 6.0 pour l’ensemble des composants.
  • Docker Performance Monitoring with Metricbeat and ELK Stack : Tutoriel indiquant comment remonter des métriques Docker (container, réseau, healthcheck, etc) via Metricbeat et leur ingestion dans Elasticsearch puis visualisation dans Kibana.
  • Elastic Stack 6.1.0 Released : le module d’APM a sa propre UI, Beats apprend à faire de l’autodiscovery sur docker en plus de voir la liste de modules s’enrichir, Kibana améliore toujours sa visualisation, etc.

Kafka

  • Introducing Confluent Platform 4.0 : nouvelle version majeure de cette plateforme autour de Kafka 1.0 et la consolidation des autres outils autour (Control Center, Kafka Streams, Connecteurs Kafka, etc)
  • Enabling Exactly-Once in Kafka Streams : le billet présente comment se gère le “exactly once message” dans un contexte Kafka Streams.
  • Kafkapocalypse: Monitoring Kafka Without Losing Your Mind : l’équipe de New Relic a transcrit un talk réalisé lors d’une conférence sur un incident majeur qu’ils ont eu avec Kafka et les points de vigilance qu’ils ont développé pour monitorer au mieux leur infrastructure kafka. Ils surveillent les notions de rétention (temps ET espace), la réplication et le retard des consommateurs (“consumer lag”). Si Kafka est une solution très intéressante, son monitoring reste une bête noire pour moi. La nécessité de passer par Confluent Platform et son Control Center semble être une nécessité pour le faire dans de bonnes conditions (ou de devoir monter ses propres dashboards).

(No)SQL

Serverless

TICK

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.

Big Data

  • Compte rendu du Spark Summit 2017 (Dublin) : La conférence européenne annulle de l’éditeur de Spark, Databricks, a cherché à montrer que le Streaming et le Deep Learning sont/seront bientôt plus accessibles via Spark et également la plateforme cloud DataBricks.

Dataviz

  • Grafana 4.6 Released : Nouvelle version de l’outil de visualisation des bases de données time series mais pas uniquement avec l’ajout de la source Postgres, du support de l’alerting pour Amazon Cloudwatch, des annotations simplifiées sur les graphs et autres améliorations sur la base prometheus.
  • Wizzy : il s’agit d’un ensemble de script pour versionner et se simplifier la gestion de ses dashboards réalisés sous Grafana. Pas encore testé, sous peu !

Cloud

  • Bootstrapping a Cloud with Cloud-Init and HypriotOS : j’avais croisé Cloud-Init dans Rancher OS mais n’avais pas eu le temps d’investiguer le sujet. Récemment, un podcast avec son créateur m’a permis d’en savoir plus sur le projet, à savoir que c’est un ensemble de script python qui permettent de configurer une machine lors de son initialisation (boot). Cet article permet du coup d’en avoir un exemple pratique par la configuration d’une image pour un Raspberry Pi 3 installant automatiquement le logiciel NextCloud sous la forme d’un container Docker.

Elasticsearch

  • An Ansible role to Manage your Elasticsearch Clusters : Synthesio publie son playbook ansible pour gérer des clusters Elasticsearch ; vu les clusters gérés, il y a surement de bonnes choses à récupérer - la limite étant peut être que pour un cluster de débutant, cela pourrait être trop complexe au regard du besoin. A évaluer suivant votre contexte.
  • Operating Large Elasticsearch Clusters : un retour d’expérience de l’équipe Synthesio sur la bonne gestion de leurs clusters ElasticSearch lors des Sysadmindays il y a peu.
  • La Stack ELK passe en 6.0 :
    • Elasticsearch 6.0.0 GA released : mise à jour sans downtime, index filtré, meilleures performances, meilleure résilience et meilleure sécurité (mot de passe, usage de TLS).
    • Logstash 6.0.0 GA released : il est désormais possible d’avoir des pipelines dont l’exécution se fait en parallèle et via X-Pack, il y a maintenant une UI pour piloter vos pipelines.
    • Kibana 6.0.0 GA released : Plein d’améliorations au programme : Export CSV, Amélioration de l’UI, Mode lecture seule pour pouvoir partager des dashboards et d’autres nouveautés spécifiques à X-Pack.
    • Beats 6.0.0 GA released : capture des données Docker/Kubernetes, auditbeat pour captuer les données d’auditd, une meilleure gestion des modules et de leur configuration, amélioration de performance et du stockage des données.
  • Devez-vous migrer vers Elasticsearch 6 : l’équipe Jolicode passe en revue les avancées de la version 6 et globalement conseille de passer vers cette version 6.

GraphQL

  • Modernisez vos API, passez à GraphQL ! (slides et vidéo) : Une introduction à GraphQL présentée à Codeurs en Seine 2017. Je reste toujours sceptique sur GraphQL, si coté client cela semble magique, personne ne montre la partie backend pour que la “magie” opère.
  • The GraphQL stack: How everything fits together : état des lieux suite à GraphQL Summit 2017 sur les parties cache, tracing (suivi d’une requête de bout en bout du système) et composabilité d’API (une requête GraphQL qui intérogge plusieurs API au lieu d’une).

Kafka

  • Apache Kafka Goes 1.0 : cette version 1.0 représente plutôt la complétude à l’égard d’une vision de ce que devait être Kafka que de sa stabilité ou de sa capacité à être utilisé en production. Le billet énoncce les derniers apports mais reviens surtout sur tout cette génése et la vision associée au produit.

(No)SQL

Time Series

select(db:"foo")
 .where(exp:{"_measurement"=="cpu" AND 
             "_field"=="usage_system" AND 
             "service"=="app-server"})
 .range(start:-12h)
 .window(every:10m)
 .max()

Agile

  • Isolation Continue : choisir librement l’ordre des mises en production : récit de la migration du modèle Gitflow vers un modèle où chaque fonctionnalité est isolée dans une branche dédiée et peut être réintégrée dans la branche de production aisément et rapidement. A contrario de Gitflow où la livraison contient un ensemble de fonctionnalités, là il est possible de moduler les fonctionnalités à déployer en fonction de son avancement et des besoins de déploiement. Cela n’empêche pas de tester ses branches et de déceler les bugs, voir même leur découverte a été accélérée.

Big Data

  • Genesis of M6’s Datalake : un retour d’expérience de l’équipe de M6 depuis leur usage d’une Data Management Platform d’un éditeur vers leur propre solution Hadoop avec le choix des composants et de l’infrastructure.

Container et Orchestration

Elasticsearch

  • 5 Filebeat Pitfalls To Be Aware Of : la sensibilité de yaml, le registre, le renommage/la suppressio n de fichiers de log, le multi-pipelines et l’usage CPU dans certains cas. Au passage, des recommandations d’options sur ces différents points.
  • Elastic APM enters alpha : Annoncé précédemment, Elastic commence à montrer son programme d’APM (Application Performance Management) avec une version alpha. Il ne permet de monitorer que des projets python ou node.js pour le moment. Il est fourni avec une première intégration dans Kibana. Ce produit est intégré dans la version 6.0.0 rc1

Licences & Open Source

  • Facebook grants full patent rights to all GraphQL users : après le débat le mois dernier sur la/les licences de ReactJS & co, Facebook a mis la spécification de GraphQL sous une licence libre (Open Web Foundation Agreement) et les implémentations Graphql.js et Relay sous licence MIT. Cela pourrait accéler le développement de l’écosystème GraphQL maintenant que les restrictions/doutes sont levés.

Mobile

  • React Native et CodePush : déployer sans compter : présentation de l’outil CodePush qui permet de mettre à jour son application mobile (basée sur React Native ou Cordova) sans repasser par les store pour un certain nombre de cas. Voir les limitations en fin d’article.

(No)SQL

  • Scaling the GitLab database : retour d’expérience de l’équipe de gitlab pour faire scaler la base de données du service gitlab.com. A la fin, pgpool et le hot standby ont été écartés, tout comme le sharding au profit de pgbouncer. Comme ils s’imposent d’intégrer les solutions qu’ils utilisent dans le produit (principe du eat your own food), cette solution permet d’avoir la haute disponibilité dans Gitlab Entreprise.

Architecture

CLI

  • Use .bashrc.d directory instead of bloated .bashrc : Une bonne astuce pour gérer tout ce que l’on veut mettre dans .bashrc sans que cela devienne une pagaille monstre : mettre tout dans un dossier et “sourcer” l’ensemble des fichiers s’y trouvant. Du coup, ça peut se versionner plus facilement/atomiquement ;-)

Cloud

Dashboard

  • Graphana 4.5 Released : des améliorations concernant surtout Elasticseach, Prometheus, MySQL, la capacité de rendre des valeurs cliquables pour investiguer une donnée, ainsi qu’un inspecteur de requêtes.

Docker

  • Preview: Linux Containers on Windows : annoncés à la DockerCon en Mai/Juin dernier, cela va arriver avec la version 17.09 de Docker : le support des conteneurs Linux depuis un hôte Windows. Jusqu’à présent, un hôte Windows ne pouvait faire tourner que des conteneurs Windows. A priori, on peut maintenant faire les 2 simultanément.
  • Docker Official Images are now Multi-platform : enfin ! Plus besoin de construire des images spécifiques pour ARM vs 64 bits, les images officielles de Docker savent le gérer nativement et de façon transparente. Avoir le même Dockerfile que l’on soit sur un serveur 64 bits ou un raspberry, cela va faciliter les chaines de développement et déploiement.
  • DockerHub Official Images Go Multi-platform! : un retour plus complet sur la gestion du passage au multi-platform des images Docker.

Documentation

Elastiscearch

  • A Full Stack in One Command : Elastic, pour appréhender les capacités de la stack Elastic, propose de mettre à dispositon des examples permettant de tester cette stack en 1 seule commande (et via l’utilisation de Docker Compose). Un premier cas est décrit, d’autres devraient suivre…
  • Elastic Stack 5.6.0 Released : Cette version de la stack Elastic prépare la migration vers Elasticsearch 6.0 et apporte quelques nouveautés, dont notamment un client REST Java de haut niveau pour Elasticsearch.

Kafka

  • Kafka 0.11.0 == ♥ : petit tour des améliorations de la version 0.11 de Kafka apportant les headers dans les messages, le support du “exactly once” via des notions d’idempotence et de transactions.
  • Exactly-once Support in Apache Kafka : le co-fondateur de Confluent revient sur la signification de “Exactly-once support” dans Kafka et sur son implémentation.
  • Exactly-once Semantics are Possible: Here’s How Kafka Does it : la même expliquée par la CTO de Confluent.
  • Introducing KSQL: Open Source Streaming SQL for Apache Kafka : Kafka se dote d’une interface SQL permettant de faire des requêtes de façon continue (continuous queries) et de requêter des topics kafka sous forme de stream et/ou de table et de mener quelques opérations dessus. Cela est basé sur l’API de Kafka Streams, il y aura un KSQL Server qui exécutera les requêtes KSQL à l’encontre d’un cluster Kafka. C’est encore en developer preview mais cela peut être intéressant à terme.
  • Mais c’est quoi Kafka : une présentation synthétique de Kafka et son écosystème pour bien appréhender cette plateforme.
  • BigData Hebdo - Ep 47 : Kafka, SQL, Beam & co : un excellent épisode du podcast BigData Hebdo faisant un point très clair sur les annonces Kafka (mais aussi sur Beam)
  • It’s Okay To Store Data In Apache Kafka : la question abordée dans l’épisode de BigData Hebdo trouve du coup un peu sa réponse dans ce billet où le co-fondateur de Kafka indique qu’il est possible de stocker ses données dans Kafka. Après, faut-il le faire, c’est un autre débat :-)
  • Kafka Wakes Up And Is Metamorphosed Into A Database : opinion sur la “métamorphone” de Kafka en base de données avec une opinion rigolote : “It would have been far funnier, of course, if Kafka woke up one morning and had been turned into CockroachDB”.
  • Crossing the Streams – Joins in Apache Kafka : le billet explique les capacités de jointure qu’il est possible de réaliser dans un contexte Kafka Streams. En fonction de si vous manipulez des KStreams ou des KTables, vous pourrez faire différents types de jointure (inner join, left join ou outer join).

Licences et Open Source

Microservices

  • Monolith First : Martin Fowler constate que les migrations réussies vers des micro-services se sont faites à partir de monolithes. A contrario, démarrer un projet en micro-services se solde souvent par des échecs. Il “recommande” donc de démarrer par un monolithe et de le modulariser puis de l’éclater en micro-services.

NoSQL

  • Redis 4.0.0 released : la version 4.x de la base Redis est sortie cet été et apporte son lot de nouvelles fonctionalités (réplication améliorée, appararition des modules, amélioration du cache, amélioration du monitoring, etc).
  • BigData Hebdo - Ep 46: Elassandra : Vous vouliez le meilleur des mondes entre Cassandra et Elasticsearch - c’est désormais possible avec Elassandra. Durant cet épisode, le créateur d’Elassandra explique comment il s’y est pris pour créer ce projet et atteindre cette promesse de combiner le meilleur des deux mondes via une intégration la plus légère possible et sans réduire les fonctionnalités de chaque outil.

SQL

Streaming

Vie du développeur

Web

Le Blog

Nous partageons ici notre veille et nos réflexions

Nuage de tags

docker kubernetes elasticsearch kafka postgres ansible grafana mysql tick influxdb sécurité python aws chronograf redis swarm cassandra cloud microservice spark terraform traefik angularjs confluent container graphql hashicorp javascript rancher serverless stream test api architecture arm csp devops docker-compose documentation elastic hpkp java kapacitor kibana lambda lean log microsoft npm orientdb rest rethinkdb reverse-proxy service-mesh sql ssh windows agile azure bash big-data certificat cli cluster cncf cookie dns fluxlang gcp gdpr git grav hsts https hypriot iac istio json ksql lets-encrypt licence linux mobile monitoring nginx opensource php prometheus redhat replication rsyslog scale solr systemd telegraf timescaledb vue.js wagtail yarn accessibilité akka alerte amazon-emr anonymisation apm ara automatisation bastion beam beat bilan bounded-context branche brigade browser buildkit cdc certificats checklist cloud-init cloud-storage cockroachdb code codeurs-en-seine consul containerd continous-delivery coreos cors cqrs crash cron crontab csrf css curl cérénit d3.js dashboard data-pipelining dataviz date ddd debezium debian desktop devoxx distributed-systems dive docker-app dokcer draft drop-in ebs ec2 elassandra electron elk engineering event-sourcing facebook falcor feature-policy feed filebeat firebase firefox fish flash flask fleet fluentd flux foundation framework frontend fullstack github glacier google 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 k8s kubeadm laravel liste-de-diffusion logstatsh loi machine-learning mailing-list management mariadb message micro-service molecule mot-de-passe multi-cloud médecine newsletter nomad nosql null openmetrics openshit openweb over-engineering packaging password performance perspective pip portainer publicité push queue quic raml react reaper reindex reinvent responsive revocation revue-de-code rkt rolespec root rpi rpo rto rwd s3 scaleway search select serverless-architecture service-worker sha1 shell shipyard société spinnaker sre sri ssl statistique superset sympa syslog-ng test-unitaire tiers timer timezone tls training travail ubuntu unikernel unit ux vault vie-privée virtualbox virtualenv vm vnc voxxeddays vpc

Syndication

Atom