Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Réunion de la communauté du libre

Fedora Paris

L'April et Parinux ayant décidé de faire un apéro commun le 15 janvier, Fedora Paris a décidé de se joindre à eux. Ce sera l'occasion de se souhaiter la bonne année et de discuter avec nos amis libristes pour voir si on ne peut pas faire quelque chose en commun pour promouvoir le Logiciel Libre en général et Fedora en particulier. Nous nous... Lire Réunion de la communauté du libre

PHP version 7.0.2RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests. Uniquement pour x86_64.

Les RPM de PHP version 7.0.2RC1 sont disponibles en SCL dans le dépôt remi-test pour Fedora20 et Enterprise Linux 6 et les paquets de base dans le dépôt remi-php70-test pour Enterprise Linux6.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 7.0 :

yum --enablerepo=remi-test install php70

Mise à jour, de PHP 7.0 :

yum --enablerepo=remi-php70,remi-php70-test update php\*

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php70)

Paquets standards (php)

Bonnes fêtes de fin d'année et nouvelles...

Sylvain Réault

Et bien je vous souhaite de bonnes fêtes de fin d'année.

Il n'y aura pas de nouvelle version des paquets car il manque une mise à jour de la libdrm qui devrait être disponible rapidement je l'espère.

Du coup la nouvelle version sera disponible en début d'année si tout vas bien. N'étant pas fixé sur mon emploi du temps d'ici là, je ne peux pas non plus trop m'avancer.

Sur ceux @ l'année prochaine :).

PHP version 7.0.1

Remi Collet

Les RPM de PHP version 7.0.1 sont disponibles dans le dépôt remi-php70 pour Fedora 21 et Enterprise Linux6 (RHEL, CentOS), ainsi qu'en Software Collection dans le dépôt remi-safe.

Annonces de la version :

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.0 (le plus simple) :

yum-config-manager --enable remi-php70
yum update

Installation en parallèle, en Software Collection de PHP 7.0 (x86_64 uniquement) :

yum install php70

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.1 (les prochains utiliseront 7.2)
  • la version EL6 est construite avec RHEL-6.7
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php70)

PHP version 5.6.17RC1 et 7.0.1RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests.

Les RPM de PHP version 5.6.17RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 20-23 et Enterprise Linux 6-7.

Les RPM de PHP version 7.0.1RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le nouveau dépôt remi-php70-test pour Fedora 20-23 et Enterprise Linux 6-7.

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi-test install php56

Installation en parallèle, en Software Collections de PHP 7.0 (x86_64 uniquement) :

yum --enablerepo=remi-test install php70

Mise à jour, de PHP 7.0 (x86_64 uniquement) :

yum --enablerepo=remi-php70-test update php\*

A noter : la version 5.6.17RC1 est aussi disponible dans Fedora rawhide.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php56, php70)

Paquets standards (php)

Semaine électorale chez Fedora !

Charles-Antoine Couret

Si la France est actuellement en pleine période électorale pour les élections régionales, Fedora n'est pas en reste avec cette semaine pas moins de trois élections.

En effet, comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et FAmSCo. Et ce sont les contributeurs qui décident ! Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mardi 15 décembre à 1h du matin heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le FAmSCo. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour l'une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

FAmSCo

Le FAmSCo (Fedora Ambassadors Steering Committee) est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur.

Voici un exemple des thèmes dont il a compétence :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Les 7 membres de cette équipe sont également entièrement élus avec une durée de mandat d'un an. Chaque élection renouvelle le collège par moitié.

Compte rendu des JM2L 2015

Charles-Antoine Couret

Me voici de retour de cette nouvelle édition de la Journée Méditerranéenne du Logiciel Libre placée sous le signe récurrent du soleil mais aussi du thème Do It Yourself.

Contrairement aux éditions précédentes, la journée du vendredi n'a pas eu lieu faute de moyens. Les locaux de l'école Polytech'Nice ont enfin terminé leurs travaux ce qui a facilité la découverte des lieux. Cette fois, le bâtiment des stands / install party était dissocié de celui des conférences. Ce n'était pas forcément un problème, si ce n'est que durant certaines plages horaires le bâtiment qui m'était affecté était plutôt vide.

La journée s'est très bien passée, l'affluence était habituelle probablement aux alentours de 150-200 visiteurs/participants. C'était l'occasion de revoir la communauté locale des environs de Toulon/Sophia-Antipolis que je ne vois plus beaucoup depuis mon déménagement. Bien entendu lors de la tenue du stand j'ai été amené à rencontrer du monde.

Contrairement à d'habitude, la plupart des visiteurs semblaient connaître Fedora de nom ce qui a facilité un peu la présentation. Beaucoup ont encore des difficultés à assimiler la différence par exemple entre le projet Fedora et Ubuntu. Ce rappel n'est pas un problème. J'en ai profité pour faire une démonstration d'une Fedora 23 sous Gnome-Shell en fonctionnement ce qui a intéressé de nombreux curieux. Des personnes plus connaisseurs se sont intéressées à la question des spins de Fedora notamment la version ARM dans un cadre d'une box domotique. La connexion n'était hélas pas suffisante pour télécharger sur place une telle image afin d'effectuer un essai.

DSC_0256_b.JPG

Les membres du stand d'OpenSuse sont également venus échanger quelques mots à propos d'OpenQA, projet pour automatiser les tests dont la distribution au caméléon est d'origine et que le projet Fedora met en place de son côté actuellement.

Les quelques DVDs de Fedora 22 que j'avais ont pu en partie s'écouler. Cela est devenu difficile avec la Fedora 23 disponible depuis près d'un mois. Quelques goodies ont également été distribués / vendus. Borsalinux-fr accueille également un nouvel adhérent.

C'est donc au plaisir de vous revoir à ce genre d'évènements. Un grand merci à Emmanuel Seyman pour le matériel et aux organisateurs des JM2L pour leur hospitalité et leur organisation. À l'année prochaine, et cette fois-ci je tiendrais une conférence !

Le jour d'après

Matthieu Saulnier

Ce matin (enfin cet après-midi) j'ai trouvé le message que je me suis laissé hier soir (ou plutôt la nuit dernière). On papotait à propos de fallback, de système de backup fiable, et surtout de trouver des failles dans un système en place.

Visiblement il s'agit de la description de mon système de fallback, fait de ma main. J'aurais aimé me souvenir si on a trouvé des failles évidentes (ou moins évidentes), sachant que l'évidence augmente proportionnellement avec la concentration de sang par litre...

Petite note : fichier1-200Gio et fichier2-200Gio sont des noms de fichier normaux, faisant une taille de 200Gio chacun, avec des propriètaires/groupes d'utilisateur Linux normaux avec des permissions standards. C'est un peu comme des fichiers ISO mais ce sont en fait des volumes LUKS.


fallback2.jpg

PHP version 7.0.0 est sortie !

Remi Collet

La RC était bien GOLD, donc la version 7.0.0 GA vient juste d'être publiée, à la date prévue.

Un grand merci à tous les développeurs qui ont contribué à cette nouvelle version majeure de PHP, et à tous les testeurs des versions RC qui ont permit de livrer un version de qualité.

Les RPM sont disponibles dans le dépôt remi-php70 pour Fedora 21 et et Enterprise Linux 6 (RHEL, CentOS) ainsi qu'en Software Collection dans le dépôt remi-safe.

Grâce aux importants gains de performance de cette version, vous allez pouvoir contribuer à l'effort contre le réchauffement climatique en éteignant la moitié de vos serveurs !

Lire l'annonce de version PHP 7.0.0 Release Announcement (en anglais).

La tribu sagrandit:

Tribe.jpg

 

Lire aussi :

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.0 (le plus simple) :

yum-config-manager --enable remi-php70
yum update php\*

Installation en parallèle, en Software Collection de PHP 7.0 (x86_64 uniquement, recommandée pour les tests) :

yum install php70

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.1
  • la version EL6 est construite avec RHEL-6.7
  • les extensions commencent à être disponibles, voir la page PECL extension RPM status..

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php70)

PHPUnit 5.1

Remi Collet

Les RPM de PHPUnit version 5.1 sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (CentOS, RHEL...)

Documentation : PHPUnit 5.0 manual et Release Announcement for PHPUnit 5.1.0 (english)

emblem-notice-24.pngCette nouvelle version nécessaite PHP ≥ 5.6.

Certaines dépendances ne sont pas encore compatibles

  • php-phpunit-PHPUnit-Selenium

En attendant leur disponibilité, cette version reste donc uniquement dans le dépôt remi-test.

Installation :

yum --enablerepo=remi,remi-test,remi-php56 install phpunit

Remarque: cet outil est un epièce essentielle de la QA PHP dans Fedora.

QElectroTech version 0.5

Remi Collet

Les RPM de QElectroTech version 0.5, une application pour réaliser des schémas électriques, sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux 7.

Seulement 9 mois après la sortie de la version 0.4, le projet vient de publier une nouvelle version de son éditeur de schéma électriques.

Site officiel : http://qelectrotech.org/ (avec l'annonce de version)

Annonce de la version sur linuxfr.

Bien sur l'installation se fait avec YUM :

yum --enablerepo=remi install qelectrotech

Les RPM (version 0.50-1) sont disponibles pour Fedora ≥ 19 et Enterprise Linux 7 (RHEL, CentOS, ...)

Les mises à jour sont aussi en route pour les dépôts officiels

À noter :il existe aussi un dépôt Copr / Qelectrotech avec les versions de "dévelopement" (actuellement la 0.5).

Fin de vie de la Fedora 21

Edouard Bourguignon

Un bref rappel concernant la Fedora 21, celle-ci ne sera plus maintenue à partir du 1er décembre 2015. Pensez à migrer vers une Fedora plus récente.

Deuxième version de Mesa 11.2-devel en route

Sylvain Réault

Une nouvelle version des derniers développements de Mesa arrive dans sur le dépôt avec en prime la version RAWHIDE des paquets (actuellement la branche de développement pour Fedora 24).

Beaucoup d'améliorations et pas mal de corrections de bogues en vue. Je ferai un retour d'ici lundi.

N'hésitez pas à faire votre propre retour dans les commentaires.

Forum PHP Paris 2015

Remi Collet

De retour du Forum PHP Paris 2015.

Tout d'abord un grand merci à l'AFUP pour l'organisation de ce grand moment pour la communauté, comme toujours, accueil irréprochable.

Cet événement a été, une nouvelle fois, l'occasion de faire de nombreuses et enrichissantes rencontres avec de nombreux développeurs et utilisateurs de PHP.

Cette année exceptionnelle en raison des 20 ans de PHP, des 15 ans de l'AFUP et bien entendu de la sortie imminente de PHP 7:

22976893670_aa78e7414b_o.jpg 

Sur la photo : (en haut) Derick Rethans, Anatol Belski, moi, Zeev Suraski, (en bas) Pierre Joye, Rasmus Lerdorf, Bob Weinand et Nikita Popov.

Plus de photos sur Flickr.

J'ai eu l'opportunité de donner une conférence sur la collaboration entre upstream (projets) et downstream (distribution) avec un point important sur les tests réalisés par le projet Fedora.

Lire le support de cette présentation: Paris2015.pdf.

Les retours me semblent bons, cf fiche joind.id.

J'attends avec impatience les prochaines conférences.

PHP version 5.6.16

Remi Collet

Les RPM de PHP version 5.6.16 sont disponibles dans le dépôt remi pour Fedora 21 et remi-php56 pour Fedora ≤ 20  et Enterprise Linux (RHEL, CentOS).

Annonces de la version :

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 5.6 (le plus simple) :

yum-config-manager --enable remi-php56
yum update

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum install php56

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.1
  • la version EL6 est construite avec RHEL-6.7
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php56)

Mesa 11.2.0-devel pour Fedora 23 disponible

Sylvain Réault

La première version de Mesa 11.2-devel est disponible. Les paquets datent de dimanche.

Une refonte du site est aussi en cours, cela devrait être disponible ce week end si tout vas bien. Pour le moment ce ne sera que la migration vers Drupal 8. Par la suite un site complètement refait de font en comble.

La version Rawhide des paquets est en route, cela devrait être bon ce soir ou demain dans la soirée.

Dockerized

Matthieu Saulnier Docker, c'est la grande mode du moment. Ce projet très récent permet de cloisonner facilement n'importe quel processus avec une installation simplifiée. La gestion exceptionnelle du chainage entre les conteneurs tout en restant isolé de l'hôte ouvre des possibilités assez hors-norme. La documentation officielle et de nombreux articles traitent déjà la bonne manière pour installer le moteur Docker, et comment démarrer un nouveau service à partir de rien. La problématique pour les vieux sysadmins est légèrement différente, puisque nous avons déjà un nombre conséquent de services qui tournent sur nos serveurs LAMP traditionnels, et qui ne demandent qu'à être aussi dockerizé. À cette problématique vient s'ajouter celle du backup des données statiques, engendrées par l'utilisation de l'application. La plupart des articles de blogs traitent l'installation des services standards, ici nous allons voir comment exploiter le moteur Docker hors des sentiers battus, parce qu'on est des oufs.

Faites place au porte-container !

Avant même d'attaquer les opérations, vous pouvez ajouter un disque dur supplémentaire et créer un nouveau Volume Logique LVM de 1024Gio pour /var/lib/docker/, le répertoire où seront stocké les images, les conteneurs d'application, et surtout les conteneurs de données qui contiennent toutes vos données statiques. Pour ma part j'estime que 1Tio sera suffisant.

# lvcreate -n lv24 -L 1024G vg_lancaster /dev/sdb1
# mkfs.ext4 /dev/mapper/vg_lancaster-lv24


Dans la première commande, je crée le Volume Logique uniquement sur le disque dur initialisé en Volume Physique /dev/sdb1. En effet, lorsque je concentre toutes mes données dans un seul volume, j'ai pour habitude de répliquer ce volume sur d'autres disques dur. Ce volume sera ultérieurement répliqué sur /dev/sdc1, je ne le fais pas maintenant car ce dd est déjà rempli par les données statiques de mon serveur LAMP traditionnel.

# systemctl stop docker
# mount /dev/mapper/vg_lancaster-lv24 /mnt/lv1
# mv /var/lib/docker/* /mnt/lv1/
<< Ajouter le point de montage /var/lib/docker dans fstab >>
# umount /mnt/lv1
# mount -a
# systemctl start docker


Nous voilà à présent avec suffisament de place pour procéder à la suite des opérations.

Construction des containeurs de données

Commençons par le plus facile, les containeurs de données statique. Ces conteneurs ne contiendrons que les données générées par l'application dockerisée. Son fonctionnement est guère différent des services non-dockerisés sur serveur. Vous avez l'habitude de mettre sur un volume à part et de backuper /var/lib/mysql/ ou /var/www/mon_super_site/, et bien ce containeur ne contiendra que ce type de donnée. Il servira de backend au containeur faisant tourner le processus lui-même.

Pour dockerizer ce blog par exemple, je vais récupérer mes données dans les répertoires /var/lib/mysql et /var/www/dotclear1. Avant de construire ces containers il est nécessaire de stopper les services httpd et mariadb pour éviter de se retrouver avec une base de données corrompu dans le container.

Placer les Dockerfiles dans leurs répertoires de travail respectifs :
docker
├── data
│   ├── Dockerfile
│   └── truc
│       └── trunk
│           └── trac
├── dotclear1
│   └── Dockerfile
├── mariadb
│   ├── Dockerfile
│   └── Dockerfile~


Dockerfile :
FROM scratch

ADD var/lib/mysql /var/lib/mysql

# Execution environement
VOLUME /var/lib/mysql
CMD ''

MAINTAINER fantom at fedoraproject.org


Dockerfile :
FROM scratch

ADD var/www/dotclear1 /var/www/html

# Execution environement
VOLUME /var/www/html
CMD ''

MAINTAINER fantom at fedoraproject.org


Il faut aussi copier les données statiques dans les répertoires de travail :

# systemctl stop httpd
# systemctl stop mariadb
# mkdir -p /home/casper/docker/dotclear1/var/www/
# cp -a /var/www/dotclear1 /home/casper/docker/dotclear1/var/www/
# mkdir -p /home/casper/docker/mariadb/var/lib/
# cp -a /var/lib/mysql /home/casper/docker/mariadb/var/lib/
# systemctl start mariadb
# systemctl start httpd


Puis on construit les images.

# cd /home/casper/docker/dotclear1
# docker build -t web-blog-data:20150926 .
# cd /home/casper/docker/mariadb
# docker build -t database-blog-data:20150926 .

Nos images de données statiques sont prêtes...

De l'arrière vers l'avant

Au niveau applicatif, c'est à dire au niveau des programmes sur lesquels reposent les données statiques que l'on a empaqueté précédemment, il y a une certaine logique à respecter. Avant de dockerizer le serveur web qui fait tourner notre application en PHP, il faut dockeriser le serveur de base de donnée sur lequel s'appuie l'appli PHP. En fait, l'idée est de construire un système, et comme pour tout système il faut commencer par la base, la basse couche invisible pour l'utilisateur. Des serveurs de backend il y en a des tonnes, si vous voulez construire un système avec des bases solides, je vous recommande de commencer par les backends.

Dans le cas de mon petit blog par exemple, mariadb est le serveur le plus en arrière car inaccessible depuis tout Internet.

Pour le démarrage du mariadb cloisonné en conteneur, il n'y a pas de conflits de port d'écoute avec le mariadb sur mon système à craindre. En effet Docker va faire en sorte que son port d'écoute soit injoignable depuis l'interface réseau, et seul les containeurs que j'aurais spécialement configuré pour communiquer avec le containeur mariadb pourront accèder à son port d'écoute. Cet avantage vient du fait que Docker possède sa propre interface réseau pour gérer les communications entre les containeurs et l'hôte.

Attention à la différence de version entre le programme sur le système et le programme cloisonné. La base de donnée fonctionnait avec mariadb-10.0.20-1.fc21.x86_64, il faut donc veiller à réutiliser la même version du mariadb dockerizé soit la 10.0.20.

# docker run --name db-blog-static database-blog-data:20150926
# docker run --name mariadb-blog -d --restart always --volumes-from db-blog-static docker.io/mariadb:10.0.20


Mariadb est désormais opérationnel et attend tout nouveau container pour se plugger dessus. En l'occurence le containeur apache+php.
Voici queques explications sur les deux commandes 'docker run' à rallonge qui peuvent parraître déroutantes. Le container mariadb-blog expose par nature son répertoire /var/lib/mysql, ce qui nous offre la possibilité d'assigner ce répertoire à un répertoire particulier sur l'hôte ou bien de l'assigner au répertoire exposé d'un autre container. Comme vous le voyez avec l'option --volumes-from, son répertoire exposé va être assigné au répertoire exposé du container db-blog-static et le programme pourra accèder aux données que l'on a empaqueté précédemment. L'option --restart always indique que le container du programme doit être démarré si celui-ci crashe ou si l'hôte redémarre. Enfin l'option -d indique de lancer le container en arrière-plan, comme un démon ou service traditionnel.

Images sur mesure

Nous venons de voir comment migrer un service en docker en réutilisant une image toute prête faite, maintenant voyons comment adapter une image pré-existante à nos besoins. On ne change rien sur l'idée d'avoir un container de données statiques pour les backups à froid, sauf que l'on peut se permettre de customiser l'image contenant l'application lorsqu'on en trouve aucune sur la registry Docker répondant à nos besoin. Toujours sur le cas mon petit blog, je cherche une image d'un serveur web (Apache) pouvant exécuter du code en PHP, avec les dépendances PHP spécifiques au moteur de blog Dotclear. Autant vous dire qu'il y en a aucune sur la registry Docker officielle, mais on peut reprendre une images apache simple et lui ajouter les dépendances PHP. Une image ou un container Docker n'est pas une boite noire où l'on peut rien entrevoir à l'intérieur, les sources des images sont libres et accessibles, on peut les lire, les copier, les modifier et les redistribuer.

Je vais donc reprendre les sources de l'image fedora/apache et ajouter la liste des paquets PHP présents sur mon serveur. (Entre parenthèses, mon serveur ne fait tourner qu'une seule application PHP, Dotclear, s'il y avait eu plusieurs applis ça aurait vite compliqué la tâche...).

% git clone https://github.com/fedora-cloud/Fedora-Dockerfiles.git
% cp -a Fedora-Dockerfiles/apache apache-php-dotclear/
<< Éditer le Dockerfile >>


Dockerfile :
FROM fedora:21
MAINTAINER http://fedoraproject.org/wiki/Cloud

RUN yum -y update && yum clean all
RUN yum -y install httpd php-php-gettext php-mysqlnd \
                   php             \
                   php-pdo         \
                   php-imap        \
                   php-simplepie   \
                   php-mbstring    \
                   php-pear        \
                   php-mcrypt      \
                   php-domxml-php4-php5 \
                   php-cli         \
                   php-snmp        \
                   php-ldap        \
                   php-pgsql       \
                   php-process     \
                   php-IDNA_Convert \
                   php-xml         \
                   php-pecl-jsonc  \
                   php-common      \
                   php-gd          \
&& yum clean all

EXPOSE 80

# Simple startup script to avoid some issues observed with container restart
ADD run-apache.sh /run-apache.sh
RUN chmod -v +x /run-apache.sh

VOLUME /var/www/html
CMD ["/run-apache.sh"]


Puis on reconstruit l'image :

# cd /home/casper/docker/apache-php-dotclear/
# docker build -t apache-php-dotclear:2.4.16 .


Notre images Apache + PHP est prête. Attention à ne pas tomber dans l'excès, une image ***doit*** rester minimaliste, il est inconcevable d'avoir Linux + Apache + MySQL + PHP dans la même image. Chaque contener représente un peu une brique LEGO, et c'est de la façon dont on les empile que dépend la fiabilité du système.

# docker run --name web-blog-static web-blog-data:20150926
# docker run --name apache-php-blog -d -p 8082:80 --restart always --link mariadb-blog:mysql --volumes-from web-blog-static apache-php-dotclear:2.4.16


L'Apache de mon blog est désormais opérationnel...

« Euh mais attend Casper, ton Apache il écoute sur le port 8082 là, tu t'es pas un peu gourré ?... »

Un peu de réseau

Revenons en arrière, imaginons que je n'ai pas ajouté l'option -p 8082:80. Docker aurait isolé le container et seul un autre container pourrait spécifiquement se connecter au port 80 du container apache-php-blog. C'est insuffisant. Maintenant imaginons que j'ajoute l'option -p 80:80. L'hôte pourrait se connecter au container en passant par le port 80, sauf que le port 80 est déjà pris sur l'hôte ! Maintenant imaginons que le port 80 est disponible sur l'hôte et que j'associe ce port au port 80 du container. J'ai un second site web avec son container apache+php et son container de données statiques, comment vais-je faire pour que ce nouveau container apache-php-truc écoute lui aussi sur le port 80 ? La solution est de relèguer les containers apache au rand de serveurs backend, ils ne sont là que pour exécuter du code (PHP/Python/whatever). Le container peut continuer à écouter sur le port 80 ce n'est pas un soucis, mais le port de l'hôte associé à ce port sera un port différent, ce qui ne pose aucun soucis également puisque Docker permet une gestion très affinée des linkages de port d'écoute.

Si le container apache-php-blog est un backend, quel serveur HTTP est le frontend ? Il y a deux solutions possible dans ce cas de figure, soit on démarre un nouveau container Apache qui écoute sur les ports 80 et 443 et qui est linké pour pouvoir se connecter aux containers de backend (apache-php-blog et apache-php-truc), soit on utilise l'Apache du système hôte, qui doit pouvoir se connecter au container à travers le port 8082 exposé par Docker.

Le première solution est la meilleure, mais surtout c'est celle qui est mise en place en tout dernier, après avoir dockerizé tous les backends du Apache de l'hôte sans exception.

L'option --link mariadb-blog:mysql entraine deux choses distinctes : Docker autorise la connexion du container apache-php-dotclear au port 3306 (mysql) du container mariadb-blog, plutôt utile pour que l'application puisse se connecter à sa base de données. Mais surtout Docker ajoute dynamiquement une entrée au DNS du container apache. Quelle que soit l'adresse IP du container mariadb, son adresse IP sera automatiquement associée au nom de domaine "mysql". Il faudra penser à mettre à jour le fichier de configuration de l'application et remplacer "localhost" par "mysql" pour joindre le serveur de base de données avant ou après la migration ça n'a pas d'importance.

Un ptit coup de sed :
# docker exec -ti apache-php-blog /bin/bash
bash-4.3# grep -r localhost /var/www/html/*
/var/www/html/inc/config.php.in:// Database hostname (usually "localhost")
/var/www/html/inc/prepend.php:                  ,(DC_DBHOST != '' ? DC_DBHOST : 'localhost')
/var/www/html/inc/config.php:// Database hostname (usually "localhost")
/var/www/html/inc/config.php:define('DC_DBHOST','localhost');


Comme prévu il n'y a qu'un fichier de config à modifier à chaud.

bash-4.3# sed -i s/localhost/mysql/ /var/www/html/inc/config.php


Pas besoin de re-runner le container, l'entrée DNS est déjà là sauf que maintenant l'application pointe vers le bon serveur de base de données.

Troubleshooting

Il se peut que votre application en PHP ne parvienne pas à se connecter à la base de données, vous devriez voir dans le journal du container mariadb-blog une ligne du genre :

# docker logs mariadb-blog
151004 17:57:48 [Warning] Access denied for user 'dotclear1user'@'172.17.0.18' (using password: YES)


En effet, lorsque j'ai initialisé la base de données, j'ai configuré les privilèges pour l'utilisateur 'dotclear1user'@'localhost'. Évidemment avec un nom d'hôte différent, ça marche tout de suite moins bien. La solution la plus simple pour fixer ce problème est de se connecter au serveur de l'hôte puis de reconstruire un container de données statiques :

Se connecter en root :

# mysql -u root -h localhost -p

Ajouter un mot de passe à l'utilisateur :

MariaDB [(none)]> set password for 'dotclear1user'@'%'=password('monsupermotdepasse');

Ajouter les bons privilèges :

MariaDB [(none)]> grant all on dotclear1.* to 'dotclear1user'@'%';

C'est tout !

Rebuild the system

Okay, on a 2 serveurs de backend cloisonnés... il ne reste plus qu'à configurer l'Apache de l'hôte en mode reverse proxy pointant vers localhost:8082... Okay, on a cloisonné 2 services... Regardons maintenant ce qui se passe si on cloisonne d'autres types de programmes.

Casper, tu penses à quoi là ?

Je pense à cloisonner des applications bureautique comme Firefox et Thunderbird, je pense à cloisonner mon porte-feuille Bitcoin, je pense à cloisonner mes routeurs Tor, mais aussi générer des images de backup de mes données personnelles !

À suivre...

Mesa 11.1-0.devel.2.vind_depot Disponible

Sylvain Réault

Voilà, après pas mal de tâtonnements, la version pour Fedora 23 de développement est disponible.

Le fichier du dépôt pour F23 est disponible ici : http://www.vind-depot.fr/depot/
A copier en root dans : /etc/yum.repo.d/

A revoir : J'ai désactivé la signature le temps de vérifier si tout fonctionne. Elle sera de retour normalement d'ici la fin du mois.

La version pour Fedora 22 est toujours en préparation, mais demande beaucoup trop de dépendances en l'état (noyau, LLVM, les pilotes Xorg principalement).
Laissez moi un commentaire si cela vaudrait le coup d'investir du temps sur cette version.

PHP version 5.6.16RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont uniquement fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests.

Les RPM de PHP version 5.6.16RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 19-23 et Enterprise Linux 6-7.

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi-test install php56

A noter :

  • la version 5.6.16RC1 est aussi disponible dans Fedora rawhide.
  • la version 7.0.0RC7 est aussi disponible

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php56)

Mesa 11.1-devel Fedora 23 En test

Sylvain Réault

Les paquets de la version 11.1-devel pour Fedora 23 viennent de rentrer en test. Ils seront disponible samedi avec la nouvelle version du dépôt.

L'empaquetage est basé sur la dernière version des spécifications pour Fedora 23, disponible sur koji, avec quelques modifications mineurs.

Un test pour les porter sur F22 est aussi en cours, mais il n'y a pas de grandes chances pour que ce soit possible. Il y a une trop grande différences de versions d'autres dépendances qui provoque ce problème.

Les tests seront effectués sur une R9 290x OC de chez Gigabyte, la R9 270x étant en partance sur un autre poste plus modeste.
La différence en terme de performance est vraiment énorme, passant de 46,9 i/s de moyenne à plus de 81 i/s sur le benchmark Uningine Valley.
Le défaut étant que la gestion du refroidissement fait augmenter trop rapidement la vitesse des ventilateurs et donc un bruit assourdissant malgré l'utilisation d'un boitier insonorisé.
La solution est de gérer manuellement les paliers pour garder un bon ratio bruit/refroidissement.

Je fais enfin rentrer, d'ici quelques jours, une Nvidia pour pouvoir avancer sur les tests avec le pilote "nouveau".

Suite ce samedi...

Page générée le 26 sept 2016 à 19:17