Share
Als PHP-applicatie wordt WordPress meestal op een heel oude manier geïmplementeerd: bestanden uploaden via FTP.
We hebben een aantal implementatietools, maar ze hebben vaak een soort Ruby-vaardigheid nodig. Een populaire, krachtige tool is bijvoorbeeld Capistrano, maar het is ook erg zwaar met veel Ruby / Rails gerelateerde functies. Ik denk ook dat het een beetje lastig is om Capistrano voor een PHP-ontwikkelaar te installeren zonder enige Ruby-kennis.
Dus welke opties hebben we als WordPress-ontwikkelaars?
In deze tutorial zal ik je voorstellen aan Mina: een kleine, lichte tool die gericht is op snelle implementatie en serverautomatisering.
Geautomatiseerde implementatie bespaart ons de tijd om herhaaltaken uit te voeren telkens als we ons WordPress-project gaan implementeren. Het helpt ook de uitvaltijd tijdens de implementatie te minimaliseren en menselijke fouten te elimineren, zoals ontbrekende bestanden, het uploaden van verkeerde bestanden, enzovoort.
Dit automatiseringsproces kan worden gedeeld door meerdere ontwikkelaars in het team, waardoor een unieke methode voor inzet in het hele team wordt gecreëerd. Eén bedrijf ging bijna failliet vanwege het ontbreken van een goed implementatieproces. Een geautomatiseerde implementatiemethode is meestal gekoppeld aan een controlesysteem voor broncodes: Git, SVN, Mercurial, enzovoort.
In het kader van deze tutorial zullen we een kijkje nemen bij Git. Als je een Git-repository had, voel je vrij om het te gebruiken; anders, pak een gratis bij BitBucket of GitLab. Met deze services kunt u privé Git-bibliotheken maken.
Voordat we verder gaan, zorgen we ervoor dat we aan de vereisten voldoen:
[note] Ik neem aan dat je WordPress uitvoert op Apache met PHP installeren als Apache PHP-module. Als u PHP met FPM of CGI gebruikt, moet u flexibel zijn wanneer we het hebben over onze webserver of ons PHP-proces. [/Notitie]
Het algemene idee is dat wanneer we naar de server pushen, Git een URL oproept die naar een PHP-script kan verwijzen om de implementatie uit te voeren door de nieuwste code uit de repository te trekken of samen te voegen.
Hoewel dit perfect werkt en erg nuttig is, stelt het een gat bloot: we openden een geheime deur op de server. Als iemand die URL kent, kunnen ze een implementatie handmatig activeren. Een ander gevaar is dat we functies moeten bouwen om op te schonen, terug te draaien of te vergrendelen (om ervoor te zorgen dat slechts één enkel implementatieproces wordt uitgevoerd), enzovoort.
Als we deze functies beginnen te coderen, vinden we het wiel opnieuw uit, dus waarom zou u geen bestaand gereedschap gebruiken??
Mina is een inzetgereedschap dat als doel heeft zeer snel te zijn; Je zult verrast zijn hoe snel het is wanneer je het probeert. Volgens de website van Mina:
Echt snel inzetbaar en serverautomatiseringshulpmiddel. Echt verdomd snel.
Simpel gezegd, hier 'hoe te denken van Mina: in plaats van in te loggen op de server en een reeks opdrachten in te tikken om in te zetten. Mina genereert een shellscript dat een set van deze opdrachten is.
Mina uploadt dit shellscript naar de server en voert het uit. Dit generatieproces wordt uitgevoerd op uw lokale computer.
Alle Mina-taken zijn slechts een reeks shell-opdrachten. Omdat het gewoon shell-commando's zijn, heb je geen toegang tot een fantastische Ruby-helper zoals in Capistrano of Vlad.
Een andere manier om aan Mina te denken, is deze: Mina organiseert uw shell-opdrachten die u op een externe computer moet uitvoeren in codeblokken (die Mina-taken worden genoemd).
Mina vereist een directory-indeling voor uw website. U moet de openbare map van uw webserver wijzigen. Laten we, om het gemakkelijker te maken, aannemen dat uw huidige serverdirectorystructuur als volgt is.
/var/www/yourdomain.com/ # De openbare map waar uw WordPress zit | - index.php | - wp-admin | - wp-content | - wp-includes | - wp-login.php | - wp-activate. php | - ... .
yourdomain.com verwijst naar /var/www/yourdomain.com/, en index.php bestand, dat zich in deze map bevindt, wordt uitgevoerd en reageert op uw verzoek. Met Mina moet je de layout van de map een beetje veranderen.
Mina verwacht deze structuur:
/var/www/ydomdomain.com/ # Het pad deploy_to | - releases / # bevat releases, één subdir per release | | - 1 / # Elke implementatie van WordPress zit hier | | - 2 / # Elke implementatie van WordPress zit hier | | - 3 / # Elke implementatie van WordPress zit hier | | - ... | - shared / # bevat bestanden die worden gedeeld tussen releases: zoals logbestand, configuratie, ... | | - logs / # logbestanden worden meestal hier opgeslagen | - ... | - current / # Een symlink naar de huidige release in releases, dit zal een nieuwe public folder zijn
Mina voegt drie mappen toe:
Accentsconagua
releases: elke implementatie wordt opgeslagen in afzonderlijke mappen in deze map, waardoor we versie 1, versie 2, versie 3, enzovoort kunnen onderhouden.gedeelde: bevat gemeenschappelijk bestand / mappen die wordt gedeeld tussen meerdere implementaties. Een voorbeeld is wp-content / uploads. Bij elke implementatie hebben we een nieuwe map wp-content / uploads dat is anders dan vorige wp-content / uploads directory. En de inhoud van binnen is verdwenen. Daarom zullen we een gemeenschappelijke map gebruiken: shared / wp-content / uploads. We zullen hebben: /var/www/yourdomain.com/releases/7/wp-contents/uploads is een symbolische verwijzing naar /var/www/yourdomain.com/shared/wp-content/uploads.stroom: wijst naar de huidige release. Voorbeeld: /var/www/yourdomain.com/current wijst naar /var/www/yourdomain.com/releases/7. Volgens Wikipedia:
Een symbolische koppeling (ook een symlink of een zachte koppeling) is een speciaal type bestand met een verwijzing naar een ander bestand of een andere map in de vorm van een absoluut of relatief pad en dat van invloed is op de resolutie van de padnaam. Symbolische links waren al aanwezig in 1978 in mini-computer besturingssystemen van DEC en Data General RDOS. Tegenwoordig worden ze ondersteund door de POSIX-besturingssysteemstandaard, de meeste Unix-achtige besturingssystemen zoals FreeBSD, GNU / Linux en Mac OS X, en ook Windows-besturingssystemen zoals Windows Vista, Windows 7 en tot op zekere hoogte in Windows 2000 en Windows XP in de vorm van snelkoppelingsbestanden.
Yourdomain.com nu moet wijst naar /var/www/yourdomain.com/current in plaats van /var/www/yourdomain.com. Webserver zal het bestand uitvoeren /var/www/yourdomain.com/current/index.php wanneer je op bezoek komt http://yourdomain.com. We moeten de webserver (Apache, Nginx) opnieuw converteren naar punt docroot(of openbare map) hieraan stroom directory.
Open je /etc/httpd/conf/httpd.conf, vind de DocumentRoot regel en verander het naar.
DocumentRoot /var/www/ydomdom.com/current
Bewerk je /etc/nginx/nginx.conf en werk je update bij wortel definitie.
server servernaam log.axcoto.com www.log.axcoto.com; root /srv/http/domain/log.axcoto.com/current/; # ...
Mina is een Ruby-juweeltje dus je moet Ruby installeren. Installeren is vrij esy. Als u OS X of Linux gebruikt, is de kans groot dat u Ruby al hebt geïnstalleerd; anders kunt u deze tutorials volgen om Ruby te installeren:
Eens, je hebt Ruby, ga verder met het installeren van edelsteen. Ren gewoon:
$ gem mina installeren
Controleer of Mina correct werkt.
$ mina -V
Je zou iets soortgelijks moeten zien.
Mina, versie v0.3.0
Een van de dingen die PHP-applicaties minder veilig maken, is het instellen van de onjuiste rechten.
Neem WordPress voor een voorbeeld: ik wil misschien een plug-in uploaden of een thema uploaden om het te proberen. Om dit te doen, eindig ik ze te uploaden in het WordPress-dashboard. Als ik of een van de sitebeheerders het beheerderswachtwoord verliest, stap ik in en kan een PHP-bestand worden geüpload en als plug-in worden uitgevoerd, en niet alleen mijn site hacken, maar ook mijn volledige server..
Voorbeeld: ze kunnen een bestand in / etc lezen, de serverconfiguratie leren kennen en vervolgens shell-opdrachten uitvoeren via PHP.
Ik denk dat we een WordPress-instantie moeten behandelen als een alleen-lezen-installatie. Voor installatie van thema's en plug-ins kunnen we installeren door lokaal bestanden toe te voegen en vervolgens opnieuw implementeren via Mina. Implementeren met Mina is goedkoop en erg snel, op mijn 512 MB RAM DigitalOcean-server duurt het minder dan 30 seconden om te implementeren.
Voor door gebruikers geüploade inhoud (zoals foto's en audiobestanden), zullen we ze symboliseren naar buiten de broncodemap, en het is het beste als we de server kunnen configureren om het uitvoeren van een PHP-bestand in de door de gebruiker geüploade inhoudsmap te voorkomen. maar dat is buiten het bereik van deze tutorial.
Voor nu proberen we Mina te gebruiken voor snelle implementatie en het toevoegen van een thema of een plug-in. We doen dit lokaal, zodat we kunnen voorkomen dat we de webserver toestemming geven om in deze mappen te schrijven.
Zoals vermeld in het begin van de zelfstudie, moet je een Git-repository hebben voor je WordPress-site. Laten we samenvatten wat we hier nodig hebben:
Laten we aannemen dat ...
Als je niet bekend bent met Git, lees dan de volgende tutorials:
Als uw WordPress-broncode geen Git-repository is, laten we het nu doen; ga anders naar de volgende stap.
$ cd ~ / Site / wordpress $ git init $ git remote add origin [email protected]: kureikain / wordpress.git $ git add. $ git push origin master
Voer onderstaande opdracht uit om te beginnen met het instellen van Mina voor uw project.
$ mina init
Hiermee maak je een map config met een enkel bestand deploy.rb erin.
$ 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-includes wp-trackback.php wp-admin wp-links-opml.php xmlrpc.php $ ls config deploy.rb
Open nu config / deploy.rb in de vorige stap en laten we wat configuratie definiëren.
Dit deploy.rb-bestand bevat een implementatieconfiguratie en een set Mina-taken. Elke taak is ingepakt taak: taskname blok. Binnen elke taak kunnen we een andere taak aanroepen beroep doen op Als u een comand op server wilt uitvoeren, geeft u dit op met wachtrij commando.
Een taak kan er bijvoorbeeld als volgt uitzien:
task: down do invoke: maintenance_on invoke: restart queue 'rm -rf / tmp / cache' end
Laten we met dit in gedachten beginnen met het bewerken van dit deploy.rb-bestand.
Geef commentaar op deze regel omdat we ze niet zullen gebruiken.
#require 'mina / bundler' #require 'mina / rails'
De standaardcode ziet er zo uit
set: gebruiker, 'gebruikersnaam' set: domein, 'foobar.com' set: deploy_to, '/var/www/foobar.com' set: repository, 'git: // ...' set: branch, 'master'
domein is een domein voor de domeinnaam van uw WordPress-site.deploy_to is waar u uw WordPress-project wilt lokaliseren.bewaarplaats is je Git repository adres.tak uw implementatietak. Git ondersteunt veel takken, en sommige pepple willen een inzetten filiaal voor inzet doel.Laten we het bijwerken met onze serverconfiguratie:
set: domain, 'yourdomain.com' set: deploy_to, '/var/www/ydomdomain.com' set: repository, 'https: //[email protected]/kureikain/wordpress.git' set: branch, 'master 'set: user,' your_username '# gebruikersnaam in de server naar SSH naar.
Zorg ervoor dat u de bewaarplaats op uw externe computer.
Vervolgens zullen we omgaan met de wp-content / uploads map. Deze map bevat door gebruikers geüploade inhoud. Elke keer dat we implementeren, zal het een andere map zijn dan de map die we momenteel gebruiken, omdat de recent geïmplementeerde code zich in verschillende mappen binnenin bevindt releases.
Als we deze nieuwe map bewaren, verliezen we alle oude inhoud. Als zodanig moeten we een symlink gebruiken om het naar een andere locatie te verwijzen. Zodra het is geïmplementeerd, werken we het bij om te wijzen op een probleem.
Zoek deze regel:
set: shared_paths, ['config / database.yml', 'log']
En verander het in:
set: shared_paths, ['wp-content / uploads']
shared_paths is een verzameling gemeenschappelijke bronnen (bestand / map) tussen de verschillende releases en kan per release verschillend zijn. Net als logbestanden, moet door gebruikers geüploade inhoud in shared_paths worden geplaatst. Als we dat niet doen, verliezen we de gegevens bij elke nieuwe release.
Bijvoorbeeld: wanneer een gebruiker een bestand uploadt, slaat WordPress het op /var/www/yourdomain.com/current/wp-content/upload/2014/01/29/picture.png. Maar /var/www/yourdomain.com/current is een symlink-punt /var/www/yourdomain.com/releases/4/ welke onze huidige versie is. Daarom is het eigenlijke bestand te vinden op: /var/www/yourdomain.com/releases/4/wp-content/upload/2014/01/29/picture.png.
Nu, als je een nieuwe release hebt gemaakt, stroom zal wijzen /var/www/yourdomain.com/releases/5. Het bestand /var/www/yourdomain.com/current/wp-content/upload/2014/01/29/picture.png is er niet meer, omdat /var/www/yourdomain.com/releases/5/wp-content/uploads is een nieuwe map, zonder inhoud.
Als zodanig moeten we het in gedeelde_paden plaatsen en Mina zal een symbolische link naar punt maken /www/yourdomain.com/releases/5/wp-content/uploads naar /www/yourdomain.com/shared/wp-content/uploads.
Dit is de taak die we de eerste keer uitvoeren om onze serveromgeving voor te bereiden. De standaard ziet er als volgt uit:
task: setup =>: environment do queue! % [mkdir -p "# deploy_to / shared / log"] wachtrij! % [chmod g + rx, u + rwx "# deploy_to / shared / log"] wachtrij! % [mkdir -p "# deploy_to / shared / config"] wachtrij! % [chmod g + rx, u + rwx "# deploy_to / shared / config"] wachtrij! % [touch "# deploy_to /shared/config/database.yml"] wachtrij% [echo "-----> Zorg ervoor dat u 'shared / config / database.yml'."] end bewerkt
Laten we het veranderen in:
task: setup =>: environment do queue! % [mkdir -p "# deploy_to / shared / wp-content / uploads"] end
Onze setup-taak maakt eenvoudig een wp-content / uploads directory.
De standaardtaak ziet er als volgt uit.
task: deploy =>: environment do deploy do # Zet dingen die een lege map opzetten op in een volledig opgezet # exemplaar van uw project. invoke: 'git: clone' roept aan: 'deploy: link_shared_paths' roept: 'bundle: install' aanroep op: 'rails: db_migrate' invoke: 'rails: assets_precompile' om: startrij te starten "touch # deploy_to / tmp / restart .txt "end end end
We hebben niets nodig dat te maken heeft met Rails. Omdat de implementatie van WordPress geen webserver- of PHP-proces nodig had, herstart, hoeven we alleen maar de opdracht git: clone and deploy: link_shared_paths aan te roepen.
Laat ze veranderen in:
task: deploy =>: environment do deploy do # Zet dingen die een lege map opzetten op in een volledig opgezet # exemplaar van uw project. invoke: 'git: clone' invoke: 'deploy: link_shared_paths' end end
Helaas heeft Mina geen officiële methode voor rollback, dus heb ik een taak gemaakt voor ons eigen rollback-proces. Wat de terugdraaitaak zal doen, is dat deze de huidige release en het re-punt zal verwijderen stroom symlink naar vorige release. Voeg deze taak toe aan het einde van uw deploy.rb
desc "Terugdraaien naar vorige versie." taak: rollback =>: omgeving wachtrij% [echo "----> Start naar rollback"] wachtrij% [if [$ (ls # deploy_to / releases | wc -l) -gt 1]; dan echo "----> Relink to previos release" && unlink # deploy_to / current && ln -s # deploy_to / releases / "$ (ls # deploy_to / releases | tail -2 | head -1 ) "# deploy_to / current && echo" Remove old releases "&& rm -rf # deploy_to / releases /" $ (ls # deploy_to / releases | tail -1) "&& echo" $ (ls # deploy_to / releases | tail -1) "> # deploy_to / last_version && echo" Klaar. Terugdraaien naar v $ (cat # deploy_to / last_version) "; anders echo "Geen release meer om terug te draaien"; fi] einde
De bovenstaande code ziet er ingewikkeld uit, maar het is eigenlijk een versie met één regel van de volgende code. Ik zal het opsplitsen en een annotatie plaatsen bovenop elke opdracht.
# Controleer of we meer dan 1 releases hebben als [$ (ls /var/www/yourdomain.com/releases | wc -l) -gt 1] vervolgens echo "----> Opnieuw koppelen aan eerdere releases" # Huidige link verwijderen ontkoppelen /var/www/yourdomain.com/current # Wijs het op de vorige release ln -s /var/www/ydomdom.com/releases/"$(ls /var/www/ydomdom.com/releases | tail -2 | head -1) "/var/www/yourdomain.com/current echo" Oude releases verwijderen "# Laatste release verwijderen die we al terugdraaien rm -rf /var/www/ydomdom.com/releases/"$(ls / var / www / yourdomain.com / releases | tail -1) "# Log huidige versie naar last_version bestand echo" $ (ls /var/www/ydomodome.com/releases | tail -1) "> /var/www/yourdomain.com / last_version # Plaats wat info naar gebruiker echo "Klaar. Rollback naar v $ (cat /var/www/ydomodome.com/last_version)" else # Als we niet meer dan 1 releases hebben, dan kunnen we niet terugdraaien. echo "Geen vrijgave meer om terug te draaien" fi
Op dit punt configureren we de server, bewerken Setup-taak, implementeren taak en rollback-taak. Begin nu Mina daadwerkelijk te gebruiken.
In dit deel zal ik laten zien hoe je Mina kunt gebruiken om een server op te zetten, naar de server te distribueren en een rollback uit te voeren. Mina is een opdrachtregelhulpprogramma. U moet toegang hebben tot een terminal. Elke Mina-taak wordt vanaf de terminal opgeroepen.
We voeren dit alleen uit als we ons de eerste keer voorbereiden op een server. SSH naar server en maak de deploy_to directory. Haar /var/www/yourdomain.com in ons geval.
$ ssh [email protected] # op uw externe machine (nadat u bent verbonden via SSH), voer deze $ sudo mkdir -p /var/www/ydomain.com $ sudo chown -R uw_naam /var/www/uwdomein.com uit
Zodra we de chown opdracht, veranderen we de eigenaar van /var/www/uwdomein.com in gebruiker uw naam. Daarom kan de webserver niets naar deze map schrijven. Onze WordPress-site zal op deze manier beter beveiligd zijn. Vervolgens, op uw lokale, uitvoeren mina instellen. Het heeft iets als dit uitgevoerd:
$ mina setup -----> Instellen van /var/www/uwdomein.com totaal 16 drwxr-xr-x 4 kurei root 4096 27 januari 22:51. drwxr-xr-x 3 root root 4096 27 januari 00: 16 ... drwxr-xr-x 2 kurei gebruikers 4096 27 jan 22:51 releases drwxr-xr-x 2 kurei gebruikers 4096 27 jan 22:51 gedeeld ----- > Klaar. Verstreken tijd: 1,00 seconden
Als je wilt bevestigen wat Mina voor ons op de server heeft gemaakt, laten we het op een externe computer controleren:
$ cd /var/www/yourdomain.com $ ls releases gedeelde $ ls gedeelde / wp-inhoud uploads
Op dit moment is alles bijna klaar. Vergeet niet dat de uploaddirectory door gebruikers geüploade inhoud opslaat. Daarom moet de webserver ernaar kunnen schrijven. We moeten bepalen met welke gebruiker uw Apache / Nginx (of PHP FPM-proces, afhankelijk van hoe u uw server configureert) wordt uitgevoerd en de eigenaar van de map uploads naar deze map wijzigen, zodat de webserver naar deze map kan schrijven. Meestal, als u uw Apache-configuratiebestand of Nginx-configuratiebestand opent, kunt u deze gebruiker vinden, iets soortgelijks:
[Sourecode]
# Open voor Apache /etc/httpd/conf/httpd.conf
Gebruiker www Groep www
# Open voor Nginx /etc/nginx/nginx.conf
gebruiker http http; worker_processes 2;
[/ Sourecode]
Laten we aannemen dat Apache actief is www gebruiker.
[sourecode] ssh [email protected] sudo chown -R www /var/www/ydomdom.com/wp-content/uploads [/ sourecode]
Telkens als we de code willen implementeren, gebruiken we deze taak.
Het proces is:
Zodra uw code op de Git-server stond.
Laten we inzetten
$ mina deploy
Binnen enkele seconden moet het worden voltooid. Hier is een voorbeelduitvoer van het inzetresultaat:
$ mina deploy -----> Een tijdelijk build-pad maken -----> Nieuwe git-commits ophalen -----> Git branch gebruiken 'master' Klonen in '.' ... klaar. -----> Gebruik deze git commit kureikain (347d9b3):> Update nieuwe config / deploy -----> Symlinking shared paths -----> Build finished -----> Build naar release / 2 verplaatsen -----> Actualiseren van de huidige symlink -----> Starten -----> Klaar. Geïmplementeerd v2 Verstreken tijd: 1,00 seconden
Als een release kritieke bugs bevat, of we simpelweg om een of andere reden de code naar de vorige release willen terugdraaien, doen we dit:
$ mina rollback
Zijn uitvoer lijkt op iets
----> Starten om terug te draaien ----> Opnieuw koppelen aan vorige release Oude releases verwijderen Klaar. Rollback to v2 Verbinding met axcoto.com gesloten. Verstreken tijd: 0.00 seconden
Je hebt geleerd hoe je met Mina implementeert. Het implementatieproces is vrij snel nu. Uw website zal nul downtime ervaren. Maar stop daar niet bij, ga naar de Mina-website en leun er meer over. Ik heb een voorbeeld van een WordPress-project gedeeld dat Mina op GitHub gebruikt.
In het volgende deel zullen we meer te weten komen over WP-CLI. We zullen specifiek leren hoe we het kunnen gebruiken en algemene beheertaken kunnen uitvoeren, zoals het updaten van WordPress, het installeren van thema's, plug-ins, enzovoort via WP-CLI bovenop een Mina-taak. We zullen ook bekijken hoe we het gebruiken om onze WordPress-installatie veiliger te maken.
Tot die tijd, laat een reactie achter wat u doet om uw WordPress-implementatie een fluitje van een cent te maken.
