Share
Come applicazione PHP, WordPress viene solitamente distribuito con un metodo molto vecchio: caricare file tramite FTP.
Abbiamo alcuni strumenti di distribuzione, ma spesso richiedono un certo tipo di abilità Ruby. Ad esempio, uno strumento popolare e potente è Capistrano, ma è anche molto pesante con molte funzionalità relative a Ruby / Rails. Penso anche che sia un po 'complicato installare Capistrano per uno sviluppatore PHP senza alcuna conoscenza di Ruby.
Quindi quali opzioni abbiamo come sviluppatori di WordPress?
In questo tutorial, ti presenterò Mina: uno strumento piccolo e leggero che mira alla rapida implementazione e all'automazione dei server.
L'implementazione automatizzata ci consente di risparmiare tempo durante le attività di ripetizione ogni volta che iniziamo a implementare il nostro progetto WordPress. Aiuta anche a ridurre al minimo i tempi di fermo durante la distribuzione ed eliminare errori umani come file mancanti, caricamento di file errati e così via.
Questo processo di automazione può essere condiviso tra più sviluppatori nel team, creando così un metodo unico per l'implementazione in tutto il team. Una società è quasi fallita a causa della mancanza di un buon processo di distribuzione. Un metodo di distribuzione automatizzato è solitamente associato a un sistema di controllo del codice sorgente: Git, SVN, Mercurial e così via.
Nell'ambito di questo tutorial daremo un'occhiata a Git. Se hai un repository Git, sentiti libero di usarlo; altrimenti, prendine uno gratis su BitBucket o GitLab. Questi servizi ti consentono di creare repository Git privati.
Prima di andare oltre, assicurati di soddisfare i requisiti:
[nota] Suppongo che tu stia eseguendo WordPress su Apache con PHP che installa come modulo Apache PHP. Se stai utilizzando PHP con FPM o CGI, sii flessibile quando parliamo del nostro server web o del nostro processo PHP. [/Nota]
L'idea generale è che quando inviamo al server, Git invocherà un URL che potrebbe fare riferimento a uno script PHP per eseguire la distribuzione estrapolando o unendo il nuovo codice dal repository.
Mentre questo funziona perfettamente, ed è molto utile, espone un buco: abbiamo aperto una porta segreta sul server. Se qualcuno conosce quell'URL, può attivare manualmente una distribuzione. Un altro pericolo è che dobbiamo creare funzionalità per la pulizia, il rollback, il blocco (per assicurarsi che sia in esecuzione un solo processo di distribuzione), e così via.
Se iniziamo a codificare queste funzionalità, stiamo reinventando la ruota, quindi perché non utilizzare uno strumento esistente?
Mina è uno strumento di distribuzione che mira ad essere molto veloce; Sarai sorpreso di quanto sia veloce quando lo provi. Secondo il sito web di Mina:
Strumento di deployer e server server davvero veloce. Davvero maledettamente veloce.
In poche parole, qui 'come pensare a Mina: invece di accedere al server e digitare una sequenza di comandi da distribuire. Mina genera uno script di shell che è un insieme di questi comandi.
Mina carica questo script di shell sul server e lo esegue. Questo processo di generazione viene eseguito sul computer locale.
Tutte le attività di Mina sono solo una sequenza di comandi della shell. Poiché sono solo comandi di shell, non avrai accesso a fantastici aiutanti di Ruby come in Capistrano o Vlad.
Un altro modo di pensare a Mina è questo: Mina organizza i comandi della shell che devi eseguire sulla macchina remota in blocchi di codice (che sono chiamati compiti Mina).
Mina richiede un layout di directory per il tuo sito web. Dovrai modificare la directory pubblica del tuo server web. Per semplificare, supponiamo che la struttura della directory del server corrente sia la seguente.
/var/www/yourdomain.com/ # La directory pubblica in cui si trova il tuo WordPress | - index.php | - wp-admin | - wp-content | - wp-includes | - wp-login.php | - wp-activate. php | - ... .
yourdomain.com punta a /var/www/yourdomain.com/, e index.php il file, che si trova all'interno di questa directory, viene eseguito e risponde alla tua richiesta. Con Mina, devi cambiare un po 'il layout della directory.
Mina si aspetta questa struttura:
/var/www/yourdomain.com/ # Il percorso deploy_to | - releases / # contiene le release, un subdir per release | | - 1 / # Ciascuna implementazione di WordPress si trova qui | | - 2 / # Ogni distribuzione di WordPress si siede qui | | - 3 / # Ogni implementazione di WordPress si siede qui | | - ... | - shared / # Contiene i file condivisi tra le versioni: come file di registro, config, ... | | - logs / # I file di registro sono solitamente memorizzati qui | - ... | - current / # Un link simbolico alla versione corrente nelle versioni, questa sarà una nuova cartella pubblica
Mina aggiunge tre directory:
Accentsconagua
rilasci: ogni distribuzione verrà archiviata in directory separate all'interno di questa cartella che ci consente di mantenere la versione 1, la versione 2, la versione 3 e così via.condivisa: contiene file / cartelle comuni condivisi tra più implementazioni. Un esempio è wp-content / uploads. A ciascuna distribuzione, avremo una nuova directory wp-content / uploads questo è diverso dal precedente wp-content / uploads directory. E il contenuto dentro è sparito. Pertanto, useremo una directory comune: condivisi / wp-content / uploads. Avremo: /var/www/yourdomain.com/releases/7/wp-contents/uploads è un collegamento simbolico a /var/www/yourdomain.com/shared/wp-content/uploads.attuale: indica la versione corrente. Esempio: /var/www/yourdomain.com/current punta a /var/www/yourdomain.com/releases/7. Secondo Wikipedia:
Un collegamento simbolico (anche link simbolico o soft link) è un tipo speciale di file che contiene un riferimento a un altro file o directory sotto forma di un percorso assoluto o relativo e che influisce sulla risoluzione del percorso. I collegamenti simbolici erano già presenti nel 1978 in sistemi operativi mini-computer da DEC e RDOS di Data General. Oggi sono supportati dallo standard del sistema operativo POSIX, dalla maggior parte dei sistemi operativi Unix come FreeBSD, GNU / Linux e Mac OS X, e anche dai sistemi operativi Windows come Windows Vista, Windows 7 e in parte con Windows 2000 e Windows XP sotto forma di file di scelta rapida.
Yourdomain.com ora deve puntare a /var/www/yourdomain.com/current invece di /var/www/yourdomain.com. Il server Web eseguirà il file /var/www/yourdomain.com/current/index.php quando visiti http://yourdomain.com. Dobbiamo ricontrigare il web server (Apache, Nginx) in modo che punti docroot(o directory pubblica) a questo attuale elenco.
Apri i tuoi /etc/httpd/conf/httpd.conf, trovare la DocumentRoot linea e cambiarlo.
DocumentRoot /var/www/yourdomain.com/current
Modifica il tuo /etc/nginx/nginx.conf e aggiorna il tuo radice definizione.
server nome_server log.axcoto.com www.log.axcoto.com; root /srv/http/domain/log.axcoto.com/current/; # ...
Mina è una gemma Ruby quindi è necessario installare Ruby. L'installazione è abbastanza esy. Se stai usando OS X o Linux, è probabile che tu abbia già installato Ruby; altrimenti, puoi seguire questi tutorial per installare Ruby:
Una volta, hai Ruby, procedi per installare gem. Corri:
$ gem installa mina
Conferma che Mina funziona correttamente.
$ mina -V
Dovresti vedere qualcosa di simile.
Mina, versione v0.3.0
Una delle cose che rendono le applicazioni PHP meno sicure è l'impostazione delle autorizzazioni errate.
Prendi WordPress per un esempio: potrei voler caricare plugin o caricare temi per provarlo. Per fare questo, finisco per caricarli nella dashboard di WordPress. Se io o uno degli amministratori del sito perde la password dell'amministratore, qualcuno entra e può caricare un file PHP ed eseguirlo come plug in e non solo hackerare il mio sito, ma anche il mio intero server,.
Caso in questione: possono leggere un file in / etc, apprendere la configurazione del server e quindi iniziare a eseguire i comandi della shell tramite PHP.
Penso che dovremmo trattare un'istanza di WordPress come un'installazione di sola lettura. Per l'installazione di temi e plug-in, possiamo installare tramite l'aggiunta di file localmente, quindi ri-distribuire tramite Mina. La distribuzione con Mina è economica e molto veloce, sul mio server DigitalOcean RAM da 512 MB, ci vogliono meno di 30 secondi per la distribuzione.
Per i contenuti caricati dall'utente (come immagini e file audio), li collegheremo ad un link simbolico all'esterno della directory del codice sorgente, e sarà meglio se possiamo configurare il server per impedire l'esecuzione di qualsiasi file PHP all'interno della cartella di contenuti caricata dall'utente, ma questo è fuori dagli scopi di questo tutorial.
Per ora, proveremo a utilizzare Mina per l'implementazione rapida e l'aggiunta di temi o plug-in e lo faremo a livello locale per evitare di dare al server Web il permesso di scrivere in queste directory.
Come affermato all'inizio del tutorial, devi avere un repository Git per il tuo sito WordPress. Ricapitoliamo ciò di cui abbiamo bisogno qui:
Supponiamo che ...
Se non hai familiarità con Git, leggi i seguenti tutorial:
Se il tuo codice sorgente WordPress non è un repository Git, facciamolo ora; in caso contrario, passa al passaggio successivo.
$ cd ~ / Site / wordpress $ git init $ git remote add origine [email protected]: kureikain / wordpress.git $ git add. $ git push origin master
Esegui sotto il comando per iniziare a configurare Mina per il tuo progetto.
$ mina init
Questo ti creerà una cartella config con un singolo file deploy.rb al suo interno.
$ ls config wp-blog-header.php wp-load.php index.php wp-comments-post.php wp-login.php latest.tar.gz wp-config-sample.php wp-mail.php license.txt wp-content wp-settings.php readme.html wp-cron.php wp-signup.php wp-activate.php wp-include wp-trackback.php wp-admin wp-links-opml.php xmlrpc.php $ ls config deploy.rb
Ora, apri config / deploy.rb nel passaggio precedente e definiamo alcune configurazioni.
Questo file deploy.rb contiene la configurazione di distribuzione e un set di attività Mina. Ogni attività è racchiusa all'interno compito: nome compito bloccare. All'interno di ogni attività, possiamo richiamare un'altra attività con invocare Per eseguire un comando sul server, lo si specifica con coda comando.
Ad esempio, un'attività può assomigliare a questa:
task: down do invoke: maintenance_on invoke: restart queue 'rm -rf / tmp / cache' fine
Con questo in mente, iniziamo ad editare questo file deploy.rb.
Commenta queste righe perché non le useremo.
#require 'mina / bundler' #require 'mina / rails'
Il codice predefinito assomiglia a questo
set: user, 'username' set: domain, 'foobar.com' set: deploy_to, '/var/www/foobar.com' set: repository, 'git: // ...' set: branch, 'master'
dominio è dominio del nome di dominio del tuo sito WordPress.deploy_to è dove vuoi che il tuo progetto WordPress trovi.deposito è il tuo indirizzo di repository Git.ramo il tuo ramo di implementazione. Git supporta molti rami, e alcuni pepple vogliono avere un schierare filiale per scopi di implementazione.Aggiorniamolo con la nostra configurazione del server:
set: domain, 'yourdomain.com' set: deploy_to, '/var/www/yourdomain.com' set: repository, 'https: //[email protected]/kureikain/wordpress.git' set: branch, 'master 'set: user,' your_username '# Username nel server su SSH a.
Assicurati di poter raggiungere il deposito sulla tua macchina remota.
Successivamente, gestiremo il wp-content / uploads cartella. Questa cartella contiene contenuti caricati dall'utente. Ogni volta che distribuiamo, sarà una cartella diversa da quella attualmente in uso perché il codice distribuito di recente si trova in una cartella diversa all'interno rilasci.
Se conserviamo questa nuova cartella, perderemo tutto il vecchio contenuto. Come tale, dobbiamo usare un link simbolico per puntarlo in qualche altro posto. Una volta implementato, lo aggiorneremo per correggerne uno.
Trova questa linea:
set: shared_paths, ['config / database.yml', 'log']
E cambialo in:
set: shared_paths, ['wp-content / uploads']
shared_paths è una raccolta di risorse comuni (file / cartella) tra le varie versioni e può essere diversa tra la versione. Come i file di registro, i contenuti caricati dagli utenti devono essere messi in percorsi condivisi. Se non lo facciamo, perderemo i dati con ogni nuova versione.
Ad esempio: quando un utente carica un file, WordPress lo memorizza /var/www/yourdomain.com/current/wp-content/upload/2014/01/29/picture.png. Ma /var/www/yourdomain.com/current è un punto di collegamento simbolico a /var/www/yourdomain.com/releases/4/ qual è la nostra versione attuale. Pertanto, il file effettivo si trova in: /var/www/yourdomain.com/releases/4/wp-content/upload/2014/01/29/picture.png.
Ora, se hai fatto una nuova versione, attuale punterà a /var/www/yourdomain.com/releases/5. Il file /var/www/yourdomain.com/current/wp-content/upload/2014/01/29/picture.png non è più lì, perché /var/www/yourdomain.com/releases/5/wp-content/uploads è una nuova cartella, senza contenuto.
Come tale, dobbiamo metterlo in shared_paths, e Mina creerà un link simbolico al punto /www/yourdomain.com/releases/5/wp-content/uploads a /www/yourdomain.com/shared/wp-content/uploads.
Questo è il compito che eseguiamo la prima volta per preparare il nostro ambiente server. Quello di default assomiglia a questo:
task: setup =>: environment fa queue! % [mkdir -p "# deploy_to / shared / log"] coda! % [chmod g + rx, u + rwx "# deploy_to / shared / log"] coda! % [mkdir -p "# deploy_to / shared / config"] coda! % [chmod g + rx, u + rwx "# deploy_to / shared / config"] coda! % [touch "# deploy_to /shared/config/database.yml"] coda% [echo "-----> Assicurati di modificare" shared / config / database.yml "."] end
Passiamo a:
task: setup =>: environment fa queue! % [mkdir -p "# deploy_to / shared / wp-content / uploads"] fine
Il nostro compito di installazione crea semplicemente a wp-content / uploads elenco.
L'attività di default è simile a questa.
task: deploy =>: environment do deploy do # Metti le cose che imposteranno una directory vuota in un'istanza # completamente configurata del tuo progetto. invoke: 'git: clone' invoke: 'deploy: link_shared_paths' invoca: 'bundle: install' invoke: 'rails: db_migrate' richiama: 'rails: assets_precompile' per: avvio fa coda "touch # deploy_to / tmp / restart .txt "end end end
Non abbiamo bisogno di nulla che abbia a che fare con Rails. Inoltre, poiché la distribuzione di WordPress non ha richiesto un server Web o un riavvio del processo PHP, è sufficiente richiamare git: clone e distribuire: attività link_shared_paths.
Lasciali cambiare a:
task: deploy =>: environment do deploy do # Metti le cose che imposteranno una directory vuota in un'istanza # completamente configurata del tuo progetto. invoca: 'git: clone' invoca: 'deploy: link_shared_paths' end end
Purtroppo Mina non ha un metodo ufficiale per il rollback, quindi ho creato un'attività per il nostro processo di rollback. Quello che l'attività di rollback farà è che rimuoverà la versione corrente e re punto attuale collegamento simbolico alla versione precedente. Aggiungi questa attività alla fine del tuo deploy.rb
desc "Rollback alla verison precedente." task: rollback =>: environment fa queue% [echo "----> Start to rollback"] coda% [se [$ (ls # deploy_to / releases | wc -l) -gt 1]; then echo "----> Ricollega alla versione precedente" && scollega # deploy_to / current && ln -s # deploy_to / releases / "$ (ls # deploy_to / releases | tail -2 | head -1 ) "# deploy_to / current && echo" Rimuovi vecchie versioni "&& rm -rf # deploy_to / releases /" $ (ls # deploy_to / releases | tail -1) "&& echo" $ (ls # deploy_to / releases | tail -1) "> # deploy_to / last_version && echo" Fine. Ripristino a v $ (cat # deploy_to / last_version) "; else echo "Non più rilascio al rollback"; demone
Il codice sopra sembra complesso ma in realtà è una versione a linea singola del codice seguente. Lo romperò e metto un'annotazione sopra ogni comando.
# Controlla se abbiamo 1 rilasci se [$ (ls /var/www/yourdomain.com/releases | wc -l) -gt 1] e poi echo "----> Ricollega alla versione precedente" # Rimuovi corrente link simbolico /var/www/yourdomain.com/current # Puntalo alla versione precedente ln -s /var/www/yourdomain.com/releases/"$(ls /var/www/yourdomain.com/releases | tail -2 | head -1) "/var/www/yourdomain.com/current echo" Rimuovi vecchie versioni "# Rimuove l'ultima versione che abbiamo già ripristinato rm -rf /var/www/yourdomain.com/releases/"$(ls / var / www / yourdomain.com / releases | tail -1) "# Registra la versione corrente su last_version file echo" $ (ls /var/www/yourdomain.com/releases | tail -1) "> /var/www/yourdomain.com / last_version # Out inserisci alcune informazioni per l'utente echo "Fatto. Ripristina v $ (cat /var/www/yourdomain.com/last_version)" else # Se non abbiamo più di 1 rilasci, non possiamo eseguire il rollback. echo "Non più release per il rollback" fi
A questo punto, configuriamo il server, modifica l'attività di configurazione, distribuisci attività e attività di rollback. Cominciamo a usare effettivamente Mina ora.
In questa parte, ti mostrerò come eseguire Mina su setup server, deploy su server ed esegui un rollback. Mina è un'utilità a riga di comando. Devi avere accesso a un terminale. Ogni task Mina verrà richiamato dal terminale.
Lo eseguiamo solo la prima volta che ci prepariamo per la distribuzione su un server. SSH al server e creare il deploy_to directory. Suo /var/www/yourdomain.com nel nostro caso.
$ ssh [email protected] # sul tuo computer remoto (dopo aver effettuato il collegamento tramite SSH), esegui $ sudo mkdir -p /var/www/yourdomain.com $ sudo chown -R your_name /var/www/yourdomain.com
Una volta che eseguiamo il chown comando, cambieremo il proprietario di /var/www/yourdomain.com all'utente il tuo nome. Pertanto, il web server non può scrivere nulla in questa directory. Il nostro sito WordPress sarà più sicuro in questo modo. Successivamente, sul tuo locale, corri installazione mina. Produce qualcosa come questo:
$ mina setup -----> Impostazione di /var/www/yourdomain.com totale 16 drwxr-xr-x 4 kurei root 4096 gen 27 22:51. drwxr-xr-x 3 root root 4096 gen 27 00: 16 ... drwxr-xr-x 2 utenti kurei 4096 gen 27 22:51 releases drwxr-xr-x 2 utenti kurei 4096 gen 27 22:51 condivisi ----- > Fatto. Tempo trascorso: 1,00 secondi
Se vuoi confermare ciò che Mina ha creato per noi sul server, controllalo sulla macchina remota:
$ cd /var/www/yourdomain.com $ ls rilascia condivise condivise $ ls / wp-content
A questo punto, tutto è quasi pronto. Ricorda, la directory di caricamento memorizza il contenuto caricato dall'utente. Pertanto, il server Web deve essere in grado di scrivere su di esso. Dobbiamo determinare quale utente Apache / Nginx (o processo FPM di PHP, dipende da come si configura il server) è in esecuzione e cambiare il proprietario della cartella di upload su di esso, per consentire al server Web di scrivere in questa cartella. Di solito, se apri il tuo file di configurazione di Apache o il file di configurazione di Nginx, puoi trovare questo utente, qualcosa di simile:
[Sourecode]
# Per Apache, apri /etc/httpd/conf/httpd.conf
Utente www Gruppo www
# Per Nginx, apri /etc/nginx/nginx.conf
utente http http; worker_processes 2;
[/ Sourecode]
Supponiamo che Apache sia in esecuzione www utente.
[codice sorgente] ssh [email protected] sudo chown -R www /var/www/yourdomain.com/wp-content/uploads [/ sourecode]
Ogni volta che vogliamo distribuire il codice, usiamo questo compito.
Il processo è:
Una volta che il codice era attivo sul server Git.
Facciamo distribuire
$ mina deploy
In alcuni secondi, dovrebbe finire. Ecco un esempio di output del risultato di implementazione:
$ mina deploy -----> Creazione di un percorso di build temporaneo -----> Recupero di nuovi commit git -----> Uso di git branch "master" Cloning in "." ... done. -----> Usando questo git commit kureikain (347d9b3):> Aggiorna nuova config / deploy -----> Symlinking percorsi condivisi -----> Build finished -----> Moving build to releases / 2 -----> Aggiornamento del link simbolico corrente -----> Avvio -----> Fatto. Implementato v2 Tempo trascorso: 1.00 secondi
Se una versione ha un bug critico, o semplicemente vogliamo riportare il codice alla versione precedente per un motivo o per un altro, facciamo questo:
$ mina rollback
La sua uscita qualcosa di simile
----> Inizia a rollback ----> Ricollega alla versione precedente Rimuovi vecchie versioni Fine. Ripristino della connessione v2 a axcoto.com chiuso. Tempo trascorso: 0,00 secondi
Hai imparato come schierare con Mina. Il processo di distribuzione è abbastanza veloce ora. Il tuo sito Web non subirà alcun downtime. Ma non fermarti a questo, vai sul sito web di Mina e cerca di saperne di più. Ho condiviso un esempio di progetto WordPress che utilizza Mina su GitHub.
Nella parte successiva, impareremo a conoscere WP-CLI. Nello specifico, impareremo come utilizzarlo ed eseguire attività di amministrazione comuni come l'aggiornamento di WordPress, l'installazione di temi, plug-in e così via tramite WP-CLI in cima a un'attività Mina. Vedremo anche come lo usiamo per rendere più sicura la nostra installazione di WordPress.
Fino ad allora, lascia un commento su ciò che fai per rendere la distribuzione di WordPress un gioco da ragazzi.
