WordPress on nykyään yhä suositumpi valinta CMS-alustaksi. OpenShiftillä voidaan näitäkin palveluita tarjota ja skaalata tarpeiden mukaan. Tämä blogikirjoitus on jatkoa edelliseen kirjoitukseeni OpenShift haltuun – vinkkejä sovelluskehitykseen. Tässä osassa pohditaan, mitä kaikkea kehittäjän on syytä huomioida OpenShift-ympäristössä, kun sovelluksena on WordPress-sivusto.

WordPressin ominaisuudet haastavat miettimään, mitkä ratkaisut ovat parhaita sivuston pystyttämiseen, päivittämiseen ja ylläpitoon OpenShiftissä. Selkeät hyödyt WordPressin pystyttämisestä OpenShiftiin ovat kuitenkin nähtävissä juuri sovelluksen saavutettavuuden kasvaessa, eri kehitysympäristöiden automatisoinnissa ja monistettavuudessa sekä ylläpidossa.

WordPressin ominaisuudet OpenShiftissä

WordPress-sivusto koostuu yleensä teemasta, käytössä on usein lisäosia (plugins) ja taustalla on tietokanta, jossa säilytetään sisältöjä. Lisäksi sivusto tallentaa tiedostoja, kuten liitteitä ja kuvia. Kun WordPress-sivusto viedään OpenShiftiin, voidaan ainakin tietokanta ja varsinainen WordPress-toteutus jakaa luonnollisesti omiin kontteihinsa, mikä selkeyttää vastuunjakoa (separation of concerns).

OpenShiftissä onkin tarjolla valmiita tietokanta-imageita, jollainen on helppo ottaa käyttöön myös WordPressin kanssa. Lisäksi WordPressistä on julkaistu esimerkiksi virallinen Docker-image, jonka kanssa pääsee alkuun OpenShiftissä. Dockerilla on helppo laajentaa sovellusta luomalla omia ”kerroksia” tarpeen mukaan: lisätä tarvitsemiaan riippuvuuksia ja mahdollisia asennusvaiheita. Mielenkiintoiseksi WordPressin pystyttämisen OpenShiftiin tekee tietojen, liitteiden ja kuvien säilytys, asennuksen automatisointi sekä sivuston ylläpidolliset toimet, kuten lisäosien asentaminen ja päivitys.

Suunniteltaessa WordPress-sivuston pystyttämistä OpenShiftiin ensimmäiseksi on syytä huomioida, kuinka sovellus aiotaan asentaa ja mahdollisesti skaalata. Manuaaliset toimenpiteet eivät useinkaan tähän prosessiin sovi. Toisaalta täysin uuden ympäristön, esimerkiksi testiympäristön, pystytys voi sisältää kertaluontoisia manuaalisia alustustoimenpiteitä, kuten tietokannan tai uploads-hakemiston kopioinnin pysyvälle levyosiolle. Asennuksen automaattisuus ja skaalaus vaikuttavat siihen, mitä kaikkea WordPress-sovelluksesta pitää säilyttää pysyvästi ja mitä voidaan asentaa aina uudelleen per sovellusinstanssi.

WordPressin taustalla on tietokanta, joka luonnollisesti vaatii oman pysyvän levytilan. Tietokannan lisäksi WordPress-sovelluksessa on sisällöntuottajan lataamia tiedostoja (uploads), jotka täytyy säilyttää myös pysyvästi. WordPress käyttää teemoja ja lisäosia, joiden kanssa on syytä miettiä, pitääkö näitä säilyttää ja jakaa esimerkiksi eri instanssien eli podien välillä.

Perinteisesti lisäosia hallitaan WordPressin hallintanäkymästä, mutta asennuksen automaattisuus OpenShiftissä edellyttää näiden asentamista ja päivitystä esimerkiksi versionhallinnasta tai automaattisesti skripteillä. Etenkin jos lisäosien hallinta halutaan estää hallintanäkymästä, on pelkkä automatisointi varteenotettava vaihtoehto. Jos lisäosia kuitenkin halutaan päivittää myös hallintakäyttöliittymästä, täytyy lisäosatkin tallentaa pysyvästi ja jakaa eri podien kesken. Mikäli WordPress-sovellusta ajettaisiin usealla podilla ja lisäosia ei säilöttäisikään, jokainen pod käyttäisi omia versioita lisäosista. Hallintakäyttöliittymästä päivitys kohdistuisi kuitenkin vain sille podille, johon OpenShift reitittäisi sillä hetkellä liikenteen, joten lopputuloksena voisi olla eri lisäosaversioiden ajaminen eri podeilla.

Valmiina tuotantoon

Kun projektia ollaan viimeistelemässä ennen varsinaiseen julkaisuversioon siirtymistä, on viimeistään syytä tarkistaa sovelluksen elinkaari ja ympäristön toimivuus OpenShiftissä. Näihin voi kuulua esimerkiksi sovelluksen tilan ja normaaliuden tarkistaminen (health checks), häiriötilasta toipuminen ja mahdollinen skaalaustarve. Lähtökohtaisesti ajettava sovellus tulisi rakentaa mahdollisimman valmiiksi jo käännösvaiheessa (build) ja asennusvaiheen (deploy) tulisi olla nopea. Tällöin kävijäkuorman kasvaessa skaalaustilanteet ja virhetilanteesta toipuminen sujuisivat mahdollisimman nopeasti.

WordPressin virallinen Docker-image ei kuitenkaan tältä osin ole paras mahdollinen OpenShift-ympäristöön. Docker-image nimittäin asentaa kyllä riippuvuuksia ja muita ympäristöön liittyviä yksityiskohtia imagen luontivaiheessa, mutta varsinainen WordPressin asennus tapahtuu vasta, kun Docker-image käynnistetään ajoon. Mikäli kehittäjä haluaa määritellä omia WordPress-ympäristöön liittyviä asennusvaiheita, kuten lisäosien asennusta tai päivitystä, nämä suoritetaan vasta OpenShiftin asennusvaiheen aikana, kun image käynnistetään ajoon. Näin asennus pitkittyy ja vie pahimmillaan paljon aikaa uuden podin käynnistysajasta, joka taas vaikuttaa esimerkiksi skaalaukseen.

Parempi tapa olisi siis muodostaa Docker-image mahdollisimman valmiiksi jo sen luontivaiheessa. Tällöin WordPressin asennus tapahtuisi aiemmin ja mahdollistaisi muun muassa omien riippuvuuksien (teemat, lisäosat, lisäosien päivitykset jne.) asentamisen valmiiksi jo OpenShiftin käännösvaiheessa esimerkiksi WordPressin komentorivityökaluja hyödyntäen. Näin OpenShiftin asennusvaiheessa otettaisiin vain valmis image ajoon, jolloin skaalauskin tapahtuisi nopeammin.

WordPress-sivuston ylläpito ja automaatio

WordPress-sivusto vaatii jatkuvaa ylläpitoa: uusien WordPress-versioiden asennuksia ja lisäosien päivityksiä, jotka saattavat pahimmillaan rikkoa koko sivuston. Näin ollen onkin syytä miettiä tarkasti, mitä näistä voidaan suorittaa automaattisesti. Lähtökohtaisesti sivuston hajoaminen kehitys- tai testausympäristössä automaattisten päivitysten vuoksi ei liene niin suuri katastrofi kuin tuotannossa. Siksi päivitystilanteissa tuleekin vahvasti nojata testiympäristön verifiointiin ennen tuotannon päivitystä.

Toisaalta päivitysten ilmestyessä hyvinkin tiuhaan kannattaa miettiä, minkälainen prosessi itselle sopii: voidaanko päivityksiä automatisoida vai ovatko ne täysin tai osittain manuaalisia prosesseja. Tämä onkin enemmän WordPressin ominaisuuksiin liittyvä kysymys, mutta tässäkin voidaan hyödyntää testiympäristöä, automaation tuomaa vaivattomuutta ja kokeilla eri tapoja löytääkseen omaan projektiin sopivat prosessit.

OpenShift tarjoaa siis ajoalustan lisäksi helpon ja joustavan tavan testata, kehittää ja iteroida oman sovellusympäristön tarpeisiin sopivat prosessit ja konfiguraatiot. Yhdistämällä parhaat käytännöt konfiguraatioiden ja ajoympäristöjen hallintaan kehittäjän on helppo kokeilla ja testata tarvitsemansa puitteet sovelluksen ylläpitoprosesseihin ja ajonaikaisiin konfiguraatioihin. Kun konfiguraatiot ovat tallessa, uuden ympäristön pystytys ja tuhoaminen käyvät käden käänteessä ja iterointi on helppoa.

Mielestäni OpenShift onkin parhaimmillaan juuri WordPressiin liittyvien ylläpidollisten prosessien määrittelyssä, kehittämisessä ja usean eri ympäristön yhtäaikaisessa tarjoamisessa.

Entä sitten OpenShiftin mitattavat hyödyt? Täytä kenttään sähköpostiosoitteesi, niin lähetämme sinulle ladattavan, IDC:n laatiman englanninkielisen tutkimusraportin ”The Business Value of OpenShift”. Raportissa keskitytään OpenShiftin vaikutuksiin yhdeksän eri organisaation toiminnassa sekä sen mitattuihin hyötyihin.

  • Voimmeko kertoa sinulle lisää OpenShiftista ja konttiteknologioista sähköpostitse?

 

Lisää OpenShiftistä blogissamme:

Hei liiketoimintapäättäjä: kontteja eikä könttejä!

OpenShift haltuun – vinkkejä sovelluskehitykseen

OpenShiftillä kohti modernia arkkitehtuuria

Avainsanat:
openshift, wordpress
ambientia

Blogi