Catégorie : Technique

Créer des serveurs sur Openstack OVH avecTerraform

Comme dirait mon vendeur de téléphone, “on ne va pas se mentir” : je déteste le Cloud. Ça vient de très loin – je me demande même si je faisais de l’informatique – d’une discussion avec une fraîche mouture de Science-Po de l’époque qui me vantait l’avantage du concept “magique” du cloud, et en quoi il était bon que “Mme Michu” n’y comprenne rien. Maintenant que je vois cela de l’intérieur, je dirais que mon sentiment de défiance est renforcé. 

Derrière le Cloud il y a du “barre metal”, c’est à dire des serveurs physiques reliés les uns aux autres, très souvent sous Linux, avec une couche d’automatisation complexe qui permet d’offrir des services de plus en plus importants aux clients. Or il est une règle vieille comme le monde : pas d’indépendance sans connaissance… Durant le temps que vous chercherez la technique pour construire des serveurs sur l’infra d’Amazon ou Microsoft, d’autres le passeront à trouver des techniques plus poussées pour vous rendre toujours plus dépendant. Des services rendus propriétaires qui étrangement fonctionnent mieux que le standard opensource… par exemple des bases de données, de la redondance de charge… Le Cloud c’est avec modération, celui qui se sert du Cloud pour des applications critiques est fou, et dans le fond celui qui vend des services Cloud américains aux grands comptes français ne veut pas vraiment de l’indépendance économique française. C’est une situation qui devrait être accompagnée par le politique car dans les DSI, l’argent est bien souvent ROI… et la stratégie sur le long terme se fait rare. Si ces questions liées à la  “souveraineté numérique” vous intéressent, je vous invite à lire cet article : Souveraineté numérique : le choix inquiétant fait par la BPI pour l’hébergement des données.

Vous l’aurez compris, je vais prendre un exemple de Cloud bien français même si ce dernier s’étend maintenant dans le monde entier : celui d’OVH. En plus ils utilisent la techno Openstack, ce qui est parfait pour s’initier aux concepts de cloud public/privé. Il faut savoir que le Cloud n’est pas gratuit, 0.01€ vous seront facturés à la création de l’infra ci-dessous, plus si vous décidez de garder le serveur.

Prérequis

  • Avoir un compte chez OVH et souscrit à l’offre Cloud
  • Un utilisateur OpenStack
  • Les variables d’environnement OpenStack
  • Vos identifiants API et clés d’autorisations OVH
  • Une clé SSH
  • L’exécutable Terraform
  • Les clients OpenStack (nova, glance)

Vous trouverez les pages de tutoriel chez OHV et sur ce site. Normalement pas de soucis majeurs pour effectuer ces opérations, si vous avez néanmoins des problèmes, envoyez-moi un message et je détaillerai ce paragraphe des prérequis.

Utilisation de Terraform pour les instances Cloud public

On va faire très simple, trois fichiers. Un pour la connection à Openstack, un autre pour la création de la machine et son réseau, le dernier pour les variables :

$ tree
.
├── connections.tf
├── simple_instance.tf
└── variables.tf

connections.tf

Rien de bien compliqué ici :

provider "openstack" {
  auth_url = "https://auth.cloud.ovh.net/v3.0/"
  domain_name = "default"
  tenant_name = ""
  alias = "ovh"
  user_name   = "utilisateur_openstack" # vous possédez ces valeurs 
  password    = "le_mot_de_passe"       # si vous avez effectué les prérequis
}

simple_instance.tf

Voilà maintenant pour créer un serveur, j’utilise l’adresse IP de la machine d’administration afin de l’autoriser à accéder au serveur Cloud via SSH. Vous pouvez utiliser une autre technique que firewalld, il suffit de changer le script run.sh … Comme d’habitude, j’utilise des images cloud de Fedora Server (ici 32).

resource "openstack_compute_keypair_v2" "mattkey" {
  provider   = openstack.ovh
  name       = "mattkey" # A changer : c'est la clé que vous avez préalablement créée dans l'interface openstack OVH
  public_key = file("~/.ssh/id_rsa.pub") # C'est la clé que vous avez préalablement créée dans l'interface openstack OVH
}

data "openstack_networking_network_v2" "public_a" {
  name     = "Ext-Net"
  provider = openstack.ovh
}

resource "openstack_networking_port_v2" "public_a" {
  name           = "test_a_0"
  network_id     = data.openstack_networking_network_v2.public_a.id
  admin_state_up = "true"
  provider       = openstack.ovh
}

data "http" "myip" {
  url = "https://api.ipify.org"
}

data "template_file" "setup" {
  template = <<SETUP
#!/bin/bash
# install & configure firewall
dnf install -y firewalld
systemctl start firewalld
systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-source=${trimspace(data.http.myip.body)}/32 --zone=trusted
firewall-cmd --permanent --add-service=ssh --zone trusted
firewall-cmd --permanent --remove-service=ssh --zone=public
firewall-cmd --reload
SETUP
}

data "template_file" "userdata" {
  template = <<CLOUDCONFIG
#cloud-config
write_files:
  - path: /tmp/setup/run.sh
    permissions: '0755'
    content: |
      ${indent(6, data.template_file.setup.rendered)}
  - path: /etc/systemd/network/30-ens3.network
    permissions: '0644'
    content: |
      [Match]
      Name=ens3
      [Network]
      DHCP=ipv4
runcmd:
   - sh /tmp/setup/run.sh
CLOUDCONFIG
}

resource "openstack_compute_instance_v2" "fed-test" {
  region      = var.region
  name 	      = "test-fed-instance"
  provider    = openstack.ovh
  image_name  = "Fedora 32"
  flavor_name = "s1-2"
  user_data   = data.template_file.userdata.rendered
  key_pair    = openstack_compute_keypair_v2.mattkey.name

  network {
    access_network = true
    port           = openstack_networking_port_v2.public_a.id
  }
}

output "Server_IP" {
  value = openstack_networking_port_v2.public_a.all_fixed_ips
}

variables.tf

variable "region" {
  type    = string
  default = "UK1" # cette valeur dépend de votre compte OVH et du fichier openstack .rc
}

Et voilà le tour est joué, théoriquement, l’ip du serveur s’affiche à la fin de l’exécution du `terraform apply`, vous pouvez vous y connecter via SSH avec votre clé privée. Pour tout détruire : `terraform destroy`. Si vous vous souvenez de mes précédents articles, ici ou , vous pouvez maintenant provisionner la ou les machines avec Ansible.

Un seul et même réseau quelque soit le datacenter

Derrière ce titre un poil “putaclic” se cache des heures de recherches et des litres de café. Et oui, le réseau et moi ça fait deux… Vous vous souvenez sans doute de mon dernier article portant sur openvswitch, il n’était pas écrit pour rien… généralement quand je commence à fouiller une techno c’est que j’ai une idée derrière la tête.

Jusqu’à présent pour créer un réseau privé, j’utilisais tinc. Je ne vais pas m’appesantir sur ce sujet, mais c’est tout de même assez puissant. Je ne cache pas que dans une logique d’automatisation et d’industrialisation, ce n’est pas franchement sexy. Il faut installer le binaire, le configurer (en mode switch c’est mieux), créer les interfaces tun/tap, les clés, les partager…  Il existe des rôles Ansible pour faire le job, vous les trouverez facilement sur Github.

On va s’approcher un peu plus d’un fonctionnement type OpenStack et utiliser les possibilités offertes par OpenVSwitch.

Nous allons créer un bridge interne GRE avec tunnel IPsec :

Pré-requis

Pour ce faire il faut au minimum deux hyperviseurs KVM bare metal, ça fonctionne aussi avec Proxmox et MacOS VMWare (ahahah), OpenStack puisque c’est intégré dans la solution, mais aussi sans rien… Il faut deux IPs joignables qui pointent vers les serveurs. Avoir installé openvswitch, sauf si ça ne vous intéresse pas mais dans ce cas, je me demande pourquoi vous lisez ces lignes.

Configuration

On ne va pas faire une usine à gaz, juste créer des certificats auto-signés avec la cli d’openvswitch sur le premier hôte : 

mkdir /etc/keys
cd !$
ovs-pki req -u `hostname`
ovs-pki self-sign `hostname`

La même procédure sur le deuxième hôte :

mkdir /etc/keys
cd !$
ovs-pki req -u `hostname`
ovs-pki self-sign `hostname`

Il faut copier la clé d’un serveur sur l’autre : 

scp `hostname`-cert.pem user@hote2:/etc/keys/`hostname`-cert.pem
scp `hostname`-cert.pem user@hote1:/etc/keys/`hostname`-cert.pem

Ensuite on va dire à openvswitch où se trouvent ces fichiers :

ovs-vsctl set Open_vSwitch . \
other_config:certificate=/etc/keys/<hostname1>-cert.pem \
other_config:private_key=/etc/keys/<hostname1>-privkey.pem

A faire sur chacun des serveurs bien sûr et changeant le nom hostname du .pem. C’est terminé pour les certificats et clés. Maintenant la mise en place des bridges ipsec GRE avec openvswitch. Sur l’hôte 1:

ip addr add 192.0.0.1/24 dev br-ipsec
ip link set br-ipsec up
ovs-vsctl add-port br-ipsec tun -- set interface tun type=gre \
options:remote_ip=<ip_de_hote2> \
options:remote_cert=/etc/keys/<hostname2>-cert.pem
ovs-vsctl show

Sur l’hôte 2 :

ip addr add 192.0.0.2/24 dev br-ipsec
ip link set br-ipsec up
ovs-vsctl add-port br-ipsec tun -- set interface tun type=gre \
options:remote_ip=<ip_de_hote1> \
options:remote_cert=/etc/keys/<hostname1>-cert.pem

Et maintenant sous vos yeux ébahis depuis l’hôte 2 :

ping 192.0.0.1
PING 192.0.0.1 (192.0.0.1) 56(84) bytes of data.
64 bytes from 192.0.0.1: icmp_seq=1 ttl=64 time=88.9 ms
64 bytes from 192.0.0.1: icmp_seq=2 ttl=64 time=87.6 ms
64 bytes from 192.0.0.1: icmp_seq=3 ttl=64 time=87.8 ms
^C
--- 192.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 87.587/88.097/88.926/0.591 ms

Généralisation

Vu que les serveurs sont des hyperviseurs KVM, on va tenter de créer des machines virtuelles qui profiteront du tunnel IPsec.
Comme nous l’avons vu dans le dernier article sur openvswitch, il faut intégrer le xml du bridge pour qu’il soit interprété par libvirt :

# cat /tmp/net-ipsec.xml
<network>
  <name>net-ipsec</name>
  <forward mode='bridge'/>
  <bridge name='br-ipsec'/>
  <virtualport type='openvswitch'/>
</network>
virsh net-define /tmp/net-ipsec.xml
virsh net-start net-ipsec
virsh net-autostart net-ipsec

Faites démarrer une vm sur chaque hyperviseur avec comme réseau net-ipsec, donnez-lui une adresse dans ce réseau et pingez. 

Ping de deux vms entre Paris et Beauharnois (datacenter OVH)… latence cata…

Automatisation

Pour travailler dans un environnement automatisé, avec Terraform et Libvirt KVM, il faudra utiliser un alias pour le provider (j’ai mis Toronto en hommage à Glenn Gould, le joueur de foot) :

# cat multi_hyp.tf
provider "libvirt" {
          uri   = "qemu:///system"
}

provider "libvirt" {
          alias = "toronto"
          uri   = "qemu+ssh://<kvm_user>@<ip_address>/system"
}

resource "libvirt_volume" "local-fedora-qcow2" {
          name = "fedora-qcow2"
          pool = "default"
          source = "https://download.fedoraproject.org/pub/fedora/linux/releases/32/Cloud/x86_64/images/Fedora-Cloud-Base-32-1.6.x86_64.qcow2"
          format = "qcow2"
}

resource "libvirt_volume" "remote-fedora-qcow2" {
          provider = libvirt.toronto
          name = "fedora-qcow2"
          pool = "default"
          source = "https://download.fedoraproject.org/pub/fedora/linux/releases/32/Cloud/x86_64/images/Fedora-Cloud-Base-32-1.6.x86_64.qcow2"
          format = "qcow2"
}

resource "libvirt_cloudinit_disk" "commoninit-local" {
          name = "local-commoninit.iso"
          pool = "default"
          user_data = data.template_file.user_data.rendered
          network_config = data.template_file.network_config_local.rendered
}

resource "libvirt_cloudinit_disk" "commoninit-remote" {
          provider = libvirt.toronto
          name = "remote-commoninit.iso"
          pool = "default"
          user_data = data.template_file.user_data.rendered
          network_config = data.template_file.network_config_remote.rendered
}

data "template_file" "user_data" {
          template = file("${path.module}/cloud_init.cfg")
          vars = {
             hostname       = "fedora"
             fqdn           = "lan"
             user           = "matt"
             ssh_public_key = "ssh-rsa AAAA..."
          }
}


data "template_file" "network_config_local" {
          template = file("${path.module}/network_config_static.cfg")
          vars = {
             prefixIP = "192.0.0"
             octetIP = "6"
          }
}

data "template_file" "network_config_remote" {
          template = file("${path.module}/network_config_static.cfg")
          vars = {
             prefixIP = "192.0.0"
             octetIP = "7"
          }
}

resource "libvirt_domain" "local-domain" {
          name   = "local"
          memory = "2048"
          vcpu   = 2

          disk {
            volume_id = libvirt_volume.local-fedora-qcow2.id
          }

          cloudinit = libvirt_cloudinit_disk.commoninit-local.id

          network_interface {
             network_name   = "net-ipsec"
          }
}

resource "libvirt_domain" "remotehost-domain" {
          provider = libvirt.toronto
          name     = "toronto"
          memory   = "2048"
          vcpu     = 2

          disk {
            volume_id = libvirt_volume.remote-fedora-qcow2.id
          }

          cloudinit = libvirt_cloudinit_disk.commoninit-remote.id

          network_interface {
            network_name = "net-ipsec"
          }
}

terraform {
          required_version = ">= 0.12"
}

Avec les fichiers config de cloudinit qui vont bien :

# cat cloud_init.cfg
#cloud-config
# vim: syntax=yaml
hostname: ${hostname}
fqdn: ${fqdn}
ssh_pwauth: true
manage_etc_hosts: true
chpasswd:
  list: |
     root: StrongPassword
  expire: False
users:
  - name: ${user}
    passwd: $6$rounds=4096$sWnV/iBTck9OVnMl$PcfdG7/Yjq91I7KdGJyfap23K3wvt3OFtnGhC2vXpbeK7zYC1EO4qU3toVinoYHxPPhkA3HmyKURONXv1Ezrq.
    lock-passwd: false
    ssh_authorized_keys:
      - ${ssh_public_key}
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash
    groups: wheel
growpart:
  mode: auto
  devices: ['/']
output:
    init:
        output: "> /var/log/cloud-init.out"
        error: "> /var/log/cloud-init.err"
    config: "tee -a /var/log/cloud-config.log"
    final:
        - ">> /var/log/cloud-final.out"
        - "/var/log/cloud-final.err"
final_message: "The system is up, after $UPTIME seconds"

et pour le réseau statique :

# cat network_config_static.cfg
version: 2
ethernets:
  eth0:
     dhcp4: no
     dhcp6: no
     addresses: [ ${prefixIP}.${octetIP}/24 ]

Et les vms se pingent, on peut également s’y connecter en SSH depuis leurs adresses privées sur 192.0.0.0/24 :

Optimisation

Il peut être franchement intéressant d’optimiser en configurant la valeur du MTU. Par exemple sur ma connexion entre mes deux hyperviseurs kvm (Paris et Beauharnois) en passant d’un MTU 1500 à 1554 j’obtiens : 

[root@hyp ~]# iperf -c 192.0.0.2
------------------------------------------------------------
Client connecting to 192.0.0.2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 192.0.0.1 port 44128 connected with 192.0.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.2 sec  10.1 MBytes  8.35 Mbits/sec
[root@hyp ~]# ifconfig eno3 mtu 1554
[root@hyp ~]# iperf -c 192.0.0.2
------------------------------------------------------------
Client connecting to 192.0.0.2, TCP port 5001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 192.0.0.1 port 44130 connected with 192.0.0.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec   264 MBytes   220 Mbits/sec

Voilà pour cet article, reste maintenant à isoler à l’intérieur avec des VLANS, mais aussi VXLAN… dans un futur… proche… si j’ai le temps…

Nextcloud avec cluster KVM: GlusterFS, Redis, MariaDB et Load-Balancing

Nous avons vu précédemment comment monter une infra simple et créer un module scalable avec Terraform et Ansible. Maintenant nous allons tout mélanger pour faire un autre cocktail.

Présentation :

schema archi nextcloud

Pour le fun, je mets le graph Terraform que l’on obtient avec la commande `terraform graph | dot -Tpng > graph.png` (la sortie peut également être en .svg) :

Graph terraform
Graph Terraform

Comme vous l’avez compris, il y a maintenant cinq modules : 

  • 2 Mariadb Master / Slave servers,
  • 2 Redis Master / Slave servers,
  • 2 vms in GlusterFS Cluster,
  • Haproxy load-balancer,
  • 2 Nextcloud serveurs avec Nginx ou Apache et php-fpm.

Avec cette version du code j’ai forcé l’installation de nginx : j’avais mis précédemment apache par défaut. C’est configurable via les variables d’Ansible. La base de donnée est répliquée sur le slave de mariadb, j’utiliserai prochainement galera. Le cache Redis est également configuré en Master/Slave, il n’y a pas (encore) de Redis-Sentinelle pour basculer le slave en master en cas de crash du master… Le cluster GlusterFS possède deux bricks répliquées en temps réel sur deux serveurs (replica). Les serveurs Nexcloud utilisent un répertoire /var/www/html/nextcloud commun pour l’application web ainsi qu’un répertoire /var/nc_data commun pour les données du cloud. Vous l’aurez compris lorsque haproxy vous redirige sur l’un ou l’autre des deux serveurs nexcloud, les données sont immédiatement visibles et accessibles sur les deux et répliquées. Par sécurité j’ai gardé SELinux en mode enforcing, mais vous avez la possibilité de basculer en permissive via une variable Ansible.

J’ai aussi intégré dans cette version le code du réseau. J’aurais pu créer des réseaux distincts avec des routes pour que les briques puissent communiquer, cela sera dans une prochaine version… pour l’instant tout est dans un réseau 10.17.3.0/26. De même je n’ai pas eu le temps de coder l’intégration avec les serveurs d’autorité DNS, pour l’instant ça reste un POC, mais ça aussi sera pour une version ultérieure avec noms de domaines, Let’s Encrypt et Terraform en mode multi providers : libvirt et sans doute OVH hein parce qu’on est frenchies.

Requirement

Le tout fonctionne sous Fedora Server cloud image.

Vous devez avoir installé sur l’hyperviseur : Terraform, Libvirt provider et Ansible (Tout est expliqué ici)

Copie / Installation

Copiez le repo, séparez la partie Terraform de la partie Ansible dans les répertoires des applications respectives. Adaptez les variables :

  • variables.tf (terraform)
  • vars (ansible)

Comme le code est franchement long, j’ai tout mis dans un github.

A vous de jouer…

Virtualiser sous iOS ?

Cela peut paraitre étonnant, mais un projet assez Fun se fait connaitre via les réseaux sociaux, en environnement de virtualisation (certes sommaire), pour virtualiser … sous votre iOS préféré. Un iPad, iPhone.

Oui, vous ne rêvez pas…Sur ces mobiles ou tablettes nous voyons développer des tâches de choses assez farfelus et innovateurs. Mais là…joker !

Rien de très spécifique, puisqu’il s’agit d’embarquer un QEMU et Spice.
C’est amusant, de voir un Windows sous un iOS, certes. Mais finalement il y a t’il un intérêt ?

Si vous y trouver un intéret dans un développement le projet GitHub ici.

Portainer…Plus qu’une WEBUI

Que vous soyez développeur ou que vous manipuliez du Docker voici un outil intéressant qui dépasse les 200 000 téléchargements à ce jour.
Portainer.io est mise à disposition en version OpenSource est une boite à outils permettant la gestion de vos conteneurs Docker et ainsi de créer, gérer et réaliser la maintenance via une interface WebUI unique.
Dans sa dernière version, Portanier supporte IPV6 et est actuellement en version 2.4.6 et s’interface avec Kubernetes.

Vous pouvez tester cet outil en démo sur le site de Portainer.

Portainer oui mais pour qui ?

Portainer est compatible avec les versions suivantes de Docker : Docker > 1.9
Cet outil peut être géré sur Docker Swarm, Docker Kubernetes, Docker sur Azur.

Architectures compatibles:

Portainer peut être déployé sur les plates-formes suivantes :

  • Linux plateforme amd64
  • Linux plateforme Arm
  • Linux plateforme arm64
  • Linux plateforme ppc64le
  • Linux plateforme s390x
  • Windows plateforme amd64
  • Darwin plateforme amd64 (MacOS)

Installation de Portainer à l’aide de Docker

L’ensemble du projet est disponible sur le Github du projet, mais n’est pas nécessaire.

Portainer est composé de deux éléments, le Portainer Server et le Portainer Agent. Les deux éléments fonctionnent comme des conteneurs pod Docker sur un moteur Docker ou dans un cluster Swarm, ou encore un Cluster K8s. Lié à Docker, il existe de nombreux scénarios de déploiement possibles. Le scénario présenté est celui le plus couramment utilisé. (si votre configuration n’est pas répertoriée, voir portainer.readthedocs.io pour des options supplémentaires).

Il faut notez que le mode de déploiement recommandé de l’outil est d’utiliser l’agent Portainer.
Vous devez donc déployer Portainer Server sur un cluster swarm ou autonome, soit LINUX Docker host/single node ou Windows Docker Host fonctionnant en mode “Linux containers”).

Utilisez les commandes suivantes de Docker pour déployer le Portainer Server ; notez que l’agent n’est pas nécessaire sur les hôtes autonomes, mais qu’il offre des fonctionnalités supplémentaires s’il est utilisé (voir le scénario du portainer et de l’agent ci-dessous):

$ docker volume create portainer_data
$ docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

Il vous suffit ensuite, d’accéder au port 9000 du moteur Docker où fonctionne portainer à l’aide de votre navigateur préféré.

Remarques

Le port 9000 est le port général utilisé par Portainer pour l’accès à l’interface utilisateur. Le port 8000 est utilisé exclusivement par l’agent EDGE pour la fonction de tunnel inverse. Si vous ne prévoyez pas d’utiliser l’agent edge, vous n’avez pas besoin d’exposer le port 8000 vers votre réseau.

L’option -v /var/run/docker.sock:/var/run/docker.sock ne peut être utilisée que dans les environnements Linux.
Vous pouvez déployer Portainer Server sur un Host Docker WINDOWS autonome (en exécutant des conteneurs Windows) mais attention il doit-être de version build Windows 1803 ou plus récent.

$ docker volume create portainer_data
$ docker run -d -p 8000:8000 -p 9000:9000 --name portainer --restart always -v \.\pipe\docker_engine:\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer

Il vous suffit ensuite, d’accéder au port 9000 du moteur Docker où fonctionne Portainer à l’aide de votre navigateur.

Remarque: l’option -v \.\pipe\docker_engine:\\\.\ peut être utilisée dans les environnements Windows 1803+ Container uniquement.
Gérer un cluster LINUX Swarm avec Portainer Server et le Portainer Agent.

Pour déployer Portainer et un Portainer Agent pour gérer un cluster Swarm, vous pouvez directement déployer Portainer en tant que service dans votre cluster Docker. Il est à noter que cette méthode déploiera automatiquement une seule instance du serveur Portainer et l’agent Portainer comme un service global sur chaque nœud de votre cluster.

$ curl -L https://downloads.portainer.io/portainer-agent-stack.yml -o portainer-agent-stack.yml
$ docker stack deploy --compose-file=portainer-agent-stack.yml portainer

Il vous suffit ensuite et comme à l’habitude d’accéder au port 9000 du moteur Docker où fonctionne Portainer à l’aide de votre navigateur.

Gérer un cluster WINDOWS Swarm avec Portainer Server et l’agent Portainer

Pour déployer Portainer et l’agent Portainer pour gérer un cluster Swarm sous Windows 2016 (1803) ou Windows 2019 (10903), vous pouvez déployer Portainer directement en tant que service dans votre cluster Docker. Notez que cette méthode déploiera automatiquement une seule instance du serveur Portainer, et déploiera l’agent Portainer en tant que service global sur chaque nœud de votre cluster. A peu près à l’identique que sous Linux.

$ curl https://downloads.portainer.io/portainer_windows_stack.yml -o portainer_windows_stack.yml
$ docker stack deploy --compose-file=portainer_windows_stack.yml portainer

Il vous suffit d’accéder ensuite au port 9000 du moteur Docker où fonctionne portainer à l’aide de votre navigateur.

Il est important de noter qu’il faut s’assurer que les ports réseaux requis sont exposés sur les hôtes Docker dans votre cluster AVANT de déployer la pile (et redémarrez votre hôte après avoir ajouté les règles).

netsh advfirewall firewall add rule name="cluster_management" dir=in action=allow protocol=TCP localport=2377
netsh advfirewall firewall add rule name="node_communication_tcp" dir=in action=allow protocol=TCP localport=7946
netsh advfirewall firewall add rule name="node_communication_udp" dir=in action=allow protocol=UDP localport=7946
netsh advfirewall firewall add rule name="overlay_network" dir=in action=allow protocol=UDP localport=4789
netsh advfirewall firewall add rule name="swarm_dns_tcp" dir=in action=allow protocol=TCP localport=53
netsh advfirewall firewall add rule name="swarm_dns_udp" dir=in action=allow protocol=UDP localport=53

DÉPLOIEMENT D’AGENTS DE TRANSPORT SEUL

Pour déployez Portainer Agent sur un cluster LINUX Swarm distant en tant que service d’essaimage, exécutez cette commande sur un nœud de gestion dans le cluster distant.

$ docker service create --name portainer_agent --network portainer_agent_network --publish mode=host,target=9001,published=9001 -e AGENT_CLUSTER_ADDR=tasks. portainer_agent --mode global --mount type=bind,src=//var/run/docker.sock,dst=/var/run/docker.sock --mount type=bind,src=//var/lib/docker/volumes,dst=/var/lib/docker/volumes --mount type=bind,src=/,dst=/host portainer/agent

Pour déployer Portainer Agent sur un Host Docker autonome LINUX distant (sans cluster), exécutez cette commande

$ docker run -d -p 9001:9001 --name portainer_agent --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/docker/volumes:/var/lib/docker/volumes portainer/agent

Pour déployer Portainer Agent sur un serveur autonome Windows Server 2016 (ou ultérieur ) host Docker.

$ docker run -d -p 9001:9001 --name portainer_agent --restart=always -v \.\pipe\docker_engine:\\.\pipe\docker_engine portainer/agent

Pour déployer l’agent Portainer sur un serveur docker SINGLE Windows Server 2016 ( ou ultérieur) fonctionnant comme un nœud Swarm (pour les déploiements multi-noeuds, veuillez consulter les configurations avancées)

$ docker run -d -p 9001:9001 --name portainer_agent --restart=always -v \.\pipe\docker_engine:\.\pipe\docker_engine -e AGENT_CLUSTER_ADDR=tasks.agent portainer/agent

Note : les options ci-dessus ne font que déployer l’agent, vous devez vous connecter à l’agent à partir d’une instance existante de Portainer Server.
Pour d’autres scénarios de déploiement, et pour connaître les conseils et les techniques de déploiement avancées, consultez la documentation complète de Portainer.

Portainer est libre d’utilisation

… mais le support ne l’est pas, voici les modèles de supports facturables:

Créer un module scalable avec Terraform

Je profite de la fin du confinement qui n’en finit plus de finir pour continuer de jouer avec ma récente découverte : Terraform. Comme j’en parlais dans de précédents articles, la force de Terraform vient d’une part de sa capacité à pouvoir “dialoguer” avec différents fournisseurs de Cloud, d’autre part de rendre trivial la “scalabilité” de l’infra. On peut parfaitement en cas de montée de charge sur une application, décider de créer par exemple, un serveur supplémentaire dédié au cache (un slave Redis).

Poursuivre la lecture « Créer un module scalable avec Terraform »