5 décembre 2018Fred Aucun commentaire

Comment exécuter un script à intervalle régulier sur un CoreOS ?

Pour exécuter un script bash à intervalle régulié sur un CoreOS, on peut utiliser les systemd timers.

L’exemple ci-dessous copie un fichier vers un répertoire toutes les 2 minutes. Mais vous pouvez exécuter le script que vous voulez.

Créer le fichier service. Il doit être créé dans ce répertoire, et son nom doit se terminer par « .service »

sudo vi /etc/systemd/system/copy.service

Contenu du fichier de service

[Unit]
Description=Copy files from a folder to another

[Service]
Type=oneshot
ExecStart=/usr/bin/sh -c '/home/core/script/copy'

Le script appelé copy qui s’exécute dans le service

#!/bin/bash
# Copy the hello.png file to home folder
cp /tmp/hello.png /home/core/

Créez le timer. Il faut le mettre dans le même répertoire, et son nom doit se terminer par « .timer »

sudo vi /etc/systemd/system/copy.timer

Contenu du fichier

[Unit]
Description=Run service every 2 minutes

[Timer]
OnCalendar=*:0/2

Quelques commandes utiles

# Pour lister tous les timers
sudo systemctl list-timers --all

Cela permet de savoir quand le timer va s’exécuter à nouveau, et quand il s’est exécuté la dernière fois.

# Pour démarrer le timer
sudo systemctl start copy.timer

# Pour l'arrêter
sudo systemctl stop copy.timer

Voir la documentation :
https://coreos.com/os/docs/latest/scheduling-tasks-with-systemd-timers.html

18 avril 2018Fred Aucun commentaire

Comment Maven choisit entre une dépendance locale ou une dépendance Nexus ?

Lors d’un build Maven, celui-ci doit récupérer des dépendances. Il a le choix entre utiliser :
– une dépendance locale, elles sont dans le répertoire .m2 sur votre poste
Lorsque l’on builde du code en local (mvn install), les jars sont copiés dans ce .m2
– une dépendance distante sur Nexus
Elle sont créées par le server de build

Comment Maven choisit entre une dépendance locale ou Nexus ?

– Pour une dépendance en SNAPSHOT, il se base sur la date de build, si une version plus récente existe sur le server, c’est celle-ci qui est utilisée.
– Pour une dépendance en release, si elle existe en local, il ne va pas la récupérer sur le server.

Paramétrer ce comportement dans le settings.xml
Il y a un paramétrage pour les dépendances, et un pour les dépendances pour les plugins maven. Et pour chacun, il y a une partie pour les snapshots et une partie pour les versions releases.

<repository>
 <id>public</id>
 <name>Public Repositories</name>
 <url>http://ournexus.com:8081/nexus/content/groups/public</url>
 <releases>
  <enabled>true</enabled>
  <updatePolicy>XXX</updatePolicy>
  </releases>
 <snapshots>
  <enabled>true</enabled>
  <updatePolicy>XXX</updatePolicy>
 </snapshots>
</repository>

where XXX can be:
always: Maven will check for a newer version on every build;
daily, the default value;
interval:XXX: an interval in minutes (XXX)
never: Maven will never try to retrieve another version. It will do that only if it doesn’t exist locally. With the configuration, SNAPSHOT version will be handled as the stable libraries.

https://maven.apache.org/settings.html

Problème si vous ne compilez pas tous les modules régulièrement, ou si l’on a un problème d’ordre de build dans notre projet :
il est possible d’utiliser un vieux SNAPSHOT d’un de nos modules provenant de Nexus, alors que l’on pense utiliser un SNAPSHOT local.

11 avril 2018Fred Aucun commentaire

Comment modifier à chaud la configuration de logback ?

logback

Pour pouvoir modifier à chaud la configuration de logback,
il faut modifier la balise « configuration » du fichier logback.xml et rajouter scanPeriod.

par exemple

<configuration scan="true" scanPeriod="5 seconds">

Par défaut, la période de scan des modifs est d’une minute. Il est possible de la modifier comme ici à 5 secondes.
Vous pouvez maintenant modifier ce que vous voulez, le niveau de log, les appenders, etc …

documentation :
https://logback.qos.ch/manual/configuration.html#autoScan

4 avril 2018Fred Aucun commentaire

Comment faire du ménage dans vos branches git ?

Lorsque l’on travaille sur une application versionnée sur Git, il est normal de créer régulièrement des branches. Le problème, c’est que les branches inutiles ne sont pas toujours supprimées au fur et à mesure.

Comment faire du ménage dans vos branches git ?

Lister les branches

Lister les branches distantes, avec la date du dernier commit, triée par date de commit

for branch in `git branch -r | grep -v HEAD`; \
do echo -e `git show --format="%ci" \
$branch | head -n 1` \\t$branch; done | sort -r

2018-03-28 12:13:23 +0200 origin/master
2018-03-26 12:13:23 +0200 origin/develop
2018-03-26 11:14:05 +0200 origin/feature-new-button
2018-03-23 18:35:41 +0100 origin/feature-fix-css
2017-03-23 17:36:50 +0100 origin/feature-new-page
2016-02-09 12:11:53 +0100 origin/feature-process
…

Lister les branches en local, non mergées sur develop

En principe, ceux sont des branches qui ne doivent pas être supprimées, car elles n’ont pas été mergées sur la branche develop (choisir master dans la commande si vous n’utilisez pas de branche develop).

De plus, si vous avez squashé certaines branches après merge, elles peuvent se retrouver dans cette liste, même si vous l’avez mergée sur develop. Car lors d’un squash, le hash du commit change.

 git branch --no-merged develop

Une fois que vous avez ces listes de branches, il va falloir supprimer les branches qui vous paraissent inutiles !

Supprimer les références de branches distantes, pour lesquelles on n’a pas de branches locales

Pour voir la liste

git remote prune origin --dry-run

Pour supprimer les références

git remote prune origin

Supprimer une branche locale

Par exemple, la branche locale « feature/mybranch »

git branch -D feature/mybranch

Supprimer une branche distante

Par exemple, la branche distante « feature/mybranch », (il faut avoir les droits)

git push origin --delete feature/mybranch

29 mars 2018Fred Aucun commentaire

Comment générer des setters avec return this dans Intellij ?

Dans Intellij, il est possible de générer les setters d’une classe. Il peut être intéressant dans certains cas de renvoyer « this » dans ces setters.

– Faire Alt Insert, « getter and setter »
– Choisir « Setter template : Builder »

Voir l’impression écran ci-dessous.

28 mars 2018Fred Aucun commentaire

Comment faire un heap dump de la JVM d’un container Docker ?

Si vous n’avez pas de jdk dans vos containers Docker, vous ne pourrez pas directement faire de heap dump de la JVM. Par exemple, si vos containers sont basés sur Alpine, avec un jre OpenJdk. Il n’y a pas les outils nécessaires.

Exemple pour faire un heap dump. Les commandes sont à effectuer depuis la machine hôte.

# Installer un OpenJdk pour pouvoir lancer le dump
docker exec -ti container-name apk add \ 
--no-cache openjdk8

# Lister les process java du container, 
# et mémoriser celui de l'application, ici c'est le 22
docker exec -ti container-name jps

# Créer un heap dump
# à la fin de la commande, remplacer 22 par le bon pid
# le dump se fait ici à la racine /
docker exec -ti container-name jmap \
-dump:live,format=b,file=/heapDump.hprof 22


# Copier le dump, 
# du container vers la machine hôte
docker cp container-name:/heapDump.hprof ./