Share
Det är vanligt att arbeta lokalt på ett projekt och trycka revisioner till en produktionsserver, men det steg som folk ofta hoppa över är staging-servern. En staging server är en blandning mellan produktion och utveckling; du får prova din app som om den var i produktion. Låt oss granska några av de problem som du måste överväga, liksom de steg som behövs för att replikera en produktionsplattform som en tjänst (PAAS).
Det har hänt mer än en gång: Jag driver en översyn av min app till produktion, bara för att hitta ett problem efter att det är offentligt. Dessa problem kan vara lika enkelt som att glömma att lägga till bilder i ditt förråd, eller det kan vara så stort som att ändra en databas struktur lokalt och glömma att uppdatera produktionsdatabasen. Problem händer med alla, särskilt när du har rusade tidsfrister. I dessa situationer är det en smart idé att installera en scenmiljö. Tanken är att ha en server som omedelbart replikerar produktionsmiljön för att testa din app före publicering.
Staging miljöer inte bara fånga mänskliga fel, men också mjukvarurelaterade problem.
Du kan hitta och åtgärda dessa problem eftersom staging-området har samma programvara som din produktionsmiljö. Detta står i skarp kontrast till din lokala maskin, där du kan ha olika versioner av programvara installerade (t.ex. PHP 5.3 vs PHP 5.4) eller till och med olika funktioner. Jag har tryckt på kod som innehöll samtal till file_get_contents bara för att finna att produktionsservern inte stödde den funktionen.
Så hur går det med att ställa in en raderingsserver? Tja, det första steget är en liten rekognosering.
Problem händer med alla, särskilt när du har rusade tidsfrister.
Att skapa en scenmiljö är specifik för din produktionsmiljö. Det finns ingen magisk lösning som fungerar i alla situationer. Men de flesta fall följer ett liknande mönster, och jag täcker alla viktiga punkter som vi går med.
Det är rimligt att anta att de flesta använder sina appar med något slags versionsverktyg (som GIT). På den udda chansen att du arbetar med ett gammalt projekt som fortfarande använder FTP kan webbplatser som ftploy.com eller deployHQ.com fungera som en buffert mellan GIT och din server. Jeffrey Way sammanställde en informativ video som beskriver hur man ställer upp det.
Förutom GIT måste du tänka på språk, programvara och "speciella" funktioner som erbjuds av din produktionsservrar. Jag använder en PHP-baserad PAAS, som heter Fortrabbit, eftersom de erbjuder aktuellt PHP, Apache och GIT-support. De ger också möjlighet att lägga till ett nyckelord i ditt GIT-commit-meddelande som utlöser kompositören för att installera ditt projekts beroenden.
Detta är det system som jag kommer att installera i resten av denna artikel. Dess standardfunktionsuppsättning, liksom den speciella komponistfunktionen, gör Fortrabbit perfekt för en mängd olika värdar. Kom bara ihåg: det här är inte en magisk lösning, men de olika åtgärderna följer samma mönster som du skulle använda för att konfigurera en scenmiljö för de flesta projekt. Skräddarsy processen till dina specifika behov.
Så utan vidare, låt oss hoppa in.
Att skapa en scenmiljö är specifik för din produktionsmiljö.
Det finns många olika operativsystem som du kan köra på en server. Fortrabbit kör Debian Squeeze på sina servrar, och eftersom vi försöker matcha dem bestämde jag mig för att köra det också.
Jag använder Vagrant för att ställa upp det här. Oroa dig inte om du aldrig har använt Vagrant; vi kommer inte göra något avancerat. Se till att du har VirtualBox och Vagrant installerat (Vagrant är en CLI för VirtualBox, så VirtualBox krävs).
Vagrant tar en virtuell ögonblicksbild av ett operativsystem som en basfält, och du kan sedan skapa flera VM-filer från den bilden. Först måste vi ladda ner basrutan för Debian Squeeze. Jag är inte exakt säker på var min kopia kommer ifrån, så jag laddar upp den till DropBox för att du ska ladda ner och använda. För att installera, öppna ett terminalfönster och skriv:
vagrant box lägg till debian https://dl.dropbox.com/u/30949096/debian.box
Detta lägger till rutan till Vagrant med namnet "debian". Vi kan nu skapa en förekomst av den här rutan för vårt staging-område. Låt oss först skapa en ny mapp:
mkdir ~ / staging_server cd ~ / staging_server
Skapa sedan Vagrant config-filen genom att skriva:
vagrant init debian
Detta skapar en config-fil med namnet "VagrantFile", som innehåller alla inställningar för din server. Det ser ganska trångt ut när du öppnar det, men de flesta av raderna är kommentarer. Du behöver bara kommentera raden som säger: config.vm.network: bridged. Om du tar bort alla andra kommentarer lämnar du en fil som ser ut så här:
Vagrant :: Config.run gör | config | config.vm.box = "debian" config.vm.network: bridged end
Dessa alternativ berättar för Vagrant att skapa en ny virtuell maskin baserad på basfältet Debian Squeeze. Det ställer sedan nätverksläget för att "överbryggas". En VM med ett överbryggat nätverk visas som en ny fysisk maskin till din router, så den hämtar automatiskt sin egen IP-adress. Detta låter dig komma åt maskinen från vilken enhet som helst i ditt nätverk (eventuellt utanför ditt nätverk om du konfigurerar routern).
Nu kan vi starta vår VM med kommandot: "
vagrant upp" (utan citaten).
Du bör se produktionen från Vagrant som skapar din VM. Om din dator har flera NIC-enheter anslutna till nätverket uppmanar Vagrant dig att välja NIC för att överbrygga.
Vi använder SSH för att logga in, men vi måste använda Vagrant's inbyggda "vagrant ssh"kommandot att logga in. Enligt Vagrant bästa praxis ska alla lådor ha en användare som heter" vagrant "med lösenordet, för både rot och vagrant" vagrant ". Den vagrantanvändaren läggs till som en sudo användare som inte behöver ange ett lösenord, så att du kan använda direkt sudo kommandon.
Låt oss gå vidare och ställa in serverns programvara.
Fortrabbits inställning inkluderar:
Dessutom använder de dotdebförvaret för att installera huvuddelen av det. För dem som är obekanta är dotdeb ett projekt av Guillaume Plessis som installerar de mest aktuella versionerna av populära webbserverpaket.
Vi är redo att börja. Kontrollera att ditt terminalfönster är öppet och loggat in på servern via SSH. Lägg först till dotdeb repo till APT (pakethanteraren) genom att lägga till en ny fil till sources.d katalogen:
sudo vim /etc/apt/sources.list.d/dotdeb.list
Detta öppnar en ny fil med namnet dotdeb.list i vim (en textredigerare). Namnet är inte viktigt eftersom alla filer i den här katalogen läses in i APT. Vi måste lägga till fyra rader i den här filen. Om du aldrig har använt VIM, skriv bara "jag"för att ange insert-läge och kopiera / klistra in de följande fyra raderna:
deb http://packages.dotdeb.org krama alla deb-src http://packages.dotdeb.org krama alla deb http://packages.dotdeb.org squeeze-php54 alla deb-src http: //packages.dotdeb .org squeeze-php54 alla
För att spara, tryck på esc nyckel och typ : wq. Det är kommandot att skriva och avsluta, vilket i princip betyder att spara och avsluta.
Genom att trycka på enter sparas filen och returnerar dig till kommandoraden.
Vi har nu lagt till repos, men vi måste fortfarande lägga till signaturen innan vi kan använda dem. Skriv följande för att lägga till GNU-nyckeln:
curl http://www.dotdeb.org/dotdeb.gpg | sudo apt-key lägg till -
Detta hämtar dotdeb-nyckeln och lägger till den som en signerad källa. Uppdatera nu APT för att dra in det nya paketet genom att skriva:
sudo apt-get uppdatering
Det kan ta en minut eller så, men du har alla dotdeb-paket som anges i APT när det är klart. På grund av hur dotdeb är inställd och hur APT beroenden är laddade kan vi installera Apache och PHP samtidigt genom att skriva:
sudo apt-get installera php5
Med denna enda rad installerar och konfigurerar APT Apache2 och PHP5. Om du använder Fortrabbits memcache-tillägg kan du installera det med:
sudo apt-get install memcached
Men jag kommer inte att gå in i memcache i vårt exempel i den här artikeln.
Nu måste vi installera de tillägg som Fortrabbit använder. Kör följande kommando:
sudo apt-get installera php5-xdebug php5-nety php5-sqlite php5-redis php5-pgsql \ php5-mysqlnd php5-memcache php5-memcached php5-mcrypt php5-imagick php5-http \ php5-gmp php5-gd php5-curl php5 -apc php5-intl
Det sista vi behöver installera är Composer. Jag ska installera den globalt eftersom vi kommer att använda den på några olika platser. Kommandona för att globalt installera kompositören är:
curl -s https://getcomposer.org/installer | php sudo mv composer.phar / usr / local / bin / composer
Det första kommandot hämtar och kör installatören; det andra kommandot flyttar kompositören till bin-mappen så att vi kan använda den utan att deklarera sökvägen. Låt oss gå vidare till konfigurationen.
Chansen är bra att du kanske arbetar med mer än ett projekt. Om så är fallet skapar en staging-server för varje projekt mycket kostnader. För att tillåta flera webbplatser på en enda server måste vi lägga till namnbaserade virtuella värdar till Apache och separera kataloger och repos för varje projekt.
Låt oss börja med en virtuell värd.
Jag ska fortsätta använda vim, men vet att om du vill arbeta i dina egna program kan du antingen kopiera och klistra in eller spara det i
staging_servermapp du skapade på din dator.
Den mappen delas till din VM, och du kan komma åt filerna i luffare rotkatalog. Du kan då använda: sudo cp / vagrant / file newfile eller sudo mv / vagrant / filee newfile att kopiera eller flytta filerna, respektive.
För att skapa en ny virtuell värd måste vi skapa en fil i / etc / apache2 / sites-tillgängligt / katalogen. För att göra detta med VIM skriver du följande:
sudo vim /etc/apache2/sites-available/demo.site
Inåt, skriv in följande (kom ihåg tryck "jag"för infogningsläge):
ServerAdmin [email protected] Servernamn demo.dev DocumentRoot / var / www / demo Alternativ Indexer FollowSymLinks MultiViews AllowOverride ALL Order tillåter, neka tillåta från alla ErrorLog $ APACHE_LOG_DIR /demo.log LogLevel debug
Den första raden deklarerar en virtuell värd som lyssnar på förfrågningar på vilken IP som helst i port 80. Därefter ställer vi in serverns administratörs-e-postadress och servernamnet. E-postmeddelandet är avsett för felrapportering, och serverns namnalternativ berättar Apache när den ska läsas den här virtuella värden. Vanliga virtuella värdar fungerar utanför IP-adresser. Till exempel lyssnar varje vhost på en annan IP; så skiljer Apache dem från varandra.
Eftersom du förmodligen bara har en IP, kan vi använda namnbaserade virtuella värdar, så att du kan ange ett annat namn på samma IP.
I vårt exempel plockas alla förfrågningar riktade till demo.dev av denna virtuella värd.
Nästa rad anger dokumentets rotmapp. Det är här Apache hämtar filer för detta vhost. Uttalandena inom Directory Direktivet anger behörigheter för detta vhost. Jag kommer inte att gå in på för mycket detaljer, men vi ställde in Apache-alternativen för kataloger, då ställer vi in vad som kan överdras i en .htaccess-fil och slutligen ställer vi in vem som kan komma åt webbplatsen (alla kan i vårt fall).
De sista två raderna berättar Apache vad man ska namnge loggfilen och vad man ska skriva till loggen. Vår loggfil heter demo.log i Apache loggmappen som finns på / Var / log / apache2 / på denna VM.
För att aktivera detta vhost skriver du följande:
sudo a2ensite demo.site
Detta skapar en symlink mellan filen i den tillgängliga mappen, till en fil i mappen som är lokaliserad. När du har kört det här kommandot uppmanas du att starta om Apache. Du får ett fel om du försöker starta om Apache eftersom vi inte har skapat webbplatsens katalog. Detta är lätt att fixa köpa skapa demo mapp som vi hänvisade till i vhost-filen:
sudo mkdir / var / www / demo
Vi vill inte att rotanvändaren ska äga mappen, så byt den till vagrantanvändaren med chown kommando:
sudo chown -R vagrant: vagrant / var / www / demo
Starta om Apache nu:
sudo service apache2 omstart
Vår nya webbplats ska nu vara fullt fungerande. Vårt nästa steg är att installera GIT.
Se till att du är i hemkatalogen genom att skriva cd ~. Skapa en ny mapp för repo: mkdir demo.git, skriv in mappen och initiera en ny, ren GIT repo:
cd demo.git git init --bare
En ren repo är i grunden en standard repo utan en arbetsbok. Om du vill lära dig mer om GIT, kolla in Andrew Burgess videoserie.
Vi behöver nu förmågan att trycka kod till webbplatsens mapp, och det finns många sätt att uppnå detta. Men jag gillar att få saker att se så nära som möjligt till den tjänst jag efterliknar. Här är en bild av fortrabbits git-process som tagits från deras webbplats:
Du kan se att push-processen går igenom tre steg. Det visar ett uppdateringsmeddelande när det ansluter, och det distribuerar webbplatsen i katalogen. Det sista steget installerar allt om commit-meddelandet innehåller sökorden "[trigger: composer]". Sedan efter de tre tre stegen är du klar med ">> All Done <
Innan vi skapar krokarna vill jag prata om färger.
Jag gör det mesta av mitt arbete i terminalen, och oftare lämnar terminalapparaten allt samma färg. Att lägga till olika färger i din app ökar inte bara läsbarheten, men ökar också lika förmåga. Så vidare sprida "färgpraxis" i terminalappar, jag tar en stund att diskutera hur de fungerar.
Terminaler kommer med sexton ANSI-färger som kan konfigureras och användas över hela terminalen. Här är en bild på skärmen iTerm2-inställningar, som visar de sexton färgspåren:
Du kan komma åt dem i terminalen genom att skriva flygteckenet följt av den öppna kvadratkonsolen och sedan färgkoden. Du kan se i bilden att färgerna är uppdelade i två linjer: en märkt "Normal" och den andra "Bright". Koderna för de normala färgerna är siffrorna 30-37 följt av bokstaven "m", och de ljusa färgerna är från 90-97, följt av en m. Du kan testa detta i ditt terminalfönster med eko. För att skapa escape-tecknet, skriv ctrl-v följd av Ctrl- [. Du kommer att få en karaktär som ser ut ^ [, men det kommer inte fungera om du bara skriver "^ [" (skift-6 och sedan öppna kvadratkonsolen). Så i terminalfönstret:
eko "^ [[31m Hello World ^ [[0m"
Återigen, den första ^ [ Det var inte skrivet men skapades med ctrl-v och då Ctrl- [. De 0m teckenkod är återställningskoden; Det tar bort all formatering. Detta beror på att färgkoderna inte slutar efter nästa ord, de fortsätter tills de får en annan kod.
Om det görs korrekt, matar den ovan angivna koden orden "hej världen" i rött (om du inte har den platsen till en annan färg).
Under resten av handledningen kommer jag att lägga till färger på kommandona. Gärna följa med eller utelämna dem; de är inte strikt nödvändiga. Men om du vill använda färger, var god att använda min färgassisterande klass. Nu, låt oss gå tillbaka till att skriva krokarna.
Om du tittar på Fortrabbit-bilden igen ser du meddelandet "Steg 1: Uppdatera förråd" innan du uppdaterar repo. För att göra det på rätt sätt måste vi sätta det här meddelandet i förhandsmottagningskroken, som körs innan repo uppdateras. I terminalfönstret:
vim ~ / demo.git / krokar / för-mottagning
Detta öppnar kroken för redigering. Lägg till följande kod:
#! / Usr / bin / php
Den första raden berättar OS att det här är en PHP-fil och att köra den som sådan. Sedan tilldelar vi en färg och återställningsföljden till variabler. Det sista steget ekos linjen.
Nästa krok är lite mer komplicerad eftersom den hanterar resten av åtgärderna. Vi tar det steg för steg, så spara den första kroken (: wq) och öppna nästa krok:
vim ~ / demo.git / krokar / efter-mottagning
Efter-mottagningskroken körs efter repo är uppdaterad. Vi måste först uppdatera webbplatsen och sedan leta efter kompositörens utlösare. Här är ett skelett av vårt program och lämnar ut någon ny logik:
#! / Usr / bin / php ". $" blank ". $ blank." \ n "; echo $ yellow." Steg 2: Implementera ". $ blank." \ n "; / * TODO: Distribuera till webbplats * / echo" -> ". $ cyan. "OK". $ blank. "\ n"; / * TODO: Kontrollera om commit har utlösare * / echo $ yellow. ">> All Done <<" . $blank . "\n"; ?>
Detta är bara en skiss för att arbeta från. Det första vi behöver lägga in är funktionen att dra repoens nya version till webbplatsens katalog. Traditionellt skulle jag helt enkelt skriva följande om jag var i mappen:
git hämta ursprung git reset - hårdast ursprung / mästare
Du kan använda något som git pull, men det kan orsaka fel. Om en fil ändrats direkt, eller om du saknade ett åtagande, då git pull kommer inte heller tillåta dig att dra eller radera dina ospårade filer.
Det här är två enkla kommandon, men du får ett fel om du försöker köra dem från kroken.
GIT anger vissa miljövariabler innan krokarna körs. Du kan kringgå detta med en av två lösningar, och jag ska visa er båda.
Den första är att åsidosätta miljövariablerna, direkt i informationen. Den andra helt raderar variablerna. Jag kommer att använda det första alternativet i det här exemplet och det andra alternativet när vi arbetar på komponentutlösaren. Byt kommentar jag lade till ovan där det står "TODO Deploy to site" med följande:
Accentsconagua
$ git = "git - git-dir = / var / www / demo / .git / --work-tree = / var / www / demo /"; exec ("$ git-hämta -q-ursprung"); exec ("$ git reset - hard origin / master"); Detta strider mot miljövariablerna och kallar de ovan nämnda funktionerna. Den tillsatta -q parametern berättar att GIT är "tyst", vilket förbjuder GIT från att echo några meddelanden.
Nu måste vi kolla på kompositörens utlösare. Låt oss bryta detta i två steg. Vi kontrollerar först för utlösaren, och sedan utför vi Kompositör. Byt ut den andra TODO-kommentaren med följande:
$ msg = exec ("$ git log -n 1 --format = format:% s% b"); om (strpos ($ msg, "[trigger: composer]")! == false) echo $ yellow. "Step3: Composer Hook". $ tomt. "\ N"; echo "-> Utlösande installation - få en". $ cyan. "kaffe". $ tomt. "\ N"; // köra kompositör eko "->". $ cyan. "OK". $ tomt. "\ N"; Den första raden hämtar commit-meddelandet med hjälp av git logg kommandot och passerar i ett speciellt format för att utesluta ytterligare information. Därefter kontrollerar vi om strängen har det speciella triggerordet, och eko det tredje steget och OK-meddelandet. Vi letar efter Composer-sökordet, men du kan implementera flera nyckelord för andra funktioner som: migrera i Laravel eller kör enhetstester. Lägg till något för att förbättra ditt arbetsflöde.
Det sista steget är att utföra kompositören. Komponist har två kommandon: kompositör installera och kompositör uppdatering.
Installationskommandot läser inte
composer.jsonfil om den finner acomposer.lock, och eftersom vissa människor kan lägga tillcomposer.locktill deras .gitignore-fil, är det säkrare att körakompositör uppdatering(det ser alltid påcomposer.jsonfil.
Den andra frågan är att ibland använder Composer GIT för att ladda ner paket, och dessa försök misslyckas på grund av miljövariablerna. Så här är ett bra ställe att bara ta bort miljövariabeln "GIT_DIR". Byt kommentaren för att köra Kompositör med följande:
chdir ( "/ var / www / demo"); putenv ( "GIT_DIR"); exec ("kompositör uppdatering"); Denna kod är rakt framåt. Vi flyttar PHP-processen till webbplatsens mapp och tar sedan bort GIT_DIR miljövariabel så att GIT fungerar normalt. Den sista raden kör kompositör.
Vi har nu båda krokarna, men vi är inte helt redo att börja använda vår server. Först måste vi göra dessa krokar körbara:
chmod a + x ~ / demo.git / krokar / pre-receive chmod a + x ~ / demo.git / krokar / efter-mottagning
Skapa sedan en GIT-repo i webbplatsens mapp. Vi skulle få ett fel om vi försöker köra våra krokar eftersom webbplatsens mapp inte är en GIT-repo. För att åtgärda denna typ:
cd / var / www / demo git init git fjärrkontroll lägg till ursprung /home/vagrant/demo.git
De första två raderna skapar repo, och sedan lägger vi till det öppna arkivet som den här repoens ursprung.
Du bör också lägga till din allmänna nyckel till den här serverns auktoriserade värdar så att du kan komma åt servern via GIT utan ett lösenord. Du kan kopiera din offentliga nyckel genom att skriva på din dator (inte VM):
katt ~ / .ssh / id_rsa.pub | pbcopy
Sedan klistra in det enkelt på servern i filen ~ / .Ssh / authorized_keys:
vim ~ / .ssh / authorized_keys
Lägg bara till den i filen, men lämna det som redan finns inuti.
Därefter måste vi lägga till IP för denna server till vår hosts-fil. För att hitta IP, skriv:
ip -4 -o addr visa etikett et *
Här visas IP för alla nätverksenheter på den här VM. Lägg till den som ansluter till ditt lokala nätverk. Om du inte kan bestämma vilken IP-adress som ska användas kopierar du och klistrar in en i din webbläsare. Om den ansluter, har du rätt IP-adress.
Ta IP och lägg till den i din dators värdfil (inte VM: s värdfil). Värdarfilen på en Mac finns på etc / hosts:
sudo vim / etc / hosts
Lägg sedan till följande rad:
#Format: IP_address site_name 192.168.0.110 demo.dev
Om detta fungerar kan du navigera till http://demo.dev i din webbläsare. Medan du fortfarande finns på din Mac, skapar du en mapp och initierar en GIT-repo:
mkdir ~ / demo cd ~ / demo git init echo "Hello World"> index.php git add. git commit -am "added index.php" git fjärr lägg till staging [email protected]: demo.git git push staging master
Om allt gick bra bör du se ett svar från våra GIT-krokar. Navigera till http://demo.dev bör resultera i meddelandet "Hello World" som visas i din webbläsare.
Så det är så du kan skapa en scenmiljö som efterliknar funktionen hos en typisk PAAS. Om du hade problem med att följa med, eller om du behöver konfigurera flera scenmiljöer, skapade jag ett skript som automatiserar processen helt. För mer information, kan du besöka stagr.gmanricks.com.
Jag hoppas att du tyckte om artikeln. Ställ dig några frågor som du kanske har i kommentarerna. Tack för att du läste.
