Ce livre sur Terraform s’adresse aussi bien aux « Devs » qu’aux « Ops », débutants ou disposant déjà de notions de base, qui souhaitent maîtriser le développement d’une infrastructure sur le cloud. Le lecteur y trouvera des cas d’usage illustrés par des exemples de code variés lui permettant d’être à l’aise avec son langage, son utilisation et son écosystème.
Apache Tomcat est le plus célèbre des conteneurs de Servlets Java. Les versions se succèdent au fil des années. Avec Spring Boot, et son utilisation de la version «embedded», son usage en tant que serveur «installé» a diminué, mais il reste encore au cœur de la majorité de nos micro-services, parfois sans que les développeurs s’en rendent compte.
Chaque version majeure de Tomcat apporte le support des nouvelles versions des API Java EE ou JEE.
Dans cet article, nous allons voir comment déployer SonarQube sur Clever Cloud en deux temps. Le premier consistera en un déploiement très simple, qui est équivalent à une installation locale. Dans un second temps, nous utiliserons une base de données PostgreSQL externalisée pour assurer la persistance des données.
Cet article suppose que vous avez déjà un compte actif sur Clever Cloud, et que votre CLI est installé et configuré. L’installation du CLI est décrite dans la documentation de Clever Cloud.
HTTP, pour Hypertext Transfer Protocol, est le protocole principal pour les échanges internet. Il est utilisé aussi bien par le navigateur que vous utilisez pour lire cet article, que pour faire communiquer des applications. Il s’appuie sur un éhange de requête et réponse, entre un client et un serveur, au format texte. L’avantage du format texte est qu’il est facile à implémenter dans tous les langages de programmation. Le protocole HTTP est spécifié par la RFC 2616, protocole dont la toute première version d’HTTP date de 1990.
Que ce soit pour un projet d’entreprise ou un projet open-source, la documentation utilisateur et technique est cruciale. Dans une documentation d’usage, les utilisateurs doivent pouvoir retrouver les instructions leur permettant d’accomplir les gestes métier de tous les jours. Pour la documentation technique, les administrateurs, opérateurs et développeurs doivent pouvoir retrouver les opérations d’installation, de mise à jour, ou encore de développement du produit.
La documentation peut prendre plusieurs formes:
Lors du développement d’une application pour Kubernetes, le développeur est souvent lié à une boucle de feedback assez longue:
Cette boucle est généralement implémentée par des pipelines de CI/CD. Ces pipelines augmentent encore le temps entre le développement et une application démarrée sur Kubernetes. Ce temps est relativement long lorsqu’on compare un cycle de développement local auquel un développeur peut être habitué.
Je suis le genre de développeur qui travaille toujours avec un terminal ouvert sur le côté, en plus de mon IDE.
Je lance souvent des commandes mvn pour m’assurer que mon projet compile et que mes tests s’exécutent correctement. C’est un vieux réflexe qui date de l’époque où les IDE n’avaient qu’un support limité de Maven. Lancer ces commandes hors-IDE m’aide souvent à valider que tout fonctionnera bien dans un environnement de CI par exemple.
J’ai donc parfois besoin de changer de version de Java en fonction du projet dans lequel je me trouve.
Maven utilise la variable d’environnement JAVA_HOME pour localiser l’installation de Java à utiliser. Donc être capable de charger des variables d’environnement différentes en fonction d’un projet peut s’avérer pratique.
Un autre usage courant consiste à venir charger des clé d’API ou des secrets d’accès cloud comme des variables AWS_ACCESS_KEY ou autres en fonction de mes différents projets.
La KeyLight se connecte à votre réseau WiFi. La première étape consiste à récupérer son adresse IP.
La keylight répond aux requêtes mDNS (multicast dns).
C’est d’ailleurs indiqué dans leur documentation:
Pour obtenir l’IP du keylight, il suffit donc d’emettre une requête DNS:
dig -p 5353 PTR _elg._tcp.local @224.0.0.251
; <<>> DiG 9.16.15-Ubuntu <<>> -p 5353 PTR _elg._tcp.local @224.0.0.251
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18533
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;_elg._tcp.local. IN PTR
;; ANSWER SECTION:
_elg._tcp.local. 10 IN PTR Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local.
;; ADDITIONAL SECTION:
Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local. 10 IN SRV 0 0 9123 elgato-key-light-air-f3df.local.
Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local. 10 IN TXT "mf=Elgato" "dt=200" "id=3C:6A:9D:16:12:45" "md=Elgato Key Light Air 20LAB9901" "pv=1.0"
elgato-key-light-air-f3df.local. 10 IN A 192.168.1.11
elgato-key-light-air-f3df.local. 10 IN AAAA fe80::3e6a:9dff:fe16:1245
;; Query time: 120 msec
;; SERVER: 192.168.1.11#5353(224.0.0.251)
;; WHEN: Fri Apr 15 13:55:25 CEST 2022
;; MSG SIZE rcvd: 254
On obtient l’URL d’accès au Keylight Elgato\032Key\032Light\032Air\032F3DF._elg._tcp.local., son IP 192.168.1.11 ainsi que son port d’écoute 9123
Je suis tombé sur un cas où un fichier a été ajouté dans git (commité), puis modifié par plusieurs commits successifs.
Malheureusement, ce fichier contient des credentials.
On va donc devoir supprimer ce fichier de tout l’historique git (oui ça implique une réécriture de la sainte branche main 😇).
Le fichier que je recherche s’appelle config.json.
Je vais faire un git log, pour trouver le commit qui a ajouté ce fichier.
I played a lot these days with xdotool, to try to automate some stuff for my Elgato Streamdeck.
These are the things I try to do:
Here are some links that I found about xdotool:
Below are the commands I found useful during my research.
As I prepare and run a lot of scripts, sometimes I need to run a script at a precise time of the day.
When a script must be only run once, cron is not a viable solution.
So I discovered the at scheduler
You need to install it first, using apt as usual.
$ sudo apt install at
at with a time / date$ at 9AM
warning: commands will be executed using /bin/sh
at> cd workspaces/github/dotfiles
at> git pull
at> <EOT>
job 1 at Sat Apr 16 09:00:00 2022
This example will pull a repository contents at 9 AM tomorrow !