vendredi 2 septembre 2016

Migration du blog

Ayant fait l'acquisition d'un nom de domaine j'ai migré le blog vers http://pro.fabien-travaglia.fr
Tout nouvel article sera rédigé sur le nouveau blog.

jeudi 7 avril 2016

Docker registry avec certificat auto-signé (--insecure-registry)

Démarrer le registry sur le serveur

docker run -d -p 5000:5000 --restart=always --name registry \
  -v {chemin_du_fs_stockage_des_donnes}/data:/var/lib/registry \
  registry:2f

Authentification auto-signé (Voir https://docs.docker.com/registry/insecure/ ) 

myregistrydomain => ip, dns du serveur hébergeant le registry
Attention! Pas du tout adapté pour un environnement de PROD ! 

Génération du certificat sur le serveur hébergeant le registry

 mkdir -p certs && openssl req \
  -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \
  -x509 -days 365 -out certs/domain.crt
Be sure to use the name myregistrydomain.com as a CN.


Démarrage du registry avec les certificats

docker run -d -p 5000:5000 --restart=always --name registry \
-v {chemin_contenant_les_crt_key}:/certs \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key registry:2

Coté client

Attention testé uniquement sur Ubuntu, la facon diffère selon les distributions. Cela doit fonctionner sur distribution qui sont basés Debian sur car Ubuntu est développé a partir de celui-ci.
RedHat & les autres distribution ont leur propre facon d'ajout de certificat.


  1. Récupérer le certificat généré utilisé par le registry
  2. Sous Ubuntu aller dans /usr/local/ca-certificates
  3. Déposer le certificat update-ca-certificates
  4. service docker stop 
  5. vi /etc/default/docker
  6. Ajouter DOCKER_OPTS="--insecure-registry {url-registry}:5000" (Ex: DOCKER_OPTS="--insecure-registry myregistrydomain.com:5000" )
  7. service docker start 


Commandes 


myregistrydomain => ip, dns du serveur hébergeant le registry

Déposer une image sur le registry

docker push myregistrydomain.com:5000/{images}/{tag}

Obtenir une image du registry

docker pull myregistrydomain.com:5000/{images}/{tag}

Lister les images dans le docker repository

Sur le serveur hébergeant le registry ont peut trouver les repositories correspondant aux images déposés dans le registry

ls -l {chemin_du_fs_stockage_des_donnes}/data/docker/registry/v2/repositories

lundi 26 octobre 2015

Page blanche lors de l'installation de testlink

Problème

Après avoir installé (migration testlink 1.9.13 > 1.9.14) testlink j'avais une page blanche sur tout le site.
La page blanche survenait lorsque je copias le fichier config_db.inc.php contenant les infos de connexion à la base de donnée.

Solution

Après avoir déclaré un incident mantis a l'équipe gérant testlink (http://mantis.testlink.org/view.php?id=7311) il s'avère que c'était bêtement un problème de droits sur deux répertoires.

Il m'a suffit de changer les droits pour les répertoires en 775: 

{testlink_install}/gui/templates_c
{testlink_install}/logs



mardi 10 février 2015

Stubber des classes dans une chaine d'appel pour cloisonner les test d'intégration

Problème

Dans le code applicatif une classe qui faisait un appel web service vers une autre application. 

Je voulais tester ma méthode a travers un test d'intégration sans pour autant faire l'appel réel vers le web service afin de ne pas créer de couplage pendant l’exécution de mon test.

J'ai voulu utiliser Mockito et PowerMock afin de stubber la classe mais cette classe était utilisée très loin dans la chaine d'appel (Le TI que je faisait était de haut niveau). 

Mon test était donc dépendant du service distant.

Solution

Exclure les classes gênantes

J'ai exclu dans ShrinkWrap les classes gênantes dans la construction de l'archive java pour Arquillian : 

package fr.ftravaglia;

import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.shrinkwrap.api.Filters;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.EmptyAsset;
import org.jboss.shrinkwrap.api.spec.JavaArchive;
import org.junit.runner.RunWith;

import fr.ftravaglia.RemoteServiceMails;
import fr.ftravaglia.RemoteServiceAdresses;


@RunWith(Arquillian.class)
public class ArquillianInit {
  
 @Deployment
 public static final JavaArchive createArchive() {
  return ShrinkWrap
    .create(JavaArchive.class, "demo-ftravaglia.jar")
    .addPackages(true, Filters.exclude(RemoteServiceMails.class, RemoteServiceAdresses.class), "fr.ftravaglia")
    .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
    .addAsResource("META-INF/persistence.xml",
      "META-INF/persistence.xml");
 }
}

Ajouter les stubs coté test

Dans la partie test du projet (src/test/java) j'ai crée deux classe remplaçant celle qui ont été exclues.
Dans mon projet j'utilise CDI. Les classes injectés le sont a travers des qualifiers car les instances sont représenté par des interfaces pour l'IOC.

Voici une des classes (la deuxième a la même structure) 


package fr.ftravaglia;

import fr.ftravaglia.RemoteServiceMailsEAO;
import fr.ftravaglia.RemoteServiceMailsImplWS.RemoteServiceMailsQualifier;

/**
 * Use for not call remote app.
 */
@RemoteServiceMailsQualifier
public class RemoteServiceMailsMock implements RemoteServiceMailsEAO {

 /**
  * Default constructor
  */
 public RemoteServiceMailsMock() {
  super();
 }
 
 /**
  * {@inheritDoc}
  */
 @Override
 public boolean isMailValid(String mail){
  boolean result = false;

  if (mail != null && !mail.isEmpty()) {
   result = true;
  }
  return result;
 }

}

Dans le code applicatif réel l'injection se fait par :

@Inject
@RemoteServiceMailsQualifier
private transiant RemoteServiceMailsEAO serviceMailEAO;

Du coup lorsque d'Arquillian se lance et publie l'application dans le serveur d'application embarqué, les classes sont supprimés de l'archive et celles définies en tant que stubs sont utilisés a la place des classes réelles.

En cas de questions n'hésitez pas ;)


jeudi 5 février 2015

Insufficient privileges avec SonarQube 5.0 et Jenkins

Problème

Suite au passage a SonarQube 5.0 les jobs jenkins qui étaient responsable de faire l'analyse Sonar ne fonctionnaient plus. 

J'avais comme erreur : 
Caused by: java.lang.IllegalStateException: {"errors":[{"msg":"Insufficient privileges"}]}

Après quelque recherche je me suis rendu compte que c'était lié au changement de profil qualité (Quality Profiles).

Solution

Prérequis:
Avoir les accès admin sur Sonar et Jenkins
  • Créer dans Sonar un utilisateur 
  • Aller dans le fichier sonar.properties sur le file system
  • Ajouter dans le fichier : sonar.security.localUsers: {utilisateur-technique-crée}
  • Aller dans la configuration Jenkins (Adminstrer Jenkins > Configurer le système)
  • Puis dans la partie 'Installations de Sonar'
  • Dans 'Login du compte Sonar' mettre le login de l'utilisateur sonar crée
  • Dans 'Mot de passe du compte Sonar' mettre le mdp associé au login
  • Aller dans l'interface web de Sonar
  • Cliquer sur 'Settings' puis 'Global Permissions'
  • Ajouter l'utilisateur défini dans Jenkins pour les permissions de : Execute Analysis et Execute Preview Analysis
  • Ensuite pour chaque projets il faut attribuer le droit de 'BROWSE' à l'utilisateur technique
Après ces modifications mes builds sonar fonctionnaient de nouveau.

Plus d'infos sur les utilisateurs techniques de sonar : http://docs.sonarqube.org/display/SONAR/Authentication#Authentication-TechnicalUsers

Enjoy !