Share
Dit artikel helpt je om Vagrant te gebruiken om je virtuele machine-instanties te beheren en uit te leggen hoe je van Puppet kunt profiteren om verschillende bronnen aan te bieden, zoals PHP en PostgreSQL.
Ontwikkelaars hebben een enorme keuze aan manieren om hun webontwikkelomgeving te bouwen.
Ontwikkelaars hebben een enorme keuze aan manieren om hun webontwikkelomgeving te bouwen. U kunt "lokale" opties gebruiken, zoals het installeren van kant-en-klare "alles-in-één" serverstapels, zoals Zend Server, XAMPP, MAMP, WAMP, enz., Of u kunt de componenten zelf installeren vanaf de bron, of via pakketbeheersystemen zoals Homebrew, Apt en Yum.
Dit kan opbouwen terwijl je aan verschillende projecten werkt met: PHP 5.3 en PHP 5.4, MySQL, SQLite, MongoDB, Postgres, PEAR, PHPUnit, Rails 3.1, Memcached, Redis, Gearman, NodeJS, etc. Als je een upgrade uitvoert of je computer sterft , je moet helemaal opnieuw beginnen.
U zou een "remote" -instelling kunnen hebben, een server op het netwerk gebruiken met Samba-shares of een SSH-server die is gekoppeld aan een tool als ExpanDrive. De laatste optie kan leiden tot latentie bij het lezen en schrijven van bestanden, wat erg vervelend is. Je zou SSH + Vim voor alles kunnen gebruiken, dat is snel, maar dat werkt alleen als je Vim voor alles wilt gebruiken.
Hoewel je misschien blij zult zijn met hoe je het nu doet, hoeveel van jullie hebben gehoord (of gezegd): "Wel, het werkt op mijn computer". Dit is vreselijk vaak en gebeurt wanneer omgevingen zelfs in de meest triviale details verschillen.
Het is uiterst belangrijk om ervoor te zorgen dat uw ontwikkelomgeving identiek is aan de productieomgeving en overeenkomt met het inrichten en testen van servers als u die ook hebt.
Dat klinkt misschien eenvoudig als je denkt aan het installeren van Apache, PHP en een exemplaar van MySQL, maar er zijn een miljoen factoren om over na te denken. Als u zich ontwikkelt op OSX en implementeert op een Ubuntu-systeem, zult u leuke problemen met bestandskapitalisatie opmerken. Dit is gebruikelijk in CodeIgniter, wanneer iemand een bibliotheek met een kleine letter in kleine letters heeft. Het laadt prima op OSX, maar zal breken wanneer het wordt ingezet voor productie. Uw ontwikkelingsproces heeft u misschien wat zaken verloren, allemaal vanwege een triviaal OS-verschil waar niemand aan dacht voordat het te laat was.
Het dwingen van ontwikkelaars om hetzelfde besturingssysteem te gebruiken, zal tot problemen leiden.
Dus wat is de oplossing? Dwing al uw ontwikkelaars om hun verschillende tools weg te gooien en zich te ontwikkelen op exact hetzelfde model van de laptop? Als je ontwikkelaars allemaal gloednieuwe Macbooks krijgen, krijg je misschien niet al te veel klachten, maar dan moet je OSX Server gebruiken voor alles.
Je zou Linux voor alles kunnen gebruiken, maar dan moet je vechten over welke distributie je wilt gebruiken. Het dwingen van ontwikkelaars om hetzelfde besturingssysteem te gebruiken zal leiden tot problemen, verminderde productiviteit en het promoten van nerd-gevechten.
Virtualisatie is het antwoord en het is niets nieuws, maar wanneer mensen aan virtualisatie denken, denken ze vaak aan prestatieproblemen en rennen hun fans wild rond terwijl hun laptop wanhopig probeert twee besturingssystemen uit te voeren.
Dit kan nog steeds het geval zijn om Windows op een energiezuinige computer te laten werken, maar tegenwoordig heeft een gemiddelde Mac 4 GB RAM uit de doos, wat meer dan genoeg is om een Ubuntu-serverinstallatie in opdrachtregelmodus te voeden en al je gebruikelijke ontwikkeltools (IDE, browser, foutopsporingstools, enz.). Er zijn een paar opties voor virtualisatie, maar ik geef de voorkeur aan VirtualBox van Oracle (wat gratis is). Deze software doet al het zware werk voor de virtualisatie, daarna beheert een tool genaamd Vagrant de instanties.
Download eerst VirtualBox en installeer het. Op * nix-systemen (Mac OSX, Linux, enz.), Moet u uw wijzigen .bash_profile (of .zsh_profile) om uw $ PATH variabele:
PATH = $ PATH: / Applications/VirtualBox.app/Contents/MacOS/ PATH exporteren
Hierdoor weet Vagrant waar VirtualBox is geïnstalleerd, en dit varieert uiteraard voor verschillende besturingssystemen.
U kunt een zwervende build voor uw besturingssysteem downloaden of installeren als een pareltje als er geen beschikbaar is:
$ gem installeer vagrant
Maak ergens een plek voor je zwervende opstellingen om te leven:
mkdir -p ~ / Vagrant / test cd ~ / Vagrant / test
We gebruiken Ubuntu 12.04 LTS (Precise Pangolin), die al een "box" -instelling heeft.
dwaallicht vak toevoegen precis32 http://files.vagrantup.com/precise32.box
U ziet hier het argument "precise32", een bijnaam voor de URL. U kunt nu een exemplaar maken dat deze .box zal downloaden.
vagrant init exact32 vagrant up
Het zal nu draaien. Gemakkelijk! Als je in dit geval via SSH wilt ingaan, gebruik dan deze opdracht:
zwervende ssh
Je hebt een bestand, genaamd Vagrantfile, welke configuratie voor deze instantie bevat:
Accentsconagua
# - * - mode: ruby - * - # vi: set ft = ruby: Vagrant :: Config.run do | config | config.vm.box = "precise32" config.vm.box_url = "http://files.vagrantup.com/precise32.box" # Wijs deze VM toe aan een IP-adres van een host-netwerk, zodat u deze kunt openen # via de IK P. Host-only netwerken kunnen zowel met de host-machine praten als met # andere machines op hetzelfde netwerk, maar kunnen niet worden benaderd (via deze # netwerkinterface) door externe netwerken. config.vm.network: hostonly, "192.168.33.10" # Stel de standaard projectshare in om nfs te gebruiken config.vm.share_folder ("v-web", "/ vagrant / www", "./www",: nfs = > true) config.vm.share_folder ("v-db", "/ vagrant / db", "./db",: nfs => true) # Stuur een poort van de gast naar de host, die buiten # toestaat computers om toegang tot de VM te krijgen, terwijl host-only-netwerken dat niet doet. config.vm.forward_port 80, 8080 # Stel de Tijdzone in op iets nuttigs config.vm.provision: shell,: inline => "echo \" Europa / Londen \ "| sudo tee / etc / timezone && dpkg-reconfigure --frontend noninteractive tzdata "# Update de server config.vm.provision: shell,: inline =>" apt-get update --fix-missing "# Puppet inschakelen config.vm.provision: marionet do | marionet | puppet.facter = "fqdn" => "local.pyrocms", "hostname" => "www" puppet.manifests_path = "marionet / manifesten" puppet.manifest_file = "ubuntu-apache2-pgsql-php5.pp" marionet .module_path = "poppen / modules" einde Dit, als u het niet had opgemerkt, is Ruby-syntaxis; dus je kunt redelijk creatief worden met dit bestand, maar dit is de basis.
Het zal laten zien welke bijnaam moet worden gebruikt en moet de URL hebben voor het geval dat de bijnaam niet lokaal is ingesteld (goed voor delen rond).
De deel map regels zijn erg handig voor het toewijzen van een map in het exemplaar aan een lokale map. Gebruik makend van nfs => waar de instantie kan machtigingen van de bestanden schrijven en wijzigen, wat handig is als u bijvoorbeeld probeert een CMS daar te installeren.
Port forwarding geeft u toegang tot uw instantie op http: // localhost: 8080 en, natuurlijk, verander dat naar een andere poort als dat conflicteert.
Dit configuratiebestand zal ook de tijdzone naar Europa / Londen instellen en vervolgens uitvoeren apt-get update, die uw systeem moet dwingen up-to-date te zijn wanneer het wordt opgestart. Als u dit configuratie-item overslaat, is het mogelijk dat meerdere pakketten weigeren te installeren omdat de referenties nu verouderd zijn.
Wanneer u de configuratie wijzigt, kunt u het exemplaar opnieuw laden om het te gebruiken:
vagrant herladen
Nu onze servers draaiende en klaar voor gebruik zijn, moeten we wat software installeren. Dat gaan we niet gewoon doen apt-get install een stapel pakketten via de opdrachtregel, we gaan onze servers "aanbieden".
Serverregistratie is niet iets waar veel ontwikkelaars aan moeten denken.
Serverprovisioning is niet iets waar veel ontwikkelaars over na moeten denken, omdat het normaal gesproken aan sysadmins wordt overgelaten. Het idee is om vast te leggen welke software en configuratie op een server is gemaakt, zodat u nieuwe ontwikkelomgevingen kunt maken, nieuwe staging-servers die de productie repliceren of een andere productieserver maken om de balans tussen de twee te laden.
Hoe sysadmins hiermee omgaan, varieert, maar in het verleden zijn allerlei oplossingen gebruikt - van het houden van een wiki aan opdrachten (die snel groot en verouderd kunnen worden) en de geweldige aanpak van het hebben van een "multi-terminal", waar je typt commando's in een venster en het repliceert dezelfde opdrachten op een andere 7 servers op hetzelfde moment. Deze methoden zijn allemaal verschrikkelijk.
Een oplossing zou zijn om uw eigen te bouwen .doos bestand, of maak aan .iso back-ups zodat nieuwe servers daar gewoon op kunnen worden gebaseerd, maar het bijhouden van die afbeeldingen levert veel extra werk op, en hoe hard je ook probeert, die ontwikkelingsmachines zullen niet meer synchroon lopen naarmate de tijd vordert.
Er zijn momenteel twee populaire systemen genaamd Puppet en Chef.
Er zijn momenteel twee populaire systemen, Puppet en Chef genoemd. Beide zijn er al jaren, maar zijn een stuk populairder geworden geworden door de toename van de DevOps-ontwikkelmethode. De ideeën voor beide zijn vergelijkbaar en je zou beide systemen moeten onderzoeken, maar deze tutorial zal zich exclusief richten op Puppet.
In wezen, in plaats van een heleboel opdrachten uit te voeren en te hopen dat alles goed werkt, bouw je een manifest voor Puppet waarin alles wordt uitgelegd wat je nodig hebt om ervoor te zorgen dat het is gedaan. Wanneer u een opdracht in de terminal uitvoert, zegt u in feite tegen de computer:
"Installeer Apache"
Met Puppet zouden we zeggen:
"Zorg ervoor dat Apache is geïnstalleerd"
Of in plaats van:
"Maak een nieuwe map, genaamd
/ Var / wwwen machtigingen instellen voor www-data: www-data "
Met Puppet zouden we zeggen:
"Ervoor zorgen
/ Var / wwwbestaat en heeft machtigingen die overeenkomen met www-data: www-data "
Het verschil hier is dat deze manifesten meerdere keren kunnen worden uitgevoerd (op een cron-taak per uur of dagelijks) om dingen up-to-date te houden, en er zullen geen onverwachte resultaten zijn van iets dat tweemaal probeert te installeren.
Het zal je ook helpen testen of alles loopt zoals verwacht, omdat een van deze regels faalt en fouten zal opleveren die makkelijker te volgen zijn dan een enorme hoeveelheid bash commando-resultaten. Puppet zal grote rode fouten veroorzaken die je laten weten dat PHP niet heeft geïnstalleerd, of dat een specifieke module niet kon worden geconfigureerd.
Manifest zijn in het begin enigszins verwarrend, maar na een tijdje beginnen ze logisch te worden.
Om een eenvoudig voorbeeld te bekijken:
bestand 'testbestand': pad => '/ tmp / testbestand', zorg ervoor => aanwezig, modus => 0640, inhoud => "Ik ben een testbestand.",
Het is niet nodig om uit te leggen wat hier gebeurt, goed?
Dit bestand kan later in uw manifest worden aangeduid als "testbestand", wat betekent dat het kan worden vermeld als een afhankelijkheid voor andere acties.
Voor verdere voorbeelden verwijzen we naar de PyroCMS Puppet-manifesten op GitHub.
include apache $ docroot = '/ vagrant / www / pyrocms /' $ db_location = "/vagrant/db/pyrocms.sqlite" # Apache-installatieklasse 'apache :: php': apache :: vhost 'local.pyrocms' : priority => '20', port => '80', docroot => $ docroot, configure_firewall => false, a2mod 'rewrite': provide => present;
Dit omvat de "apache" -module, stelt een aantal variabelen in, voert het extra "apache :: php" -manifest uit in de apache-module, stelt een virtuele host in en zorgt er vervolgens voor dat "mod_rewrite" is ingeschakeld.
Al deze klassen worden gedefinieerd in de Apache-module die we hebben opgenomen.
Verderop willen we ook PHP installeren:
include php php :: module ['xdebug', 'pgsql', 'curl', 'gd']: notify => [Service ['httpd'],], php :: conf ['pdo', ' pdo_pgsql ']: require => Package [' php5-pgsql '], notify => Service [' httpd '],
Deze brok manifest zal de PHP-extensies installeren die we nodig hebben, en vervolgens de verwittigen optie laat Apache weten dat je een nieuwe configuratie hebt geïnstalleerd, wat betekent dat het opnieuw zal opstarten.
include postgresql class 'postgresql :: server': postgresql :: db 'pyrocms': owner => 'pyrocms', password => 'password',
Dit zal een postgres-server opzetten, een database maken, "pyrocms" genoemd en zorgen dat er een gebruiker, "pyrocms", bestaat met het wachtwoord.
Bijna klaar! De laatste stap is om ervoor te zorgen dat beschrijfbare bestanden en mappen correct zijn ingesteld:
bestand $ docroot: sure => 'map', bestand "$ docroot system / cms / config / config.php": sure => "present", mode => "0666", vereist => Bestand [ $ docroot], $ writeable_dirs = ["$ docroot systeem / cms / cache /", "$ docroot systeem / cms / config /", "$ docroot addons /", "$ docroot assets / cache / "," $ docroot uploads / "] bestand $ writeable_dirs: zorgen voor =>" map ", mode => '0777', vereisen => Bestand [$ docroot],
Dit zorgt ervoor dat de Apache document root er is, het configuratiebestand is ingesteld op 0666, en een paar beschrijfbare mappen zijn ingesteld op 777.
Daar hebben we het!
Om dit allemaal uit te voeren, herstart je eenvoudig je zwervende instantie of voer je uit:
vagrant bepaling
Als alles correct is verlopen, ziet u veel blauwe tekstsignalering dat alles wordt geïnstalleerd, maar als er iets misgaat, ziet u rood. Vergis die fouten en probeer het opnieuw.
De modules die hier worden gebruikt zijn: Apache, Postgres, PHP en je kunt het hele ding in actie zien door de PyroCMS Vagrant repo te klonen:
git clone --recursive git: //github.com/pyrocms/devops-vagrant.git ~ / vagrant / pyrocms cd ~ / vagrant / pyrocms vagrant up
Richt uw browser op http: // localhost: 8089 / en je zou het installatieprogramma moeten zien. Gemakkelijke dingen, he?
Notitie: Dit zal met MySQL worden geïnstalleerd, omdat de Postgres- en SQLite-ondersteuning van PyroCMS nog steeds in ontwikkeling is en wacht tot enkele CodeIgniter PDO-functies zijn voltooid. Als je geïnteresseerd bent, kun je experimenteren door het Vagrantbestand te wijzigen om het te gebruiken ubuntu-apache2-pgsql-php5.pp manifest, vernietig de instance en start deze opnieuw op. De submodule van pyrocms moet ook worden uitgecheckt om feature / pdo weer te geven
In dit artikel hebben we Vagrant, VirtualBox en Puppet gebruikt om niet alleen één serverexemplaar in te stellen waarmee we kunnen werken, maar we hebben ook een testsuite voor onze server gemaakt om ervoor te zorgen dat alles correct wordt uitgevoerd, geïnstalleerd en geconfigureerd.
We hebben ook een checklist voor vereisten opgesteld en kunnen in de toekomst elk aantal identieke servers in minuten maken, niet uren!
