Nginx

Websivut ovat webpalvelimessa. Niitä on olemassa useampikin, mutta kaksi suurinta ovat Apache2 ja Nginx. Apache2 on minusta helpompi, mutta koska nyt on tarkoitus saada maailmalle näkyville mahdollisimman nopea WordPress-sivusto, niin asennetaan toiseksi suosituin eli Nginx.

Syy on se, että Nginx tarjoaa välimuistin, cachen, mutta Apache2 ei. Apachen kanssa, kuin myös Nginxin, saadaan erillinen cache tekemään tismalleen saman kuin mitä Nginx tekee, ja tehokkaamminkin, mutta se on hankalampi ylläpidettävä. Siksi jätetään moinen väliin. Mutta jos asia kiinnostaa, niin asennusohjeet systeemille, jossa on ensimmäisenä Nginx ottamassa tulijat vastaan, sitten on Varnish hoitamassa cachen ja viimeisenä Apache2 huolehtimassa web-sivustoista, löytyy täältä.

Nginx asennetaan komennolla, jonka muoto tulee hyvin nopeasti tutuksi:

apt install nginx

Olisi mukavaa, että Nginx käynnistyisi itsestään, jos/kun serveri joudutaan buuttaamaan. Se onnistuu tällä:

systemctl enable nginx

Tuota ei tarvitse enää antaa toiste (paitsi jos joskus komennat systemctl disable nginx, mutta kun olet tuolla asti, niin tiedät asian muutenkin).

Nginxillä on asetettuna eräänlainen oletusdomain. Sitä voisi periaatteessa käyttää pohjana, jos serverillä on käytössä vain yksi domain, mutta se ei ole ihan fiksu systeemi. Parempi tehdä kaikki selvästi per domain, niin tietää myöhemminkin mitä on missäkin. Joten otetaan se pois käytöstä:

unlink /etc/nginx/sites-enabled/default

Käytännössä aina kun jotain asennetaan, niin se toimii sellaisenaan oletusarvoilla, ainakin periaatteessa – tai sitten se ei toimi ollenkaan ilman erityisiä säätöjä. Kun oletusarvot riittävät, niin ne ovat yleensä huomattavan tiukat, jopa kireät. Niin kireät, että niitä ei voi käyttää ns. tuotantokäytössä, eli kun ihmiset pääsevät sivustoillesi. Nginx ei ole poikkeus tässä, joten sitä on hieman säädettävä.

Nyt sinulla on kaksi vaihtoehtoa, oikaista tai tehdä itse.

Siirrytään sitä ennen Nginxin hakemistoon, niin ei tarvitse antaa polkua joka kerta erikseen:

cd /etc/nginx

Nano

Ennenkuin tehdään mitään, niin tehdään pikasukellus Nanon maailmaan. Älä huoli, kohta näet mistä on kyse.

Nano on ehkä helpoimmasta päästä linuxien editoreista. Toki siitä puuttuu toiminnallisuuksia, joita isot pojat arvostavat, mutta tavallinen ylläpitäjä ei niitä toiminnallisuuksia oikeastaan koskaan tarvitse. Nano riittää mainiosti.

Joudut liikkumaan tekstissä kursorilla. Alareunassa näkyviin pikakomentoihin pääset control-näppäimen avulla, eli hakutoiminto (Where Is) onnistuu näppäinyhdistelmällä ctrl-W.

Kun olet valmis, niin paina ctrl-X, joka sulkee editorin. Sinulta kysytään haluatko tallentaa tiedoston.

Save modified buffer?

Siihen kannattaa vastata y (yes) eli kyllä. Jos vastaa n (no) eli ei, niin muokkaukset hukataan.

Jos vastasit kyllä, niin sinulta kysytään kysytään mille nimelle tallennetaan. Esimerkiksi:

File Name to Write: /etc/nginx/nginx.conf 

Jos olet nimeen tyytyväinen, kuten olettaa saattaa, niin paina pelkästään enter. Nimen voi muuttaa, ja koska nimeen kuuluu myös polku, niin voit jopa vaihtaa samalla lennossa tiedoston tallennuspaikan. Jos sinulle tuleekin mieleen, että piti jotain muutakin tehdä tekstille, niin pääset keskeyttämään tallentamisen näppäinyhdistelmällä ctrl-C.

Puolipiste; ja #risuaita

Todella usein linuxmaailman asioissa rivit päätetään puolipisteeseen. Ne ovat erittäin tärkeitä. Jos sen unohtaa, niin ohjelma kaatuu. Joskus virheilmoitus johtaa suoraan oikeaan paikkaan, joskus sitten ihan muualle.

Risuaita, tai hash, on kommentoinnin merkki. Silloin se rivi ei ole käytössä. Usein ohjeissa sanotaan, että kun joku halutaan päälle, niin poistetaan kommentointi. Tai jos sama asia halutaan pois päältä, niin se kommentoidaan.

Jotta kommentointikaan ei olisi liian helppo asia, niin välillä se on kaksi kauttaviivaa: //. Ja jotta asia menisi vielä sekavammaksi, niin välillä jopa puolipiste ; on kommentoinnin merkki – mutta silloin sitä ei käytetä rivin päättävänä merkkinä.

Yleensä käytetään risuaitaa. Mutta aika usein se onkin kaksi kauttaviivaa. Joskus voi käyttää molempia. En ole koskaan oppinut logiikkaa sille kumpaa kuuluu käyttää. Noudatan yleensä aina sitä mitä on tiedostossa käytetty – välillä asiat ei toimi, jos käyttää väärää tapaa kommentoida.

Backuppien palauttaminen

Useassakin kohdassa tehdään alkuperäisestä backup-kopio. Jos jossain vaiheessa haluat palauttaa varmuuskopion, niin se onnistuu helposti parilla kopiolla. Komennot ovat itseasiassa samat kuin millä backup aikoinaan luotiin, mutta päinvastaisessa järjestyksessä. Käytän esimerkkinä tiedostoa nginx.conf, mutta sama toimii kaikilla – muutat vain polun ja tiedostonimen oikeiksi.

Poistetaan varsinainen tiedosto. Tarkista aina polku ja tiedosto kahteen tai kolmeen kertaan. Poisto ei varmistele mitään ja kun olet painanut enteria. niin se oli siinä.

rm -f /etc/nginx/nginx.conf

Palautetaan varmuuskopio, ja jätetään se edelleen koskemattomaksi:

cp /etc/nginx/nginx.conf.backup /etc/nginx/naginx.conf

nginx.conf

Tähän tullaan pyrkimään:

Asetusten muokkaaminen

Kopioidaan Nginxin asetukset valmiista mallista, joten siirretään alkuperäinen syrjään. Muutetaan nginx.conf tiedoston nimi .backup -loppuiseksi:

mv nginx.conf nginx.conf.backup

Tehdään uusi nginx.conf aloittamalla sellaisen kirjoittaminen Nanolla:

nano nginx.conf

Maalaa ja kopioi ylläoleva koodi ihan normaalisti hiirellä.

Siirry terminaaliin ja klikkaa hiiren oikeaa korvaa Nanon ikkunassa. Kopioimasi koodi liitetään luomaasi tiedostoon.

Anna ctrl-X, y ja enter – loit ja tallensit uuden nginx.conf tiedoston.

Mitä tehtiin?

Nginxille annettiin serverin tekniikan rajoissa enemmän resursseja käyttöön. Itseasiassa niin paljon kuin sille voidaan antaa. Ei sitä voi pitää vajaakäytöllä, koska silloin webbipalvelin alkaa hidastelemaan jo muutaman samanaikaisen kävijän myötä.

Lisäksi päätettiin, että se ei saa kertoa kyselijöille versiotaan; pieni turvallisuusjuttu.

Nginxille annettiin hieman enemmän muistia pitää sivustojen nimiä muistissaan.

Annettiin sivustoille lupa siirtää maksimissaan 64 MB tiedostoja (Oletko törmännyt WordPressin 2 megan rajoitukseen? Se periaatteessa korjattiin nyt).

Otettiin käyttöön nettiliikenteessä gzip-pakkaus, joka nopeuttaa jonkun verrankin sivujen siirtymistä sinulta käyttäjälle.

Ei kerrota mitään sellaisille kyselijöille, jotka yrittävät löytää serveriltä domainin, jota ei ole. Tuo ei vaikuta ihmisiin, mutta botteihin kylläkin.

Muutokset käyttöön

Nyt muutettiin Nginxin asetuksia, mutta ne eivät ole vielä käytössä. Muutokset täytyy kertoa Nginxille.

Sitä ennen opetellaan yksi komento, joka on pakko opetella ulkoa, vaikka sitä ei tulevaisuudessa niin usein ehkä tarvitsekaan. Tarkistetaan, että ei tehty kirjoitusvirheitä ja muutokset ovat oikeissa paikoissa – se, että ovatko muutokset fiksuja ja tekevätkö ne haluttuja asioita, on aivan toinen juttu.

Nginxin syntaksi tarkistetaan näin:

nginx -t

Sinun täytyy saada vastaukseksi:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Jos saat jotain muuta, niin asia täytyy korjata. Jos vaikka unohtaa yhden puolipisteen:

nginx: [emerg] invalid number of arguments in "client_max_body_size" directive in /etc/nginx/nginx.conf:26
nginx: configuration file /etc/nginx/nginx.conf test failed

Tämä virhe oli mukava. Se kertoo suoraan, että tiedostossa nginx.conf rivillä 26 olevassa komennossa client_max_body_size on jotain pielessä. Koska olin unohtanut rivin päättävän puolipisteen, niin Nginx luuli, että yritin tarjota seuraava riviä client_max_body_size määrittelyksi. Puolipiste rivin loppuun sekä tallennus ja nginx -t näyttää vihreää valoa.

Valitettavasti ihan aina virheet eivät löydy näin helposti, vaan luultu virhe voi olla aika kaukanakin aidosta virheestä. Mutta yleensä on hyvä aloittaa virheen metsästys juuri siitä muutoksesta, joka tuli juuri tehtyä.

Jos en olisi antanut komentoa nginx -t, vaan yrittänyt käynnistää Nginxin suoraan, niin se olisi kaatunut virhetilanteeseen ja sinä aikana kukaan ei olisi päässyt sivustoille. Joten muista aina nginx -t kun olet muuttanut mitään, joka liittyy Nginxin toimintaan eli tehdään hakemistoon /etc/nginx.

Otetaan muutokset käyttöön:

systemctl restart nginx

Hypätään hieman asioiden edelle, mutta ei tule myöhemmin niin suurena yllätyksenä vastaan.

• Kun muutetaan Nginxin toimintaa, niin käynnistetään uudestaan komennolla restart
• Kun muutetaan sivustoihin liittyviä asioita (puhutaan virtual hosteista eli niistä domaineista), niin ne ladataan Nginxille komennolla reload

Tuossa on pieni aste-ero. Restart ensin pysäyttää ja sitten käynnistää. Kävijät näkevät sen erittäin lyhyenä hidasteluna, mutta silloin hukataan mm. Nginxille tehdyt välimuistit. Reload ei keskeytä Ngixin toimintaan, vaan muutokset tehdään lennossa.

Palataan jatkoa varten takaisin serverin juureen, niin komentokehoite on siistimpi:

cd /