Share
Cet article vous aidera à utiliser Vagrant pour gérer vos instances de machine virtuelle et vous expliquera comment tirer parti de Puppet pour mettre à disposition diverses ressources, telles que PHP et PostgreSQL..
Les développeurs ont un grand choix de façons de créer leur environnement de développement Web.
Les développeurs disposent d’un grand choix de moyens pour créer leur environnement de développement Web. Vous pouvez utiliser des options "locales", telles que l’installation de piles de serveurs "tout-en-un" pré-construites, telles que Zend Server, XAMPP, MAMP, WAMP, etc., ou vous pouvez installer les composants vous-même à partir des sources ou via systèmes de gestion de paquets comme Homebrew, Apt et Yum.
Cela peut augmenter lorsque vous travaillez sur divers projets avec: PHP 5.3 et PHP 5.4, MySQL, SQLite, MongoDB, Postgres, PEAR, PHPUnit, Rails 3.1, Memcached, Redis, Gearman, NodeJS, etc. Si vous effectuez une mise à niveau ou si votre ordinateur est arrêté , vous devrez tout recommencer.
Vous pouvez avoir une configuration "à distance", en utilisant un serveur sur le réseau avec des partages Samba ou un serveur SSH monté avec un outil tel que ExpanDrive. Cette dernière option peut entraîner une latence sur les lectures / écritures de fichiers, qui sont extrêmement gênantes. Vous pouvez utiliser SSH + Vim pour tout, ce qui est rapide, mais cela ne fonctionne que si vous voulez utiliser Vim pour tout..
Bien que vous soyez satisfait de la façon dont vous faites les choses en ce moment, combien d'entre vous ont entendu (ou dit) "Cela fonctionne sur mon ordinateur". C'est horriblement courant et cela se produit lorsque les environnements diffèrent même par les détails les plus triviaux..
Il est extrêmement important de vous assurer que votre environnement de développement est identique à l'environnement de production et qu'il correspond aux serveurs de transfert et de test si vous en possédez également..
Cela peut sembler facile si vous pensez à installer Apache, PHP et une copie de MySQL, mais vous devez prendre en considération un million de facteurs. Si vous développez sur OSX et déployez sur un système Ubuntu, vous remarquerez des problèmes amusants liés à la capitalisation des fichiers. C'est courant dans CodeIgniter, quand quelqu'un a une bibliothèque avec une première lettre minuscule. Il se chargera bien sur OSX, mais s’arrêtera lorsqu’il sera déployé en production. Votre processus de développement vient peut-être de vous faire perdre des affaires, tout cela à cause d'une différence insignifiante dans le système d'exploitation à laquelle personne n'a pensé jusqu'à ce qu'il soit trop tard..
Forcer les développeurs à utiliser le même système d'exploitation créera des problèmes.
Donc, quelle est la solution? Obliger tous vos développeurs à se débarrasser de leurs différents outils et à développer exactement le même modèle d’ordinateur portable? Si vos développeurs obtiennent tous de nouveaux Macbooks, vous ne recevrez peut-être pas trop de plaintes, mais vous devrez alors utiliser OSX Server pour tout..
Vous pouvez utiliser Linux pour tout, mais vous devez ensuite vous battre pour savoir quelle distribution utiliser. Forcer les développeurs à utiliser le même système d'exploitation créera des problèmes, réduira la productivité et favorisera la lutte contre les nerds..
La virtualisation est la solution et ce n'est pas une nouveauté, mais lorsque les utilisateurs pensent à la virtualisation, ils pensent souvent aux problèmes de performances et à la folie de leurs fans alors que leur ordinateur portable tente désespérément de faire fonctionner deux systèmes d'exploitation..
Cela peut toujours être le cas si vous essayez d’exécuter Windows sur une machine basse consommation, mais de nos jours, un Mac moyen dispose de 4 Go de RAM, ce qui est largement suffisant pour alimenter une installation de serveur Ubuntu fonctionnant en mode ligne de commande. et tous vos outils de développement habituels (IDE, navigateur, outils de débogage, etc.). Il y a quelques options pour la virtualisation, mais je préfère VirtualBox de Oracle (qui est gratuit). Ce logiciel fait le gros du travail pour la virtualisation, puis un outil appelé Vagrant gère les instances.
Commencez par télécharger VirtualBox et installez-le. Sur les systèmes * nix (Mac OSX, Linux, etc.), vous devrez modifier votre .bash_profile (ou .zsh_profile) pour étendre votre $ PATH variable:
PATH = $ PATH: /Applications/VirtualBox.app/Contents/MacOS/ export PATH
Cela permettra à Vagrant de savoir où VirtualBox est installé et variera bien sûr selon les systèmes d'exploitation..
Vous pouvez télécharger une version de vagrant pour votre système d'exploitation ou l'installer comme une gemme si elle n'est pas disponible:
$ gem install vagrant
Faites vivre vos aménagements vagabonds:
mkdir -p ~ / Vagrant / test cd ~ / Vagrant / test
Nous utiliserons Ubuntu 12.04 LTS (Precise Pangolin), qui a déjà une "boîte" configurée.
vagrant box add precise32 http://files.vagrantup.com/precise32.box
Vous voyez ici l'argument "precise32" qui est un surnom pour l'URL. Vous pouvez maintenant créer une instance qui téléchargera cette boîte..
vagrant init précis32 vagrant vers le haut
Il va maintenant être en cours d'exécution. Facile! Si vous voulez entrer dans cette instance, via SSH, utilisez cette commande:
ssh vagabond
Vous aurez un fichier, appelé Vagrantfile, qui contient la configuration pour cette instance:
Accentsconagua
# - * - mode: ruby - * - # vi: définir ft = ruby: Vagrant :: Config.run do | config | config.vm.box = "precise32" config.vm.box_url = "http://files.vagrantup.com/precise32.box" # Affectez cette machine virtuelle à une adresse IP de réseau pour hôte uniquement, vous permettant d'y accéder # via le IP. Les réseaux réservés aux hôtes peuvent communiquer avec la machine hôte # ainsi que toutes les autres machines du même réseau, mais aucun réseau externe ne peut y accéder (via cette interface réseau #). config.vm.network: hostonly, "192.168.33.10" # Définissez le partage de projet par défaut pour utiliser nfs config.vm.share_folder ("v-web", "/ vagrant / www", "./www",: nfs = > true) config.vm.share_folder ("v-db", "/ vagrant / db", "./db",: nfs => true) # Transmet un port de l'invité à l'hôte, ce qui permet de faire # en dehors ordinateurs pour accéder à la machine virtuelle, alors que la mise en réseau uniquement de l’hôte ne le fait pas. config.vm.forward_port 80, 8080 # Définissez le fuseau horaire sur quelque chose d'utile config.vm.provision: shell,: inline => "echo \" Europe / Londres \ "| sudo tee / etc / timezone && dpkg-reconfigure --frontend nonz interactif tzdata "# Met à jour le serveur config.vm.provision: shell,: inline =>" apt-get update --fix-missing "# Activer Puppet config.vm.provision: puppet do | puppet | puppet.facter = "fqdn" => "local.pyrocms", "hostname" => "www" puppet.manifests_path = "puppet / manifestes" puppet.manifest_file = "ubuntu-apache2-pgsql-php5.pp" .module_path = "puppet / modules" end end Si vous ne l’avez pas remarqué, c’est la syntaxe de Ruby; vous pouvez donc être assez créatif avec ce fichier, mais ce sont les bases.
Il montrera quel pseudonyme à utiliser et aura l'URL au cas où le pseudonyme n'est pas configuré localement (bon pour le partage).
le dossier de partage les lignes sont vraiment utiles pour mapper un dossier de l'instance sur un dossier local. En utilisant nfs => true l'instance pourra écrire et modifier les autorisations des fichiers, ce qui est utile si, par exemple, vous essayez d'installer un CMS dans cet emplacement..
La redirection de port vous permet d’accéder à votre instance le http: // localhost: 8080 et, bien sûr, changer cela à un autre port si cela est en conflit.
Ce fichier de configuration définira également le fuseau horaire sur Europe / London, puis sera exécuté. apt-get update, ce qui devrait forcer votre système à être à jour à chaque démarrage. Si vous ignorez cet élément de configuration, plusieurs packages peuvent être refusés, car les références ne sont plus à jour..
Lorsque vous modifiez la configuration, vous pouvez recharger l'instance pour l'utiliser:
rechargement vagabond
Maintenant que nos serveurs fonctionnent et sont prêts à fonctionner, nous devons installer certains logiciels. Nous n'allons pas seulement à apt-get install un paquet de paquets via la ligne de commande, nous allons "approvisionner" nos serveurs.
Le provisioning de serveur n'est pas une chose à laquelle de nombreux développeurs doivent penser.
De nombreux développeurs doivent prendre en compte le provisionnement des serveurs, car il appartient normalement aux administrateurs système. L’idée est d’enregistrer le logiciel et la configuration qui ont été créés sur un serveur pour pouvoir créer de nouveaux environnements de développement, de nouveaux serveurs intermédiaires répliquant la production ou créer un autre serveur de production permettant d’équilibrer la charge entre les deux..
La façon dont les administrateurs système gèrent cela varie, mais toutes sortes de solutions ont été utilisées dans le passé - depuis le maintien d'un wiki de commandes (qui peut devenir volumineux et rapidement obsolète) et de la formidable approche consistant à avoir un "multi-terminal", où vous tapez commandes dans une fenêtre et il réplique les mêmes commandes sur 7 autres serveurs en même temps. Ces méthodes sont toutes terribles.
Une solution serait de construire votre propre .boîte déposer ou créer .iso sauvegardes afin que les nouveaux serveurs puissent simplement être basés sur cela, mais la maintenance de ces images crée beaucoup de travail supplémentaire, et quels que soient vos efforts, ces machines de développement se désynchroniseront avec le temps..
Il existe actuellement deux systèmes populaires, appelés Puppet et Chef..
Il existe actuellement deux systèmes populaires, appelés Puppet et Chef. Les deux existent depuis des années, mais ont commencé à devenir beaucoup plus populaires avec l’augmentation de la méthode de développement DevOps. Les idées pour les deux sont similaires et vous devriez étudier les deux systèmes, mais ce tutoriel se concentrera exclusivement sur Puppet..
Essentiellement, au lieu d'exécuter un ensemble de commandes et d'espérer que tout fonctionne correctement, vous créez un manifeste pour Puppet, expliquant tout ce dont vous avez besoin pour vous assurer que tout a été fait. Lorsque vous exécutez une commande dans le terminal, vous dites essentiellement à l’ordinateur:
"Installer Apache"
Avec Puppet, on dirait:
"Assurez-vous qu'Apache est installé"
Ou au lieu de:
"Créer un nouveau dossier, appelé
/ var / wwwet définir les autorisations sur www-data: www-data "
Avec Puppet, on dirait:
"Assurer
/ var / wwwexiste et possède les autorisations correspondant à www-data: www-data "
La différence est que ces manifestes peuvent être exécutés plusieurs fois (sur une tâche cron horaire ou quotidienne) pour maintenir les éléments à jour, sans résultats inattendus..
Cela vous aidera également à vérifier que tout fonctionne comme prévu. En cas d'échec de l'une de ces règles, les erreurs générées seront plus faciles à suivre que la répétition d'une quantité considérable de résultats de commandes bash. Puppet émettra de grosses erreurs rouges vous informant que PHP n'a pas été installé ou qu'un module spécifique n'a pas pu être configuré.
Les manifestes sont un peu déroutants au début, mais après un certain temps, ils commencent à avoir un sens..
Pour revoir un exemple de base:
fichier 'testfile': chemin => '/ tmp / testfile', assure => présent, mode => 0640, content => "Je suis un fichier test.",
Pas besoin d'expliquer ce qui se passe ici, à droite?
Ce fichier peut ensuite être appelé "fichier de test" dans votre manifeste, ce qui signifie qu'il peut être répertorié comme dépendance pour d'autres actions..
Pour d'autres exemples, nous nous référons aux manifestes de la marionnette PyroCMS sur GitHub..
include apache $ docroot = '/ vagrant / www / pyrocms /' $ db_location = "/vagrant/db/pyrocms.sqlite" # Classe d'installation Apache 'apache :: php': apache :: vhost 'local.pyrocms' : priorité => '20', port => '80', docroot => $ docroot, configure_firewall => false, a2mod 'rewrite': sure => present;
Cela inclut le module "apache", configure certaines variables, exécute le manifeste supplémentaire "apache :: php" dans le module apache, configure un hôte virtuel puis s'assure que "mod_rewrite" est activé..
Toutes ces classes sont définies dans le module Apache que nous avons inclus.
Pour continuer, nous voulons aussi installer PHP:
include php php :: module ['' xdebug '', 'pgsql', 'curl', 'gd']: notify => [Service ['httpd'],], php :: conf ['pdo', ' pdo_pgsql ']: require => Paquet [' php5-pgsql '], notify => Service [' httpd '],
Ce morceau de manifeste installera les extensions PHP dont nous avons besoin, puis le notifier Cette option indiquera à Apache que vous avez installé une nouvelle configuration, ce qui signifie qu’elle redémarrera..
inclure la classe postgresql 'postgresql :: server': postgresql :: db 'pyrocms': propriétaire => 'pyrocms', mot de passe => 'mot de passe',
Cela va configurer un serveur postgres, créer une base de données, appelée "pyrocms" et s'assurer qu'un utilisateur, appelé "pyrocms" existe avec le mot de passe fourni..
Presque fini! La dernière étape consiste à vérifier que les fichiers et les dossiers accessibles en écriture sont correctement définis:
fichier $ docroot: assure => 'répertoire', fichier "$ docroot système / cms / config / config.php": assure => "présent", mode => "0666", require => Fichier [ $ docroot], $ writeable_dirs = ["$ docroot system / cms / cache /", "$ docroot system / cms / config /", "$ docroot addons /", "$ docroot assets / cache / "," $ docroot uploads / "] fichier $ Writeable_Dirs: Ensure =>" répertoire ", mode => '0777', require => Fichier [$ docroot],
Cela garantira que la racine du document Apache est présente, que le fichier de configuration est défini sur 0666 et que quelques dossiers en écriture sont définis sur 777..
Là nous l'avons!
Pour exécuter tout cela, redémarrez simplement votre instance de vagrant ou exécutez:
disposition de vagabond
Si tout fonctionne correctement, vous devriez voir beaucoup de texte bleu indiquant que tout est en cours d'installation, mais si un problème survient, vous verrez apparaître du rouge. Google ces erreurs et essayez à nouveau.
Les modules utilisés ici sont: Apache, Postgres, PHP et vous pouvez tout voir en action en clonant le repo PyroCMS Vagrant:
git clone --recursive git: //github.com/pyrocms/devops-vagrant.git ~ / vagrant / pyrocms cd ~ / vagrant / pyrocms vagabondent
Pointez votre navigateur sur http: // localhost: 8089 / et vous devriez voir l'installateur. Truc facile, hein?
Remarque: Ceci s’installera avec MySQL car PyroCMS est toujours supporté par Postgres et le support SQLite est toujours en développement, il reste quelques fonctionnalités PDO de CodeIgniter à compléter. Si vous êtes intéressé, vous pouvez expérimenter en changeant le fichier Vagrant pour utiliser le ubuntu-apache2-pgsql-php5.pp manifeste, détruisez l’instance, puis redémarrez-la. Le sous-module pyrocms devra également être extrait pour présenter / pdo
Dans cet article, nous avons utilisé Vagrant, VirtualBox et Puppet non seulement pour configurer une instance de serveur avec laquelle nous travaillons, mais nous avons également créé une suite de tests pour notre serveur afin de nous assurer que tout est en cours d'exécution, installé et configuré correctement..
Nous avons également créé une liste de contrôle des exigences et nous pourrons, à l'avenir, créer un nombre quelconque de serveurs identiques en quelques minutes et non plus en heures.!
