![terraform](terraform.svg) ![openstack](openstack.svg) ![kubernetes](kubernetes.svg) Déployer **kubernetes** sur **OpenStack** grâce à **Terraform**
Alexandre Buisine [@alexbuisine](https://twitter.com/alexbuisine)
![enix](enix.svg)
# D'où je viens
3 ans en **Espagne**,
où j'ai développé un service de **réalité virtuelle** basé sur **Docker**
avec une grosse ferme d'**encodage vidéo** nécessitant moult **orchestration**
et je viens de revenir sur **Paris** pour rejoindre [Enix](https://enix.io) !
# La génèse de ce _talk_ *
Enix **opère** des clusters de **virtualisation** et de **conteneurs** pour le compte de ses clients
*
création d'un [POC](https://github.com/enix/terraform-openstack-kubernetes) pour tester la **faisabilité** et les **limites** du sujet dont on parle aujourd'hui
*
suivi d'un [blogpost](https://enix.io/fr/blog/deployer-kubernetes-1-13-sur-openstack-grace-a-terraform/) qui restitue les **observations**, positives comme négatives
# les slides ![qr code](qr.svg)
# Terraform aka _infrastructure-as-code_
fichier descriptif
→
déploiement automatisé
### on manipule des objets * instance de machine virtuelle * ip publique * droits d'accès ...
# Terraform HCL un language qui décrit l'infrastructure visée ```Ruby provider "openstack" { auth_url = "http://api.openstack/v42" } resource "openstack_compute_instance_v2" "meetup_node" { name = "meetup_42" } resource "openstack_networking_floatingip_v2" "public_ip" { pool = "A dummy pool" } resource "openstack_compute_floatingip_associate_v2" "association" { floating_ip = "${openstack_networking_floatingip_v2.public_ip.address}" instance_id = "${openstack_compute_instance_v2.meetup_node.id}" } ```
# Terraform 1.
`terraform init`
2.
`terraform apply`
3.
`terraform destroy`
# Terraform un dépendance en graphe entre objets ![Graph](floating.svg)
# Kubeadm et la haute disponibilité *
Qui a déjà fait un **kubeadm init** ?
*
un [kubeadm init/alpha phase](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/) ?
preflight
**certs**
kubeconfig
kubelet-start
**control-plane**
etcd
mark-control-plane
bootstrap-token
upload-config
**addon**
ou bien `kubeadm join --experimental-control-plane`
# Orchestrer les phases de kubeadm avec Terraform
utiliser un [provisioner](https://www.terraform.io/docs/provisioners/remote-exec.html)
de type **remote-exec**
pour profiter de la dépendance en **graphe**
afin d'obtenir une meilleure **performance**
(de déploiement)
# kubernete's cloud-controller-manager Il existe aujourd'hui [3 façons](https://kubernetes.io/docs/concepts/architecture/cloud-controller/) d'intégrer un cluster kubernetes avec un cloud provider 1.
kube-controller-manager
**deprecated**
2.
cloud-controller-manager [in-tree](https://kubernetes.io/docs/reference/command-line-tools-reference/cloud-controller-manager/)
3.
cloud-controller-manager [out-of-tree](https://github.com/kubernetes/cloud-provider-openstack)
# POUR * **fonctionnalités** du cloud provider sans attendre * arrivée de **nouveaux** cloud provider facilitée # CONTRE * le **bootstrap TLS** n'est pas encore supporté
# Un poil de sécurité
Terraform **stocke** l'état de l'infrastructure
ainsi que toutes les **variables** du plan
, **en clair**
, dans un fichier `.tfstate`
préférez un **token** plutôt que le couple **user/password** pour authentifier le **provider** terraform
préférez l'utilisation de **ssh-agent** plutôt que de passer une clef privée en paramètre d'un **provisioner** terraform
# Les sujets à creuser * Terraform [0.12](https://www.hashicorp.com/blog/terraform-0-1-2-preview) avec HCL 2.0 * [cloud-controller-manager](https://docs.google.com/document/d/1ZsPtRz2glAWH81MP0-9X8tG7sRWYuZPbj0VvZVETa2U/edit) * [Container Storage Interface](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi-migration.md) * formations [Kubernetes](https://enix.io/fr/services/formation/deployer-ses-applications-avec-kubernetes/) ou [Docker](https://enix.io/fr/services/formation/bien-demarrer-avec-les-conteneurs/) ![qr code](qr.svg)