CDN ja podcast-linkit
https://www.eksis.one/palvelimet/cdn-ja-podcast-linkit/
Käytin aiemmin sivustolla katiska.eu Amazonin AWS:n CDN:ää. Sivuston cdn-osoite viittasi CloudFrontiin, joka oli kytketty hakemaan tiedostot S3-bucketista. Normikauraa siis.
Alussa sinne meni aivan kaikki staattiset tiedostot. JS, css, kuvat, audio jne. Sitten tuli hassu olo, että joka sivulatauksessa haettavat JavaScriptit ja tyylimuotoilut itseasiassa aiheuttivat latenssia, hidastelua, kun ne haettiin CDN:stä. Mutta suurin hidaste oli cacheaminen, koska minulla oli silloin Varnish käytössä. Joten ne palasivat takaisin kotiin. Kuvat ja audiot jäivät AWS:n hoiviin.
Sitten oivalsin yhden asian. Minä en tee CDN:llä yhtään mitään. En varsinkaan tilanteessa, jossa edge-CDN ei palvele mitään eikä ketään.
Globaali vastaan paikallinen
Olin tehnyt asioita kuin superisot sivustot. Mutta minä ja sivustoni emme ole muuta kuin ikkiriikkisiä. Olin syyllistynyt perussyntiini, tekemiseen tekemisen vuoksi.
CDN sellaisenaan tarjoaa yhden asian, sen edgen. Edge-CDN tarkoittaa sitä, että se on maailmanlaajuinen tai muuten iso verkosto servereitä, jotka tarjoavat cachestaan sivun tiedostot lähempää kävijää.
Kun otin Amazonin myymän systeemin käyttöön, niin sivustojeni sisältö — oikeammin niihin liittyvä oheismateriaali, kuten juurikin ulkonäköä säätelevät CSS:t, laitteissa toiminnallisuutta tarjoavat JS:t, kuvat jne. — tarjottiin lähempää pyytäjää kuin missä aito serveri sijaitsee.
Maailma on suuri ja vaikka internet, valokuitu ja satelliitit kattavat pallon hyvin ja ovat nopeita, niin silti viivettä on.
Edge tarkoittaa sitä, että kävijän pyyntö sivujen tiedostoista menee jonnekin muualle kuin alkuperäiselle palvelimelle. Eräällä tavalla annetaan ymmärtää, että varsinainen datakeskus on keskiössä ja sen ympärille rakennetaan verkosto tai ympyrä, ja kävijää palvellaankin sen reunoilta, lähempää aitoa kävijää.
Koska minulla oli silloin sivustot Saksassa, niin AWS ja CloudFront pystyivät tarjoamaan eräällä tavalla paikallisesti, tai ainakin lähempää, eri mantereilla sivustojeni tiedostot.
Ongelma on siinä, että minulla ei ole kävijöitä noissa maissa. Niistä tulevat (haitalliset) botit sen sijaan saivat tiedostot hieman nopeammin. Minun kävijäni ovat suomalaisia ja muutamaa ulkosuomalaista lukuunottamatta… Suomessa — ja siellä/täällä ei ole edge-serveriä.
Siihen aikaan lähin oli Saksassa. Kotiserverinikin oli Saksassa. Sitten Amazon hieman laajensi ja Tukholmaan tuli datakeskus. Joten logiikka sitten yritti päätellä, että annetaanko suomalaisille tiedostot Saksasta, jossa kaikki siis alunperinkin oli, vai Ruotisista.
Ei mitään merkitystä millekään muulle paitsi sille, että maksoin joka kuukausi tuosta ilosta. Paitsi että se toi iloa vain Amazonin liikevaihdolle.
Toiminnan järkeistäminen
Minä en saanut CloudFrontin kanssa minkäänlaista nopeusetua, koska se ei lyhentänyt tiedonsiirron matkaa. Se itseasiassa pidensi. Toki voidaan olettaa, että Amazonin serverit ovat yhteyksiltään nopeampia kuin käyttämäni palvelin, mutta kyse oli teoreettisesta edusta. Ei näkyvästä.
Toinen ongelma oli se, jonka ratkaisin Varnishilla. Eivät kuvat ja sivujen pikkutiedostot, vaikka niitä paljon määrällisesti onkin, ole se pullonkaula. Käyttämäni WordPress on.
Sivujen rakentaminen PHP:n ja tietokannan yhteistyöllä vei enemmän aikaa kuin sisällön siirtäminen kävijälle. Edes siinä vaiheessa kun aloin tarjoamaan Varnishin avulla cachetettua sisältöä, suoraan tarjoiltavat oheistiedostot — joita on yleensä turha viedä välimuistiin — eivät tuoneet lataukseen nopeutta CDN:ää käytettäessä.
Joten purin CloudFrontin ja lakkasin tuolta osin rahoittamasta Jeff Bezoksen elämää.
CDN (oikeammin sen tarjoama järjestelmä, mutta oion mutkia) tarjoaa yhden asian, jota tavallinen serverisivusto ei tarjoa. Se on isojen mediatiedostojen striimaus.
Striimaus tarkoittaa sitä, että esimerkiksi videon tai audion sisältöä aletaan toistamaan heti. Ei odoteta, että koko megatiedosto on ladattu puhelimeen tai tietokoneelle. Tuttua esimerkiksi Netflixistä tai Spotifystä — toki niiden tekniikka on hieman erilainen, mutta periaate on sama.
Minulla on audiotiedostoja, podcasteja. Niiden toistossa olisi mukavaa, jos ne alkaisivat jutella nyt, ei vasta minuutin kuluttua. Mutta minulla on kaksi järjestelmää, joka hoitavat tuon: podcastit tarjoava plugin sekä Varnish.
Sitten on sekin, että niitä kuunnellaan paljon podcastejä tarjoavien palveluiden kautta, kuten Spotifystä, Applesta jne. En pidä tuosta tilanteesta, koska silloin ihmiset maksavat noille kuunnellessaan minun sisältöäni. Minä en saa muuta iloa kuin maksaa serverimaksuja. Tuolle tilanteelle ei voi mitään, joten sen kanssa on vain elettävä.
Joten en saanut striimauksenkaan etua Amazonin palveluista
Tiedostokokojen tuska
Kun purin CDN:n oheistiedostojen suhteen, niin tilan käytössä omalla serverillä ei muuttunut mikään. Ne on pakko olla paikallisesti ja siirretään maailmalle kävijöiden takia.
Kuvat ovat siinä rajoilla. Niitä tuppaa kertymään ja ne vievät tilaa ilman, että niitä käytetään pyydetyn sivun rakentamiseen. Ne ovat osa sen sivun sisältöä. Mutta päätin, että tilan kulutus kuvien takia ei ollut merkityksellistä.
Audiot olivat hieman toinen juttu. Eivät nekään videoiden kokoluokkaa ole, mutta yksi podcast-jakso syö levytilaa 30 – 50 kuvan verran. Joten tein kompromissin. Jätin audiot CDN:n haltuun. En voittaakseni nopeudessa, vaan säästääkseni oman serverin tilaa. Sen laajentaminen maksaa aina.
Aloin kuitenkin lopulta lähestyä hetkeä, että oma serveri olisi päivitettävä suurempaan. Samalla lompakko sanoi, että minulla menee nyt rahaa liikaa joka suuntaan.
Sama ongelma kuin kotitalouksilla striimauspalveluiden kanssa. Ei se yksi tai kaksi kympin kuussa maksava palvelu normaalitaloudessa maailmaa kaada. Mutta kun niitä kympin palveluita on kymmenen, ja suurinta osaa ei edes käytä, niin se satanen kuussa ja 1200 euroa vuodessa alkaa sattumaan.
Minulla meni liikaa rahaa Amazonille. Serverin laajennus maksaisi lisää. Aloin ynnäilemään noita ja havaitsin, että kun otan audiot pois Amazonilta, sekä muutaman muun backup-tyyppisen tiedostosäilön, niin itseasiassa serverin kallistuminen ei nostaisi kulujani. Toki ne pitäisi siirtää jonnekin muualla, mutta silti kokonaiskulut olisivat samat kuin ennen serverin päivitystä.
Elämässä on valintoja
Tässä oli taustalla muutakin, nimittäin nykyisen maailmanpolitiikan tila. Minä en halua enää rahoittaa amerikkalaisia megakorporaatioita yhtään sen enempää kuin on pakko.
Olen luopunut vahvasti Facebookista ja siirtynyt federoituun ja algoritmivapaaseen someen, joka ei rahoita Mark Zuckerbergin vakoilua, sisällön varastamista ja vittuilua. Joten olen Mastodonissa. Samaten lopetin Instagramin ja siirryin Pixelfediin.
Sivustoni olivat ennen DigitalOceanilla. Sitten päätin, että en halua rahoittaa venäläisomisteisen amerikkalaisen suuryhtiön, joka vuotaa servereiden tiedot mm. tiedustelupalvelulle, yhtään enempää. Joten vaihdoin saksalaiselle Hetznerille.
Ehkä täytyy olla hieman rehellisempi. Päätöstä helpotti DigitalOceanin melkoisen isot hinnankorotukset.
Jeff Bezos on yrittäjänä täysi hirviö. Amazonin yritys- ja henkilöpolitiikka on sellaista, jota täällä ei edes ymmärretä. Mutta Amazonin AWS:n palvelujen korvaaminen on vaikeaa. Korvaan kuitenkin sen minkä pystyn. Ja CDN-tyyppinen tiedostojen välitys on sellainen.
S3 tiedostosäilö Suomessa
Sivustojani hostaava Hetzner pitää niitä datakeskuksessa lähellä Helsinkiä. Porvoossako se aidosti sijaitsee? Joten sivustoni muuttivat takaisin Suomeen, ja siihen paloikin sitten CDN:n hyöty lopullisesti.
Hetzner tarjoaa aidon CDN:n lisäksi myös S3-tyyppisen pilvipalvelun. Inhoan pilvi-nimitystä, koska eivät tiedostot missään pilven reunalla ohuessa ilmassa leiju. Ne ovat ihan tismalleen samassa datakeskuksessa syömässä sähköä ja tuottamassa lämpöä.
S3 on tapa, jolla Amazon rakensi tiedostosäilöt. Muut adoptoivat/kopioivat tekniikan, ja siitä tule de facto standardi. Se kuitenkin tarkoittaa sitä, että ne toimivat samalla tavalla ja niitä pystyy komentoriviltä käyttämään samalla tavalla.
Niiden ero on enemmän UX-tyyppinen. AWS:n S3 antaa suoraan aidot linkit tiedostoihin. Hetznerin S3 antaa polun tiedostoon. Sitten täytyy erikseen kopioida endpoint. Sitten täytyy lisätä endpointin alkuun bucketin nimi. Ja lopuksi liimata nuo yhteen. Vähintäänkin ärsyttävää ja epämukavaa. Ehkä he kehittävät tuota jossain vaiheessa.
Joten otin Hetznerin S3:n käyttöön. Koska ne käyttävät samaa kieltä ja rakennetta, niin yksinkertaisella bash-scriptillä tiedostojen siirto AWS:stä Hetzneriin on kohtuullisen vaivatonta asw cli avulla.
Nyt podcastini tulevat Hetznerin tiedostosäilöstä AWS:n S3 sijaan.
Rumat domainit
Podcastin aito url näkyy aniharvoin kenellekään. Mutta silti url malliin https://podcastit.hel1.your-objectstorage.com/kaffepaussi/podcast-149.mp3 saa amalgaamit kirkumaan tuskasta ja silmät vuotamaan verta. Se täytyy muuttaa joksikin inhimillisemmäksi.
Aidon CDN:n käyttö tekisi sen, koska silloin käytetään omaa domainia. Mutta kun en halua maksaa CDN:stä, koska se ei tuo mitään etua.
Tuohon on olemassa kiertotie. Tehdään Nginxillä proxy ja kierrätetään sitä kautta pyynnöt Hetznerin S3:een. Se mahdollistaa myös suunnitelmien muuttumisen tulevaisuudessa. Jos yhtä äkkiä päätänkin käyttää jonkun muun myymää S3-säilöä, niin muutan vain Nginxin proxyn kohdetta.
Mikä parasta, niin tuo ei maksa mitään. Toki S3:n verran, mutta senhän joutuu kuitenkin maksamaan aivan riippumatta minkä näköinen url on.
Hetzner S3 domainin muuttaminen
Tämä onnistunee Apachellakin, mutta en tiedä miten siellä nämä tehdään. Minä käytän reverse proxyna Nginxiä.
Kaikessa seuraavassa minä toimin aina rootin ominaisuudessa. Olen serverini ainoa käyttäjä ja jos SSH murretaan, niin silloin murtuu rootinkin tili, eikä sudon käyttö pelasta miltään. Mutta kun kuitenkin olet normaalina käyttäjänä liikkeellä, niin muista sudo oikeisiin paikkoihin.
Ensiksi täytyy lisätä DNS-tietoihin haluttu domain. Minä käytän podcast.katiska.eu. Voisi se olla myös cdn, mutta olen kyllästynyt siihen, eikä tuo ole määritelmällisesti eikä toiminnallisesti content delivery network, sisällönjakoverkko.
Nginxille tarvitaan host. Muista, että esimerkki on live, joten muokkaa se kohdalleen. Ja ei, vaikka yrittäisit käyttää tuota päästäksesi buckettiini, niin se ei nyt vaan toimi niin (ystävällinen vinkki, koska joku yritti sitä).
server { listen 443 ssl; http2 on; server_name podcast.katiska.eu; # Let’s Encryptin sertit ssl_certificate /etc/nginx/dummy-certs/dummy.crt; ssl_certificate_key /etc/nginx/dummy-certs/dummy.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers HIGH:!aNULL:!MD5; # CORS-headereita jos audiosoitin tarvitsee niitä add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods "GET, HEAD" always; # Proxy S3-tiedostoille Hetzneriltä location /kaffepaussi/ { proxy_pass https://podcastit.hel1.your-objectstorage.com/kaffepaussi/; proxy_set_header Host podcastit.hel1.your-objectstorage.com; # Poistetaan mahdollinen Varnish cache-bypass-otsikko proxy_set_header X-Bypass-Cache ""; # Sallitaan puskurointi proxy_buffering on; proxy_request_buffering off; # Estetään gzip (S3 palauttaa jo valmiiksi sopivasti) proxy_set_header Accept-Encoding ""; # Poistetaan virheellinen SSL-verifikaatio, jos ongelmia proxy_ssl_verify off; }}server { listen 80; server_name podcast.katiska.eu; # Pakotetaan HTTPS return 301 https://$host$request_uri;}
- Jos et tiedä miten dummy SSL-sertikaatti tehdään, niin googleta. Se on siellä vain siksi, että saan lennosta conffin kuntoon ennen Let’s Encryptiä. Voit toki tehdä saman perinteistä tietä laittamalla ensin vain serveriblokin 80, hakemalla SSL:n ja sitten muokkaamalla 443 kuntoon.
Tarvitaan SSL-sertifikaatti.
certbot --nginx -d podcast.katiska.eu
Ja perään tietysti:
nginx -t && systemctl reload nginx
Se oli siinä. Nyt urlit ovat paljon kauniimpia.
Entä ne WordPressin linkit?
Yleensä jotain tällaista tehdään siinä vaiheessa, kun on jo jotain käytössä (tämähän toki toimii muullekin kuin vain podcast-audiolle). Joten pelkästään se, että on kopioinut tiedostot S3:een, ei riitä. WordPressin sisällössä täytyy linkit myös muuttaa.
Käsin moinen homma on kurjaa ja SQL:n suora tökkiminen on riskialtista. Käytä WP CLI:tä, kuten jokaisem WordPress-adminin kuuluisi tehdä.
Ihan ensimmäiseksi turvaa selustasi ja tee tietokannasta varmuuskopio.
wp --allow-root db export tietokanta.sql
- kyllä, edelleenkin olen root; tuo kannattaa laittaa aliakseksi malliin
wp='wp --allow-root'
Sitten tehdään haku ja korvaus, search & replace. Ja tässäkin, muokkaa itsellesi sopivaksi.
wp --allow-root search-replace \ 'https://podcastit.hel1.your-objectstorage.com/kaffepaussi/' \ 'https://podcast.katiska.eu/kaffepaussi/' \ --skip-columns=guid --precise --all-tables
Tuo ei tosin toimi minulla, koska podcasteissä käyttämäni Seriously Simple Podcast ei tallenna audion polkua itse artikkeliin vaan metatietoihin kentällä audio_file. Joten joudun menemään hieman toista reittiä.
Ensin kannattaa kokeilla, että saa jollain aidolla artikkeli-ID:llä sen urlin mitä on muuttamassa.
wp post meta get 158851 audio_file
Tuo antoi vastaukseksi
https://podcastit.hel1.your-objectstorage.com/kaffepaussi/podcast-149.mp3
Sitten tehdään vähän luuppikierroksia. Tämä toimii komentoriviltä, mutta on hieman tarkka sisennyksistä, kauttaviivoista ja sellaisista. Joten se voi laittaa scriptiksikin.
Huomio. Jos käyttää wp --allow-root aliasta, niin se toimii komentorivillä ensimmäisessä. Mutta jos on scripti, niin se täytyy lisätä sinne. Samaten jos on on pipe, niin alias toimii vain ensimmäisessä, muihin --allow-root täytyy lisätä.
#!/bin/bashecho "id,old_url,new_url" > podcast-url-replacements.csvpost_ids=$(wp --allow-root post list --post_type=post --post_status=publish --format=ids)for id in $post_ids; do current_url=$(wp --allow-root post meta get "$id" audio_file 2>/dev/null) if [[ "$current_url" == https://podcastit.hel1.your-objectstorage.com/kaffepaussi/* ]]; then new_url="${current_url/podcastit.hel1.your-objectstorage.com/podcast.katiska.eu}" echo "🔁 $id: $current_url → $new_url" wp --allow-root post meta update "$id" audio_file "$new_url" >/dev/null echo "$id,$current_url,$new_url" >> podcast-url-replacements.csv fidone
Sitten kannattaa tarkistaa, että urlit ovat tosiaan muuttunneet.
#cdn #hetzner #nginx #podcast #wordpress
