Après Vancouver, Tokyo, Austin, Barcelone, Boston et Sydney, c’est de nouveau à Vancouver que nous nous retrouvons pour l'édition 2018 de l’OpenStack Summit ! 17ème summit OpenStack, Osones vous fait, comme à son habitude, vivre l’OpenStack Summit de Vancouver comme si vous y étiez !

• Vers le jour 1
• Vers le jour 2
• Vers le jour 4
  

Breakout Sessions

SIG K8s et OpenStack provider

Pour les personnes aillant déjà déployé Kubernetes sur un Cloud Provider, il existe outils d'intégrations pour la plupart des Cloud (OpenStack, AWS, GCP, etc). Le problème avec ces modules est qu'ils résident dans le code "in tree" de Kubernetes et qu'ils sont par conséquent soumis au même cycle de release.

Depuis la version 1.6, le concept de "Cloud Controller Manager" a vu le jour, afin de sortir le code de Kubernetes et ainsi permettre aux différents Cloud Provider de développer leur controleur, indépendamment du cycle de release de Kubernetes. OpenStack dispose de sont propre Cloud Controller en développement afin de remplacer le code "in tree"

Les Cloud Controller permettent de tirer partie des fonctionnalités offertes par les Cloud provider tels que les volumes et les loadbalancers par exemple. En plus des fonctionnalités déjà existantes, des travaux sont en cours afin de s’intégrer avec d'autres composants :

• Barbican pour le management des secrets
• La création d'un "ingress controller" pour Octavia afin de pouvoir utiliser les fonctionnalités de loadbalancing niveau 7 telle que la terminaison TLS par exemple.
• L'autoscaling : potentiellement avec Heat or Senlin or Nova directly

En plus du Cloud Controller, on remarque plusieurs points d'avancement autour de Kubernetes, notamment avec CSI(Container Storage Interface) qui est l'équivalent du Cloud Controller mais pour les volumes, le code des volumes étant lui aussi majoritairement "in tree".

Concernant l'authentification, l'integration de Kubernetes avec Keystone avance et permettra aux utilisateur d'OpenStack d'utiliser leur credentials Keystone afin de s´authentifier avec leur cluster. Cette fonctionnalité pourra ensuite être exploitée par différents outils de déploiement ou projets tels que Magnum ou Zun.

Target : OpenStack Architecture and deployment

Target est une entreprise de grand distribution très répandue aux États Unis. Quelques chiffres :

• 1829 magasins aux États Unis
• 39 entrepôts
• 350 000 employés
• target.com 4ème site de commerce en ligne (USA)

Target a fait le choix du cloud en 2015 :

• Utilisation de hardware existant
• Icehouse
• Packstack (RedHat)
• Ceph avec disques HDD, Block pour Nova/Cinder, Objet pour Swift
• Pas d'outils de gconf

Leur premier cloud est fortement orienté développement afin d'y créer les nouveaux applications frontend de Target.

Deux régions de production (150 hyperviseurs) et une région de développement (100 hyperviseurs), au total 10K cores

Ce cloud a subit:

• Deux mises à jour : Icehouse > Juno > Kilo
• Passage des routeurs neutron en HA
• Ajout de network node

Le Ceph a également évolué :

• passage en full SSD
• mise a jour Hammer à Jewel

En 2017, un second cloud est deloyé afin d'ameliorer :

• Les performances et la stabilité réseau : utilisation du DVR
• La maintenabilité (Jenkins+git+drone+Chef)

A l'avenir, Target utilisera les branches stables de la communauté plutôt que les RPMs fournit par Redhat. Se rapprocher de la communauté permettra de partager les modifications effectuées en interne afin de gagner en confiance sur ces modifications de codes.

Le DVR permet au trafic des FIP de sortir directement depuis les computes, ce qui limite le besoin de nœud dédié network. Le seul trafic sortant des network est donc le trafic SNAT.

OpenStack Passport

Passport est un programme de la Fondation OpenStack lancé lors du Summit de Sydney, il y a 6 mois, qui recense les clouds publics tournant sur OpenStack. 11 cloud publics sont actuellement référencés dont nos compatriote OVH. Ce talk était l'occasion pour John Studarus, OpenStack Ambassador pour les Etats Unis et Stacy Véronneau, OpenStack Ambassador pour le Canada de présenter leur étude sur ces différents providers.

Le usecase considéré est celui d'un nouveau utilisateur OpenStack qui souhaite tester OpenStack , l'expérience utilisateur est donc fortement prise en compte.

Les tests comprenaient :

• La facilité d'inscription
• La version d'OpenStack déployée
• Les services OpenStack disponibles dans le catalogue et sur le Dashboard
• La taille des quotas alloués
• Le nombre d'AZ et de Région

Globalement, le constat fait est que les quotas attribués étaient relativement faible et que contrairement à AWS ou GCP, aucun cloud provider ne propose de free tier. Coté authentification, une harmonisation (via OpenStackID par exemple) pourrait être une approche intéressante mais celà ira probablement à l'encontre des SI internes de chaque providers.

Deux "médailles" furent attribuées, une pour OVH et sa CLI intégré à son portail utilisateur, permettant de toujours avoir la bonne version, la deuxième à Catalyst Cloud pour son système d'invitation permettant d'ajouter facilement de nouveaux utilisateurs à son projet.

Vous pouvez dès maintenant la vidéo du talk et le résultat de l'étude par la même occasion !

Plates-formes de CI/CD : Jenkins et Spinnaker

Liam Newman de Cloudbees et Nick Chase de Mirantis nous présentent l'approche et le potentiel des plates-formes de CI/CD Jenkins et Spinnaker.

Rappelons que le principal objectif d'une plate-forme de CI/CD est d'offrir aux applications un circuit court, efficace et automatisé depuis les phases de développement en amont jusqu'au déploiement en aval.

Notons que la notion de déploiement peut prendre différentes significations suivant les contextes et les environnements : déploiement de l'application sur son infrastructure d'exécution, upload d'artifacts vers un dépôt, publication dans un catalogue d'applications,...

1/ Jenkins : l'IHM "Blue Ocean" et "pipeline as code"

La notion centrale est celle de "pipeline as code". Le pipeline se code en langage Groovy dans le "Jenkinsfile" qui est versionné dans le repository aux côtés du code applicatif. De ce fait, l'usage d'outils programmatiques permettant de configurer les jobs tels que Jenkins Job Builder n'est plus nécessaire. Jenkins/Blue Ocean exécute directement le code Groovy contenu dans le Jenkinsfile.

Afin de faciliter la prise en main, il est possible de définir un pipeline via Blue Ocean et générer ensuite en un clic le Jenkinsfile correspondant.

Du point de vue conceptuel, il faut voir un pipeline comme de la "glue" entre les différentes étapes qui composent la chaine de CI/CD. Inutile donc de remettre en cause la logique et les traitements de celle-ci, il suffit de les relier en utilisant le mécanisme de pipeline.

Voici un exemple de code Groovy. Il s'agit de l'étape tests unitaires d'une application Java déclenchés via l'outil gatling :

stage('Backend unit tests') {
  /* ... */
  steps {
    unstash 'war'
    sh './mvnw -B gatling:execute'
  }
}

A souligner le second souffle apporté à Jenkins par son nouveau GUI "Blue Ocean" bien plus moderne. Jenkins en avait bien besoin...

2/ Spinnaker : la CD "intelligente" A l'instar de Jenkins, Spinnaker possède aussi la notion de "pipeline", mais de façon plus native et plus centrale.

A la différence de Jenkins, les pipelines Spinnaker sont codés en JSON.

Nettement orienté déploiement d'applications sur leur infrastructure cible, Spinnaker peut :

• mettre à l'échelle (scaling) des groupes de serveurs
• gérer des stratégies de déploiement
• prendre des décisions en fonction d'événements

L' "intelligence" dont nous parle Nick Chase trouve son origine :

• dans de la logique pré-codée
• dans l'IA et le Machine Learning

Pour en savoir plus, voir les travaux sur le sujet OpenStack fault-tolerance : https://wiki.openstack.org/wiki/Fault_Genes_Working_Group

Enfin, rappelons que Spinnaker a été développé par la société Netflix et est disponible sur github.com.

Forum

Parmi les sessions de Forum de la journée, une attendue par beaucoup concernait la dette technique des API OpenStack. Il s'agit d'un travail au long cours, non-trivial, mais qui permettra d'offrir aux utilisateurs des interfaces plus propres et cohérentes, et ainsi faciliter leur utilisation.

Soirée francophone

Nous étions présent hier, à la soirée francophone organisée par l'association OpenStack-Fr. C'était un plaisir de rencontrer où retrouver les francophones qui ont fait le déplacement à Vancouver.

Et nous nous sommes réunis aujourd'hui pour la traditionnelle photo !