Accueil
Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)
docker compose
(au lieu de l’original docker-compose
coté en python)COPY --chmod
reduced the size of my container image by 35% : pour réduire la taille de vos images, plutôt que de faire un ADD ...
puis un RUN chmod ...
, faites directement un ADD/COPY --chmod
. Marche aussi avec --chown
.depends_on
a une syntaxe longue qui permet de définir une condition sur l'état du service dépendant : démarré (valeur par défaut de la version courte), "sain" (en fonction du résultat d'un healthcheck) ou "terminé avec succès" (si votre service dépend du résultat d'un job ou d'une tâche).tig
pas très intuitif/pratique, GitUI pourrait vous plaire. Prévu pour le terminal, il permet de se ballader facilement dans votre historique git & co. L' outil en codé en Rust.argparse
est assez connu et peut être aussi Fire, c'est l'occasion de découvrir Click (par l'équipe derrière Flask & co et à ne pas confondre avec clikt en Kotlin), Typer (par le fondateur de FastAPI).compose
devrait devenir une sous-commande officiel de la CLI Docker ; on pourra alors faire docker compose up -d
jq
pour les données relationelles. Du SQL ou des fichiers Excel/CSV/JOSN/XML en entrée et les mêmes formats en sortie (et un peu plus).vector top
, la source internal_logs
et l'API GraphQL. Un guide de mise à jour vers la nouvelle syntaxe est disponible.Ce soir, il y a la 8ème édition du Paris Time Series Meetup sur AWS TimeStream.
scp file destination:/path/to/file
? La commande scp est victime de nombreuses failles. Du coup, elle va être dépréciée. Néanmoins une initiative vise à maintenir uen commande scp
mais se fondant sur sftp
et son modèle de sécurité.Pour ceux sous Fedora et utilisant podman en alternative au binaire docker, pour se connecter à la registry google (via):
gcloud auth print-access-token | podman login -u oauth2accesstoken --password-stdin gcr.io
Des nouvelles du Paris Time Series Meetup : l'éditions 6 sur TimescaleDB et l'édition 7 sur QuestDB
include
et extends
sont déjà sympathiques, les anchors
ont l'air de faire des choses intéressantes aussi !Sur la base des informations disponibles pour le moment :
Pour les moins bons côtés :
Une solution a priori très orienté pour du monitoring et qui semble souffir des mêmes travers qu'InfluxDB avec InfluxQL et pourtant en passe d'être résolus avec Flux.
On devrait en parler plus en détail dans une prochaine édition du Paris Time Series Meetup avec des personnes de chez AWS ;-)
Les "conventional commits" apportent une formalisation des messages de commit git. Ils sont de la forme :
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Pour reprendre quelques exemples :
# Commit message with no body
feat: allow provided config object to extend other configs
# Commit message with scope
feat(lang): add polish language
# Commit message with ! to draw attention to breaking change
refactor!: drop support for Node 6
# Commit message with both ! and BREAKING CHANGE footer
refactor!: drop support for Node 6
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
En forçant ce formalisme, le développeur est un peu moins tenté d'avoir un historique de commit du style :
fix button
typo
add some tests
add some tests
...
Au lieu de faire un commit à chaque sauvegarde du fichier ou presque, il va commencer à "raconter une histoire" :
fix: button on home page does not work on IE6
docs: typo in the README file
feat: add some tests for module XXX
Cela a le mérite aussi de générer un changelog plus agréable à lire. Si en plus, on rajoute par ex un identifiant de ticket, on peut alors facilement retracer l'historique d'un changement et sa raison d'être :
fix(123): button on home page does not work on IE6
docs(211): typo in the README file
feat(175): add some tests for module XXX
Un peu à la manière de "Properly managing your .gitignore file", on peut vouloir que le hook git s'applique à tous nos dépôts présents et à venir et ne pas avoir à contribuer le hook à chaque dépôt git.
# Create ~/.git-templates/hooks
mkdir -p ~/.git-templates/hooks
# Create commit-msg file and make it executable
touch ~/.git-templates/hooks/commit-msg
chmod +x ~/.git-templates/hooks/commit-msg
Ajoutons ensuite notre hooks dans ~/.git-templates/hooks/commit-msg
:
#!/usr/bin/env python3
# Original source: https://github.com/prahladyeri/enforce-git-message/
# Extended with BREAKING CHANGE, exclamation mark support (!) and space before " : " for French people
import re, sys, os
examples = """+ 61c8ca9 fix: navbar not responsive on mobile
+ 479c48b test: prepared test cases for user authentication
+ a992020 chore: moved to semantic versioning
+ b818120 fix: button click even handler firing twice
+ c6e9a97 fix: login page css
+ dfdc715 feat(auth): added social login using twitter
+ b235677 BREAKING CHANGE: remove support for XXX
+ a234556 revert!: back to version X.Y.Z for component ZZZ
+ b123456 feat : we support space before : for French people :-)
"""
def main():
pattern = r'(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test|BREAKING CHANGE)(\([\w\-\s]+\))?!?\s?:\s.*'
filename = sys.argv[1]
ss = open(filename, 'r').read()
m = re.match(pattern, ss)
if m == None:
print("\nCOMMIT FAILED!")
print("\nPlease enter commit message in the conventional format and try to commit again. Examples:")
print("\n" + examples)
sys.exit(1)
if __name__ == "__main__":
main()
Il faut ensuite indiquer à git que vos templates sont dans ce dossier :
git config --global init.templatedir '~/.git-templates'
Pour les dépots git existants, il faut réinitialiser votre dépôt git :
cd /path/to/git/repo
git init
Dépôt Git existant réinitialisé dans /path/to/git/repo/.git/
Vous pouvez alors commencer à travailler dans votre repo et valider le bon fonctionnement du hook.
~/.config/git/ignore
pour y mettre votre configuration personnelle (IDE, OS, etc) et limiter le .gitignore
de vos projets aux éléments de build & co.Meilleurs voeux à tous pour cette nouvelle année !
docker-compose.yml
et ensuite il montre les apports de Docker App, qui permet d'avoir un niveau de personnalisation supplémentaire. Ainsi, on peut avoir un seul fichier docker-compose.yml de référence et auquel on rajoute un fichier avec des propriétés par environnement ou par client ou par instance par ex. Une combinaison intéressante pour améliorer l'industrialisation de vos containers.Surveillez le Time Series Paris Meetup, car la première édition du Meetup sera annoncée mardi avec une présentation des usages avancées des séries temporelles avec Warp10 (comprendre au-delà du monitoring classique) et une présentation par les équipes OVH sur du monitoring de datacenter aidé par du machine learning et leur offre Préscience.
git checkout
par git switch
et git restore
pour mieux encadrer les usagesgit --force
est déconseillée si ce n'est proscrite, sa variante git --force-with-lease
est plus intéressante et permet d'éviter d'écraser le travail de vos camarades alors que vous pensiez juste faire un push en force sur une branche distante suite à un rebase local.Lorsque l'on déploie une même application dans plusieurs contextes via docker-compose
, il est intéressant d'utiliser le COMPOSE_PROJECT_NAME qui permet de donner un préfixe à vos réseaux et containers docker a minima.
L'inconvénient est qu'il faut ajouter à vos commandes un -p <project_name>
:
docker-compose -p instancea build --pull
docker-compose -p instancea up -d
docker-compose -p instancea logs -f
docker-compose -p instancea stop <service>
docker-compose -p instancea down
...
Ainsi, vos conteneurs seront nommés instancea_<service name>_<occurence>
et votre réseau instancea_<network name>
.
Mais il est possible d'aller plus loin avec les fichiers d'environnement .env
.
Dans votre fichier .env
à la racine de votre dossier où se trouve votre fichier docker-compose.yml
, définissez la/les variable(s) dont vous avez besoin. Ici, nous allons nous limiter à COMPOSE_PROJET_NAME
mais ne vous privez pas.
COMPOSE_PROJECT_NAME=instancea
A partir de ce moment-là, plus besoin de précier l'argument -p <project name>
, vos commandes redeviennent :
docker-compose build --pull
docker-compose up -d
docker-compose logs -f
docker-compose stop <service>
docker-compose down
...
... et pour autant, vos réseaux et containers ont le bon préfix car le fichier .env
est lu à l'exécution de la commande docker-compose
avant de parser docker-compose.yml
.
On peut aller encore plus loin en utilisant ce COMPOSE_PROJECT_NAME
dans le taggage des images d'un container par ex ou
version: '3'
services:
nginx:
build:
context: ./nginx/
image: "registry.mycompany.com/nginx:${COMPOSE_PROJECT_NAME}"
Lors de la phase de build, l'image sera tagguée avec le nom passé au projet compose. Ensuite, vous pouvez poussez sur la registry de votre entreprise puis déployer cette version sur votre cluster Swarm par ex.
A noter justement une limitation actuelle de docker stack deploy <stack name> -c docker-compose.yml
qui ne lit pas le fichier .env
en amont et donc COMPOSE_PROJECT_NAME
reste vide lors de la lecture du fichier docker-compose.yml
.
Une solution possible est par ex dans le script (simplifié) de déploiement :
cd $BUILDDIR/compose/
source .env
# Remplace la variable COMPOSE_PROJECT_NAME par sa valeur
sed -i -e "s/\${COMPOSE_PROJECT_NAME}/${COMPOSE_PROJECT_NAME}/g" docker-compose.yml
docker stack deploy ${COMPOSE_PROJECT_NAME} -c docker-compose.yml
Et voilà !