DroidTV MX Android 4.2.2 Dual core XBMC. Google TV, G-Box Midnight MX2, Apple TV 2,3 paaudze

Tā ir PHP lietotne. Kā es varu samazināt dīkstāvi, atjauninot visu koda bāzi?

Tas, ko mēs parasti darām darbā, ir:

  • pirms mēs atjauninām, servera dokumenta sakne ir:
    • iekšā /www/app-2009-09-01
    • bet tam piekļūst, izmantojot simbolisku saiti, ko sauc /www/application
  • mēs ievietojām visu jauno kodu bāzi /www/app-2009-09-08
  • kad visa kodu bāze ir tur:
    • mēs noņemam veco simbolisko saiti
    • mēs izveidojam jaunu simbolisku saiti, ko joprojām sauc /www/application, bet kas norāda uz jaunajiem avotiem: /www/app-2009-09-08
  • mēs pārlādējam apache, lai piespiestu modifikāciju ņemt vērā.

Viss šis process tiek veikts, izmantojot automātisko skriptu (vienīgā neautomātiskā lieta ir tā, ka mēs to palaižam, kad nepieciešams). Tas nozīmē :

  • Viss notiek ātri (īpaši simboliskās saites pārslēgšana, kas ir svarīga daļa)
  • Nav kļūdu riska: skripts ir labi pārbaudīts un darbojas mēnešus / gadus


Vēl viena šīs simboliskās saites priekšrocības priekšrocība ir tā, ka ir ļoti viegli atjaunināt atjauninājumu, ja katastrofisku kļūdu pamanām tikai pēc jaunās avotu versijas ieviešanas ražošanā: mums vienkārši jāpārslēdz simboliskās saites.

Protams, tas neliedz jums pārbaudīt jauno versiju savā inscenēšanas serverī, pirms to nodod ražošanai, bet, kas zina ... Dažreiz ir patiešām liela kļūda, kuru neviens nav spējis redzēt, kamēr testēšana :-(
Piemēram, tāpēc, ka inscenēšanas mašīnā regulāri netiek veikta slodzes pārbaude.
(Esmu redzējis, ka "atcelšanas" lieta 3 gadu laikā ir izmantota kaut kā 4 vai 5 reizes - katru reizi tas ietaupa dienu - un vietnes ^^)


Šeit ir sava veida ātrs piemērs: pieņemsim, ka man Apache konfigurācijā ir šis VirtualHost:

 ServerName example.com DocumentRoot /www/application  # Whatever you might need here (this example is copy-pasted from a test server and test application ^^ ) Options Indexes FollowSymLinks MultiViews +SymLinksIfOwnerMatch AllowOverride All php_value error_reporting 6135 php_value short_open_tag on   

Diezgan "standarts" ... Vienīgais ir /www/application nav īsts katalogs: tā ir tikai simboliska saite uz pašreizējo avotu versiju.
Tas nozīmē, ka tad, kad avotus esat ievietojis serverī, bet vēl neesat pārslēdzis, jums būs kaut kas līdzīgs šim:

[email protected]:/www # ll total 8 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08 lrwxrwxrwx 1 root root 19 2009-09-08 22:08 application -> /www/app-2009-09-01 

Ievērojiet, ka simlins norāda uz "veco versiju"

Tagad, kad jaunā versija ir pilnībā augšupielādēta serverī, pārslēdzamies:

[email protected]:/www # rm /www/application [email protected]:/www # ln -s /www/app-2009-09-08 /www/application 

Un tagad /www/application norāda uz jauno avotu versiju:

[email protected]:/www # ll total 8 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01 drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08 lrwxrwxrwx 1 root root 19 2009-09-08 22:09 application -> /www/app-2009-09-08 

Un mums vienkārši jāpārstartē Apache:

[email protected]:/www # /etc/init.d/apache2 restart * Restarting web server apache2 

Trīs soļi "noņemt saiti; izveidot jauno saiti; restartējiet apache"jāizveido ātri, ti, ar automatizētu skriptu, nevis ar cilvēku.

Izmantojot šo risinājumu:

  • varat aizņemt tik daudz laika, cik nepieciešams, lai augšupielādētu jauno avotu versiju: ​​Apache tos neizmantos, kamēr simbols nav mainīts
  • kad viss ir kārtībā, vienkārši pārslēdziet symlink: tas notiks ātrāk nekā mainot pat 1 vai 2 failus ... Tas nozīmē, ka praktiski nav dīkstāves :-)

Un, ja lietoju kādu opcode-kešatmiņu, piemēram, APC, ar stat opciju 0, es domāju, tas var nozīmēt vēl mazāku dīkstāves risku.


Protams, šī ir "vienkāršā" versija - piemēram, ja jums ir daži augšupielādēti faili, jums kaut kur būs jāizmanto cita saite vai cits VirtualHost vai kāds cits ...


Ceru, ka tas ir skaidrāk :-)

  • Arī tas ir sava veida serveru nomaiņa. :-)
  • mod_rewrite, lai pārvaldītu simboliskās saites?
  • @gAMBOOKa: nē: jautājums ir tikai par Apache's DocumentRoot (vai VirtualHost DocumentRoot), kas ir / www / application ;; ti, simboliskā saite - neatkarīgi no tā, kur šis norāda.
  • 2 drausmīga atbilde. Tomēr vēl viens padoms: jūs varat likt simboliskajai saitei notikt, to neatsaistot. Kā citēts: "Trīs darbības… jāveic ātri, ti, ar automatizētu skriptu, nevis ar cilvēku." Mv komanda ir atomu darbība, tāpēc varat izveidot simlink, piemēram, 'ln -s / www / app-2011-01-28 / www / application-temp' un pēc tam veikt 'mv -T / www / application-temp / www / pieteikums ”.
  • 1 Ir kaut kas, uz ko neattiecas symlink metode. Jūsu veids darbojas ar Apache + mod_php, taču tas var neizdoties, izmantojot lighttpd + fastcgi. Vietnē ar lielu datplūsmu pieprasījums tiks pasniegts saites maiņas vidū, ja php koda atkarība neizdosies ar jauktu versiju.

Vai nevarat paņemt esošo kodu un migrēt projektu atsevišķā testa php failā un izmantot to atjaunināšanas laikā? Es domāju, ka jums vajadzētu būt testa serverim un ražošanas serverim, lai, veicot atjaunināšanu, nerastos dīkstāves.

Iestatiet otro serveri ar atjaunināto koda bāzi un pēc iespējas ātrāk pārslēdziet tos. :-)

Ja tas nav iespējams, pārliecinieties, vai koda bāze ir sadalīta desmitos mazāku daļu. Tad dīkstāve vienlaikus būtu ierobežota tikai ar vienu apakšnodaļu. Mazākos koda blokus ir vieglāk nomainīt, un lielākā daļa to turpinās darboties bez problēmām. Tomēr vispirms izmēģiniet to testa vidē!

  • Tā kā lietotne nav testēta ar sadrumstalotiem moduļiem, tā var izraisīt neparedzētus scenārijus.
  • Tas nozīmē, ka pēc šī atjauninājuma tas būs jūsu uzdevumu sarakstā. :-) Padariet to modulārāku, un jūs varat atjaunināt katrā modulī.
  • 1 Tas ir ToDo sarakstā, bet ir ilgtermiņa mērķis. Mēs esam jauns jaunuzņēmums, tāpēc organizācija izstrādātāju komandā dabiski prasīs kādu laiku. = D

Pirmkārt, es bieži izmantoju metodi, kas ir līdzīga Pascal MARTIN atbildei.

Vēl viena metode, kas man arī patīk, ir izmantot manu SCM, lai ievadītu jaunu kodu. Precīzs process ir atkarīgs no jūsu SCM veida (git vs svn vs ...). Ja jūs izmantojat svn, man patīk izveidot filiāli “tiešsaistē” vai “ražošanas”, kuru es izrakstos kā dokumenta sakni serverī. Pēc tam, kad es vēlos nospiest jaunu kodu no citas filiāles / tag / bagāžnieka, es vienkārši piešķiru jauno kodu filiālei "online" un palaižu svn update dokumenta saknē. Tas ļauj veikt ļoti vienkāršas atkāpšanās, jo ir pilnīgs pārskatīšanas žurnāls par to, kas serverim ir bijis augšup / lejup, un kas to izdarīja un kad. Jūs varat arī viegli palaist šo "tiešsaistes" filiāli testa lodziņā, ļaujot veterinārārstēt lietotni, kuru grasāties virzīt.

Process ir līdzīgs git un citiem SCM stiliem, tikai pārveidots, lai būtu dabiskāks viņu darba plūsmas stilam.

Vai vēlaties uzzināt / aptaujāt, nevis virzīt atjauninājumus? Vienkārši izmantojiet cron darbu vai citu, gudrāku mehānismu, kas automātiski izpilda svn atjauninājumu.

Papildus: Varat arī izmantot šo procesu, lai dublētu failus, kurus lietojumprogramma ir ierakstījusi diskā. Vienkārši veiciet cron darbu vai kādu citu mehānismu, kas darbojas svn. Tagad jūsu izveidotās lietojumprogrammas faili tiek dublēti jūsu SCM, pārskatītajā žurnālā utt. (Piemēram, ja lietotājs atjaunina failu diskā, bet vēlas, lai jūs to atjaunotu, vienkārši nospiediet veco versiju).

Es izmantoju līdzīgu pieeju arī Pascal MARTIN. Bet tā vietā, lai produkcijas serverī augšupielādētu vairākas manas lietotnes versijas, es glabāju "būvējumus" aiz sava ugunsmūra, katru no tiem atsevišķā direktorijā ar uzbūves numuru un datumu. Kad es vēlos augšupielādēt jaunu versiju, es izmantoju vienkāršu skriptu, kas ietver "rsync -avh --delay-updates". Karodziņš "delay = updates" augšupielādēs visu (tas ir atšķirīgi) pagaidu mapē, līdz visi atjauninājumi būs pieejami, un pēc tam pārsūtīšanas beigās visu uzreiz pārvietos uz to pareizajiem ceļiem, lai lietotne nekad neatrastos pa pusei vecs-pa pusei jauns štats. Tam ir tāds pats efekts kā iepriekš aprakstītajai metodei, izņemot to, ka ražošanas vietnē es glabāju tikai vienu lietotnes versiju (vislabāk, ja ražošanas serverī, SJO, ir tikai tikai nepieciešamie faili).

strādāja par jums: Charles Robertson | Vēlies ar mums sazināties?