Domain

Tarvitset domainin. Jos sinulla ei vielä ole sopivaa, tai tarvitset uuden, niin niitä myyvät käytännössä jokainen webhotelleja tarjoava palvelu. Itse käytän Name.con palvelua. Ulkolainen toki, mutta helppo, nopea, kohtuullisen edullinen ja siellä on sellaisiakin päätteitä, joita kotimaiset eivät kauppaa. Käy vilkaisemassa. Tässä on referral-linkki Name.com sivustolle: https://www.name.com/referral/337a07

Name.com harrastaa sisäänvetona alennusmyyntejä. Parhaimmillaan saat ostettua parilla eurolla domainin ensimmäiseksi vuodeksi ja ylipäätään jonkun saa aina luokkaa vitonen. Tarkoittaa sitä, että testejä varten kannattaa ostaa erillinen domain, koska puhutaan kahvirahoista. Jos et erikseen salli uusimista, niin domain vanhenee vuoden kuluttua. Jos haluat pitää sen, niin maksat lisää. Ei se sen kummallisempaa ole.

He haluavat myydä erilaisia lisäpaketteja kassalla. Älä suotta tuhlaa niihin rahaa, ellet koe ehdottomasti tarvitsevasi. Minä en ole koskaan tarvinnut. Myös se ”suojapaketti”, jonka he haluavat aina myydä kylkiäisinä, kannattaa poistaa kassalla.

Serveri

Lisäksi tarvitset virtuaaliserverin. Pelkkä domain ei vielä tee mitään. Olen mennyt tarjontaa läpi ja järkevimmän hinta/laatu-suhteen tarjoaa Hetzner.

Teksti on vanhaa perua, joten hintatiedot ja muut eivät pidä enää paikkaansa. Lisäksi DigitalOceanin houkuttelevuutta vähentää rutkasti se, että he ovat rampauttaneet uloslähtevät mailit melkoisen tehokkaasti. Hetzner on edullisempi, toimivampi ja lisäksi eurooppalainen. En kuitenkaan vaivaudu muuttamaan koko tekstiä.

On hieman makuasia minkä kokoluokan palikan itselleen ostaa. Halvin maksaa 5 dollaria kuussa ja sillä pyörittää yhtä ei-niin-suosittua blogia tai hiljaisempaa verkkokauppaa. Se on tehty oikeastaan vain kokeilua varten, mutta siitä voi toki lähteä liikkeelle. Kun tarvitsee enemmän tehoja ja tilaa, niin suurentaminen on yhden klikkauksen takana.

Silti uskaltaisin väittää, että 20 dollaria kuussa maksava droplet (DigitalOceanin nimi virtuaalipalvelimelle) on ensimmäinen järkevä hankinta. Itse pyöritän puolen tusinaa WordPressiä, paria verkkokauppaa ja Moodlen verkkokoulutusohjelmistoa 40 taalan paketilla ja se riittää mainiosti noin 10 000 kävijälle päivässä.

Monet suuntaavat halvimpaan versioon, koska ovat epävarmoja. Minä sanoisin, että koska maksetaan vain käytetyistä päivistä, niin kannattaa aloittaa heti oikeammaksi mitoitetulla dropletilla. Jos (oikeammin, kun) se jää, niin käytössä on heti riittävän vahva työkalu. Jos viikon tai kahden jälkeen toteaa, että oman serverin pyörittäminen ei olekaan sitä mitä haluaa, niin rahaa on mennyt vain yhden hampurilaisaterian verran – ei se iso tappio ole.

Luo DigitalOceanille tili ja vilkaise hieman miltä hallinta näyttää. Pääset alkuun tällä referral-linkillä, niin itseasiassa ensimmäinen kuukausi ei paljoa maksa: https://m.do.co/c/1a52415150cf

Dropletin luominen

Klikkaa vihreää nappulaa tekstillä Create ja valitse Droplet.

• Choose an image: Ubuntu 20.04 (LTS) x64
• Choose a plan: Standard
• Minä suosittaisin ottamaan 20 tai 40 USD kuussa maksavan

• Add block storage: –
• Choose a datacenter region: Frankfurt (kannattaa ottaa suurinta osaa kävijöitä lähimpänä oleva)
• Select additional options: Monitoring 

• Authentication: Password (luot root-tunnuksen salasanan kohdassa Create root password)
• How many droplets: 1
• Choose a host name: anna joku sinulle selvä ja lyhyt (se näkyy shellin komentokehotteessa; ennen sillä oli enemmän merkitystä, mutta ei nykyään kun omaa sähköpostipalvelinta ei voi eikä kannata käyttää)
• Add tag/Select project: Jätä tyhjäksi
• Enable backups hieman riippuu. Itse en ota. Se tekee koko serveristä levykuvan kerran viikossa ja siitä on hyötyä ainoastaan täydellisessä katastrofissa. Ehkä kokeiluvaiheessa kannattaa ottaa, koska sen voi lopettaa koska haluaa.

• Create droplet tekee virtuaaliserverisi

Dropletin luomiseen menee minuutti tai kaksi. Se on valmis käytettäväksi, kun IP-osoite ilmestyy DigitalOceanin hallintaan Saat tiedon myös sähköpostiisi.

Nyt sinulla on oma virtuaaliserveri. Joka on suunnilleen yhtä hyödyllinen kuin kotitietokone ilman Windowsia tai Mac ilman OsX:ää. Kyllä, vertailu oli huono, koska dropletissa on käyttöjärjestelmä, Ubuntu. mutta sillä ei sinällään tee paljoakaan. Ainakaan se ei tuollaisenaan pysty tarjoamaan nettisivuja.

Nyt alkaa varsinainen asennustyö.

SSH ja terminaali

Virtuaaliserveriä ei hallita graafisesti kuten vaikka Windowsia. Sille ei ole myöskään mitään sellaista liittymää kuin webhotellien cPanel. Kaikki tehdään komentoriviltä. Ja se on se mikä suurinta osaa ihmisiä pelottaa.

Itseasiassa ei se ole niin hankalaa kuin miltä saattaa tuntua. Plus että suurin osa kuitenkin tehdään kopypeistaamalla.

Jos sinulla on käytössä PuTTY (sorry mac-ihmiset, en tiedä teidän maailmastanne, mutta vastaavat sieltä löytyvät), niin se on se työkalu mitä kaipaat. Jos et tiedä yhtään mistä puhutaan, niin vilkaise tämä juttu.

Sinun ei kuitenkaan tarvitse heti alkaa riitelemään PuTTYn kanssa, vaan alkuun pääsee Windowsin omalla komentokehoitteella. Löydät sen käynnistysvalikosta Windows-järjestelmä takaa. Jos törmäät sellaiseen kuin PowerShell, niin sekin kelpaa mainiosti.

PuTTY kannattaa kuitenkin asentaa jossain vaiheessa. Ihan siksi, että luultavasti kyllästyt antamaan salasanan joka kerta kirjautuessasi ja voidaksesi kirjautua suoraan ilman salasanoja, niin silloin tarvitset SSH:ta – joka ei Windowsin komentokehotteelta luonnistu. Lisäksi jossain vaiheessa voi haluta jopa kaksi ikkunaa auki yhtä aikaa, ja siinäkin PuTTY on näppärä.

Jos/kun törmäät teksteissä termiin terminaali, niin aina näistä samoista on puhe.

Klikkaa Komentokehote auki.

Anna komento:

ssh root@dropletin-ip-osoite

Sinulta kysytään (englanniksi), että kun kyseessä on ihan uusi tuttavuus, niin voidaanko tähän luottaa. Vastaa siihen kirjoittamalla yes.

Pääset kirjautumaan.

• Sinulta ei kysytä käyttäjätunnusta, koska kerroit SSH-komennossa, että se on root
• Salasana on se, jonka keksit dropletia luodessa

Pääset sisään ja sinulle aukeaa tämänkaltainen näkymä:

Yksi pieni käytännön vinkki: kopioi ja liimaa, copypaste, ei toimi kuten luultavasti haluaisit.

Useimmiten (Windowseista tuttu) ctrl-V ei toimi. Vielä vähemmän se onnistuu, jos olet tottunut tekemään työt hiiren pikavalikon kautta. Jos sinulla on kopioitua tekstiä, vaikka joku esimerkin kopio, niin siinä liimaaminen onnistuu hiirellä – yleensä klikkaamalla hiiren oikeaa korvaa, jolloin liitettävä teksti ilmestyy siihen missä kursori on. Tuohon kestää hetki tottua, mutta kun toiminto alkaa olla arkipäivää, niin se ei itseasiassa ole hassumpi tapa ollenkaan.

Sen sijaan hiirellä maalaaminen ja sitten kopiointi, ctrl-C, toimii ihan normaalisti – mutta ei taaskaan hiiren pikavalikolla.

Järjestelmän päivittäminen

Paitsi että kirjautumisikkuna kertoo hieman teknisiä detaljeja, niin se kertoo myös, että Linux – tässä Ubuntu – ei eroa mitenkään muista tietolaitteista yhdessä oleellisessa asiassa: uuden laitteen käyttöönotto aloitetaan aina päivittämällä.

Joten nyt opetellaan kaksi peruskomentoa. Opit nämä äkkiä, sillä niitä käytetään niin usein.

Anna komento:

apt update

Se tarkistaa Ubuntun pakettiluottelon, joka on ikäänkuin kirjasto niistä ohjemista, jotka voidaan asentaa suoraan. Samalla katsotaan mille kaikille jo asennetuille on tullut ajankohtainen päivitys. Vaikka päivityksiä ei ihan joka hetki olisikaan tarkistamassa, niin aina kun näet, että on tullut security updates, niin teet päivityksen – et vitkuttele, vaan se on ensimmäinen asia, jonka teet.

Nyt tiedetään mitkä päivitykset tehdään. Joten tehdään ne ja se tapahtuu tällä komennolla:

apt dist-upgrade

Sinulle kerrotaan mitä ollaan asentamassa ja paljonko ne vievät tilaa. Hyväksy se enteriä napauttamalla. Aina kun sinulle tarjotaan vaihtoehtoa, kuten Y/n – kyllä tai ei – niin se mikä on isolla, tapahtuu ihan vaan enterillä eli se on oletuksena. Jos leikitään, että olisitkin halunnut keskeyttää, niin silloin olisit joutunut kirjoittamaan n.

Kiirehdin hieman asioiden edelle, mutta jätä tämä kypsymään takaraivoon. Jossain vaiheessa saatat päivityksen aikana törmätä ilmoitukseen, jossa kehoitetaan ajamaan apt auto-remove. Se tarkoittaa sitä, että joku päivitys tai ohjelman asennus on tehnyt osasta tiedostoja tarpeettomia ja Ubuntu haluaisi poistaa ne. Koska ne ovat turhia, niin komento kannattaa ajaa. Jos et sitä tee, niin mikään ei mene rikki. Ne vain vievät turhaa tilaa.

Tiedän, että tuo päivitys haluaa uudelleenkäynnistyksen. Windows kysyy aina heti, että uudelleenkäynnistetäänkö nyt heti vai vasta huomenna juuri kun sinulla on jotain kiireellistä tekemistä. Ubuntu ei buuttitarpeesta pukahda halaistua sanaakaan. Se kerrotaan sinulle vasta kun seuraavan kerran kirjaudut sisälle.

Ei odotella siihen asti, vaan hoidetaan asia pois päiväjärjestyksestä. Komenna:

reboot

Terminaaliyhteytesi katkaistiin. Käynnistyminen kestää yleensä vain joitain sekunteja, joten voit yrittää kirjautua uudestaan:

ssh root@dropletin-ip-osoite

Ubuntun asettaminen

Tässä vaiheessa jokainen ohje haluaa sinun tekevän uuden käyttäjän, jolla ei ole suoraan root-oikeuksia. Niin kauan kun sinä olet ainoa serverin käyttäjä, niin tuolla ei ole mitään merkitystä. Joten jatketaan root-tunnuksella – ja palaa takaisin vaikka EksisONEn serverisarjaan, jos myöhemmässä vaiheessa haluat moisen tehdä, Nyt se vain  sotkee asioita.

Kello kannattaa laittaa aikaan ja se tehdään aikavyöhykkeen avulla:

timedatectl set-timezone Europe/Helsinki

Jos et ole Suomessa, niin tällä pääset etsimään Euroopasta oikeaa paikkaa ja aikavyöhykettä:

timedatectl list-timezones | grep -i europe

Ja jos Eurooppakaan ei ole tarpeeksi kaukana, niin yksinkertaistetaan komentoa niin  paljon, että näet koko maailman:

timedatectl list-timezones

Nyt on oleelliset säädöt tehty ja aletaan oikeisiin töihin.

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 /

PHP ja PHP-FPM

On useampikin tekniikka, jolla sivut rakennetaan. Yleisin on PHP. Siksi oikeastaan kaikki WordPressinkin tiedostot ovat php-loppuisia. PHP koostuu oman ytimensä lisäksi erilaisia moduuleista, joista jokainen tekee jonkun asian. Esimerkiksi niinkin perusasia kuin vaikka zip-paketin purkaminen vaatii oman php-moduulinsa. Yleensä niitä asennetaan vain tarpeeseen ja kun asennat minkä tahansa muun ohjelman serverille, joka osaa hyödyntää PHP:tä, niin samalla kerrotaan mitä moduulit on löydyttävä – tai sitten Ubuntun paketinhallinta hoitaa asian puolestasi.

Kun kävijä avaa WordPress-sivusi, niin serveri ajaa melkoisen määrän pieniä php-ohjelmia, rakentaa niistä sen mikä ymmärretään sivuna, lähettää lopputuloksen Nginxille, joka tarjoilee sen viimeikseksi kävijän selaimen välilehdelle. Tuossa on tuhottomasti erilaisia välivaiheita, joista jokainen vie aikaa. Nyt aletaan vihdoin ja viimein tekemään asioita, joiden tarkoitus on nopeuttaa.

Yksi sellainen PHP-FPM. Se tehostaa PHP:n prosesseja ja muistin käyttöä web-asioissa.

Asennetaan nippu pakollisia. Tämä asentaa tuoreimman version, joka on tätä kirjoitettaessa 7.4.

apt install php-fpm php-common php-mysql php-xmlrpc php-curl php-gd php-dev php-imap php-redis php-zip php-intl -y

Ja jotta maailma olisi helppo, niin osan joutuu asentamaan versionumerolla:

apt install php7.4-opcache php7.4-cli php7.4-xml php7.4-imagick php7.4-mbstring php7.4-soap

Nuokin olisi voinut asentaa samalla apt install komennolla, mutta laitoin ne erikseen siksi, että asia osuu ensimmäisen kerran aivosoluihin. Nimittäin sitten joskus kun päivität PHP:n uudempaan, niin versionumerolliset ovat sellaisia, jotka on päivitettävä erikseen. Et sinä sitä silloin enää muista, mutta sinulle saattaa jäädä kuitenkin muistiin merkki, että versionumeroilla oli jokin merkitys.

PHP-FPM

PHP-FPM on hieman työläs asettaa. Ensialkuun kannattaa tyytyä oletusarvoihin, mutta sitä on syytä hieman viilata myöhemmässä vaiheessa. Jos sinulla on enemmän liikennettä (lue: yli 1000 käyntiä päivässä aika ajoin yli 20 samanaikaista), niin se myöhemmin tulee vastaan aika äkkiä. Mikään ei mene rikki, vaikka et säätäisikään, mutta sivustosi alkavat hidastelemaan.

PHP-FPM:n säätämisestä löytyy EksisONEsta ohjeet. Vilkaise niitä myöhemmin, älä juuri nyt. Jos et ole kokeneempi virtuaaliserverien kanssa, niin pelästyt suotta. Asia ei nimittäin ole niin vaikea kuin miltä se ensimmäisellä lukemisella saattaisi vaikuttaa.

Yksi asetus kuitenkin muutetaan. Kopioidaan ensin alkuperäinen talteen:

mv /etc/php/7.4/fpm/php-fpm.conf /etc/php/7.4/fpm/php-fpm.conf.backup

Tehdään uusi:

nano /etc/php/7.4/fpm/php-fpm.conf

Kopioi sinne tämä:

Tallennetaan ctrl-X, y ja enter.

Muistin käyttö

PHP-FPM:n tapaa käsitellä ja käyttää muistia on syytä säätää jossain vaiheessa, mutta laitetaan alustavat asetukset kuntoon. Muutoin saattaa olla riskinä, että sivustosi kaatuu, jos saat kävijäryntäyksen. Nyt varmistetaan, että moisessa tilanteessa ainoastaan latausajat kasvavat. Silti on ymmärrettävä, että kävijämäärät rasittavat aina, oli sivut sitten virtuaaliserverillä tai webhotellissa, ja liika on aina liikaa. Siihen palvelunestohyökkäyksetkin perustuvat.

Nyt joudut hieman laskemaan, mutta vain yhden jakolaskun verran.

Katsotaan paljonko muistia on käytössä:

free -hl

Katso paljonko sinulla on sarakkeessa free, minulla oli 131 MB. Pyöristän sen alaspäin 100 megaan, koska tarvitaan hieman pelivaraa, ja laitan muistiin. Mutta muutoin… serveri on vasta asetettu, ja aika paljon hyödyllisiä ohjelmia vielä puuttuu – eikä muistia ole vapaana kuin 130 megaa, ilman kävijöitä. Tämä on se syy miksi DigitalOceanin 5 taalaa kuussa maksava droplet on vain kokeilua varten.

Katsotaan paljonko eri prosessit vievät keskimäärin muistia:

ps --no-headers -o "rss,cmd" -C php-fpm7.4 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

Minulla tulos oli 38 MB.

Nyt tehdään jalolasku: jaetaan se muistimäärä, joka on vapaana (koska se voidaan uhrata kävijöille) sillä, paljonko yksi prosessi on keskimäärin vienyt (koska sen määrän yksi kävijä tarvitsee per pyyntö). eli 100/38=2,6 ~ 2. Nyt on luku, joka laitetaan siihen asetukseen, joka määrää miten PHP-FPM saa käyttää muistia webpalvelimen kanssa.

Tehdään taas varmuuskopio.

mv /etc/php/7.4/fpm/pool.d/www.conf /etc/php/7.4/fpm/pool.d/www.conf.backup

Tehdään uusi:

nano /etc/php/7.4/fpm/pool.d/www.conf

Jos otit DigitalOceanin pienimmän dropletin, niin käytä tätä. Muokkaa muutoin kohtaa pm.max.children laskusi mukaiseksi.

PHP

PHP tarvitsee myös pari muokkausta. Siirretään tässäkin ensin tiedosto php.ini varmuuskopioksi. Ylipäätään ini- ja conf-tiedostot ovat täynnä kommentteja, jotka selittävät perusteet jokaiseen asetukseen. Mahtava tietolähde, mutta hankaloittaa suuresti halutun muokattavan kohdan löytymistä. Jos jossain vaiheessa haluat tutustua tarkemmin mitä mikäkin tekee, niin tutki niitä backup-versiosta.

mv /etc/php/7.4/fpm/php.ini /etc/php/7.4/fpm/php.ini.backup

Luodaan php.ini uudestaan:

nano /etc/php/7.4/fpm/php.ini

Liitettäviä rivejä on yli 400, joten en liitä esimerkkiä tähän. Avaa se uuteen välilehteen ja kopio siitä.

Vinkki: Klikkaa koodi-ikkunan oikeassa kulmassa olevaa nappulaa Raw. Silloin koodi avataan omaan ikkunaan ja saat kopioitua sen helpoimmalla valitsemalla kaiken ctrl-A ja sitten kopioimalla ctrl-C

Etsi kohdat

upload_max_filesize = 64M
post_max_size = 128M

ja muuta niiden arvot samoiksi kuin mitä aiemmin laitoit Nginxin asetuksissa kohdassa client_max_body_size. Aidosti upload_max_filesize eli siirrettävän tiedoston maksimikoko pitäisi olla pienempi kuin post_max_size, joka pitää sisällään myös koko sen sivun muut asiat, johon siirretään – kuten vaikka WordPressin media-sivun. Ei tuo oikeasti ole niin iso asia, kunhan molemmat ovat vähintään samat kuin mitä laitoit Nginxiin.

Voit laittaa suuremmatkin, mutta silloin Nginx ei päästä siirtoa läpi. Jos laitat tähän Nginxiä pienemmät, niin serveri päästää isomman läpi, mutta se pysähtyy sitten sivustoilla.

Muista tallentaa.

Säädöt talteen

Tarkistetaan, että ei tullut kirjoitusvirheitä:

php-fpm7.4 -t

Jos sait ilmoituksen:

NOTICE: configuration file /etc/php/7.4/fpm/php-fpm.conf test is successful

niin kaikki on hyvin ja käynnistetään PHP-FPM uudestaan:

systemctl restart php7.4-fpm

Tälläkin kertaa on varmistettava, että PHP-FPM otetaan automaattisesti käyttöön, kun serveri käynnistetään:

systemctl enable php7.4-fpm

Jakke Lehtonen

Teen B2B-markkinoille sisällöntuottoa sekä UX-testauksia. Samaan liittyy myös koulutukset yrityksille ja webmaailman kanssa muutoin painiville. Serverien sielunelämää on joutunut ohessa opettelmaan. Toinen puoli toiminnasta on koirien ravitsemuksen ja ruokinnan suunnittelua sekä varsinkin omistajien kouluttamista hoitamaan koiriaan oikein ja vielä paremmin.

Profiili: Jakke Lehtonen