905 vues 0 commentaires

Tutorial : Rancher + Docker + WordPress + Mysql + Serveur Web

par le14 janvier 2017
 

L’objectif de ce premier tutorial est de pouvoir déployer rapidement des hôtes sur un service accessible comme l’est Scaleway afin d’obtenir une infrastructure web de haute disponibilité au moyen de Rancher et des containers Dockers. Dans un premier temps, cette configuration de test est établie au sein d’un réseau local. Il conviendra d’utiliser les IP publiques des différents serveurs lorsque le déploiement se fera sur un service comme Scaleway, Dedibox, Ovh et de s’assurer que les ports sont bien ouverts pour laisser passer les communications entre les hôtes et le service d’orchestration Rancher.

Pour se faire, nous procéderons à l’installation d’un serveur Hôte pour Rancher avec une version Ubuntu 14.04 sur laquelle nous installerons simplement le client Openssh , Docker, et le container rancher.

Nous installerons ensuite de nouveaux hôtes afin d’assurer la redondance de tous les éléments constitutifs de nos sites internet et notamment comment distribué une même ip publique d’un serveur Web sur plusieurs containers hébergeant des sites eux même rattachés à plusieurs containers mysql par exemple.

La question brûlante est donc comment faire pour que mon serveur mysql hébergé reste accessible si jamais l’hôte tombe. Le nouvel hôte n’aura pas forcément la même ip interne ou public.

cluster_pxc_mysql_wordpress_haproxy

[code]pxc-data:
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: ‘yes’
labels:
io.rancher.scheduler.affinity:container_label_soft_ne: io.rancher.stack_service.name=$${stack_name}/$${service_name}
io.rancher.container.start_once: ‘true’
command:
– /bin/true
image: flowman/percona-xtradb-cluster:5.6.28-1
volumes:
– /docker-entrypoint-initdb.d
– /etc/mysql/conf.d
– /var/lib/mysql
net: none
pxc:
labels:
io.rancher.sidekicks: pxc-clustercheck,pxc-server,pxc-data
io.rancher.scheduler.affinity:container_label_soft_ne: io.rancher.stack_service.name=$${stack_name}/$${service_name}
io.rancher.container.hostname_override: container_name
image: flowman/percona-xtradb-cluster-confd:v0.2.0
volumes_from:
– pxc-data
pxc-server:
environment:
MYSQL_DATABASE: wordpress
MYSQL_PASSWORD: wordpress
MYSQL_ROOT_PASSWORD: password
MYSQL_USER: wordpress
PXC_SST_PASSWORD: password
labels:
io.rancher.scheduler.affinity:container_label_soft_ne: io.rancher.stack_service.name=$${stack_name}/$${service_name}
io.rancher.container.hostname_override: container_name
entrypoint:
– bash
– -x
– /opt/rancher/start_pxc
image: flowman/percona-xtradb-cluster:5.6.28-1
volumes_from:
– pxc-data
net: container:pxc
pxc-clustercheck:
labels:
io.rancher.scheduler.affinity:container_label_soft_ne: io.rancher.stack_service.name=$${stack_name}/$${service_name}
io.rancher.container.hostname_override: container_name
image: flowman/percona-xtradb-cluster-clustercheck:v2.0
volumes_from:
– pxc-data
net: container:pxc
mywordpress:
environment:
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
WORDPRESS_DB_NAME: wordpress
tty: true
image: wordpress
links:
– pxc:db
stdin_open: true
wordpresslb:
ports:
– 80:80
tty: true
image: rancher/load-balancer-service
links:
– mywordpress:mywordpress
stdin_open: true[/code]
pxc-data:
scale: 3
metadata:
mysqld: |
innodb_buffer_pool_size=512M
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0
innodb_file_per_table=1
innodb_log_file_size=128M
innodb_log_buffer_size=64M
innodb_support_xa=0
query_cache_size=0
query_cache_type=0
sync_binlog=0
max_connections=1000
wsrep_sst_auth=sstuser:password
pxc:
scale: 3
health_check:
port: 8000
interval: 2000
unhealthy_threshold: 3
strategy: none
response_timeout: 2000
request_line: GET / HTTP/1.1
healthy_threshold: 2
metadata:
mysqld: |
innodb_buffer_pool_size=512M
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0
innodb_file_per_table=1
innodb_log_file_size=128M
innodb_log_buffer_size=64M
innodb_support_xa=0
query_cache_size=0
query_cache_type=0
sync_binlog=0
max_connections=1000
wsrep_sst_auth=sstuser:password
pxc-server:
scale: 3
metadata:
mysqld: |
innodb_buffer_pool_size=512M
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0
innodb_file_per_table=1
innodb_log_file_size=128M
innodb_log_buffer_size=64M
innodb_support_xa=0
query_cache_size=0
query_cache_type=0
sync_binlog=0
max_connections=1000
wsrep_sst_auth=sstuser:password
pxc-clustercheck:
scale: 3
metadata:
mysqld: |
innodb_buffer_pool_size=512M
innodb_doublewrite=0
innodb_flush_log_at_trx_commit=0
innodb_file_per_table=1
innodb_log_file_size=128M
innodb_log_buffer_size=64M
innodb_support_xa=0
query_cache_size=0
query_cache_type=0
sync_binlog=0
max_connections=1000
wsrep_sst_auth=sstuser:password
mywordpress:
scale: 1
wordpresslb:
scale: 1
load_balancer_config:
haproxy_config: {}
health_check:
port: 42
interval: 2000
unhealthy_threshold: 3
strategy: recreate
response_timeout: 2000
healthy_threshold: 2

Avec cette configuration, vous ajouterez un stack ou votre base de donnée se trouvera au sein d’un cluster PXC de trois containers. Dans cette configuration, on disposera donc d’un frontal en charge de l’équilibrage de charge avec HaProxy et l’acheminement des différentes requêtes web au serveurs. Dans le cas présent, il n’y qu’un seul container WordPress.

Il manque surtout dans cette configuration un espace de stockage répliqué pour le répertoire /var/www/html ou se trouve toute la configuration wordpress, les documents uploadés (image, vidéo) … Pour résoudre cette problèmatique en cas de défaillance, il faut ajouter une couche GlusterFS sur laquelle nous monterons pour nos différents containers un volume partagé.

Avec tous ces containers mirrorés, et redondés, la sauvegarde de vos bases et la surveillance de vos hôtes ne sont pas à négliger. L’infrastructure est plus résistante, encaisse mieux la charge mais n’est pas infaillible !

 

 

Sois le premier à commenter !
 
Ajouter un commentaire »

 

    Laisser un commentaire