Revue de presse Inno #7

Mobile

Protocoles génériques et Type Erasure en Swift

Avec Swift, vous pouvez définir des protocoles en leur associant un ou plusieurs types génériques. Ces types sont définis en utilisant le mot-clé « associatedtype ».  L’appellation « type générique » est un peu usurpée ici, nous devrions plutôt parler d’un espace réservé pour un type inconnu. En effet, nous verrons que de tels protocoles n’offrent pas une grande souplesse d’utilisation lorsqu’il s’agit de réellement les considérer comme génériques.
En savoir plus :

Développement Web

Django 2.0 Release Candidate désormais disponible

Par Kévin Barralon

Le framework Django dont la prochaine version 2.0 est prévue autour du 1er décembre vient de publier sa version Candidate ce jeudi 15 novembre. Contrairement à ce que l’on pourrait penser, cette nouvelle version ne va pas apporter d’incompatibilités majeures au sein du framework. Les changements seront donc du même acabit que les versions précédentes.

Cependant, le changement important de cette version 2 sera l’incompatibilité avec Python 2.7, dont la fin du support est programmée pour 2020. Django 2.0 supportera donc au minimum la version 3.4, même s’il est chaudement recommandé de passer directement à la dernière version de Python (3.6 actuellement).

Routage d’URL

Au niveau des nouveautés, la nouvelle fonction django.urls.path() rend la syntaxe du routage des URL beaucoup plus simple et lisible. Ainsi, au lieu d’écrire : url(r'^articles/(?P[0-9]{4})/$', views.year_archive)

vous pourrez écrire : path('articles/<int:year>/', views.year_archive)

Cette nouvelle syntaxe permettra également de recevoir dans la vue (views) les arguments avec le typage défini (un nombre entier dans le cas de year au lieu d’une string).

Dans cet exemple, il n’y a toutefois pas de possibilité d’ajouter une contrainte (une année à 4 chiffres dans notre exemple). Pour cela, la fonction actuelle django.conf.urls.url() sera remplacée par django.urls.re_path(), qui permettra de conserver la possibilité de mettre des expressions régulières dans la définition de l’URL.

La fonction django.conf.urls.include() sera également directement disponible via django.urls. Pour pourrez ainsi importer vos modules de la manière suivante from django.urls import include, path.

Autres nouveautés

  • Pour les autres nouveautés : L’admin de Django 2.0 sera désormais responsive, donc adapté aux appareils mobiles.
  • Une nouvelle classe Window a été ajoutée afin de permettre l’utilisation du mot-clé OVER dans les requêtes SQL.
  • Une liste de tous les ajouts mineurs est disponible dans le communiqué officiel.
En savoir plus :

Déployer des services entiers avec Docker Swarm et Gitlab CI

Chez Savoir-faire Linux, je travaille (entre autres) sur l’infrastructure de déploiement pour plusieurs services que l’on héberge, et je suis toujours à l’affût de méthodes innovantes pour améliorer notre pratique DevOps. Présentement, le système de déploiement est axé autour de l’utilisation de Ansible pour « provisioner » un service dans une machine virtuelle, et l’ajuster au besoin après. Mais pour améliorer la stabilité de nos builds, de déploiements et l’agilité avec laquelle on peut faire des déploiements en continu, nous regardons d’autres approches DevOps, comme l’utilisation des containeurs Docker hébergés dans un Registry et déployés par un outil comme Gitlab CI.
Parmi les outils disponibles pour déployer une architecture de « microservice » (créée avec docker-compose), nous trouvons Docker Swarm. En utilisant un certain nombre de serveurs proprement configuré, on peut déployer un « stack » de containeurs avec un simple docker stack deploy. Docker va choisir par la suite la meilleure configuration pour le déploiement des différents containeurs à travers l’infrastructure du Swarm. Il va même aller jusqu’à configurer la réseautique entre les containeurs automatiquement, comme si tu utilisais docker-compose sur un ordinateur en local.
 
La meilleure partie, c’est le fait que ça marche bien avec notre système d’automatisation des builds déjà existant, GitLab CI. Nous pouvons faire le pipeline « build – test – release – deploy » à travers toute notre infrastructure avec GitLab CI et le GitLab Container Registry. Il y a toujours des parties casse-têtes à régler, mais ce système représente déjà un grand bond vers l’avant pour la simplicité et l’efficacité de notre pratique DevOps.
En savoir plus :

Tester LemonLDAP::NG en 5 minutes avec Docker

lemonldap-ng-docker

Installer LemonLDAP::NG n’est pas en soi très compliqué, étant donné que le projet fournit des paquets RPM et Debian, ainsi que des dépôts permettant les mises à jour automatiques. Ceci dit, on n’a pas forcément envie d’installer ces paquets sur sa machine et de tirer toutes les dépendances qui vont avec. Grâce à Docker, il est possible d’installer le logiciel dans un conteneur sans « contaminer » son propre système. C’est donc a priori une solution idéale pour tester un logiciel comme LemonLDAP::NG.

Comme moi, vous avez certainement entendu parler (beaucoup) de Docker, ces derniers temps, sauf si vous vivez dans une grotte numérique avec un vieux modem 56 K comme seul moyen de communication avec le monde extérieur. Il s’agit donc d’une technologie de conteneurs permettant l’exécution d’application sur un système d’exploitation en l’isolant des autres processus.

Après avoir suivi quelques tutoriels en ligne, j’ai donc décidé de construire ma propre image Docker pour LemonLDAP::NG. Pour cela, j’ai créé un fichier Dockerfile qui reproduit les étapes d’installation de LemonLDAP::NG sur un système Debian. Ce fichier est visible sur mon dépôt github :

Une fois que c’est fait, on peut construire simplement l’image Docker avec cette commande:

docker build --rm -t yourname/lemonldap-ng:version

Ayant construit l’image, je l’ai publié sur un dépôt Docker: https://hub.docker.com/r/coudot/lemonldap-ng/. Ainsi il est possible de le récupérer simplement avec un client Docker:

docker pull coudot/lemonldap-ng

Maintenant, on peut lancer un conteneur à partir de cette image pour tester LemonLDAP::NG.  Tout d’abord, le SSO fonctionnant avec des noms DNS, il faut que l’hôte résolve les noms utilisés par défaut dans LemonLDAP::NG, il suffit pour cela d’ajouter cette ligne dans votre ficher /etc/hosts :

127.0.0.1 auth.example.com manager.example.com test1.example.com test2.example.com

Ensuite, il suffit de lancer un conteneur en associant le port 80 du conteneur au port 80 de sa machine (il faut donc qu’il n’y ait pas de processus local qui utilise le port 80):

docker run -d --add-host reload.example.com:127.0.0.1 -p 80:80 coudot/lemonldap-ng

Il ne reste plus qu’à accéder à http://auth.example.com et à se connecter avec les comptes de démonstration, par exemple dwho/dwho.

Essayez ça et dites-moi ce que vous en pensez. Si vous avez des commentaires ou des trucs à partager, faites-le ci-dessous et je me ferai un plaisir de vous répondre.