Share
Som en PHP-applikasjon, er WordPress vanligvis distribuert av en veldig gammel metode: opplasting av filer via FTP.
Vi har noen distribusjonsverktøy, men de krever ofte en type Ruby-ferdighet. For eksempel er et populært, kraftig verktøy Capistrano, men det er også veldig tungt med mange Ruby / Rails-relaterte funksjoner. Jeg tror også at det er litt vanskelig å installere Capistrano for en PHP-utvikler uten noen Ruby-kunnskaper.
Så hvilke alternativer har vi som WordPress-utviklere?
I denne opplæringen vil jeg introdusere deg Mina: Et lite, lett verktøy tar sikte på rask distribusjon og serverautomatisering.
Automatisert distribusjon sparer oss tid til å gjenta oppgaver hver gang vi begynner å distribuere vårt WordPress-prosjekt. Det bidrar også til å minimere nedetid under distribusjon og eliminere menneskelige feil som manglende filer, opplasting av feilfiler og så videre.
Denne automatiseringsprosessen kan deles mellom flere utviklere i teamet og dermed skape en unik metode for distribusjon i hele teamet. Ett selskap gikk nesten konkurs på grunn av mangelen på en god distribusjonsprosess. En automatisert distribusjonsmetode er vanligvis knyttet til et kildekodesystem: Git, SVN, Mercurial, og så videre.
I omfanget av denne opplæringen vil vi ta en titt på Git. Hvis du hadde et Git-depot, kan du ikke bruke det. Ellers ta en gratis en på BitBucket eller GitLab. Disse tjenestene tillater deg å opprette private Git-arkiver.
Før vi går videre, må du sørge for at vi oppfyller kravene:
[notat] Jeg antar at du kjører WordPress på Apache med PHP installering som Apache PHP-modul. Hvis du bruker PHP med FPM eller CGI, vennligst vær fleksibel når vi snakker om vår webserver eller vår PHP-prosess. [/Merk]
Den generelle ideen er at når vi presser til serveren, vil Git påkalle en nettadresse som kan referere til et PHP-skript for å utføre distribusjon ved å trekke eller slå sammen den nyeste koden fra depotet.
Selv om dette fungerer perfekt, og det er veldig nyttig, avslører det et hull: Vi åpnet en hemmelig dør på serveren. Hvis noen kjenner den URL-adressen, kan de utløse en distribusjon manuelt. En annen fare er at vi må bygge egenskaper for rydde opp, for tilbakeringing, for låsing (for å sørge for at bare en enkelt distribusjonsprosess kjører), og så videre.
Hvis vi begynner å kode disse funksjonene, oppdager vi hjulet, så hvorfor ikke bruke et eksisterende verktøy?
Mina er et distribusjonsverktøy som skal være veldig raskt; Du vil bli overrasket over hvor fort det er når du prøver det. Ifølge Mina nettside:
Virkelig rask distribusjonsverktøy og serverautomatiseringsverktøy. Virkelig blodig fort.
Enkelt sagt, her 'hvordan du tenker på Mina: I stedet for å logge inn på serveren og skrive en rekke kommandoer som skal distribueres. Mina genererer et shell-skript som er et sett med disse kommandoene.
Mina laster opp dette shell-skriptet til serveren og kjører det. Denne generasjonsprosessen kjøres på din lokale maskin.
Alle Mina-oppgaver er bare en sekvens av skallkommandoer. Fordi det bare er shell kommandoer, har du ikke tilgang til fantastisk Ruby hjelper som i Capistrano eller Vlad.
En annen måte å tenke på Mina er dette: Mina organiserer dine shell kommandoer som du må kjøre på ekstern maskin i kodeblokker (som kalles Mina-oppgaver).
Mina krever en katalogoppsett for nettstedet ditt. Du må endre den offentlige katalogen på din webserver. For å gjøre det enklere, må du anta at din nåværende serverkatalogstruktur som følger.
/var/www/yourdomain.com/ # Den offentlige katalogen der WordPress sitter | - index.php | - wp-admin | - wp-content | - wp-includes | - wp-login.php | - wp-aktiver. php | - ... .
yourdomain.com peker på /var/www/yourdomain.com/, og index.php fil, som sitter inne i denne katalogen, utføres og svarer på forespørselen din. Med Mina må du endre katalogoppsettet litt.
Mina forventer denne strukturen:
/var/www/yourdomain.com/ # Deploy_to path | - utgivelser / # Holder utgivelser, en subdir per utgivelse | | - 1 / # Hver av WordPress-distribusjonen er her | | - 2 / # Hver av WordPress-distribusjonen er her | | - 3 / # Hver av WordPress-distribusjonen er her | | - ... | - delt / # Holder filer som deles mellom utgivelser: som loggfil, config, ... | | - logger / # Loggfiler blir vanligvis lagret her | - ... | - nåværende / # En symlink til den nåværende utgivelsen i utgivelser, dette vil bli ny offentlig mappe
Mina legger til tre kataloger:
Accentsconagua
utgivelser: Hver distribusjon vil bli lagret i separate kataloger i denne mappen som gjør at vi kan vedlikeholde versjon 1, versjon 2, versjon 3 og så videre.delt: inneholder vanlige filer / mapper som deles mellom flere distribusjoner. Et eksempel er wp-innhold / opplasting. Ved hver distribusjon vil vi ha en ny katalog wp-innhold / opplasting som er forskjellig fra tidligere wp-innhold / opplasting katalogen. Og innhold inni er borte. Derfor bruker vi en felles katalog: felles / wp-content / uploads. Vi vil ha: /var/www/yourdomain.com/releases/7/wp-contents/uploads er en symlink-poeng til /var/www/yourdomain.com/shared/wp-content/uploads.nåværende: peker på gjeldende utgivelse. Eksempel: /var/www/yourdomain.com/current poeng til /var/www/yourdomain.com/releases/7. Ifølge Wikipedia:
En symbolsk lenke (også symlink eller soft link) er en spesiell type fil som inneholder en referanse til en annen fil eller katalog i form av en absolutt eller relativ vei, og som påvirker opplasting av stinavn. Symboliske koblinger var allerede til stede i 1978 i mini-operativsystemer fra DEC og Data General's RDOS. I dag støttes de av POSIX-operativsystemstandarden, de fleste Unix-lignende operativsystemer som FreeBSD, GNU / Linux og Mac OS X, og også Windows-operativsystemer som Windows Vista, Windows 7 og til en viss grad i Windows 2000 og Windows XP i form av snarvei filer.
Yourdomain.com nå må man peke på /var/www/yourdomain.com/current i stedet for /var/www/yourdomain.com. Web server vil kjøre filen /var/www/yourdomain.com/current/index.php når du besøker http://yourdomain.com. Vi må omkonfigurere webserveren (Apache, Nginx) for å peke dokumentroten(eller offentlig katalog) til dette nåværende katalog.
Åpne din /etc/httpd/conf/httpd.conf, Finn Document linje og endre den til.
DocumentRoot /var/www/yourdomain.com/current
Rediger din /etc/nginx/nginx.conf og oppdater din rot definisjon.
server server_name log.axcoto.com www.log.axcoto.com; root /srv/http/domain/log.axcoto.com/current/; # ...
Mina er en Ruby perle, så du må installere Ruby. Installasjon er ganske esy. Hvis du kjører OS X eller Linux, er det sjansene for at du allerede har Ruby installert; Ellers kan du følge disse veiledningene for å installere Ruby:
En gang har du Ruby, fortsett å installere perlen. Bare løp:
$ perle installasjon mina
Bekreft at Mina kjører riktig.
$ mina -V
Du bør se noe lignende.
Mina, versjon v0.3.0
En av de tingene som gjør PHP-applikasjoner mindre sikre, er å sette feil rettigheter.
Ta WordPress til et eksempel: Jeg vil kanskje laste opp plugin, eller laste opp tema for å prøve det. For å gjøre dette, ender jeg opp med å laste dem opp i WordPress dashboard. Hvis jeg eller en av administratorene mistet administrasjonspassordet, kommer noen inn, og de kan laste opp en PHP-fil og kjøre den, som en plugin, og ikke bare hacke siden min, men hele min server også.
Tilfelle i punkt: De kan lese en fil i / etc, lære serverkonfigurasjonen, og deretter begynne å kjøre skallkommandoer via PHP.
Jeg tror vi bør behandle en WordPress-instans som en skrivebeskyttet installasjon. For installering av tema og plugin kan vi installere ved å legge til filer lokalt, og deretter distribuere via Mina. Utplassering med Mina er billig og veldig rask, på min 512 MB RAM DigitalOcean-server tar det mindre enn 30 sekunder å distribuere.
For brukeropplastet innhold (for eksempel bilder og lydfiler), vil vi sammenkoble dem til utenfor kildekoden, og det vil være best hvis vi kan konfigurere serveren for å hindre kjøring av noen PHP-fil i den brukeropplastede innholdsmappen, men det er ikke tilgjengelig for denne opplæringen.
For nå vil vi prøve å bruke Mina for rask distribusjon, og legge til tema eller et plugin, og vi vil gjøre det lokalt, slik at vi kan unngå å gi webserver tillatelse til å skrive inn i disse katalogene.
Som nevnt i begynnelsen av opplæringen må du ha et Git-lager for ditt WordPress-nettsted. La oss gjenskape hva vi trenger her:
La oss anta at ...
Hvis du ikke er kjent med Git, kan du lese følgende veiledninger:
Hvis din WordPress-kildekode ikke er et Git-depot, la oss gjøre det nå; ellers hoppe til neste trinn.
$ cd ~ / Site / wordpress $ git init $ git ekstern legg til opprinnelse [email protected]: kureikain / wordpress.git $ git add. $ git push origin master
Kjør under kommando for å starte oppsettet Mina for prosjektet ditt.
$ mina init
Dette vil skape deg en mappe config med en enkelt fil deploy.rb inne i den.
$ ls config wp-blog-header.php wp-load.php index.php wp-kommentarer-post.php wp-login.php latest.tar.gz wp-config-sample.php wp-mail.php license.txt wp-innhold wp-settings.php readme.html wp-cron.php wp-signup.php wp-activ.php wp-inkluderer wp-trackback.php wp-admin wp-koblinger-opml.php xmlrpc.php $ ls config deploy.rb
Nå, åpne config / deploy.rb i forrige trinn, og la oss definere noen konfigurasjon.
Denne deploy.rb-filen inneholder distribusjonskonfigurasjon, og et sett med Mina-oppgave. Hver oppgave er pakket innvendig Oppgave: Oppgavenavn blokkere. Inne i hver oppgave kan vi påkalle en annen oppgave med påberope For å kjøre en kommando på server, spesifiserer du den med kø kommando.
For eksempel kan en oppgave se slik ut:
Oppgave: Nøkkelen gjør: Vedlikehold: Påkoble: Endre køen 'rm -rf / tmp / cache' slutten
Med det i tankene, la oss begynne å redigere denne deploy.rb-filen.
Kommentere denne linjen siden vi ikke vil bruke dem.
#require 'mina / bundler' #require 'mina / rails'
Standardkoden ser slik ut
sett: bruker, 'brukernavn' sett: domene, 'foobar.com' sett: deploy_to, '/var/www/foobar.com' sett: repository, 'git: // ...' sett: gren, 'master'
domene er domenet til domenenavnet på ditt WordPress-nettsted.deploy_to er der du vil at WordPress-prosjektet ditt skal finne.oppbevaringssted er din Git-depotadresse.gren distribusjonsgrenen din. Git støtter mange grener, og litt peppel vil ha en utplassere gren for distribusjonsformål.La oss oppdatere det med vår serverkonfigurasjon:
sett: domene, 'yourdomain.com' sett: deploy_to, '/var/www/yourdomain.com' sett: depot, 'https: //[email protected]/kureikain/wordpress.git' sett: gren, 'master 'sett: bruker,' ditt_brukernavn '# Brukernavn i serveren til SSH til.
Pass på at du kan nå oppbevaringssted på fjernmaskinen din.
Deretter skal vi håndtere wp-innhold / opplasting mappe. Denne mappen inneholder brukeropplastet innhold. Hver gang vi distribuerer, blir det en annen mappe fra den som vi bruker for øyeblikket, fordi den nylig distribuerte koden sitter i annen mappe inne utgivelser.
Hvis vi beholder denne nye mappen, vil vi miste alt gammelt innhold. Som sådan må vi bruke en symlink for å peke den til et annet sted. Når du har blitt distribuert, oppdaterer vi den for å korrigere en.
Finn denne linjen:
sett: shared_paths, ['config / database.yml', 'log']
Og endre den til:
sett: shared_paths, ['wp-content / uploads']
shared_paths er en samling av felles ressurser (fil / mappe) mellom de ulike utgivelsene og kan være forskjellig mellom utgivelsen. Som loggfiler skal brukeropplastet innhold settes i shared_paths. Hvis vi ikke gjør det, vil vi miste dataene med hver ny versjon.
For eksempel: Når en bruker laster opp en fil, lagrer WordPress den inn /var/www/yourdomain.com/current/wp-content/upload/2014/01/29/picture.png. Men /var/www/yourdomain.com/current er et symlink punkt til /var/www/yourdomain.com/releases/4/ som er vår nåværende utgave. Derfor er den faktiske filen plassert på: /var/www/yourdomain.com/releases/4/wp-content/upload/2014/01/29/picture.png.
Nå, hvis du har laget en ny utgave, nåværende vil peke på /var/www/yourdomain.com/releases/5. Filen /var/www/yourdomain.com/current/wp-content/upload/2014/01/29/picture.png er ikke lenger der, fordi /var/www/yourdomain.com/releases/5/wp-content/uploads er en ny mappe, uten innhold.
Som sådan må vi sette den inn i shared_paths, og Mina vil opprette en symlink til poeng /www/yourdomain.com/releases/5/wp-content/uploads til /www/yourdomain.com/shared/wp-content/uploads.
Dette er oppgaven vi kjører på første gang for å forberede vårt servermiljø. Standardinnstillingen ser slik ut:
Oppgave: setup =>: miljøet gjør køen! % [mkdir -p "# deploy_to / shared / log"] kø! % [chmod g + rx, u + rwx "# deploy_to / shared / log"] kø! % [mkdir -p "# deploy_to / shared / config"] kø! % [chmod g + rx, u + rwx "# deploy_to / shared / config"] kø! % [berør "# deploy_to /shared/config/database.yml"] kø% [echo "-----> Pass på å redigere 'shared / config / database.yml'."] slutten
La oss endre det til:
Oppgave: setup =>: miljøet gjør køen! % [mkdir -p "# deploy_to / shared / wp-content / uploads"] slutten
Oppsettoppgaven oppretter bare en wp-innhold / opplasting katalog.
Standard oppgave ser slik ut.
Oppgave: deploy =>: Miljø deployer gjør # Legg ting som vil sette opp en tom katalog i et fullstendig oppsett av ditt prosjekt. påkalle: 'git: klone' påkalle: 'deploy: link_shared_paths' påkalle: 'bundle: install' påkalle: 'skinner: db_migrate' påkalle: 'skinner: assets_precompile' til: start kjøre "trykk # deploy_to / tmp / restart .txt "slutten slutten
Vi trenger ikke noe som har å gjøre med Rails. Også siden distribusjonen av WordPress ikke krever en webserver eller PHP-prosessstart, så trenger vi bare å påkalle git: klone og distribuere: link_shared_paths-oppgave.
La dem skifte til:
Oppgave: deploy =>: Miljø deployer gjør # Legg ting som vil sette opp en tom katalog i et fullstendig oppsett av ditt prosjekt. påkalle: 'git: klon' påkaller: 'deploy: link_shared_paths' slutten
Dessverre har Mina ikke en offisiell metode for tilbakeringing, så jeg opprettet en oppgave for vår egen tilbakekallingsprosess. Hva rollback oppgaven vil gjøre er at den vil fjerne nåværende utgivelse, og re point nåværende symlink til tidligere utgivelse. Legg til denne oppgaven på slutten av deploy.rb
desc "Tilbakestill til forrige verison." oppgave: rollback =>: miljø gjør kø% [echo "----> Start å tilbakestille"] kø% [hvis [$ (ls # deploy_to / releases | wc -l) -gt 1]; ekko "----> Relink til previos release" && unlink # deploy_to / current && ln -s # deploy_to / utgivelser / "$ (ls # deploy_to / releases | tail -2 | head -1 ) "# deploy_to / current && echo" Fjern gamle utgivelser "&& rm -rf # deploy_to / utgivelser /" $ (ls # deploy_to / releases | tail -1) "&& echo" $ (ls # deploy_to / releases | tail -1) "> # deploy_to / last_version && echo" Ferdig. Tilbakestill til v $ (cat # deploy_to / last_version) "; Ellers ekko "Ikke mer utgivelse for å tilbakestille"; fi] ende
Koden ovenfor ser kompleks ut, men det er faktisk en enkeltlinjeversjon av følgende kode. Jeg vil bryte den ned og legge en kommentar på toppen av hver kommando.
# Sjekk om vi har 1 utgivelse hvis [$ (ls /var/www/yourdomain.com/releases | wc -l) -gt 1] ekko "----> Relink til previos release" # Fjern nåværende symlink unlink /var/www/yourdomain.com/current # Pek den til den forrige utgivelsen ln -s /var/www/yourdomain.com/releases/"$(ls/var/www/yourdomain.com/releases | tail -2 | head -1) "/var/www/yourdomain.com/current echo" Fjern gamle utgivelser "# Fjern siste utgivelse som vi allerede tilbakelevering rm -rf /var/www/yourdomain.com/releases/"$(ls / var / www / yourdomain.com / utgivelser | hale -1) "# Logg gjeldende versjon til last_version fil ekko" $ (ls /var/www/yourdomain.com/releases | tail -1) "> /var/www/yourdomain.com / last_version # Ut sett litt info til bruker ekko "Ferdig. Tilbakestill til v $ (cat /var/www/yourdomain.com/last_version)" ellers # Hvis vi ikke har mer enn 1 utgivelser, kan vi ikke vende tilbake. ekko "Ikke mer utgivelse for tilbakestilling" fi
På dette tidspunktet konfigurerer vi serveren, redigerer oppsettoppgave, distribuerer oppgave og tilbakestillingsoppgave. La begynne å faktisk bruke Mina nå.
I denne delen vil jeg vise deg hvordan du kjører Mina til oppsett server, distribuere til server og utføre en tilbakestilling. Mina er et kommandolinjeverktøy. Du må ha tilgang til en terminal. Hver Mina-oppgave vil bli påkalt fra terminal.
Vi kjører bare dette første gangen vi forbereder oss på å distribuere til en server. SSH til server og opprett deploy_to katalogen. Det er /var/www/yourdomain.com i vårt tilfelle.
$ ssh [email protected] # på fjernmaskinen din (etter at du er koblet til via SSH), kjør denne $ sudo mkdir -p /var/www/yourdomain.com $ sudo chown -R ditt navn /var/www/yourdomain.com
Når vi kjører chown kommando, vi vil endre eieren av /var/www/yourdomain.com til brukeren navnet ditt. Derfor kan ikke webserveren skrive noe til denne katalogen. Vårt WordPress-nettsted vil bli sikret på denne måten. Neste, på din lokale, løp mina oppsett. Det gir noe slikt ut:
$ mina oppsett -----> Sette opp /var/www/yourdomain.com totalt 16 drwxr-xr-x 4 kurei root 4096 27 jan 22:51. drwxr-xr-x 3 rotrot 4096 Jan 27 00: 16 ... drwxr-xr-x 2 kurei-brukere 4096 27 jan 22:51 utgivelser drwxr-xr-x 2 kurei-brukere 4096 Jan 27 22:51 shared ----- > Ferdig. Forløpt tid: 1,00 sekunder
Hvis du vil bekrefte hva Mina opprettet for oss på serveren, la oss sjekke det på ekstern maskin:
$ cd /var/www/yourdomain.com $ ls utgivelser delte $ ls delte / wp-innholdsopplastinger
På dette punktet er alt nesten klart. Husk at opplastingsmappen lagrer brukeropplastet innhold. Derfor må webserveren kunne skrive til den. Vi må avgjøre hvilken bruker Apache / Nginx (eller PHP FPM-prosessen, avhengig av hvordan du konfigurerer serveren din) kjører, og endrer eieren av opplastingsmappen til den, slik at webserver skrives til denne mappen. Vanligvis, hvis du åpner Apache config-fil eller Nginx config-fil, kan du finne denne brukeren, noe som ligner på:
[Sourecode]
# For Apache, åpne /etc/httpd/conf/httpd.conf
Bruker www Gruppe www
# For Nginx, åpne /etc/nginx/nginx.conf
bruker http http; worker_processes 2;
[/ Sourecode]
La oss anta at Apache kjører på www bruker.
[sourecode] ssh [email protected] sudo chown -R www /var/www/yourdomain.com/wp-content/uploads [/ sourecode]
Hver gang vi vil distribuere koden, bruker vi denne oppgaven.
Prosessen er:
Når koden din var oppe på Git-serveren.
La oss distribuere
$ mina distribuere
Om noen sekunder skal det være ferdig. Her er et eksempel utgang av distribusjonsresultat:
$ mina distribuere -----> Opprette en midlertidig byggesti -----> Hente nye git commits -----> Bruke git grenen 'master' Cloning til '.' ... ferdig. -----> Bruke denne git commit kureikain (347d9b3):> Oppdater ny config / deploy -----> Symlinking delte baner -----> Bygg ferdig -----> Flytt bygg til utgivelser / 2 -----> Oppdaterer gjeldende symlink -----> Lansering -----> Done. Utplassert v2 Forløpt tid: 1,00 sekunder
Hvis en utgave har en kritisk feil, eller bare vi ønsker å tilbakestille koden til tidligere utgave av en eller annen grunn, gjør vi dette:
$ mina tilbakebetaling
Dens produksjon er noe som
----> Begynn å tilbakestille ----> Tilbakestill til forrige utgave Fjern gamle utgaver Utført. Tilbakestilling til v2 Tilkobling til axcoto.com stengt. Forløpt tid: 0,00 sekunder
Du lærte å distribuere med Mina. Utplasseringsprosessen er ganske rask nå. Nettstedet ditt vil oppleve null nedetid. Men ikke stopp ved det, gå til Mina-nettstedet og lene mer om det. Jeg delte et eksempel på WordPress-prosjekt som bruker Mina på GitHub.
I neste del lærer vi om WP-CLI. Spesielt vil vi lære å utnytte det og utføre vanlige adminoppgaver, for eksempel å oppdatere WordPress, installere temaer, plugins og så videre alle via WP-CLI på toppen av en Mina-oppgave. Vi vil også se på hvordan vi bruker den for å gjøre vår WordPress-installasjon mer sikker.
Inntil da, legg en kommentar til hva du gjør for å gjøre WordPress-distribusjonen til en bris.
