Share
Questo articolo ti aiuterà a utilizzare Vagrant per gestire le istanze della macchina virtuale e ti spiegherà come sfruttare Puppet per il provisioning di varie risorse, come PHP e PostgreSQL.
Gli sviluppatori hanno una vasta gamma di modi per costruire il loro ambiente di sviluppo web.
Gli sviluppatori hanno una vasta gamma di modi per costruire il loro ambiente di sviluppo web. È possibile utilizzare opzioni "locali", come l'installazione di stack di server "all-in-one" predefiniti, come Zend Server, XAMPP, MAMP, WAMP, ecc., Oppure è possibile installare i componenti autonomamente dall'origine o tramite sistemi di gestione dei pacchetti come Homebrew, Apt e Yum.
Questo può svilupparsi mentre lavori su vari progetti con: PHP 5.3 e PHP 5.4, MySQL, SQLite, MongoDB, Postgres, PEAR, PHPUnit, Rails 3.1, Memcached, Redis, Gearman, NodeJS, ecc. Se esegui l'upgrade o muori un computer , dovrai ricominciare tutto da capo.
È possibile avere una configurazione "remota", utilizzando un server sulla rete con condivisioni Samba o un server SSH montato con uno strumento come ExpanDrive. Quest'ultima opzione può portare alla latenza dei file di lettura / scrittura, che sono estremamente fastidiosi. Potresti usare SSH + Vim per tutto, che è veloce, ma funziona solo se vuoi usare Vim per tutto.
Sebbene tu possa essere felice di come stai facendo le cose adesso, quanti di voi hanno sentito (o detto) "Beh, funziona sul mio computer". Questo è orribilmente comune e succede quando gli ambienti si differenziano anche dai dettagli più banali.
È estremamente importante assicurarsi che il proprio ambiente di sviluppo sia identico all'ambiente di produzione e abbinare i server di staging e test se ne possiedi anche tu.
Questo potrebbe sembrare facile se pensate solo all'installazione di Apache, PHP e qualche copia di MySQL, ma ci sono un milione di fattori a cui pensare. Se stai sviluppando su OSX e distribuisci su un sistema Ubuntu, noterai problemi divertenti con la maiuscola dei file. Questo è comune in CodeIgniter, quando qualcuno ha una libreria con una prima lettera minuscola. Si caricherà bene su OSX, ma si romperà una volta distribuito alla produzione. Il tuo processo di sviluppo potrebbe averti perso un po 'di lavoro, tutto a causa di una banale differenza di OS che nessuno ha pensato fino a quando non fosse stato troppo tardi.
Costringere gli sviluppatori a utilizzare lo stesso sistema operativo porterà a problemi.
Quindi qual è la soluzione? Imponi a tutti i tuoi sviluppatori di lanciare i loro diversi strumenti e sviluppare sullo stesso modello di laptop? Se i tuoi sviluppatori hanno tutti i MacBook nuovi di zecca, allora potresti non avere troppe lamentele, ma poi dovresti usare OSX Server per tutto.
Potresti usare Linux per tutto, ma poi devi combattere su quale distribuzione usare. Costringere gli sviluppatori a utilizzare lo stesso sistema operativo causerà problemi, ridurrà la produttività e promuoverà la lotta contro i nerd.
La virtualizzazione è la risposta e non è una novità, ma quando le persone pensano alla virtualizzazione spesso pensano ai problemi di prestazioni e ai loro fan che girano selvaggiamente mentre il loro laptop cerca disperatamente di eseguire due sistemi operativi.
Questo può ancora essere il caso di provare a eseguire Windows su una macchina a basso consumo, ma in questi giorni, un Mac medio ha 4 GB di RAM fuori dalla scatola, che è più che sufficiente per alimentare un'installazione di server Ubuntu in esecuzione in modalità riga di comando e tutti i tuoi soliti strumenti di sviluppo (IDE, browser, strumenti di debug, ecc.). Ci sono alcune opzioni per la virtualizzazione, ma preferisco VirtualBox da Oracle (che è gratuito). Questo software fa tutto il necessario per la virtualizzazione, quindi uno strumento chiamato Vagrant gestisce le istanze.
Prima scarica VirtualBox e installalo. Sui sistemi * nix (Mac OSX, Linux, ecc.), È necessario modificare il proprio .bash_profile (o .zsh_profile) per estendere il tuo $ PATH variabile:
PATH = $ PATH: /Applications/VirtualBox.app/Contents/MacOS/ export PATH
Ciò consentirà a Vagrant di sapere dove è installato VirtualBox e, ovviamente, varierà per i diversi sistemi operativi.
Puoi scaricare una build vagabonda per il tuo sistema operativo o installarla come gemma se non è disponibile:
$ gem installa vagabondo
Costruisci un posto dove vivere le tue impostazioni vagabonde:
mkdir -p ~ / Vagrant / test cd ~ / Vagrant / test
Useremo Ubuntu 12.04 LTS (Precise Pangolin), che ha già una "scatola".
scatola vagabonda aggiungere precise32 http://files.vagrantup.com/precise32.box
Vedi qui l'argomento "precise32" che è un soprannome per l'URL. Ora puoi creare un'istanza, che scaricherà questo .box.
vagabondo init precise32 vagabondo su
Ora sarà in esecuzione. Facile! Se vuoi entrare in questa istanza, tramite SSH, usa questo comando:
sergente vagabondo
Avrai un file, chiamato Vagrantfile, che contiene la configurazione per questa istanza:
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" # Assegna questa VM a un IP di rete host-only, permettendoti di accedervi # tramite il IP. Le reti solo host possono comunicare con la macchina host e con # qualsiasi altra macchina sulla stessa rete, ma non possono accedere (tramite questa # interfaccia di rete) da alcuna rete esterna. config.vm.network: hostonly, "192.168.33.10" # Imposta la condivisione di progetto predefinita per usare nfs config.vm.share_folder ("v-web", "/ vagrant / www", "./www",: nfs = > true) config.vm.share_folder ("v-db", "/ vagrant / db", "./db",: nfs => true) # Inoltra una porta dal guest all'host, che consente l'esterno # computer per accedere alla VM, mentre la rete host non lo fa. config.vm.forward_port 80, 8080 # Imposta il fuso orario su qualcosa di utile config.vm.provision: shell,: inline => "echo \" Europa / Londra \ "| sudo tee / etc / timezone && dpkg-reconfigure --frontend tzdata non interattivo "# Aggiorna il server config.vm.provision: shell,: inline =>" apt-get update --fix-missing "# Abilita Puppet config.vm.provision: puppet do | puppet | puppet.facter = "fqdn" => "local.pyrocms", "hostname" => "www" puppet.manifests_path = "puppet / manifest" puppet.manifest_file = "ubuntu-apache2-pgsql-php5.pp" fantoccio .module_path = "puppet / modules" end end Questo, se non l'avessi notato, è la sintassi di Ruby; così puoi diventare abbastanza creativo con questo file, ma questo è il punto di partenza.
Mostrerà quale nickname usare e avere l'URL nel caso in cui il nickname non sia impostato localmente (ottimo per la condivisione in giro).
Il condividi cartella le linee sono davvero utili per mappare una cartella nell'istanza in una cartella locale. utilizzando nfs => true l'istanza sarà in grado di scrivere e modificare le autorizzazioni dei file, il che è utile se, ad esempio, stai tentando di installare un CMS lì.
Il port forwarding ti permette di accedere alla tua istanza su http: // localhost: 8080 e, naturalmente, cambiarlo in un'altra porta se questo è in conflitto.
Questo file di configurazione imposterà anche il fuso orario in Europa / Londra, quindi eseguirà apt-get update, che dovrebbe forzare il tuo sistema ad essere aggiornato ogni volta che viene avviato. Se salti questo elemento di configurazione, potresti trovare che più pacchetti si rifiutano di installare poiché i riferimenti non sono aggiornati.
Quando cambi configurazione, puoi ricaricare l'istanza per usarla:
ricarica vagabonda
Ora che i nostri server sono in esecuzione e pronti per l'uso, è necessario installare alcuni software. Non stiamo solo andando apt-get install un sacco di pacchetti tramite la linea di comando, stiamo andando a "fornire" i nostri server.
Il provisioning del server non è qualcosa a cui molti sviluppatori devono pensare.
Il provisioning del server non è qualcosa a cui molti sviluppatori devono pensare, dato che normalmente viene lasciato agli amministratori di sistema. L'idea è di fare un po 'di registrazione su quale software e configurazione sono stati fatti su un server in modo da poter creare nuovi ambienti di sviluppo, nuovi server di staging che replicano la produzione o rendere un altro server di produzione in equilibrio tra i due.
Il modo in cui gli amministratori di sistema gestiscono questa situazione varia, ma in passato sono stati utilizzati tutti i tipi di soluzioni - dal tenere un wiki dei comandi eseguito (che può diventare grande e obsoleto rapidamente) e l'approccio fantastico di avere un "multi-terminale", dove si digita comandi in una finestra e replica gli stessi comandi su altri 7 server allo stesso tempo. Questi metodi sono tutti terribili.
Una soluzione potrebbe essere la tua .scatola file o creare .iso backup in modo che i nuovi server possano basarsi su questo, ma mantenere quelle immagini crea un sacco di lavoro extra, e non importa quanto duramente si provi, quelle macchine di sviluppo diventeranno fuori sincrono con il passare del tempo.
Al momento ci sono due sistemi popolari, chiamati Puppet and Chef.
Al momento ci sono due sistemi popolari, chiamati Puppet and Chef. Entrambi sono in circolazione da anni, ma hanno iniziato a diventare molto più popolari con l'aumento del metodo di sviluppo DevOps. Le idee per entrambi sono simili e dovresti studiare entrambi i sistemi, ma questo tutorial si concentrerà esclusivamente su Puppet.
In sostanza, invece di eseguire un gruppo di comandi e sperare che tutto funzioni correttamente, si costruisce un manifest per Puppet che spiega tutto ciò di cui si ha bisogno per assicurarsi che sia stato fatto. Quando esegui un comando nel terminale, stai praticamente dicendo al computer:
"Installa Apache"
Con Puppet, diremmo:
"Assicurati che Apache sia installato"
Oppure, invece di:
"Crea una nuova cartella, chiamata
/ Var / wwwe impostare le autorizzazioni su www-data: www-data "
Con Puppet, dovremmo dire:
"Garantire
/ Var / wwwesiste e ha permessi corrispondenti a www-data: www-data "
La differenza qui è che questi manifest possono essere eseguiti più volte (su un cron job ogni ora o ogni giorno) per mantenere le cose aggiornate, e non ci saranno risultati imprevisti da qualcosa che tenta di installare due volte.
Ti aiuterà anche a verificare che tutto stia funzionando come previsto, in quanto una di queste regole non riuscirà a generare errori più facili da rintracciare rispetto a un'enorme quantità di risultati di comando bash. Puppet genererà grandi errori rossi per informarti che PHP non è stato installato, o che non è stato possibile configurare un modulo specifico.
I manifesti sono leggermente confusi all'inizio, ma, dopo un po ', iniziano a dare un senso.
Per esaminare un esempio di base:
file 'testfile': percorso => '/ tmp / testfile', assicurarsi => presente, modalità => 0640, contenuto => "Sono un file di prova.",
Non c'è bisogno di spiegare cosa sta succedendo qui, giusto?
Questo file può essere successivamente indicato nel tuo manifest come "testfile", il che significa che può essere elencato come dipendenza per altre azioni.
Per ulteriori esempi, faremo riferimento ai manifesti di PyroCMS Puppet su GitHub.
include apache $ docroot = '/ vagrant / www / pyrocms /' $ db_location = "/vagrant/db/pyrocms.sqlite" # Apache setup class 'apache :: php': apache :: vhost 'local.pyrocms' : priority => '20', port => '80', docroot => $ docroot, configure_firewall => false, a2mod 'rewrite': ensure => present;
Questo include il modulo "apache", imposta alcune variabili, esegue il manifest extra "apache :: php" nel modulo apache, imposta un host virtuale e assicura che "mod_rewrite" sia abilitato.
Tutte queste classi sono definite nel modulo Apache che abbiamo incluso.
Andando avanti, vogliamo anche installare PHP:
include php php :: module ['xdebug', 'pgsql', 'curl', 'gd']: notify => [Servizio ['httpd'],], php :: conf ['pdo', ' pdo_pgsql ']: require => Pacchetto [' php5-pgsql '], notify => Servizio [' httpd '],
Questo blocco di manifest installerà le estensioni PHP di cui abbiamo bisogno, quindi il notificare l'opzione consentirà ad Apache di sapere che è stata installata una nuova configurazione, il che significa che verrà riavviata.
include postgresql class 'postgresql :: server': postgresql :: db 'pyrocms': owner => 'pyrocms', password => 'password',
Questo configurerà un server postgres, creerà un database, chiamato "pirocms" e assicurerà che un utente, chiamato "pirocms", esista con la password fornita.
Quasi finito! L'ultimo passaggio consiste nel garantire che i file e le cartelle scrivibili siano impostati correttamente:
file $ docroot: ensure => 'directory', file "$ docroot system / cms / config / config.php": ensure => "present", mode => "0666", require => File [ $ docroot], $ writeable_dirs = ["$ docroot system / cms / cache /", "$ docroot system / cms / config /", "$ docroot addons /", "$ docroot assets / cache / "," $ docroot uploads / "] file $ writeable_dirs: ensure =>" directory ", mode => '0777', require => File [$ docroot],
Ciò assicurerà che la root del documento di Apache sia presente, il file di configurazione sia impostato su 0666 e alcune cartelle scrivibili siano impostate su 777.
Ce l'abbiamo!
Per eseguire tutto questo, è sufficiente riavviare la tua istanza vagabonda o eseguire:
disposizione vagabonda
Se tutto ha funzionato correttamente, dovresti vedere un sacco di testo blu che segnala che tutto è stato installato, ma, se qualcosa va storto, vedrai rosso. Google quegli errori e riprova.
I moduli usati qui sono: Apache, Postgres, PHP e puoi vedere il tutto in azione clonando il repository Vagrant PyroCMS:
git clone - git ecologico: //github.com/pyrocms/devops-vagrant.git ~ / vagrant / pyrocms cd ~ / vagrant / pyrocms vagabondo su
Indirizza il tuo browser a http: // localhost: 8089 / e dovresti vedere l'installer. Roba facile, eh?
Nota: Questo verrà installato con MySQL come Postgres di PyroCMS e il supporto SQLite è ancora in sviluppo, in attesa di alcune funzionalità di CodeIgniter PDO da completare. Se sei interessato, puoi sperimentare cambiando il Vagrantfile per usare il ubuntu-apache2-pgsql-php5.pp manifest, distruggi l'istanza, quindi avvialo di nuovo. Il sottomodulo di Pyrocms dovrà essere estratto per mostrare / pdo
In questo articolo, abbiamo usato Vagrant, VirtualBox e Puppet per impostare non solo un'istanza del server con cui lavorare, ma abbiamo creato una suite di test per il nostro server per garantire che tutto sia in esecuzione, installato e configurato correttamente.
Abbiamo anche creato una checklist per i requisiti e, in futuro, saremo in grado di creare un numero qualsiasi di server identici in pochi minuti, non ore!
