View allAll Photos Tagged postgresql
These guys passed through a sort node just before the picture.
Teodor Sigaev, Markus Schiltknecht, Jean-Paul Argudo, Dimitri Fontaine, Oleg Bartunov
I know Dimitri since 2006, when I met him in Toronto, Canada. He is now well-known postgresql developer.
Oleg Bartunov during "Full Text Search in PostgreSQL" at PGCon 2007 at the University of Ottawa. A major PostgreSQL developer, Oleg Bartunov has been involved with PostgreSQL since 1995.
Greg Sabino Mullane smiles for the camera at PGCon 2007 at the University of Ottawa. A major PostgreSQL developer, Greg Sabino Mullane presented a number of sessions at PGCon 2007 including the "PL/Perl—Best of Both Worlds" tutorial, "PostgreSQL Version 8 in Action", the PostgreSQL Palaver BOF, and a PostgreSQL Lightning Talk with Spencer Christensen. Also pictured is Brian Dunavant, who presented "Oracle to PostgreSQL Conversion".
via WordPress ift.tt/2lz3RXr
Vous l’attendiez encore plus que le précédent, il est là tout chaud. Voici le troisième article technique sur cette machine de guerre qu’est Docker. Si vous n’avez pas lu le premier ni le second, je vous conseille de les lire avant. Autrement il vous manquera les bases pour suivre ce nouveau TP.
Voici la liste des articles précédents :
Les meilleures commandes de Docker – Partie 1
Les meilleures commandes de Docker – Partie 2
L’objectif est toujours le même que précédemment : créer le plus rapidement possible un site stable de type WordPress. L’autre idée plus générale de ce TP est de vous apprendre à structurer, et à décrire correctement à Docker l’architecture dont vous avez besoin. Ainsi, celui-ci pourra créer automatiquement votre environnement, en une seule ligne de commande.
Pourquoi structurer son environnement ?
Imaginons que vous travaillez sur une application Web qui utilise le Framework Symfony avec une base de données PostgreSQL. Vous serez d’accord avec moi : tout installer à la main, c’est long et chronophage. Mais vous me direz : « il suffit de l’installer une seule fois, après on n’est plus embêtés ».
Je suis d’accord, mais imaginez qu’un nouveau développeur arrive dans votre équipe. Il faudra tout réinstaller de nouveau, alors qu’avec cette technique vous n’aurez qu’à lui donner le fichier de configuration ainsi que la commande qui va bien. Ainsi, le nouveau sera opérationnel en très peu de temps.
Poursuivons cette réflexion : lorsque l’application est prête à être mise en production, vous n’avez qu’à déployer le fichier de configuration, et relancer la commande.
Autre élément important : imaginez que Symfony passe à une nouvelle version très importante, qui corrige une multitude de failles critiques. Vous allez devoir changer de version. Or cela risque d’être l’enfer si vous le faites à la main. De plus, il faudrait isoler votre configuration de développement de celle des tests. Alors que vous pourriez modifier un fichier configuration et spécifier à Docker d’utiliser la nouvelle version de Symfony. Puis vous lancez la même ligne de commande, et vous pouvez tester comment votre code réagit en isolant l’environnement de développement et de tests. Ensuite, si vous devez continuer vos développements, vous pourrez facilement le faire en switchant de conteneurs.
Vous y gagnerez en efficacité et en stabilité sur vos postes et serveurs. Car même pour faire les migrations de version sur les serveurs de production, ce sera plus simple. Par exemple, si la nouvelle version de Symfony réagit mal, vous pouvez faire marche arrière et revenir à l’ancienne version sans problème.
Maintenant que je vous ai fait un teaser de folie, laissez-moi vous montrer comment faire de la magie avec Docker.
Nous allons utiliser la commande docker-compose qui permet de générer une suite d’images et de conteneurs pour faire tourner un environnent précis.
Mais avant de l’utiliser, il faut décrire ce dont on a besoin. Je vous rappelle que l’objectif est dobtenir un WordPress fonctionnel.
Ecriture du fichier de configuration (docker-compose)
Pour cela, nous avons besoin de créer un fichier qui se nomme :
docker-compose.yml
Vous avez dû vous rendre compte que l’extension est particulière. C’est du YAML : pour ceux qui ne connaissent pas ce format, il signifie YAML Ain’t Markup Language soit en français YAML n’est pas un langage de balisage. C’est un peu un mix entre le format CSV, JSON et XML.
Voici la structure de base que propose Docker :
version: '2'
services:
redis:
image: "redis:alpine"
Lisons ligne par ligne les informations. Tout d’abord, on a le champ « version » : il indique le numéro de version du docker compose que vous souhaitez utiliser. En effet, en fonction de la version, on décrit différemment notre architecture.
Ensuite, on retrouve des services qui permettent de détailler la liste de vos systèmes. Un service peut être une image. Par exemple, les deux dernières lignes indiquent que l’on a besoin d’un service redis dont l’image est redis:alpine.
Je pense que vous avez compris le principe de description des services.
Revenons à notre problématique de base. Pour avoir un WordPress qui fonctionne bien, on a besoin d’une base de données MySQL et d’un WordPress. Donc je vous propose de l’écrire en mode YAML. Ensuite, on affinera notre fichier de configuration.
version: '2'
services:
base_de_donnees:
image: mysql:latest
wordpress:
image: wordpress:latest
Ici, j’indique donc à Docker que j’ai besoin de la dernière version de MySql et de WordPress. Mais ce n’est pas suffisant, si vous lancez ce fichier cela ne fonctionnera pas. Car il faut indiquer à Docker que WordPress est lié au moteur MySQL. Pour cela, on utilise le mot-clé depends_on. Ce qui nous donne un nouveau fichier de configuration :
version: '2'
services:
base_de_donnees:
image: mysql:latest
wordpress:
image: wordpress:latest
depends_on:
- base_de_donnees
Mais ce n’est pas tout. Si vous vous souvenez bien de l’article précédent, vous savez que pour WordPress et pour MySQL il y a des variables (des informations) à fournir pour que tout fonctionne bien. Pour rappel, la commande à utiliser pour obtenir un conteneur MySQL digne de ce nom est la suivante :
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -e MYSQL_DATABASE=wordpress -e MYSQL_USER=root -d mysql:8
On voit que l’on passe un mot de passe administrateur (root), un nom de base de donnée et le nom d’un user. On va faire sensiblement la même chose, à un paramètre près. Nous allons générer un utilisateur spécial pour WordPress afin d’éviter les risques d’intrusion ou d’injection dans la base de données par des hackers.
Pour faire passer ces différentes variables, on utilise le mot-clé environment. Ce qui donne le résultat suivant :
version: '2'
services:
base_de_donnees:
image: mysql:latest
environment:
MYSQL_ROOT_PASSWORD: admin-mot-de-passe
MYSQL_DATABASE: nom-base-de-donnee-wordpress
MYSQL_USER: utilisateur-wordpress
MYSQL_PASSWORD: mot-de-passe-wordpress
wordpress:
image: wordpress:latest
depends_on:
- base_de_donnees
C’est plutôt simple, non ? Donc vous avez bien compris que les valeurs « admin-mot-de-passe », »nom-base-de-donnee-wordpress », « utilisateur-wordpress » et « mot-de-passe-wordpress » sont modifiables. Mieux vaut choisir des mots de passe plutôt compliqués pour éviter de vous faire pirater votre base de données.
Passons maintenant à la configuration de WordPress. Pour que tout fonctionne bien, il faut spécifier à WordPress : le nom de la base de données, le mot de passe & le nom de l’utilisateur pour accéder à la base de données, ainsi que le nom de la base de données. Voici le résultat final :
version: '2'
services:
base_de_donnees:
image: mysql:latest
environment:
MYSQL_ROOT_PASSWORD: admin-mot-de-passe
MYSQL_DATABASE: nom-base-de-donnee-wordpress
MYSQL_USER: utilisateur-wordpress
MYSQL_PASSWORD: mot-de-passe-wordpress
wordpress:
image: wordpress:latest
depends_on:
- base_de_donnees
environment:
WORDPRESS_DB_HOST: base_de_donnees:3306
WORDPRESS_DB_PASSWORD: mot-de-passe-wordpress
WORDPRESS_DB_USER: utilisateur-wordpress
WORDPRESS_DB_NAME: nom-base-de-donnee-wordpress
J’attire votre attention sur la variable WORDPRESS_DB_HOST qui contient le nom du service lié. En gros, je dis a Docker de lier par son nom la base de données à WordPress. Il ne manque plus que la cerise sur le gâteau : mettre un nom sur nos deux conteneurs à l’aide de la propriété container_name. Puis rajouter un élément important : restart, que l’on va appliquer à always. Ce qui permet de redémarrer le conteneur s’il plante. A ce stade, je pourrais vous dire que le fichier ci-dessous est suffisant pour lancer un WordPress.
version: '2'
services:
base_de_donnees:
container_name: mysql_server
image: mysql:latest
restart: always
environment:
MYSQL_ROOT_PASSWORD: admin-mot-de-passe
MYSQL_DATABASE: nom-base-de-donnee-wordpress
MYSQL_USER: utilisateur-wordpress
MYSQL_PASSWORD: mot-de-passe-wordpress
wordpress:
container_name: my_wonderful_website
image: wordpress:latest
depends_on:
- base_de_donnees
restart: always
environment:
WORDPRESS_DB_HOST: base_de_donnees::3306
WORDPRESS_DB_PASSWORD: mot-de-passe-wordpress
WORDPRESS_DB_USER: utilisateur-wordpress
WORDPRESS_DB_NAME: nom-base-de-donnee-wordpress
Mais je préfère vous donner toutes les clés et vous laisser faire vos choix. Sur nos deux conteneurs, on peut rajouter un port cible. Par exemple si on veut que notre WordPress tourne sur le port 8010. On utilise la propriété ports, voici un exemple :
version: '2'
services:
base_de_donnees:
container_name: mysql_server
image: mysql:latest
restart: always
environment:
MYSQL_ROOT_PASSWORD: admin-mot-de-passe
MYSQL_DATABASE: nom-base-de-donnee-wordpress
MYSQL_USER: utilisateur-wordpress
MYSQL_PASSWORD: mot-de-passe-wordpress
wordpress:
container_name: my_wonderful_website
image: wordpress:latest
depends_on:
- base_de_donnees
ports:
- "8010:80"
restart: always
environment:
WORDPRESS_DB_HOST: base_de_donnees::3306
WORDPRESS_DB_PASSWORD: mot-de-passe-wordpress
WORDPRESS_DB_USER: utilisateur-wordpress
WORDPRESS_DB_NAME: nom-base-de-donnee-wordpress
Enfin, sachez que la propriété volumes vous permet d’échanger des fichiers entre votre conteneur Docker et votre système Windows. Si vous vous demandez à quoi cela peut servir, imaginez que vous devez mettre en production un site WordPress réalisé grâce à Docker. Comment récupérez-vous les fichiers PHP présents dans votre Docker ? Réponse : en utilisant la propriété volumes qui vous permettra de créer un pseudo dossier partagé. Voici comment faire :
version: '2'
services:
base_de_donnees:
container_name: mysql_server
volumes:
- C:/docker/wordpress/mysql:/var/lib/mysql:rw
image: mysql:latest
restart: always
environment:
MYSQL_ROOT_PASSWORD: admin-mot-de-passe
MYSQL_DATABASE: nom-base-de-donnee-wordpress
MYSQL_USER: utilisateur-wordpress
MYSQL_PASSWORD: mot-de-passe-wordpress
wordpress:
container_name: my_wonderful_website
image: wordpress:latest
depends_on:
- base_de_donnees
ports:
- "8010:80"
restart: always
volumes:
- C:/docker/wordpress/html:/var/www/html
environment:
WORDPRESS_DB_HOST: base_de_donnees::3306
WORDPRESS_DB_PASSWORD: mot-de-passe-wordpress
WORDPRESS_DB_USER: utilisateur-wordpress
WORDPRESS_DB_NAME: nom-base-de-donnee-wordpress
En gros, je dis à Docker de me donner un accès en lecture/écriture (rw) sur les fichiers présents dans le répertoire /var/lib/mysql du conteneur MySQL, dans mon répertoire C:/docker/wordpress/mysql. C’est la même technique pour WordPress. En même temps, cela me protège d’une suppression malencontreuse de mon conteneur, car en cas de suppression je conserve les fichiers stockés sur mon poste.
Voici donc votre fichier final ci-dessus. Il ne vous reste qu’à modifier les variables, ainsi que les chemins d’accès. Si vous n’avez pas envie de copier-coller les lignes, vous pouvez télécharger mon docker-compose.yml :
docker-compose.yml
Dernière étape : voici la commande simple à saisir pour créer les conteneurs :
docker-compose up -d
Voici le résultat :
Docker nous indique qu’il a créé un conteneur mysql_wordpress et un wordpress_enov. Pour vérifier que les conteneurs sont bien présents, vous pouvez ouvrir Kitematic.
Sur cette impression d’écran, on voit que les conteneurs my_wonderful_website et mysql_server sont actifs. Docker a repris le nom que j’avais indiqué dans mon fichier de configuration, grâce à la propriété container_name. On voit que les conteneurs sont actifs car les icônes sont vertes avec une forme de vague.
Un autre moyen de voir si tout va bien est d’aller faire un tour dans les dossiers partagés. Par exemple, si vous vous rendez dans le dossier WordPress que vous avez spécifié dans volumes, vous obtenez le résultat suivant :
A l’intérieur de ces dossiers, vous avez d’un côté les fichiers PHP de votre site WordPress, et de l’autre les fichiers de base de données :
La dernière étape de vérification consiste tout simplement à vous rendre sur votre site fraîchement créé.
Un conseil : faites très attention aux informations que vous renseignez dans la partie configuration. En effet, il faut que les informations de connexion à la base de données soient les mêmes que celles choisies dans votre docker-compose.yml.
J’espère que cet article vous a plu. C’est encore un cran plus haut, donc c’est normal si vous avez des questions. Alors n’hésitez pas et essayez de faire le TP par vous-même, voire même de rajouter d’autres conteneurs pour pimenter le tout. Puis partagez-les dans les commentaires pour donner des idées à la communauté. Je vous dis à très bientôt pour de nouvelles documentations techniques.
Attendees, speakers, and organizers at the close of PGCon 2007 at the University of Ottawa. PGCon is a conference for PostgreSQL users and developers.
(At least I _think_ they are the guys from Sun).
Robert Lor on the far right. I don't know the names of any of the others :-(
The School of Information Technology and Engineering (SITE) at the University of Ottawa, where PGCon 2007 was held. PGCon is a conference for PostgreSQL users and developers.
Simon Riggs presenting "PostgreSQL Performance Research" at PGCon 2007 at the University of Ottawa. A major PostgreSQL developer, Simon Riggs is a database architect and performance consultant.
MIchael Brewer presents "Migrating to PostgreSQL in Academia" at PGCon at the University of Ottawa. Michael Brewer is an application programmer specialist in the Franklin College Office of Information Technology at the University of Georgia.
Nikolay Samokhvalov and Peter Eisentraut presenting "The Road to the XML Type" at PGCon 2007 at the University of Ottawa. Nikolay Samokhvalov is currently researching the integration of XML and relational data models at the Institute for System Pogramming in Moscow. Peter Eisentraut is a member of the PostgreSQL core team. Together they have been working on enhancing XML functionality in PostgreSQL.
Nikolay Samokhvalov and Peter Eisentraut presenting "The Road to the XML Type" at PGCon 2007 at the University of Ottawa. Nikolay Samokhvalov is currently researching the integration of XML and relational data models at the Institute for System Pogramming in Moscow. Peter Eisentraut is a member of the PostgreSQL core team. Together they have been working on enhancing XML functionality in PostgreSQL.
PostgreSQL offers all the means necessary to spot slow queries and to figure out exactly what is going on. Here are 5 tips for improving ingest performance in PostgreSQL.
Spencer Christensen looks on as Greg Sabino Mullane inspects his laptop between sessions at PGCon 2007 at the University of Ottawa. Spencer Christensen and Greg Sabino Mullane presented a PostgreSQL Lightning Talk. A major PostgreSQL developer, Greg Sabino Mullane also presented the "PL/Perl—Best of Both Worlds" tutorial and "PostgreSQL Version 8 in Action", and hosted the PostgreSQL Palaver BOF.
Robert Treat, Devrim Gunduz, Dave Page and Korry Douglas,
on the EnterpriseDB-sponsored cruise dinner.