En direct de Barcelone, jour  3 !

Que retenir du dernier jour de l’OpenStack Summit de Barcelone ?

Prenez un café, installez-vous confortablement et profitez de l’OpenStack Summit de Barcelone comme si vous y étiez: voici le résumé des faits marquants de la journée retenus par l’équipe d’Objectif Libre sur place.
Faites une pause OpenStack !TasseVintage

 

Au menu aujourd’hui :

 

Magnum is Not the OpenStack Containers Service? How about Zun?

Par Hongbin Lu, Huawei

 

 

Cette conférence commence par un tour d’horizon des différents projets autour des “conteneurs” sous OpenStack (Magnum, Nova-docker, Kuryr…). Avant de nous présenter Zun, le speaker nous rappelle ce qu’est Magnum.

 

Magnum est le projet auquel on revient toujours lorsqu’on parle conteneurs et OpenStack. Magnum permet de déployer très facilement des clusters Kubernetes, Docker Swarm ainsi que Mesos.

L’utilisateur, une fois son cluster créé, n’a plus qu’à lancer ses conteneurs dans le cluster, comme il le ferait hors OpenStack. Le speaker, avant de présenter son projet, insiste sur le fait que Magnum permet “juste” de déployer un orchestrateur, et non de simples conteneurs.

 

 

Le projet Zun (ou Higgins de son ancien nom) est assez peu connu ; il permet de gérer le cycle de vie des conteneurs. Il est intégré avec les autres services OpenStack (keystone, nova, glance…) et a été créé pour répondre à la demande des utilisateurs de créer des conteneurs sans avoir à déployer un orchestrateur.

Contrairement à Magnum, qui n’est pas multi-tenants puisqu’il déploie un orchestrateur par tenant, Zun se positionne comme les autres composants OpenStack (par exemple Nova) et accède à la plupart des ressources de l’OpenStack.

Dans Zun, nous retrouvons deux ressources : les conteneurs et les sandbox.

 

 

Afin de mieux différencier les deux, et avant d’expliquer ce qu’est une sandbox, rappelon le processus de création d’un conteneur :

  1. L’utilisateur lance la création d’un conteneur
  2. Zun contacte Nova pour créer une instance sandbox
  3. Nova transfère la requête à Nova Compute
  4. Nova Compute la retransfère à un driver Zun de virtualisation
  5. Le driver crée l’instance
  6. Zun requête Zun compute pour créer le conteneur
  7. Le conteneur est crée dans la sandbox

 

 

La sandbox est une instance dans laquelle on déploie un conteneur. A priori, il sera bientôt possible d’avoir plusieurs conteneurs dans une seule sandbox, ce qui est déjà plus intéressant. Le fait d’avoir une sandbox permet de définir un groupe de conteneurs qui partagent des ressources (réseaux, stockage…).

 

 

De plus, Zun permet aussi de lancer des images Docker :depuis le Hub officiel, depuis un registre privé, ou depuis glance si l’image est stockée en format tar.

 

 

Pour finir cette présentation, nous avons droit à une démonstration. Le projet semble intéressant : en plus de la ligne de commande, une intégration Horizon permet de gérer tous ses conteneurs.

 

 

En conclusion : un projet intéressant, même si les fonctionnalités futures restent assez vagues (Kubernetes, stockage avec cinder…).

 

En savoir plus (démonstration):
https://www.youtube.com/watch?v=umcok662jkM

 

Retour d’expérience de ESBCO

Nate Baechtold nous a fait part de son retour d’expérience dans la création d’un cloud privé OpenStack chez ESBCO.

 

 

ESBCO est une entreprise américaine qui fournit des ressources bibliothécaires dans le domaine universitaire. Les clients peuvent rechercher et consulter ces ressources.

Les principaux besoins de ESBCO sont les suivants :

  • Automatiser le déploiement d’infrastructure
  • Améliorer l’agilité des équipe de développement
  • Avoir un ‘self-service’ : les utilisateurs peuvent créer eux-même leur infrastructure

 

Les raisons du choix d’OpenStack sont les suivantes :

– l’utilisation des APIs

– la possibilité de construire son cloud OpenStack avec les composants souhaités

– la couche d’abstraction qui permet à n’importe quel utilisateur (et notamment les développeurs) de créer son infrastructure sans se soucier du physique ni de l’environnement.

 

ESBCO voulait une plateforme multi-tenants pour isoler les utilisations de la plateforme. Les équipes de développement et d’opérations peuvent ainsi partager le même cloud.

 

Les difficultés rencontrées ont été les suivantes :

– Le manque de compétences en interne et la complexité d’embaucher des personnes connaissant très bien OpenStack. Pour cela, une équipe dédiée 100% au projet a été créée.

– L’intégration de leur propre load balancer pour fournir le LbaaS. ESBCO a dû abandonner cette option à cause d’un bug fournisseur et il a été très facile de se tourner vers une autre solution, le load balancer logiciel AVI.

– La maturité de certains projets OpenStack qui ne sont pas prêts pour la production.

 

Enfin, le plus important critère pour la réussite de ce projet est l’adoption des équipes.

Plus les équipes (les utilisateurs) sont proches du projet (feedback, leurs besoins pris en compte…), plus l’adoption sera facile. Il est très important d’avoir une plateforme disponible le plus rapidement possible afin que la plateforme soit testé par les équipes qui vont l’utiliser.

 

OpenStack chez ESBCO en quelques chiffres :

  • 3 clouds OpenStack
  • 1300 instances qui tournent
  • 500 000 instances créées
  • 68% du workload concernent les environnements de développement

 

OpenStack Troubleshooting: So Simple Even Your Kids Can Do It

Par Jonathan Jozwiak et Vinny Valdez RedHat, Inc.

 

« No Valid Host was found » : ce message standard et dénué de toute information utile vous donne des cauchemars la nuit ?
Jonathan et Vinny de RedHat démystifient ce message et nous présentent dans cette conférence les bonnes pratiques pour le troubleshoot sur OpenStack. En bonus, quelques outils bien utiles pour le debug.

 

Ne pas agir dans la précipitation

  • Ne pas foncer pour chercher LE message dans la multitude de logs produits par OpenStack. Les recherches aléatoires ne sont pas productives et ne donnent pas de solutions toutes prêtes
  • Une fois le problème identifié, ne pas appliquer de pansement mais réparer la vraie source du problème
  • Ne pas faire de changement directement en production « pour tester »
  • Connaître son infrastructure. Un schéma est toujours une bonne référence, essentiellement lorsque l’infrastructure devient complexe
  • Ne pas agir uniquement lorsqu’un utilisateur remarque le problème. Si le problème est connu, il doit être corrigé, même si l’impact est minime.

 

 

Être pro-actif

  • Monitorer son infrastructure avec son outils favoris (Zabbix, Nagios,…)
  • Analyser les logs produits par l’OpenStack : ces analyses fournissent un feedback très utile permettant d’identifier un comportement inhabituel de l’infrastructure. Une stack ELK fait très bien l’affaire par exemple.
  • Tester régulièrement les performances de son infrastructure. Par exemple, le nombre de connexions que son MariaDB accepte, sans connaissance des capacités initiales ce type de problème, peut prendre du temps à identifier.

 

 

Bonnes pratiques

  • Avoir une plate-forme de pré-production identique à la production. La résolution du problème en pré-production doit avoir le même impact sur la production
  • Automatiser son déploiement. Ce point est crucial, et est aujourd’hui indispensable si l’on souhaite avoir de la cohérence dans son infrastructure
  • Versionner les fichiers de configuration. Cela permet de garder une trace des modifications effectuée
  • Faire des modifications unitaires : trop de modifications simultanées peuvent engendrer de nouvelles sources de problème, et rendre le debugging d’autant plus chronophage
  • Utiliser les options –debug et –verbose des CLI OpenStack. Mais le problème peut aussi se trouver entre la chaise et le clavier (RTFM)
  • Passer l’option debug à True dans la configuration des services. L’utilisation d’un playbook Ansible peut automatiser le passage d’une configuration à une autre

 

 

Et ce fameux « No valid host was found » ?

 

Quelques pistes :

  • Avant tout : comprendre le processus de boot d’une instance
  • Penser « Nova Scheduler » d’abord : vérifier les filtres du scheduler appliqués (dans /etc/nova/nova.conf)
  • Utiliser la commande « grep » dans /var/log/nova et rechercher les mots clés comme « ERROR » ou « TRACE », faire une rechercher sur l’ID de la requête
  • En cas d’erreur sur les filtres CPU/RAM :
    • Vérifier l’état des hyperviseurs (nova hypervisor-stats)
    • Vérifier les options d’overcommit dans /etc/nova/nova.conf

 

La conférence se termine sur une vidéo de démonstration, avec la présentation d’openstack-detective (https://github.com/jonjozwiak/openstack-detective), une suite de role Ansible pour de l’aider au débug.

 

 

Container Defense in Depth

Par Scott McCarty de Redhat

Cette fois, il est question de sécurité des conteneurs – mais les principes de bon sens restent les mêmes.

 

Deux spécificités des conteneurs posent particulièrement problème:

  • Les containers et l’hôte partagent toujours le même noyau : un exploit noyau est très dangereux (y compris en cas d’utilisation du namespace utilisateur)
  • La gestion des images : beaucoup d’acteurs interviennent sur les images (dev, ops, middleware, supervision, sécurité….) Qui contrôle ce qui se trouve dans le conteneur ? Et qu’il n’y a pas de contenu malveillant ?

 

Appliquons quelques concepts de sécurité aux containers:

Isolation

Il est possible d’utiliser des conteneurs dans une machine virtuelle (ou l’inverse) permettant d’isoler le noyau de l’hôte et celui des containers.
On profite ainsi de l’isolation de la machine virtuelle et des fonctionnalités des containers.

Défense en profondeur
****
NDR: le principe de défense en profondeur est un principe fondamental qui revient presque systématiquement dès qu’il est question de sécurité (on l’a vu dans les comptes-rendus des journées précédentes).
L’idée sous-jacente issue de la stratégie militaire vise à ralentir la progression de l’ennemi. Chaque sous-ensemble du système est sécurisé vis-à-vis du reste et ne lui fait pas confiance.
****

Revenons aux conteneurs. Chaque élément doit être durci :

  • l’image du conteneur
  • l’hôte du conteneur
  • la plateforme gérant les conteneurs

Tout en se basant sur certains contrôles de sécurité du noyau :

  • SELinux (ou Apparmor) : s’appuie sur les structures de données du noyau : A qui ai-je le droit de parler ?
  • Seccomp : s’appuie sur les appels systèmes : Qu’ai-je le droit de dire ?

Les images

Les contrôles mis en place dans la gestion des images système traditionnelles restent valides:

  • Intégrer des contenus de confiance directement des éditeurs et dont la provenance est contrôlée
  • Réaliser des scans de vulnérabilité
  • Remédier/patcher en cas d’écart
  • Réaliser un veille sécurité sur les briques logicielles embarquéees (base de connaissances CVE)
  • Mettre en place des procédures de réponses à incident
  • Limiter les accès administrateur (ne pas survendre le namespapce utilisateur) et utilisateur (qui contrôle le contenu)

 

 

Des moyens supplémentaires sont mis à disposition par les conteneurs pour faciliter ou améliorer ces contrôles:

  • Les images peuvent être signées et vérifiées (empêche les modifications non souhaitées)
  • Les conteneurs peuvent être lancés en read-only ; Attention ce n’est pas le fonctionnement par défaut, il faut bien spécifier l’option au démarrage du container (–read-only pour docker)
  • Les points de montage ne sont pas forcément en mode lecture seule mais il est possible de forcer les labels SELinux (passer le drapeau Z pour docker)
  • Des « diff » peuvent être réalisés pour voir les modifications entre les images et les conteneurs

 

Les hôtes

Il est primordial de contrôler certains paramètres du système hôte pour garantir l’étanchéité de l’hôte et des conteneurs:

  • La qualité du noyau: utiliser un version récente pour profiter des derniers mécanismes de sécurité comme les namespaces
  • Le durcissement du noyau : utiliser des noyaux durcis avec le module grsec et les capabilities
  • La gestion de configuration : déployer des configurations contrôlées (et centralisées) grâce à des outils comme Ansible

 

De plus les hôtes peuvent durcir la configuration des conteneurs:

  • L’utilisation de profil seccomp pour limiter les appels systèmes à disposition des conteneurs
  • L’utilisation de svirt pour amener des fonctionnalités de SELinux aux conteneurs
  • La réduction des capacités des conteneurs : limiter les capabilities autorisées, restreindre le processus à un utilisateur non privilégié, lancer le conteneur en mode lecture seule…

 

Les plateformes

Utiliser des bonnes pratiques de sécurité à ce niveau permet d’améliorer la sécurité de l’ensemble de l’éco-système:

  • Isoler les utilisateurs par rôle : limiter l’utilisateur dans des tenants spécifiques
  • Mettre en place des systèmes d’authentification centralisés et auditables (comme LDAP par exemple)
  • Mettre en place des mécanismes d’isolation du réseau

 

Trove

Par Amrith Kumar de Tesora

Contrairement à certaines idées reçues, Trove n’est pas un équivalent à Amazon RDS.

Trove est un framework qui permet de construire des services similaires à Amazon RDS, Elasticache et plus encore. D’après Amrith Kumar (PTL de Trove), le module est prêt pour la production et plusieurs entreprises sont en train de franchir le pas.

 

Aujourd’hui Trove gère :

– le provisionning des bases de données : création des instances, configuration des services en cluster ou non, etc.

– la sécurisation des bases de données : gestion des ports réseaux ouverts ou fermés, application des mises à jour de sécurité, etc.

– la configuration des bases de données : tuning des différentes bases par rapport à la taille des machines virtuelles, gestion de groupes de configuration, etc.

– la gestion des bases de données : création d’utilisateurs, de tables, de backups, etc.

 

Trove supporte de nombreuses bases de données : cassandra, couchbase, mariadb, mongodb, redis, postgresql, etc.

 

Parmi les nouvelles features intégrées à Newton, on notera :

  • le support des upgrades de version
  • l’intégration avec NewRelic
  • la gestion des erreurs via la CLI
  • la possibilité de reset des bases de données
  • l’amélioration de la gestion des clusters (module pour la création, choix du type de volume)
  • le support des affinités lors de la création des bases de données

 

 

Toutefois, tout n’est pas parfait pour Trove et il reste plusieurs points d’amélioration.

La génération d’images de bases pour les différentes bases de données demeure compliquée. Tant que ce point ne sera pas adressé, une adoption massive de Trove semble peu probable. Le multi-région n’est pas géré aujourd’hui et la gestion des clusters demeure perfectible. Enfin, on notera la volonté de rendre compatible le code de Trove avec python 3.5.

 

Finalement, le projet Trove demeure très actif et gagne clairement en maturité. L’objectif pour Ocata n’est pas forcément de développer de nouvelle feature mais plutôt d’éprouver l’ensemble et rendre la création d’images de bases plus aisées.