Publié le 26 Septembre 2016

Il peut être intéressant de limiter les nombres de cores CPU disponible pour un conteneur.

Par exemple on peut vouloir n'utiliser qu'un seul core pour les conteneurs docker de façon à laisser assez de CPU disponible pour l'hôte.

docker permet de préciser les cores CPU utilisable par un conteneur grâce à l'option --cpus-set.

Cette option accept soit une liste de nombres et/ou d'intervalles.

Par exemple

--cpus-set 0 # CPU 0
--cpus-set 0-3 # CPU 0, 1, 2 et 3
--cpus-set 0,2-4 # CPU 0, 2, 3 et 4

et dans une commande docker run ça donne quelque chose comme:

docker run --cpus-set 0 <image> <commande>

Voir les commentaires

Rédigé par Bliz

Publié dans #docker

Repost 0

Publié le 23 Septembre 2016

Si vous utilisez git avec les feature branch vous avez probablement beaucoup de branch qui ont été mergées et qui ne servent plus à rien mais qui reste là car c'est un peu ennuyeux de les supprimer manuellement.

En revanche sur le repo central les branches mergées sont souvent supprimées automatiquement lorsqu'on merge la pull request associée.

Et bien on peut simplement profiter de ce fait lorsqu'on met à jour notre repo local. Il suffit d'utiliser l'option --prune lorsqu'on pull/fetch le repo central.

git fetch --prune

ou

git pull --prune

Voir les commentaires

Rédigé par Bliz

Publié dans #git

Repost 0

Publié le 19 Septembre 2016

Si vous utilisez docker vous avez surement remarqué que l'espace disque utilisé augmente rapidement. Voici quelques règles pour économiser un peu de place sur votre disque.

Supprimer les volumes associés à un conteneur

Lorsqu'on supprime un conteneur penser à utiliser l'option -v qui permet de supprimer les volumes associés à un conteneur.

Pour supprimer tous les conteneurs qui ne tournent pas on peut utiliser la commande suivante:

docker rm -v $(docker ps -aqf status=exited)

Recréé un conteneur est assez rapide du moment que son image est disponible. Ce qui nous amène vers le nettoyage des images inutiles.

Supprimer les images inutiles

J'appelle image "inutile" une image "intermédiaire" qui sert dans la construction d'une image "finale" et qui n'est donc jamais utilisé pour créer un conteneur.

On peut supprimer ces images avec la commande suivante:

docker rmi $(docker images -qf dangling=true)

Souvent indispensable après un docker pull.

Supprimer les volumes orphelins

Un volume orphelin est un volume pour lequel son conteneur associé a été supprimé sans l'option -v. Pour supprimer ces volumes on a la commande suivante:

docker volume rm $(docker volume ls -qf dangling=true)

Voir les commentaires

Rédigé par Bliz

Publié dans #docker

Repost 0

Publié le 16 Septembre 2016

J'ai récemment eu un build sbt qui échouait à cause d'un OutOfMemory exception.

La solution: donner plus de mémoire à sbt. Et la bonne nouvelle c'est que c'est maintenant beaucoup plus simple. Il suffit d'ajouter l'option -mem. Par exemple:

sbt -mem 2048 run

Voir les commentaires

Rédigé par Bliz

Publié dans #Scala

Repost 0

Publié le 13 Septembre 2016

Dans un fichier build.sbt les dépendances se déclarent de la façon suivante:

libraryDependencies += "org.nd4j" % "nd4j-native-platform" % "0.5.0"

mais parfois on trouve aussi un double pourcent "%%"

libraryDependencies += "com.typesafe.akka" %% "akka-actor" % "2.4.8"

Quelle est la différence ?

Dans le premier cas (%) on déclare une dépendance vers une librairie java (qui ne dépend pas de la version de scala donc). Dans ce cas le % est suffisant.

Dans le deuxième cas on déclare une dépendance vers une librairie scala qui dépend de la version de scala. Le %% ajoute automatiquement la version de scala au nom de la librairie.

C'est donc équivalent à ceci:

libraryDependencies += "com.typesafe.akka" % "akka-actor_2.11" % "2.4.8"

Notez le suffixe '_2.11' à la fin du nom de la librairie. Le %% permet de l'ajouter automatiquement.

Voir les commentaires

Rédigé par Bliz

Publié dans #Scala

Repost 0