CérénIT

Le blog tech de Nicolas Steinmetz (Time Series, IoT, Web, Ops, Data)

Web, Ops & Data - Juin 2017

branche terraform iaac elastic solr serverless mysql sécurité test tick lean

Agile

  • Feature Branching is evil ! : si la branche isole le nouveau code, il isole aussi le développeur des autres avancées et repousse à plus tard les problématiques de réintégration de code, refactoring, etc. L’auteur avance le feature flipping et le “trunk based development” pour avoir une intégration continue perpétuelle et des écarts les plus petits possibles.

DevOps

  • Terraform Layering : Pourquoi et comment ? : Un fichier Terraform peut vite devenir illisible dans le cas d’une architecture complexe et consommateur de temps lors de son exécution. Le billet présente une méthode pour traiter ces problèmes. Il s’agit de créer des “couches” (layers) permettant d’avoir plus de modularité et permettant qu’un fichier terraform s’appuie en entrée sur les données de sorties du fichier précédent et ainsi de suite.

Elastic

  • Welcome Opbeat to the Elastic family : Elastic se lance sur le marché de la performance applicative (APM) en acquérant la société Opbeat. Suite assez logique pour Elastic après l’ingestion de données plus orientée monitoring système avec Logstash/Beat ou des intégrations spécifiques pour faire de l’APM en s’appuyant sur Elastic.
  • Designing the Perfect Elasticsearch Cluster: the (almost) Definitive Guide : le billet traite le design d’un cluster Elasticsearch et les points d’attention à avoir. Ce n’est pas la recette magique (elle n’existe pas) mais donne tous les points d’attention à avoir dans le cadre du déploiement d’un cluster Elasticsearch.
  • Top 15 Solr vs. Elasticsearch Differences : pour ceux qui hésitent encore entre les 2 solutions, une petite revue en 15 poins pouvant vous aider à choisir la solution correspondant à votre besoin.

Infrastructure

  • Serverless vs Micro-Service avec infrastructure “maison” : comparaison de la mise en place d’une infrastructure à base de micro-services vs une infrastructure “serverless” avec prise en compte des effets de vendor lock-in, impacts entre infrastructure et architecture logicielle, facilité de dépoiement, flexibilité, etc.

MySQL

Sécurité

Tests

  • k6 : un outil en Go et Javascript permettant de faire des tests de performance. Sa prise en main a l’air aisé et il semble avoir des fonctionnalités assez intéressantes pour faire des tests variés que ce soit sur la profondeur du scénario (1 ou plusieurs urls) ou les niveau de tests (checks, ratio, etc)

TICK (Telegraf, InfluxDB, Chronograf, Kapacitor)

Bonus : Lecture de l’été

  • #hyperlean – Ce que signifie l’avènement du numérique : je n’ai pas encore lu le livre mais je suis le blog de Cecil depuis des années et ses aventures dans le monde de l’agile, du lean, de l’entreprise collaborative et de la transformation digitale. Son livre se veut un guide pratique de la transformation digitale en abordant le pourquoi, le quoi et le comment. Dans le comment, on va retrouver forcément la méthode lean.

Web, Ops & Data - Avril 2017

kafka stream container kubernetes rest python terraform rancher mysql postgres microservice angularjs test css grid

Container & Orchestration

  • Kubernetes 1.6: Multi-user, Multi-workloads at Scale : à l’occasion de KubeCon à Berlin, sortie d’une nouvelle version de Kubernetes avec son lot de nouveautés, de nouvelles fonctionnalités et de fonctionnalités qui évolue de alpha > beta > stable en fonction de leurs maturités respectives. 4 grands axes d’amélioration : scaling avec le support jusqu’à 5.000 noeuds / 150.000 pods est supporté via la fédération de clusters, sécurité avec la mise en place de RBAC (Role Based Access Control) et amélioration de kubeadm pour initialiser votre cluster, scheduling amélioré pour mieux gérer la distribution des workloads sur votre cluster et enfin le provisionning dynamique du stockage pour simplifier la vie et la gestion du stockage par une allocation à la demande.

DevOps

HTML5

  • Practical CSS Grid: Adding Grid to an Existing Design : la dernière nouveauté CSS, c’est la grille. Une fois cette grille définie, on peut y positionner les éléments de son choix. L’article permet de voir un cas pratique de mise en place de cette grille dans le cadre de la refonte d’un blog. On y voit aussi les quelques limitations et soucis que l’on peut actuellement rencontrer avec ce nouveau système disponible dans tous les navigateurs ou presque depuis Mars 2017.

Javascript

Kafka

  • Kafka Streams 101 : un article simple et pédagogique sur Kafka Streams, la librairie Java qui permet de consommer ou de produire des messages dans un topic kafka.

MySQL

Postgres

Python

Instancier un cluster de machines sur Scaleway avec Terraform

terraform scaleway infrastructure as code iac

Objectifs

Pour pouvoir tester différentes solutions, il peut être utile de pouvoir créer rapidement une infrastructure chez un fournisseur tiers. Pour cela nous allons nous appuyer sur la solution Terraform, dont l’objectif est de pouvoir gérer une insfrastructure via du code qui permet de décrire cette infrastructure et les règles associées (dans la tendance Infrastructure as Code).

Cela se fera chez Scaleway mais cela peut se faire chez d’autres fournisseurs tant qu’un provider Terraform existe.

Nous allons nous appuyer sur l’intégration Terraform/Scaleway pour créer un cluster de 3 machines.

Pré-requis

  • Un compte chez Scaleway
  • Avoir créé un token (via Account > Credentials)
  • Avoir terraform sur son PC ; version 0.9.2 dans mon cas.

Créer un ficheir cluster-3.tf dans un dossier vide. Il est important qu’il soit vide car Terraform prend en compte tous les fichiers .tf qu’il rencontre dans le répertoire courant.

Il faut commencer par déclarer notre provider ; je fournis les infos de key & token, ainsi que le datacenter où je souhaite lancer mon cluster :

provider "scaleway" {
  organization = "<access key>"
  token        = "<token>"
  region       = "par1"
}

Je déclare ensuite des data, que l’on peut assimiler à des variables à ce stade :

  • le bootscript est une option de démarrage, notamment au niveau du noyau, d’un serveur chez Scaleway,
  • l’image est l’OS voulu, ici une version Ubuntu Xenial en 64 bits.
data "scaleway_bootscript" "latest" {
  architecture = "x86_64"
  name_filter  = "stable"
}

data "scaleway_image" "ubuntu" {
  architecture = "x86_64"
  name         = "Ubuntu Xenial"
}

Ensuite, je définis une politique de sécurité en 2 étapes :

  • Je déclare la politique de sécurité,
  • J’y ajoute les différentes règles : ici on autorise par défaut ssh, http et https.
resource "scaleway_security_group" "cluster_default" {
  name        = "cluster_default"
  description = "Allow SSH, HTTP, HTTPS traffic"
}

resource "scaleway_security_group_rule" "ssh_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 22
}

resource "scaleway_security_group_rule" "http_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 80
}

resource "scaleway_security_group_rule" "https_accept" {
  security_group = "${scaleway_security_group.cluster_default.id}"
  action         = "accept"
  direction      = "inbound"
  ip_range       = "0.0.0.0/0"
  protocol       = "TCP"
  port           = 443
}

Je pourrais donc me connecter en ssh, http et https sur l’ensemble de mon cluster une fois qu’il sera initialisé.

Je déclare ensuite une IP et je l’associe au serveur qui l’utilisera :

resource "scaleway_ip" "cluster-master_ip" {
  server = "${scaleway_server.cluster-master.id}"
}

Enfin, je déclare mon serveur qui va reprendre l’ensemble des informations précédentes, ainsi que quelques informations spécifique comme le type d’instance (type) ou encore le volume additionnel (volume) attaché au serveur. Il y a des directives scaleway_volume ou scaleway_volume_attachment mais l’API Scaleway ne permet pas de les utiliser pour ce type de serveur.

resource "scaleway_server" "cluster-master" {
  name           = "cluster-master"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

Sur le même modèle, nous allons instancier les 2 autres noeuds de notre cluster :

resource "scaleway_ip" "cluster-node1_ip" {
  server = "${scaleway_server.cluster-node1.id}"
}

resource "scaleway_server" "cluster-node1" {
  name           = "cluster-node1"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

resource "scaleway_ip" "cluster-node2_ip" {
  server = "${scaleway_server.cluster-node2.id}"
}

resource "scaleway_server" "cluster-node2" {
  name           = "cluster-node2"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"
  
  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

Vous pouvez déjà valider qu’il n’y a pas d’erreur de syntaxe avec

↪ terraform fmt
cluster-3.tf

Si pas d’erreur, alors il ne retourne que le nom du fichier ou rien si commande déjà exécutée.

Ensuite vous pouvez regarder ce qu’il va se passer avec terraform plan. Cela vous sort un diff de ce qui va être réalisé (ou changé s’il y a mise à jour du plan)

Dans notre cas :

↪ terraform plan

[...]

+ scaleway_ip.cluster-master_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-master.id}"

+ scaleway_ip.cluster-node1_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node1.id}"

+ scaleway_ip.cluster-node2_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node2.id}"

+ scaleway_security_group.cluster_default
    description: "Allow SSH, HTTP, HTTPS traffic"
    name:        "cluster_default"

+ scaleway_security_group_rule.http_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "80"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_security_group_rule.https_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "443"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_security_group_rule.ssh_accept
    action:         "accept"
    direction:      "inbound"
    ip_range:       "0.0.0.0/0"
    port:           "22"
    protocol:       "TCP"
    security_group: "${scaleway_security_group.cluster_default.id}"

+ scaleway_server.cluster-master
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

+ scaleway_server.cluster-node1
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node1"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

+ scaleway_server.cluster-node2
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node2"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "${scaleway_security_group.cluster_default.id}"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"

Plan: 10 to add, 0 to change, 0 to destroy.

Pour provisionner l’infrastructure, il ne vous reste plus qu’à faire terraform apply.

↪ terraform apply
data.scaleway_bootscript.latest: Refreshing state...
data.scaleway_image.ubuntu: Refreshing state...
scaleway_security_group.cluster_default: Creating...
  description: "" => "Allow SSH, HTTP, HTTPS traffic"
  name:        "" => "cluster_default"
scaleway_security_group.cluster_default: Creation complete (ID: 06b93dc3-...2beffd62)
scaleway_security_group_rule.ssh_accept: Creating...
  action:         "" => "accept"
  direction:      "" => "inbound"
  ip_range:       "" => "0.0.0.0/0"
  port:           "" => "22"
  protocol:       "" => "TCP"
  security_group: "" => "06b93dc3-9a8b-4022-80bf-e9172beffd62"
scaleway_server.cluster-master: Creating...

[...]

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Vous pouvez consulter l’ensemble des informations de votre infrastructure avec la commande terraform show.

Il ne vous reste plus qu’à vous connecter sur vos serveurs, faire les actions dont vous avez besoin.

Supposons que nous ayons besoin d’un 4ème noeud, il suffirait de rajouter dans le fichier cluster-3.tf :

resource "scaleway_ip" "cluster-node3_ip" {
  server = "${scaleway_server.cluster-node3.id}"
}

resource "scaleway_server" "cluster-node3" {
  name           = "cluster-node3"
  image          = "${data.scaleway_image.ubuntu.id}"
  type           = "VC1M"
  bootscript     = "${data.scaleway_bootscript.latest.id}"
  security_group = "${scaleway_security_group.cluster_default.id}"

  volume {
    size_in_gb = 50
    type       = "l_ssd"
  }
}

On peut valider notre changement avec terraform plan :

↪ terraform plan

[...]

+ scaleway_ip.cluster-node3_ip
    ip:     "<computed>"
    server: "${scaleway_server.cluster-node3.id}"

+ scaleway_server.cluster-node3
    bootscript:          "8fd15f37-c176-49a4-9e1d-10eb912942ea"
    enable_ipv6:         "false"
    image:               "89457135-d446-41ba-a8df-d53e5bb54710"
    name:                "cluster-node3"
    private_ip:          "<computed>"
    public_ip:           "<computed>"
    public_ipv6:         "<computed>"
    security_group:      "06b93dc3-9a8b-4022-80bf-e9172beffd62"
    state:               "<computed>"
    state_detail:        "<computed>"
    type:                "VC1M"
    volume.#:            "1"
    volume.0.size_in_gb: "50"
    volume.0.type:       "l_ssd"
    volume.0.volume_id:  "<computed>"


Plan: 2 to add, 0 to change, 0 to destroy.

Puis de mettre à jour le cluster avec terraform apply

↪ terraform apply

[...]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Enfin, comme toutes les choses ont une fin, vous pouvez détruire l’ensemble de l’infrastructure créé via terraform destroy.

↪ terraform destroy

[...]

Destroy complete! Resources: 14 destroyed.

J’espère que cette introduction à Terraform vous donnera des idées ; les éditeurs de code modernes fournissent souvent des plugins pour la syntaxe et les snippets terraform. Scaleway reste assez limité en tant que provider terraform. Si vous regardez le provider AWS, vous pouvez interagir avec énormément de services AWS (pour ne pas dire tous) : VPC, EC2, ELB, RDS, etc.

1 2 3