Share
Det er vanlig å jobbe lokalt på et prosjekt og presse revisjoner til en produksjonsserver, men trinnet som folk ofte hopper over, er staging-serveren. En staging server er en blanding mellom produksjon og utvikling; Du får prøve appen din som om den var i produksjon. La oss se på noen av problemene du må vurdere, samt trinnene som trengs for å kopiere en produksjonsplattform som en tjeneste (PAAS).
Det har skjedd mer enn en gang: Jeg presser en revisjon av appen min til produksjon, bare for å finne et problem etter at det er offentlig. Disse problemene kan være like enkle som å glemme å legge til bilder i lageret ditt, eller det kan være så stort som å endre en databasestruktur lokalt og glemme å oppdatere produksjonsdatabasen. Problemer skje med alle, spesielt når du har rushed tidsfrister. I disse situasjonene er det en smart idé å sette opp et scenemiljø. Tanken er å ha en server som nøyaktig kopierer produksjonsmiljøet, for å teste appen din før publisering.
Staging-miljøer fanger ikke bare menneskelige feil, men også programvarerelaterte problemer.
Du kan finne og fikse disse problemene fordi oppstartsområdet har samme programvare som ditt produksjonsmiljø. Dette er i sterk kontrast til din lokale maskin, hvor du kan ha forskjellige versjoner av programvare installert (for eksempel PHP 5.3 vs PHP 5.4) eller til og med forskjellige funksjoner. Jeg har trykket på kode som inneholdt anrop til file_get_contents bare for å finne ut at produksjonsserveren ikke støttet den funksjonen.
Så hvordan går du om å sette opp en oppstartsserver? Vel, det første trinnet er en liten rekognosering.
Problemer skje med alle, spesielt når du har rushed tidsfrister.
Opprette et scenemiljø er spesifikt for produksjonsmiljøet ditt. Det er ingen magisk løsning som fungerer i alle situasjoner. Men de fleste tilfeller følger et lignende mønster, og jeg vil dekke alle de viktigste punktene når vi går.
Det er rettferdig å anta at folk flest distribuerer sine apper med en slags versjonverktøy (som GIT). På den merkelige sjansen at du jobber med et gammelt prosjekt som fortsatt bruker FTP, kan nettsteder som ftploy.com eller deployHQ.com fungere som en buffer mellom GIT og din server. Jeffrey Way satte sammen en informativ video med detaljer om hvordan du satte opp det.
Foruten GIT må du tenke på språkene, programvaren og "spesielle" funksjonene dine. Jeg bruker en PHP-basert PAAS, som heter Fortrabbit, fordi de tilbyr oppdatert PHP, Apache og GIT-støtte. De gir også muligheten til å legge til et søkeord i GIT-commit-meldingen som utløser Komponist for å installere prosjektets avhengigheter.
Dette er systemet jeg vil sette opp i resten av denne artikkelen. Standardfunksjonen, samt den spesielle komponistfunksjonen, gjør Fortrabbit perfekt for et bredt spekter av verter. Bare husk: dette er ikke en magisk løsning, men de involverte trinnene følger det samme mønsteret du vil bruke til å sette opp et scenemiljø for de fleste prosjekter. Skreddersy prosessen til dine spesifikke behov.
Så uten videre, la oss hoppe inn.
Opprette et scenemiljø er spesifikt for produksjonsmiljøet ditt.
Det er mange forskjellige operativsystemer du kan kjøre på en server. Fortrabbit kjører Debian Squeeze på sine servere, og siden vi prøver å matche dem, bestemte jeg meg for å kjøre det også.
Jeg bruker Vagrant å sette opp dette. Ikke bekymre deg hvis du aldri har brukt Vagrant; Vi vil ikke gjøre noe avansert. Pass på at du har VirtualBox og Vagrant installert (Vagrant er en CLI for VirtualBox, så VirtualBox er nødvendig).
Vagrant tar et virtuelt øyeblikksbilde av et operativsystem som en base "boks", og du kan da opprette flere VMer fra det bildet. Så først må vi laste ned basen for Debian Squeeze. Jeg er ikke akkurat sikker på hvor min kopi kommer fra, så jeg lastet den opp til DropBox for at du kan laste ned og bruke. For å installere, åpne et terminalvindu og skriv inn:
vagrant boks legg til debian https://dl.dropbox.com/u/30949096/debian.box
Dette legger til boksen til Vagrant med navnet 'debian'. Vi kan nå opprette en forekomst av denne boksen for vårt oppføringsområde. La oss først lage en ny mappe:
mkdir ~ / staging_server cd ~ / staging_server
Deretter oppretter du Vagrant config filen ved å skrive:
vagrant init debian
Dette skaper en config-fil, kalt "VagrantFile", som inneholder alle innstillingene for din server. Det ser ganske overfylt ut når du åpner det, men de fleste linjene er kommentarer. Du trenger bare å uncomment linjen som sier: config.vm.network: bridged. Hvis du sletter alle andre kommentarer, får du en fil som ser slik ut:
Vagrant :: Config.run do | config | config.vm.box = "debian" config.vm.network: bridged end
Disse alternativene forteller Vagrant å lage en ny virtuell maskin basert på Debian Squeeze-basen. Den setter deretter nettverksmodus til "brodd". En VM med et brokoblet nettverk vises som en ny fysisk maskin til ruteren, slik at den automatisk henter sin egen IP-adresse. Dette gir deg tilgang til maskinen fra en hvilken som helst enhet på nettverket ditt (muligens utenfor nettverket ditt hvis du konfigurerer ruteren).
Nå kan vi starte vår VM med kommandoen: "
vagrant opp"(uten anførselstegn).
Du bør se produksjonen fra Vagrant som lager din VM. Hvis datamaskinen har flere NICer koblet til nettverket, vil Vagrant be deg om å velge NIC for å bygge bro.
Vi bruker SSH til å logge inn, men vi må bruke Vagrant's innebygde "vagrant ssh"kommandoen for å logge inn. I henhold til Vagrant's beste praksis, bør alle bokser ha en bruker som heter" vagrant "med passordet, for både rot og vagrant," vagrant ". Vagrant brukeren er lagt til som en sudo bruker som ikke trenger å skrive inn et passord, slik at du kan bruke direkte sudo kommandoer.
La oss gå videre og sette opp serverens programvare.
Fortrabbits oppsett inkluderer:
I tillegg bruker de dotdeb-depotet til å installere hoveddelen av det. For de ukjente er dotdeb et prosjekt av Guillaume Plessis som installerer de nyeste versjonene av populære webserverpakker.
Vi er klare til å begynne. Kontroller at terminalvinduet ditt er åpent og logget inn på serveren via SSH. Først legger du til dotdeb repo til APT (pakkebehandling) ved å legge til en ny fil til sources.d katalogen:
sudo vim /etc/apt/sources.list.d/dotdeb.list
Dette åpner en ny fil med navnet dotdeb.list i vim (en tekstredigerer). Navnet er ikke viktig fordi alle filene i denne katalogen er lest inn i APT. Vi må legge til fire linjer i denne filen. Hvis du aldri har brukt VIM, skriv bare "Jeg"for å skrive inn innstillingsmodus og kopiere / lime inn de neste fire linjene:
deb http://packages.dotdeb.org klemme alle deb-src http://packages.dotdeb.org klemme alle deb http://packages.dotdeb.org squeeze-php54 alle deb-src http: //packages.dotdeb .org squeeze-php54 alle
For å lagre, trykk på esc nøkkel og type : wq. Det er kommandoen å skrive og avslutte, som i utgangspunktet betyr å lagre og avslutte.
Ved å trykke på enter lagres filen og returnerer deg til kommandolinjen.
Vi har nå lagt til repos, men vi må fortsatt legge til signaturen før vi kan bruke dem. Skriv inn følgende for å legge til GNU-tasten:
krølle http://www.dotdeb.org/dotdeb.gpg | sudo apt-key add -
Dette laster ned dotdeb-nøkkelen og legger den til som en signert kilde. Oppdater nå APT for å trekke inn den nye pakken ved å skrive:
sudo apt-get oppdatering
Dette kan ta et minutt eller så, men du får alle dotdeb-pakkene som er oppført i APT når det er ferdig. På grunn av hvordan dotdeb er installert og hvordan APT-avhengigheter er lastet, kan vi installere Apache og PHP samtidig ved å skrive:
sudo apt-get installer php5
Med denne enkeltlinjen installerer og konfigurerer APT Apache2 og PHP5. Hvis du bruker Fortrabbit's memcache tillegg, kan du installere det med:
sudo apt-get installer memcached
Men jeg kommer ikke til å gå inn i memcache i vårt eksempel i denne artikkelen.
Nå må vi installere utvidelsene som Fortrabbit bruker. Kjør følgende kommando:
sudo apt-get install php5-redd php5-sqlite php5-redis php5-pgsql \ php5-mysqlnd php5-memcache php5-memcached php5-mcrypt php5-imagick php5-http \ php5-gmp php5-gd php5-krøll php5 -apc php5-intl
Det siste vi trenger å installere er Composer. Jeg skal installere den globalt fordi vi vil bruke den på et par forskjellige steder. Kommandoene for å installere Composer globalt er:
krølle-er https://getcomposer.org/installer | php sudo mv composer.phar / usr / local / bin / komponist
Den første kommandoen laster ned og kjører installasjonsprogrammet; Den andre kommandoen flytter Komponist til bin-mappen slik at vi kan bruke den uten å erklære banen. La oss gå videre til konfigurasjonen.
Sjansene er gode at du kan jobbe med mer enn ett prosjekt. Hvis dette er tilfelle, skaper en staging server for hvert prosjekt mye overhead. For å tillate flere nettsteder på en enkelt server, må vi legge til navnebaserte virtuelle verter til Apache, og skal skille kataloger og reposer for hvert prosjekt.
La oss begynne med en virtuell vert.
Jeg skal fortsette å bruke VIM, men vet at hvis du vil jobbe i dine egne programmer, kan du enten kopiere og lime inn eller lagre det i
staging_servermappe du opprettet på datamaskinen din.
Den mappen deles med VM, og du kan få tilgang til filene i vagrant rotkatalogen. Du kan da bruke: sudo cp / vagrant / fil newfile eller sudo mv / vagrant / filee newfile å kopiere eller flytte filene, henholdsvis.
For å opprette en ny virtuell vert, må vi opprette en fil i / etc / apache2 / sites-available / katalogen. For å gjøre dette med VIM skriver du inn følgende:
sudo vim /etc/apache2/sites-available/demo.site
Innvendig, skriv inn følgende (husk trykk "Jeg"for innsettingsmodus):
ServerAdmin [email protected] Servernavn demo.dev DocumentRoot / var / www / demo Alternativer Indekser FollowSymLinks MultiViews AllowOverride ALL Bestilling tillat, nekt tillatelse fra alle ErrorLog $ APACHE_LOG_DIR /demo.log LogLevel feilsøking
Den første linjen erklærer en virtuell vert som lytter etter forespørsler på en hvilken som helst IP i port 80. Deretter angir vi serverens admin email og servernavnet. E-posten er for feilrapporteringsformål, og servernavnet alternativet forteller Apache når du skal lese denne virtuelle verten. Vanlige virtuelle verter fungerer utenfor IP-er. For eksempel lytter hver vhost på en annen IP; Det er slik Apache skiller dem.
Siden du sannsynligvis bare har en IP, kan vi bruke navnebaserte virtuelle verter, slik at du kan gi et annet navn på samme IP.
I vårt eksempel blir eventuelle forespørsler rettet mot demo.dev hentet av denne virtuelle verten.
Neste linje angir dokumentets rotmappe. Det er her Apache henter filer for dette vhost. Erklæringene inne i Directory Direktivet angir tillatelser for denne vhost. Jeg vil ikke gå inn i for mye detalj, men vi angir først Apache-alternativene for katalogene, så vi angir hva som kan overstyres i en .htaccess-fil, og til slutt bestemmer vi hvem som kan få tilgang til nettstedet (alle kan i vårt tilfelle).
De to siste linjene forteller Apache hva du skal navngi loggfilen og hva du skal skrive til loggen. Vår loggfil kalles demo.log i Apache loggmappen som ligger på / Var / log / apache2 / på denne VM.
For å aktivere dette vhost, skriv følgende:
sudo a2ensite demo.site
Dette skaper en symlink mellom filen i den tilgjengelige mappen til en fil i mappen som er aktivert. Etter at du har kjørt denne kommandoen, blir du bedt om å starte Apache på nytt. Du får en feil hvis du prøver å starte Apache på nytt fordi vi ikke har opprettet nettstedets katalog. Dette er lett løst, kjøp å skape demo mappe som vi refererte i vhost-filen:
sudo mkdir / var / www / demo
Vi vil ikke at roten brukeren skal eie mappen, så bytt den til vagrantbrukeren med chown kommando:
sudo chown -R vagrant: vagrant / var / www / demo
Start nå Apache:
sudo service apache2 restart
Vårt nye nettsted skal nå være fullt funksjonelt. Vårt neste skritt er å sette opp GIT.
Pass på at du er i hjemmekatalogen ved å skrive cd ~. Opprett en ny mappe for repo: mkdir demo.git, skriv inn mappen, og initier en ny, bare GIT repo:
cd demo.git git init --bare
En ren repo er i utgangspunktet en standard repo uten arbeidskatalog. Hvis du vil lære mer om GIT, sjekk ut Andrew Burgess videoserie.
Vi trenger nå muligheten til å skape kode til nettstedets mappe, og det er mange måter å oppnå dette på. Men jeg liker å få ting til å se så nært som mulig til tjenesten jeg emulerer. Her er et bilde av fortrabbits git-prosess tatt fra deres nettsted:
Du kan se push-prosessen går gjennom tre trinn. Den viser en oppdateringsmelding når den kobles sammen, og den distribuerer nettstedet til katalogen. Det endelige trinnet installerer alt hvis commit-meldingen inneholder søkeordene "[trigger: composer]". Etter at disse tre trinnene er ferdige, vises du >> >> Alle ferdige <
Før vi lager krokene, vil jeg snakke om farger.
Jeg gjør det meste av arbeidet mitt i terminalen, og oftere enn ikke, lar terminalapparater alt i samme farge. Å legge til forskjellige farger i appen øker ikke bare lesbarheten, men det øker også like-evne. Så også spre "farger" i terminalapps, vil jeg ta et øyeblikk for å diskutere hvordan de fungerer.
Terminaler leveres med seksten ANSI-farger som kan konfigureres og brukes over hele terminalen. Her er et bilde av innstillingsskjermbildet iTerm2, som viser de seksten fargesporene:
Du kan få tilgang til dem i terminalen ved å skrive flyktegn, etterfulgt av den åpne firkantbraketten, og deretter fargenes kode. Du kan se i dette bildet at fargene er delt i to linjer: en merket "Normal" og den andre "Bright". Kodene for de normale fargene er tallene 30-37 etterfulgt av bokstaven "m", og de lyse farger er fra 90-97 igjen etterfulgt av en m. Du kan teste dette i terminalvinduet ditt ved å bruke ekko. For å opprette flyktegn, skriv inn ctrl-v etterfulgt av Ctrl- [. Du får et tegn som ser ut som ^ [, men det vil ikke fungere hvis du bare skriver "^ [" (skift-6 og deretter åpent firkantbrakett). Så i terminalvinduet type:
ekko "^ [[31m Hello World ^ [[0m"
Igjen, den første ^ [ ble ikke skrevet ut, men ble opprettet med ctrl-v og så Ctrl- [. De 0m tegnkode er tilbakestillings-koden; det fjerner all formatering. Dette skyldes at fargekodene ikke slutter etter neste ord, de fortsetter til de mottar en annen kode.
Hvis det gjøres riktig, skriver koden ovenfor ordene "hallo verden" i rødt (med mindre du har sporet satt til en annen farge).
Gjennom resten av opplæringen vil jeg legge til farger på kommandoene. Følg fri til å følge med eller utelate dem; de er ikke strengt påkrevd. Men hvis du vil bruke farger, vær så snill å bruke min fargerassisterende klasse. La oss nå gå tilbake til å skrive krokene.
Hvis du tar en titt på Fortrabbit-bildet, vil du se at det viser meldingen "Trinn 1: Oppdatering av lager" før du oppdaterer repo. For å gjøre dette på riktig måte må vi legge denne meldingen i pre-receive-kroken, som kjøres før repoen er oppdatert. I terminalvinduetype:
vim ~ / demo.git / kroker / pre-mottak
Dette åpner kroken for redigering. Legg til følgende kode:
#! / Usr / bin / php
Den første linjen forteller OS at dette er en PHP-fil og å kjøre den som sådan. Da tilordner vi en farge og reset-sekvensen til variabler. Det siste trinnet ekkos linjen.
Neste krok er litt mer komplisert fordi den håndterer resten av handlingene. Vi tar det trinnvis, så lagre den første kroken (: wq) og åpne den neste kroken:
vim ~ / demo.git / kroker / post-mottak
Etter mottakskroken kjører etter at repoen er oppdatert. Vi må først oppdatere nettstedet og deretter sjekke ut komposisjonstrykkeren. Her er et skjelett av vårt program, og etterlater noen ny logikk:
#! / Usr / bin / php "$". "OK". $ blank. "\ n"; ekko $ gul. "Trinn2: Implementere". $ blank. "\ n"; / * TODO: Distribuere til nettsted * / ekko "->". $ cyan. "OK". $ blank. "\ n"; / * TODO: Sjekk om commit har utløser * / echo $ yellow. ">> Alle ferdige <<" . $blank . "\n"; ?>
Dette er bare en oversikt å jobbe fra. Det første vi må legge inn er funksjonen til å trekke repoens nye versjon inn i nettstedets katalog. Tradisjonelt ville jeg bare skrive følgende hvis jeg var i mappen:
git hente opprinnelse git reset - hard origin / master
Du kan bruke noe som git pull, men det kan føre til feil. Hvis en fil ble endret direkte, eller hvis du savnet en forpliktelse, så git pull Vil heller ikke tillate deg å trekke eller slette dine sporede filer.
Dette er to enkle kommandoer, men du får en feil hvis du prøver å kjøre dem fra kroken.
GIT angir noen miljøvariabler før du kjører krokene. Du kan omgå dette med en av to løsninger, og jeg vil vise dere begge.
Den første er å tilsidesette miljøvariablene, passerer direkte inn info. Den andre fullstendig sletter variablene. Jeg vil bruke det første alternativet i dette eksemplet og det andre alternativet når vi jobber med komponentutløseren. Erstatt kommentaren jeg la til ovenfor der det står "TODO Deploy to site" med følgende:
Accentsconagua
$ git = "git - git-dir = / var / www / demo / .git / --work-tree = / var / www / demo /"; exec ("$ git fetch -q origin"); exec ("$ git reset - hard origin / master"); Dette overstyrer miljøvariablene og kaller de nevnte funksjonene. Den lagt til -q parameter forteller GIT å være "stille", forby GIT å ekko noen meldinger.
Nå må vi sjekke ut komposittutløseren. La oss bryte dette inn i to trinn. Vi kontrollerer først for utløseren, og deretter utfører vi komponist. Erstatt den andre TODO-kommentaren med følgende:
$ msg = exec ("$ git log -n 1 --format = format:% s% b"); hvis (strpos ($ msg, "[trigger: composer]")! == false) echo $ yellow. "Step3: Composer Hook". $ blank. "\ N"; ekko "-> Utløsende installasjon - få en". $ cyan. "kaffe". $ blank. "\ N"; // kjøre komponist ekko "->". $ cyan. "OK". $ blank. "\ N"; Den første linjen henter commit-meldingen ved hjelp av git logg kommandoen og bestått i et spesielt format for å ekskludere ytterligere informasjon. Deretter kontrollerer vi om strengen har det spesielle utløserordet, og ekko det tredje trinnet og OK-meldingen. Vi kontrollerer Composer-søkeordet, men du kan implementere flere søkeord for andre funksjoner som: migrere i Laravel eller kjøre enhetstester. Legg til noe for å forbedre arbeidsflyten din.
Det siste trinnet er å utføre Composer. Komponist har to kommandoer: komponent installasjon og komponistoppdatering.
Installasjonskommandoen leser ikke
composer.jsonfil hvis den finner acomposer.lock, og fordi noen mennesker kan legge tilcomposer.locktil deres .gitignore-fil, er det sikrere å kjørekomponistoppdatering(det ser alltid påcomposer.jsonfil.
Det andre problemet er at noen ganger bruker Composer GIT å laste ned pakker, og disse forsøkene feiler på grunn av miljøvariablene. Så her er et godt sted å bare fjerne "GIT_DIR" miljøvariabelen. Erstatt kommentaren for å kjøre Komponist med følgende:
chdir ( "/ var / www / demo"); putenv ( "GIT_DIR"); exec ("komponistoppdatering"); Denne koden er rett fram. Vi flytter PHP-prosessen til nettstedets mappe, og fjern deretter GIT_DIR miljøvariabel slik at GIT fungerer normalt. Den siste linjen utfører Komponist.
Vi har nå begge krokoppsett, men vi er ikke helt klar til å begynne å bruke vår server. Først må vi gjøre disse krokene kjørbare:
chmod a + x ~ / demo.git / kroker / pre-receive chmod a + x ~ / demo.git / kroker / post-mottak
Deretter oppretter du en GIT-repo i nettstedets mappe. Vi vil få en feil hvis vi prøver å kjøre våre kroker fordi nettstedets mappe ikke er en GIT-repo. For å fikse denne typen:
cd / var / www / demo git init git fjernkontroll legg til opprinnelse /home/vagrant/demo.git
De to første linjene skaper repo, og så legger vi til det barne repository som denne repoens opprinnelse.
Du bør også legge til din offentlige nøkkel til denne serverens autoriserte verter, slik at du kan få tilgang til serveren via GIT uten et passord. Du kan kopiere din offentlige nøkkel ved å skrive på datamaskinen din (ikke VM):
katt ~ / .ssh / id_rsa.pub | pbcopy
Deretter limer du bare inn på serveren i filen ~ / .Ssh / authorized_keys:
vim ~ / .ssh / authorized_keys
Bare legg det til filen, men legg det som allerede er inne.
Deretter må vi legge til IP for denne serveren til vertsfilen vår. For å finne IP, skriv:
ip -4 -o addr vis etikett et *
Dette viser deg IP-adressen til alle nettverksenhetene på denne VM. Legg til den som kobles til ditt lokale nettverk. Hvis du ikke kan bestemme hvilken IP-adresse som skal brukes, kopier og lim inn en i nettleseren din. Hvis den kobles til, har du den riktige IP-adressen.
Ta IP og legg den til datamaskinens vertsfil (ikke VMs vertsfil). Vertsfilen på en Mac er plassert på etc / hosts:
sudo vim / etc / hosts
Deretter legger du til følgende linje:
#Format: IP_address site_name 192.168.0.110 demo.dev
Hvis dette virker, vil du kunne navigere til http://demo.dev i nettleseren din. Mens du fortsatt er på Mac, lager du en mappe og starter en GIT-repo:
mkdir ~ / demo cd ~ / demo git init echo "Hello World"> index.php git add. git commit -am "added index.php" git ekstern legg til staging [email protected]: demo.git git push staging master
Hvis alt gikk bra, bør du se et svar fra våre GIT-kroker. Naviger til http://demo.dev bør resultere i "Hello World" meldingen som vises i nettleseren din.
Så det er hvordan du kan lage et scenemiljø som etterligner funksjonaliteten til en typisk PAAS. Hvis du hadde problemer med å følge med, eller du må sette opp flere scenemiljøer, opprettet jeg et skript som automatiserer prosessen fullstendig. For mer informasjon, kan du besøke stagr.gmanricks.com.
Jeg håper du likte artikkelen. Ta gjerne spørsmål som du kanskje har i kommentarene. Takk for at du leser.
