Kaksi viikkoa DevOps-insinöörinä — tuskien taival Amazon Web Services ‑maailmassa

“Kelaa, jot­kut konf­faa AWS:ää joka päivä”

Tämä kir­joi­tus on san­gen tek­ni­nen ja tar­koi­tet­tu eri­tyi­ses­ti ATK-ohjelmoitsijoille.

Vuo­sien koo­daus­tauon jäl­keen olen syk­syn kulues­sa kötös­tel­lyt pal­ve­lua, joka koos­tuu Vue.js:llä toteu­te­tus­ta fron­tis­ta ja Djan­gol­la koo­da­tus­ta REST-bac­ken­dis­tä. Lisäk­si käy­tös­sä on PostgreSQL-tie­to­kan­ta, Redis-pal­ve­lin sekä pie­ni Node.js-mokkula joka jut­te­lee selai­mel­le Socket.iolla ja on yhtey­des­sä Redi­siin. Kut­sun sitä jat­kos­sa nimel­lä Redis Bridge.

Ajo­ym­pä­ris­tök­si pal­ve­lul­le valit­sin monis­ta syis­tä Amazon AWS:n. Se oli minul­le aiem­min san­gen vie­ras, ja halusin samal­la tutus­tua sii­hen tar­kem­min. Nyt osa luki­jois­ta halu­aa kom­men­toi­da että oli­sit käyt­tä­nyt Hero­kua, Azu­rea, Digi­tal Ocea­nia tai Google Cloud Plat­for­mia. Kyy­nik­ko­na veik­kaan että lop­pu­tu­lok­se­na oli­si yhtä pit­kä kir­joi­tus kun tör­mäi­sin eri­lai­siin ongel­miin. Lisäk­si olen käyt­tä­nyt nyt niin pal­jon aikaa AWS:n kans­sa tap­pe­luun että yri­tän pär­jä­tä sen kans­sa (sunk cost fal­lacy).

Tämä kir­joi­tus on yhteen­ve­to teke­mis­tä­ni muis­tiin­pa­nois­ta ja koh­taa­mis­ta­ni ongel­mis­ta. Toi­vot­ta­vas­ti sii­tä on hyö­tyä muil­le AWS:n kans­sa painiville.

Hirveä läjä käsittämättömän nimisiä palveluita

Yksi suu­rim­pia tus­kia AWS:ssä on pal­ve­lui­den jär­je­tön mää­rä. Alla ole­vas­sa kuvas­sa näkyy vain osa tar­jol­la ole­vis­ta. Lait­taa­ko siis koo­di pyö­ri­mään EC2:een, Lamb­daan, Far­ga­teen vai Elas­tic Beans­tal­kiin? Lisäk­si osa pal­ve­luis­ta on nimet­ty todel­la type­räs­ti. Mikä ihmeen elas­ti­nen pavunvarsi?

Pää­dyin lait­ta­maan fron­tin staat­ti­sen koo­di­pa­ke­tin tar­jol­le S3-pal­ve­lun buc­ke­tiin (kuka­han tuon ter­min on kek­si­nyt?). S3 eli Simple Sto­ra­ge Ser­vice tar­jo­aa yksin­ker­tai­ses­ti tal­len­nus­ti­laa, ja sitä käy­te­tään usein myös ulko­maa­il­mal­le sul­jet­tu­na tietovarastona.

Jot­ta ämpä­riin pää­see ulko­maa­il­mas­ta käsik­si, pitää sin­ne mää­ri­tel­lä “Buc­ket Policy” eli täs­sä tapauk­ses­sa 11 riviä pit­kä JSON-tie­dos­to. Tämän lisäk­si on vie­lä neli­vai­hei­nen hii­rel­lä klik­su­tel­ta­va “block public access” ‑lis­ta, jon­ka valin­to­ja saa mon­ta ker­taa tavata:

Djan­go- ja Redis Brid­ge ‑pal­ve­li­met taas hoi­tu­vat Elas­tic Beans­tal­kin kaut­ta. Elas­tic Beans­tal­kil­le ker­ro­taan esi­mer­kik­si, että halu­taan Pyt­hon-pal­ve­lin jon­ne Djan­go lai­te­taan pyö­ri­mään, ja Amazo­nin tar­joa­man eb cli ‑työ­ka­lun avul­la hoi­de­taan asen­nus (tämän auto­ma­ti­soin­ti Git­la­bil­la on help­poa). Elas­tic Beans­talk hoi­taa loput, eli tapauk­ses­sa­ni mm. pro­vi­sioi EC2-vir­tu­aa­li­ko­neen (Elas­tic Com­pu­ting Cloud) ja asen­taa sin­ne koo­din. Heti asen­nuk­sen jäl­keen palo­muu­ri esti yhtey­det ulko­maa­il­mas­ta, joten nämä piti käy­dä muuttamassa.

Ver­sion­hal­lin­taan piti lisäk­si luo­da .ebex­ten­sions-hake­mis­to molem­mil­le Elas­tic Beans­tal­kiin ajoon lai­tet­ta­vil­le pal­ve­li­mil­le. Esi­mer­kik­si Djan­goa var­ten pitää kysei­seen hake­mis­toon luo­da vähin­tään kol­me loit­su­tie­dos­toa käsin.

Ver­sion­hal­lin­ta­na ja CI-työ­ka­lu­na käy­tös­sä on Git­lab, joka hoi­taa myös pal­ve­lin­ten päi­vit­tä­mi­sen. Jot­ta Git­lab voi koo­de­ja AWS:n päi­vit­tää, pitää sil­le antaa tar­vit­ta­vat oikeu­det. Tätä var­ten tar­vi­taan Amazon IAM (Iden­ti­ty and Access Mana­ge­ment) ‑pal­ve­lua. Sen avul­la luo­daan käyt­tä­jä, jol­le anne­taan oikeu­det päi­vit­tää koo­dia S3:een sekä Elas­tic Beans­tal­kiin. Eri­lai­sia oikeuk­sia on 473 kap­pa­let­ta! IAM:n gene­roi­mat avai­met tal­len­ne­taan Git­la­biin muut­tu­jik­si ja nii­den avul­la fron­tin, bac­ken­din ja Redis Brid­gen asen­ta­mi­nen AWS:n onnis­tui lopul­ta suht kivuttomasti.

Myös Redis-pal­ve­li­men asen­nus ja käyt­töön­ot­to onnis­tui val­miik­si pake­toi­dus­ta setis­tä var­sin hel­pos­ti AWS Mar­ketplace ‑kaup­pa­pai­kas­ta veloituksetta.

PostgreSQL-tie­to­kan­nan Amazon tar­jo­aa RDS-pal­ve­lul­la. Kun vie­lä tie­to­kan­nan luon­ti RDS:n onnis­tui heit­tä­mäl­lä, ajat­te­lin että koko hom­ma on pian val­mis. Enpä oli­si voi­nut olla enem­pää väärässä.

Tuskaa sertifikaattien kanssa

Jot­ta pal­ve­li­mil­le voi­daan ottaa suo­jat­tu HTTPS-yhteys, tar­vit­see nii­hin asen­taa ser­ti­fi­kaat­ti. Pal­ve­lu­ni yhtey­des­sä tar­vi­taan suo­jat­tu yhteys kol­mel­le pal­ve­li­mel­le: fron­tend, bac­kend sekä Redis Bridge.

Amazon tar­jo­aa suh­teel­li­sen help­po­käyt­töi­sen (ja kuvaa­vas­ti nime­tyn!) Cer­ti­fica­te Mana­ger ‑pal­ve­lun, jol­la ser­ti­fi­kaat­te­ja voi vara­ta. Se hoi­taa myös ser­ti­fi­kaa­tin uusi­mi­sen auto­maat­ti­ses­ti. Här­ve­lil­le ker­ro­taan osoi­te, jol­le ser­ti­fi­kaat­ti halu­taan luo­da, ja asen­ne­taan Cer­ti­fica­te Mana­ge­rin pulaut­ta­mat tie­tu­eet DNS-nimi­pal­ve­li­mel­le. Omas­sa tapauk­ses­sa­ni ser­ti­fi­kaat­ti oli val­mis pari tun­tia DNS-muu­tok­sen teke­mi­sen jälkeen.

S3 ämpä­riin ei voi suo­raan asen­taa ser­ti­fi­kaat­tia, vaan jäl­leen pääs­tään teke­mi­siin uuden pal­ve­lun kans­sa. Nyt tar­vi­taan Amazon CloudFron­tia, jon­ka kaut­ta lii­ken­nöin­ti ämpä­riin onnis­tuu. Ja toki muu­te­taan jäl­leen myös DNS:ää, jot­ta lii­ken­ne ohjau­tuu­kin S3:n sijas­ta CloudFrontiin.

Pal­ve­lus­sa on siis kak­si Elas­tic Beans­tal­kin kaut­ta asen­net­tua EC2-pal­ve­lin­ta, joil­le tar­vi­taan myös ser­ti­fi­kaa­tit. Amazo­nin Cer­ti­fica­te Mana­ge­rin teke­miä ser­ti­fi­kaat­te­ja ei voi hyö­dyn­tää näi­den pal­ve­lin­ten kans­sa suo­raan, kos­ka ser­ti­fi­kaat­te­ja ei saa siir­ret­tyä ulos.

Yksi vaih­toeh­to on luo­da ser­ti­fi­kaat­ti suo­raan pal­ve­li­men kon­so­lil­la. Myö­hem­min kuu­len, että tämä on huo­no idea — Elas­tic Beans­tal­kin pro­vi­sioi­mien pönt­tö­jen ase­tuk­sia ei pitäi­si tök­kiä SSH-yhtey­den yli, kos­ka näin teh­dyt muu­tok­set mene­te­tään jos pal­ve­lin on tar­ve uudelleenprovisioida.

Niin­pä kui­ten­kin otin SSH-yhtey­den pal­ve­li­miin. Ensim­mäi­nen teh­tä­vä oli sel­vit­tää käy­tös­sä ole­van Linux-distri­buu­tion ver­sio, kos­ka ympä­ris­tös­tä riip­puen käy­tös­sä on koko Amazon Linux AMI tai tai Amazon Linux 2, ja ne ovat hyvin erilaisia.

Nyky­ai­kai­nen tapa asen­taa ser­ti­fi­kaa­tit kon­so­lil­ta on asen­taa Let’s Enc­rypt ‑sovel­lus pal­ve­li­mel­le ja antaa sen hoi­taa ilmai­sen ser­ti­fi­kaa­tin luon­ti ja uusin­ta. Tämä on hyvin ylei­nen toi­men­pi­de, mut­ta Amazon ei tar­joa sii­hen mitään auto­ma­ti­soin­tia (esi­mer­kik­si Net­li­fyl­lä ja Git­la­bil­la hom­ma hoi­tuu paril­la klikkauksella).

Amazon kyl­lä tar­jo­aa ohjeet Let’s Enc­ryp­tin asen­ta­mi­seen, mut­ta varoit­taa että sitä ei viral­li­ses­ti tue­ta ja olet sen jäl­keen omil­la­si. Seu­raan ohjei­ta ja yri­tän asen­taa Djan­go-pal­ve­li­mel­le ser­ti­fi­kaa­tit. Asen­nus räjäh­tää ja samal­la vetää pal­ve­li­men ase­tuk­set sel­lai­seen jojoon, että lopul­ta jou­dun pyy­tä­mään AWS:ää uudel­lee­na­sen­ta­maan koko roskan.

Samal­la tur­vau­dun vaih­toeh­toi­seen lähes­ty­mis­ta­paan. Pal­ve­li­men eteen ote­taan käyt­töön Clas­sic Load Balancer, ja sen kans­sa on mah­dol­lis­ta käyt­tää Cer­ti­fica­te Mana­ge­rin luo­mia ser­ti­fi­kaat­te­ja. Täs­sä välis­sä jou­dun toki bonuk­se­na odot­ta­maan pari tun­tia DNS-muu­tos­ta, jot­ta ser­ti­fi­kaat­ti val­mis­tuu. Rat­kai­su toi­mii aika kivut­to­mas­ti, mut­ta tun­tuu absur­dil­ta että Clas­sic Load Balance­ris­ta veloi­te­taan käy­te­tyn ajan suh­teen ja se mak­saa noin kuusi ker­taa enem­män kuin käy­tös­sä ole­va palvelin.

Seu­raa­vak­si Redis Brid­ge ‑pal­ve­li­mel­le tar­vi­taan ser­ti­fi­kaat­ti. Opti­mis­ti­na seu­raan jäl­leen Amazo­nin ohjei­ta (onhan kysees­sä Node-pal­ve­lin eikä Pyt­hon-pal­ve­lin). Nyt Let’s Enc­rypt ‑asen­nus epä­on­nis­tuu toi­seen käsit­tä­mät­tö­mään vir­heil­moi­tuk­seen. Ota suo­siol­la uuden Clas­sic Load Balance­rin käyt­töön ja odo­tan jäl­leen pari tun­tia että Ceri­fica­te Mana­ger tekee työn­sä. Ja samal­la monin­ker­tais­tan tämän­kin pal­ve­li­men kustannukset.

Tämän jäl­keen ihmet­te­len jäl­leen hyvän tovin, mik­si selain ei edel­leen­kään onnis­tu jut­te­le­maan Redis brid­ge ‑pal­ve­li­men kans­sa, vaik­ka HTTPS yhteys ter­mi­noi­daan Amazo­nin toi­mes­ta. Lopul­ta oival­lan, että syy­pää on käy­tös­sä ole­va Socket.io. Pyy­dän Clas­sic Load Balance­ria ter­mi­noi­maan HTTPS:n sijas­ta SSL-yhtey­den, ja lopul­ta kuso kulkee.

Tämän jäl­keen kuu­len, että Clas­sic Load Balance­rin sijas­ta kan­nat­tai­si­kin käyt­tää uudem­paa Applica­tion Load Balance­ria. Type­ryk­se­nä unoh­dan van­han nyrk­ki­sään­nön ettei toi­mi­vaa sys­tee­miä kan­na­ta rik­koa. AWS:stä löy­tyy suo­raan migraa­tio­työ­ka­lu joka hie­nos­ti lei­poo CLB:n poh­jal­ta ALB:n. Työ­ka­lu kui­ten­kin unoh­taa ker­toa että Elas­tic Beans­tal­kin kans­sa käy­tet­tä­vän Load Balance­rin tyyp­piä ei voi vaih­taa! Niin­pä hal­lin­ta­pa­nee­lis­ta löy­tyy nyt tupla­na Load Balance­rit. Jou­dun jäl­leen uudel­leen­luo­maan Elas­tic Beans­tal­kiin ins­tans­sit alus­ta jot­ta saan ALB.t käyttöön.

Frontti hajosi

CloudFron­tin ja HTTPS-yhtey­den käyt­töön­o­ton jäl­keen huo­maan uuden ongel­man: fron­tin päi­vi­tys ei enää onnis­tu. Git­lab kyl­lä päi­vit­tää uuden ver­sion ämpä­riin, mut­ta käyt­tä­jä saa aina näky­viin van­han version.

Syyl­li­nen­kin sel­vi­ää: CloudFront hyö­dyn­tää aina väli­muis­tia, jos­ta pal­ve­lee sivut. Tämä saa­daan kor­jat­tua lisää­mäl­lä .gitlab-ci.yml:n uusi loit­su deploy-vaiheeseen:

- aws cloudfront create-invalidation --distribution-id $STAGING_CLOUDFRONT_DISTRIBUTION_ID --paths '/*'

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<AllowedHeader>Authorization</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Tämän lisäk­si ne toki pitää erik­seen pääs­tää läpi CloudFrontista.

Redis heit­tää voltin

Yhte­nä aamu­na huo­ma­sin, että pal­ve­lu ei toi­mi. Yhteys Redis-pal­ve­li­mel­le auke­si, mut­ta pal­ve­lin ei vas­tan­nut pin­giin. Amazo­nin hal­lin­ta­pa­nee­leis­ta löy­tyi hälyt­tä­vä graafi:

Ilmei­ses­ti Redis-pal­ve­lin oli kyl­läs­ty­nyt odot­te­le­maan ja alka­nut lou­hia Bitcoi­ne­ja. Pal­ve­li­men uudel­leen­käyn­nis­tys kes­ti todel­la pit­kään, mut­ta lopul­ta se oli jäl­leen pys­tys­sä. Pal­ve­lu ei kui­ten­kaan toi­mi­nut edelleenkään.

Lopul­ta huo­ma­sin, että pal­ve­li­men alas­ajon jäl­keen AWS vapaut­ti sen IP-osoit­teen, ja vara­si uuden kun pal­ve­lin käyn­nis­tyi. Tämän sai kor­jat­tua varaa­mal­la pal­ve­li­mel­le “Elas­tic IP address” ‑osoit­teen. Nämä osoit­teet ovat jopa ilmai­sia, tosin vara­tuis­ta mut­ta käyt­tä­mät­tä jäte­tyis­tä peri­tään nimel­li­nen kor­vaus. Myö­hem­min minua valis­tet­tiin, että täs­sä­kin yhtey­des­sä Load Balancer oli­si ollut Oikea Ratkaisu.

Kun Redis jök­kä­si toi­sen ker­ran, käy­tin yhden työ­päi­vän muu­tok­seen jol­la pää­sin sii­tä eroon. Jos Redi­sil­le on jat­kos­sa pakot­ta­va tar­ve, tutus­tun AWS Elas­tiCac­he-pal­ve­luun joka poh­jau­tuu Redisiin.

Ympäristömuuttujat solmussa

Vih­doin­kin sof­ta oli muu­ta­man päi­vän pyö­ri­nyt ongel­mit­ta. Oli tul­lut aika lisä­tä bac­ken­din tietoturvaa.

Elas­tic Beans­tal­kis­sa pys­tyy sovel­luk­sil­le anta­maan ase­tuk­sia ympä­ris­tö­muut­tu­jien kaut­ta. Minul­la oli aiem­min käy­tös­sä yksi­tois­ta muut­tu­jaa. Otin käyt­töön kak­si uut­ta Djan­gon suo­jauk­sen parantamiseksi.

Pian tämän jäl­keen huo­ma­sin jäl­leen, että pal­ve­lu ei toi­mi lain­kaan. Vir­heil­moi­tuk­sis­ta sel­vi­si, että Djan­go yrit­tää kyt­key­tyä osoit­tees­sa 127.0.0.1 pyö­ri­vään tie­to­kan­taan Amazo­nin RDS-kan­nan sijaan. Djan­go siis jos­tain syys­tä kuvit­te­li, että sovel­lus­ta pyö­ri­te­tään pai­kal­li­ses­ti kehit­tä­jän koneella.

RDS:n osoi­te väli­te­tään sovel­luk­sel­le ympä­ris­tö­muut­tu­jan kaut­ta. Pit­kän sel­vi­tys­työn jäl­keen havait­sin, että nyt käy­tös­sä ole­vas­ta 13 ympä­ris­tö­muut­tu­jas­ta sovel­luk­sel­le välit­tyy vain 11. Toi­nen uusis­ta lisäyk­sis­tä ei väli­ty (toi­nen toi­mii), eikä myös­kään aiem­min toi­mi­nut, RDS:n osoit­teen sisäl­tä­vä muuttuja.

Usei­den kokei­lu­jen jäl­keen pois­tin aiem­min ympä­ris­tö­muut­tu­jis­ta sen uuden lisäyk­sen, joka ei välit­ty­nyt sovel­luk­sel­le. Ja kas, nyt RDS-muut­tu­ja­kin alkoi jäl­leen toi­mia. En edel­leen­kään tie­dä, mik­si DJAN­GO_­SEC­RET_­KEY-nimi­nen ympä­ris­tö­muut­tu­ja aiheut­taa täl­lai­sen ongelman.

Vaih­toeh­toi­ses­ti tie­dot voi­si tal­len­taa AWS Sec­rets Mana­ge­riin, mut­ta jäl­leen yhden pali­kan integroi­mi­nen ei hou­kut­te­le. SM:ssä on lisäk­si san­gen absur­di hin­noit­te­lu, jokai­nen “salai­suus” mak­saa $0,4 dol­la­ria kuussa.

Logitus ei toimi

Edes logit eivät toi­mi heit­tä­mäl­lä, ja tar­vi­taan jäl­leen häm­mäs­tyt­tä­vän pal­jon konfigurointia.

Djan­go-sovel­luk­sen gene­roi­mat info-tason logi­vies­tit eivät näy Elas­tic Beans­tal­kin logi­näy­tös­sä. Djan­goon pitää mää­ri­tel­lä uusi logi­tus­ten käsit­te­li­jä, joka tal­len­taa vies­tit /opt/python/log/django.log-tiedostoon kun koo­dia aje­taan Amazonissa.

Tämän lisäk­si .ebex­ten­sions-hake­mis­tooon pitää luo­da uusi tie­dos­to, joka sal­lii loki­tie­to­jen kir­joit­ta­mi­sen tiedostoon:

commands:
01_create_file:
command: touch /opt/python/log/django.log
02_change_permissions:
command: chmod g+s /opt/python/log/django.log
03_change_owner:
command: chown wsgi:wsgi /opt/python/log/django.log

Tie­dos­to syn­tyy, mut­ta loki­vies­tit eivät sin­ne tal­len­nu edel­leen­kään. Tämän­kin aiheut­ta­ja on edel­leen hämä­rän peitossa.

Täs­sä välis­sä voi myös ihme­tel­lä, että osa AWS:n kon­fi­gu­raa­tiois­ta kir­joi­te­taan XML-muo­dos­sa, osa JSON:na ja osa YAML:na.

Frontti hajoaa jälleen

Kun kaik­ki pali­kat vih­doin­kin toi­mi­vat, lisä­sin pal­ve­luun käyt­tä­jien auten­ti­koin­nin. Omal­la koneel­la se toi­mi hie­nos­ti, mut­ta yllä­tys yllä­tys, ei AWS:llä. Fron­tin lähet­tä­mät auten­ti­koin­ti­hea­de­rit eivät saa­pu­neet kos­kaan backendille.

Rat­kai­su? Lisä­tään .ebex­ten­sions-kan­sioon nel­jäs tie­dos­to, joka löy­tyi Stac­ko­verflows­ta!

Lambda nukkuu

Amazon Lamb­da mah­dol­lis­taa ns. ser­ver­less-pal­ve­lui­den raken­ta­mi­sen. Sin­ne siis tökä­tään koo­di joka suo­ri­te­taan pyy­det­täes­sä. Pal­ve­lin­ta ei tar­vit­se vara­ta tai provisioida.

Lamb­dan avul­la pal­ve­luun tul­laan integroi­maan vie­lä yksi palik­ka. Kokei­luis­sa Lamb­da toi­mi san­gen hie­nos­ti, mut­ta pian havait­sim­me että jos Lamb­dan koo­dia ei toviin kut­sut­tu, kes­ti sekun­te­ja ennen kuin suo­ri­tus alkoi. Jos pal­ve­lua ei pidä “läm­pöi­se­nä”, kyl­läs­tyy AWS odot­te­le­maan ja heit­tää sen pois pro­vi­sioi­dus­ta tilasta.

Aihees­ta löy­tyy lisä­tie­toa ja läm­mi­tys­oh­jei­ta esi­mer­kik­si Sam Carco­sin kir­joi­tuk­ses­ta. Jäl­leen siis pää­sem­me tutus­tu­maan uuteen AWS-pal­ve­luun kun CloudWatc­hiin pitää raken­taa pingaus.

GitLab tökkii

Jokai­sen com­mi­tin jäl­keen kes­tää kuu­ti­sen minuut­tia, että deploy on tapah­tu­nut AWS:n. Git­la­bil­le on mah­dol­lis­ta myös ker­toa, että suo­ri­ta deploy ainoas­taan kun tiet­tyyn ver­sion­hal­lin­nan haa­raan tulee muu­tok­sia. Har­mi vaan että se ei toi­mi niin kuin pitäi­si.

Palvelin näyttää punaista

Elas­tic Bens­tal­kis­sa pel­käs­tään Socket.io:ta käyt­tä­vä pal­ve­lin on punai­se­na ‘SEVERE’-tilassa, kos­ka Applica­tion Load Balancer halu­aa tar­kis­taa pal­ve­li­men syk­keen HTTP-vies­teil­lä. Niin­pä sovel­luk­seen pitää lisä­tä myös HTTP-pal­ve­lin, jon­ka ainoa teh­tä­vä on vas­ta­ta “hen­gis­sä ollaan” AWS:n uteluille.

Lopuksi

Enpä aavis­ta­nut etu­kä­teen miten kova hom­ma hyvin taval­li­sen sovel­luk­sen asen­ta­mi­ses­sa Amazo­niin on — onnek­si ei ole tois­tai­sek­si Kuber­ne­tes-tar­vet­ta. Englan­nik­si koko AWS:n kans­sa tap­pe­lua kuvaa mai­nios­ti ter­mi yak sha­ving — lie­nee­kö sil­lä kuvaa­vaa kään­nös­tä suomeksi?

DevOps-kon­sul­tit voi­vat tois­tai­sek­si olla huo­let­to­mia töi­den riit­tä­mi­sen suh­teen. Jos vain her­mot riittävät.