blog.bressure.net

Feuille de route du 26/05/2019

La migration a pour objectif de:

• Réduire le nombre de VM (moins d’administration etc)
• Réduire l’empreinte mémoire des services (blog divers, owncloud etc)
• Répondre au besoin de sauvegarde comme à l’heure actuel
• Répondre au besoin de monitoring comme à l’heure actuel
• Ajouter la possibilité d’avoir une préproduction complète

En option:

• Permettre la scalabilité des services
• L’exécution des services dans le cloud

Objectifs atteints

Si j’ai atteints facilement les objectifs principaux, la mis à l’échelle et la capacité à mettre mes services dans le cloud c’est-à-dire de faire héberger ou bien mes conteneurs ou bien la VM hôte dans le cloud, sont encore à faire.

Scalabilité

J’ai commencé avec une VM de 4 Go pour progressivement monter à 7 Go. Cela se fait en modifiant la VM et ajouter du swap pour les raisons que j’évoquais dans le billet sur l’over-commit. L’objectif était de voir combien de RAM je pouvais économiser c’est-à-dire combien j’en avais gaspillé avec le modèle tout VM où un service c’est une VM.

Cette méthode nécessite de l’administration de la VM et atteindra sa limite de toute façon avec le nombre maximum de processus par OS et la résistance à la panne. Si la VM plante alors tous les services sont impactés. C’est le Single Point Of Failure (SPOF) à éviter.

Outils possibles

Le principe est d’avoir plusieurs dockers sur des machines différente (physique ou VM) afin de répartir les conteneurs. C’est ce que swarm semble promettre. Un autre outil serait le bazooka Kubernetes. Le choix de l’outil dépendra des bénéfices apportés par rapport au temps de mise en œuvre.

Quelle que soit la solution technique qui permettra de panacher les conteneurs sur différents docker, il faudra que je revoie le reverse proxy apache pour l’instant natif sur l’hôte. Je pense à le dockeriser ou à utiliser une solution comme traefik.

Automatisation de la création de l’hôte

Dans mon infra j’ai réussi à rendre transparent le déploiement des conteneurs via le processus d’intégration continue. Cela nécessite la création préalable de l’hôte du moteur docker et du gitlab-runner natif. Si docker s’exécute dans une VM comme dans mon cas il faut encore avoir créer la VM et donc installer un OS. Tout cela est encore manuel chez moi même si cela reste simple: une débian minimaliste, docker, docker-compose et gitlab-runner natif.

Clonage de VM

Afin d’avoir une préprod et une prod identique au niveau OS/Docker, j’ai procédé par clonage de VM. Une fois la VM de préprod prête, j’ai cloné celle-ci. Ce mécanisme permet d’ajouter autant de VM que voulu à partir d’une image creuse prête à l’emploi ne contenant que l’OS, le moteur docker et le gitlab-runner natif. Cependant comment ajouter une machine physique à mon infra ? Il faut être capable de créer et configurer une machine physique également:

• Aussi bien pour accueillir un moteur docker directement
• Que pour accueillir des VM à conteneurs

Outils de configuration

La création de machine physique prête à rentrer dans mon cluster de moteur docker peut se faire avec un outils de configuration comme Ansible. Le principe est d’appliquer une configuration (installation, paramétrage) sur une machine disposant d’un accès SSH. Dès lors il me suffit d’être capable d’installer rapidement une machine physique avec les caractéristiques suivantes:

• Débian minimale
• Accès SSH pour Ansible

Dans le cas d’un machine virtuelle, il me suffira d’avoir une VM modèle avec ces mêmes caractéristiques minimales afin de pouvoir utiliser Ansible pour la configurer plus en avant. Cette configuration consistera à:

• mettre à jours le système
• installer le moteur docker
• installer docker compose
• installer le gitlab-runner natif ?

Gitlab-runner

J’utilise jusque là l’intégration continue pour faire les déploiements via gitlab-runner. Cette façon de faire m’évite d’avoir à mettre à jours une copie locale des fichiers de configuration des application par un git pull, le runner faisant tout ça automatiquement. Dans le cadre des conteneurs en cluster gérés par swarm ou kubernetes, le gitlab-runnner sera peut-être remis en cause.

La prochaine étape sera la création d’une VM modèle. La suite au prochain billet !