Yksittäisten palveluiden pystyttäminen pilveen on helppoa kuin leikki. Mutta kun infrastruktuuri laajenee ja monimuotoistuu, kriittiseksi nousee kyky hallita kokonaisuutta. Eli kyky hallita ja dokumentoida muutoksia, kyky palata edellisiin versioihin ja kyky monistaa laajoja ympäristöjä. Tällöin avuksi kannattaa ottaa IaC - Infrastructure-as-Code.
Tämän kaksiosaisen artikkelin ensimmäisessä osassa käsittelen pilvipohjaisten ympäristöjen vaatimien resurssien luomista ohjelmallisesti ja automatisoidusti. Artikkelin jälkimmäisessä osassa hypätään konkreettiseen esimerkkiin pilvipalveluresurssien luomisesta Google Cloudiin. Esimerkissä käytetään Terraform-työkalua, jonka avulla voit luoda ympäristöjä niin Googlen, AWS:n kuin Azurenkin pilveen.
Osa 1 - Pilvipalveluresurssien luominen ohjelmallisesti
Infrastruktuurin luomisessa pilveen on pitkään ollut vallitsevana tapana naksutella tarvittavat konfiguraatiot käsin, käyttäen webbiselainpohjaista käyttöliittymää eli pilvipalvelun konsolia. Muutoksen tuulet puhaltavat nyt myös tähän toimintatapaan. Manuaaliseen konfigurointiin liittyy väistämättä haasteita, koska inhimillisten virheiden mahdollisuus on olennaisen suuri, eivätkä tehdyt operaatiot ole automaattisesti toistettavissa tarpeen niin vaatiessa.
Esimerkiksi seuraaviin kysymyksiin on hankala löytää vastausta, jos pilvi-infrastruktuurin luominen on tehty täysin manuaalisesti:
- Mikä on tällä hetkellä käytössä oleva ympäristön konfiguraatio?
- Kuka teki viimeksi muutoksia?
- Mikäli oli ympäristön edellinen tila ennen muutoksia?
- Miksi tilaa muutettiin?
- Vastaako infrastruktuurin tila toivottua?
- Miten voin pyytää varmistusta muutoksille muilta?
- Jos ympäristö jouduttaisiin luomaan tyhjästä uudestaan, niin kuinka kauan tämä kestäisi?
- Miten voisimme välttyä inhimillisiltä virheiltä ympäristön uudelleenluomisessa?
Markkinoilta on löydettävissä täsmätyökaluja, joiden avulla pystytään ratkomaan osaa näistä kysymyksistä. Kokonaisvaltainen lähestyminen on usein kuitenkin parempi valinta, kuin yksittäisten kysymysten ratkominen sekalaisella työkalupakilla. Käytännössä infrastruktuurin määrittely manuaalisen prosessin kautta on samanlainen haaste, kuin jos sovelluskoodia kirjoitettaisiin huonosti kommentoituna ja dokumentoituna ilman versionhallintaa. Versioiden ja riippuvuuksien hallinnasta sekä tiimityöstä tulisi ennen pitkää kaaosta.
DevOpsin ja vastaavien liikkeiden myötä sekä uusien työkalujen tukemana infrastruktuuri aletaan nähdä samanlaisena hallittavana kokonaisuutena, kuin mikä tahansa muu osa sovellustuotantoa. Infrastuktuurin muutoksille halutaan mahdollistaa samanlaiset työkalut ja toimintatavat kuin tänä päivänä on käytössä sovelluskehitystyössä.
Infrastucture-as-Code (IaC)
Termi Infrastucture-as-Code (IaC) viittaa nimenomaan tähän tavoitteeseen, jossa pilvessä käytettävien resurssien luominen pyritään automatisoimaan ja siihen tuodaan tueksi sovelluskehitystyössä hyväksi havaittuja työtapoja ja -välineitä. Käytännön tasolla halutut resurssit, niiden väliset kytkökset ja muut määritykset esitetään koodin kautta, jolloin ratkaisu myös dokumentoi itse itsensä. Kenenkään ei tarvitse mennä tulkitsemaan ympäristöä koskevia, todennäköisesti vanhentuneita dokumentteja ja pyrkiä tekemään niiden pohjalta toimenpiteitä. Parhaimmillaan tämä koodin kautta määriteltävä ympäristö ja ympäristön muutokset ajetaan automatisoidun CI/CD-putken kautta tuotantoon (CI eli Continuous Integration ja CD eli Continuous Delivery). Tällöin pilviympäristöä määrittävä koodi versioidaan ja muutokset ympäristöön ajetaan automatisoidusti koodimuutosten yhteydessä.
Infrastructure-as-Code -lähestymistapa on käytössä jo laajalti ja nyt on viimeistään aika hypätä kelkkaan mukaan. Toki kelkkoja on hieman erilaisia riippuen siitä, mikä pilviympäristö on käytössä, mitä siihen soveltuvia työkaluja haluaa hyödyntää ja halutaanko ympäristöä koskeva koodi kirjoittaa kuvauskielellä vai jollakin yleisesti käytössä olevalla ohjelmointikielellä. Esimerkiksi
- Googlen pilvessä (GCP) on käytössä siihen soveltuva Cloud Deployment Manager,
- Amazon Web Services pilvessä (AWS) on puolestaan CloudFormation tai Cloud Development Kit (CDK),
- Azuressa infrastruktuurin määrittelyn palveluna on Azure Resource Manager.
Näiden lisäksi saatavilla on määrittelykieltä käyttäviä vaihtoehtoja kuten Terraform tai yleisiä ohjelmointikieliä tukeva Pulumi, jotka molemmat toimivat sekä Azuren, AWS:n että GCP:n kanssa. Myös Kubernetes on osittain tuettu näiden yleiskäyttöisten työkalujen kanssa.
Edellä esiteltyjä työkaluja käytetään pääosin pilviresurssien luomiseen tai muokkaamiseen. Samaten näiden työkalujen avulla voidaan ajaa palvelimille esimerkiksi niiden vaatimat skriptit tai muut konfiguraatiomääritykset. Yleensä näitä työkaluja ei kuitenkaan käytetä tuotannossa olevien palvelinten ajonaikaiseen konfigurointiin. Ajonaikaista konfigurointia edustavat työkalut kuten Chef, Puppet, Ansible, SaltStack tai useat pilvipalveluiden tarjoajien omat palvelut.
Useimmiten periatteena Infrastructure-as-Code-lähestymistavassa on, että palvelut pyritään rakentamaan muuttumattomiksi (immutable). Tavoitteena siis on, että palveluita tarvitsisi konfiguroida ajonaikaisesti mahdollisimman vähän.
Tämä muuttumattomuuden konsepti tulee erityisen hyvin esille kun siirrytään virtualisoiduista palvelimista kontitettuihin palveluihin.
Miksi Infrastructure-as-Code?
Pilvipalveluresurssien luomisessa Infrastructure-as-Code -lähestymistavalla on monia etuja erityisesti tilanteissa, joissa ympäristöön pitää tehdä nopeasti laajamittaisia muutoksia. Usein monimutkaisesta ympäristöstä joudutaan toistuvasti rakentamaan uusia kopioita esimerkiksi testausta varten. IaC-työkaluja käyttäen tällainen kokonainen ympäristö on täysin mahdollista perustaa automaattisesti ja muutamassa minuutissa, pitäen sisällään useita virtuaalikoneita, levyjä, verkkoja, pilvitallennustilaa, sisällönjakeluverkkoja (CDN), DNS-tietoja ja Kubernetes-klustereita.
Tällaisen ympäristön perustaminen käsin ohjeiden mukaan olisi varmastikin vähintään tuntien työ ja todennäköisesti perustamisen aikana tapahtuisi ainakin yksi tai useampikin inhimillinen virhe. Ammattilaiset kiittävät, kun heidän aikansa ei mene manuaalisesti naksutteluun, vaan he voivat keskittyä tärkeämpiin asioihin ja antaa automatisoinnin auttaa toistettavien asioiden kanssa.
Samaten ympäristöjen konfigurointi ohjelmallisesti mahdollistaa esimerkiksi tehokkaan blue/green-järjestelyn (tai red/black Netflix-kielellä) käyttämisen, jossa ympäristöön tehtävät muutokset konfiguroidaan taustalla ohjelmallisesti toiseen erilliseen ympäristöön, johon liikenne siirretään hiljalleen varsinaisesta tuotantoympäristöstä. Tällöin uudesta ympäristöstä tulee tuotantoympäristö liikenteen siirron jälkeen.
Ympäristön muutosten julkaisu automaattisesti
Ohjelmallinen ympäristöjen luominen ja hallinnointi voidaan myös yhdistää aiemmin esitellyn CI/CD-putken kanssa, jolloin putki ohjelmallisesti tehtävästä konfiguraatiomuutoksesta aina tuotantokäyttöön saattamiseen asti voidaan tehokkaasti automatisoida. Käytännön esimerkki yksinkertaisesta CI/CD-putkesta voisi olla seuraavan kaltainen:
- Ympäristön muutos lähtee liikkeelle, kun kehittäjä tai konfiguroija tallentaa versionhallintaan uuden version koodista ja/tai konfiguraatioista
- Usein joku toinen henkilö arvioi uuden koodin/konfiguraation ja hyväksyy sen
- Hyväksynnän jälkeen automatisoitu työkalu kuten Jenkins, CircleCI, Bamboo, Travis CI tai GitLab ajaa tarvittavat toimenpiteet ja tuottaa muutosehdotuksen ajonaikaiseen ympäristöön
- Muutosehdotuksen hyväksynnän jälkeen automatiikka ajaa muutokset ajonaikaiseen ympäristöön
- Lopuksi toteutetaan mahdolliset automatisoidut blue/green -liikenteen siirrot tai vastaavat toimenpiteet
Esimerkkiprosessissa esiintyvät tarkistuspisteet ovat vapaaehtoisia, eli CI/CD-putken läpivienti voidaan tarvittaessa automatisoida versionhallintamuutoksesta aina ajonaikaisessa ympäristössä tapahtuviin muutoksiin saakka.
Kantava periaate CI/CD-automaatiossa on se, että versionhallinnasta (esimerkiksi Git) löytyy “totuus” kyseisen ympäristön konfiguraatiosta ja ainoa tapa tehdä muutoksia ympäristöön on versionhallinnan kautta.
Tästä periaatteesta on mahdollista tehdä poikkeuksia esimerkiksi tilanteissa, joissa kyseinen asia tehdään kertaluontoisesti (esimerkiksi sertifikaattien luominen) tai mikäli prosessissa on jotain henkilökohtaista variaatiota (esimerkiksi henkilökohtaiset pääsyavaimet pilviympäristöön). Kannattaa kuitenkin vakavasti harkita, että voisiko myös tällaiset asiat hoitaa ohjelmallisesti.
Teoriasta käytäntöön - Google Cloud & Terraform
Nyt kun teoria on hallussa, on aika kääriä hihat ja kokeilla IaC:tä käytännössä! Artikkelin jälkimmäisessä osassa opit askel askeleelta ottamaan Googlen pilvipalvelut hallintaan koodin avulla Terraform-työkalua käyttäen.
Osa 2 - Google Cloud -infrastruktuurin hallinta Terraformin avulla
Suurimmilla pilvipalveluilla on kaikilla omat työkalut kyseisen pilviympäristön ohjelmallisen hallintaan liittyen. Käytännössä organisaatioilla on kuitenkin usein tarve hyödyntää useampaa kuin yhtä pilvipalvelua, ja tällöin myös pilviresurssien hallintatyökalu kannattaa valita tarpeen mukaan.
Terraform on työkalu, jonka avulla voit hallita resursseja sekä Googlen, AWS:n että Azuren pilvipalveluissa. Tässä artikkelissa Terraformia käytetään yhdessä Google Cloud Platformin (GCPn) kanssa. Huomiothan, että jos teet vastaavat toimenpiteet omassa ympäristössäsi, niistä voi kertyä kustannuksia tai tekemilläsi konfiguraatioilla voi olla turvallisuusvaikutuksia. Ensimmäisiä kokeiluja varten kannattaakin perustaa Googlen pilvipalveluun testikäyttäjä ja testitili, jotta et vahingossa mene aiheuttamaan tuotantokäytössä oleville ympäristöillesi ongelmia.
Googlen pilvipalvelussa olevat ilmaiseksi käytössä olevat palvelut saattavat riittää artikkelin ympäristöjen rakentamiseen, mutta artikkelissa käytetty Suomen konesali ei esimerkiksi kuulu Googlen ilmaiseen tasoon. Kannattaa siis olla tarkkana, mitä palveluita otat käyttöön ja mihin konesaliin ne luodaan. Lisäksi esimerkeissä luotava palvelutili ja sen käyttöoikeustiedot saattavat aiheuttaa tietoturvariskin, jos niiden tietoturvallisuudesta ei huolehdita.
Google Cloudin komentorivityökalujen käyttöönotto
Oheiset esimerkit ovat esitelty Macin avulla, mutta sovellettavissa myös muissa ympäristöissä. Esimerkeissä käytetään komentorivityökaluja. Macille kannattaa ensin asentaa aputyökalu Homebrew, jonka avulla asennetaan ja päivitetään muut tarvittavat työkalut. Ohjeet Homebrewn asentamiseen löydät osoitteesta https://docs.brew.sh/Installation. Kaikki käytetyt työkalut voi myös asentaa erikseen, mikäli et halua tai voi käyttää Homebrewta.
Ennen muiden työkalujen asentamista Macille on hyvä varmistaa, että Xcode-komentorivityökalut ovat myös asennettuina, koska osa komentorivityökaluista ei toimi ilman niitä. Käytännössä asennus pitäisi onnistua komennolla xcode-select —install. Tarkemmat ohjeet löytyvät Applen Xcode -ohjeistuksesta.
Homebrewn asennuksen jälkeen voit asentaa Google Cloudin komentorivityökalut oheisella komennolla:
brew cask install google-cloud-sdk
Jos käytössäsi ei ole Homebrewta, voit asentaa samat työkalut myös Googlen ohjeistuksen avulla: https://cloud.google.com/sdk/install.
Kirjautuminen Googlen palveluihin komentorivityökaluilla
Seuraavat esimerkit vaativat, että olet Google Cloud Platformin (GCP) käyttäjä. Voit halutessasi ottaa Google pilvipalvelut kokeiluun linkin https://cloud.google.com/start/ kautta löytyvien ohjeiden avulla.
Tämän jälkeen voit kokeilla kirjautua Googlen pilvipalveluun komentoriviltä ja kokeilla esimerkiksi listata projekteja, joita sinulla on Google Cloudissa. Ensimmäinen komento kirjautuu Googlen pilvipalveluun selaimen avulla ja toinen listaa käytössäsi olevat projektit.
gcloud auth login
gcloud projects list
Tarvittaessa voit luoda uuden projektin esimerkkejä varten tai käyttää jotain jo olemassa olevaa projektia. Huomioi kuitenkin, että uutta projektia luotaessa tulee projektin tunnisteen olla maailmanlaajuisesti uniikki, eikä siihen tule sisällyttää mitään arkaluontoista tietoa. Tästä syystä Googlen pilvipalvelun projektien tunnisteet ovat oletuksena satunnaisia sanoja ja numeroita. Korvaa oheisen esimerkin yksilollinen-projektitunniste jollakin sinulle sopivalla tunnisteella:
gcloud projects create yksilollinen-projektitunniste --name="GCP Terraform Example"
Aseta tämän jälkeen kyseinen projekti käytössä olevaksi oletusprojektiksi:
gcloud config set project yksilollinen-projektitunniste
Laskutuksen salliminen uudelle projektille
Ennen kuin uuteen projektiin voidaan perustaa palveluita, täytyy projekti kytkeä laskutusasetuksiin. Voit hoitaa asian suoraan komentoriviltä etsimällä ensin laskutustilin tunnisteen ja kytkemällä sen jälkeen laskutustunniste uuteen projektiisi.
Laskutustilin tunniste selvitetään alla olevalla komennolla:
gcloud beta billing accounts list
Huomioi, että mikäli komentoja suoritettaessa tarvitaan ottaa käyttöön uusia palveluita Googlen pilvestä, sinulta kysytään aina lupa. Esimerkiksi tätä artikkelia kirjoitettaessa laskutukseen liittyvät komentorivitoiminnot ovat vielä beta-vaiheessa, ja komennon suorituksen yhteydessä sinulta varmistetaan, haluatko ottaa beta-komponentit käyttöön (gCloud Beta Commands). Samaten ensimmäisellä käyttökerralla laskutukseen liittyvät rajapinnat (cloudbilling.googleapis.com) pitää hyväksyä käyttöönotettavaksi.
Tarkista edellisen komennon tuloksesta laskutustilin 0X0X0X-0X0X0X-0X0X0-muotoa oleva tunniste ja käytä sitä alla näkyvän komennon yhteydessä. Kyseinen komento linkittää aiemmin luomasi projektin laskutustiliin.
gcloud beta billing projects link yksilollinen-projektitunniste \
--billing-account 0X0X0X-0X0X0X-0X0X0X
Terraformin asennus
Terraformin asentamisessa kannattaa huomioida, että usein Terraformista tarvitaan koneella samanaikaisesti useita versioita. Tämä johtuu siitä, että mikäli koneellasi on useita Terraform-pohjaisia projekteja, voi niiden käyttämä versio Terraformista olla eri. Esimerkiksi 0.11- ja 0.12-versioiden välillä oli suuria eroja, eikä samaa Terraformin versiota voinut käyttää tukemaan eri versioiden mukaisia konfiguraatioita.
Alla näkyvässä listauksessa asennetaan ensin TFEnv, joka mahdollistaa Terraformin useamman version samanaikaisen käytön. Tämän jälkeen TFEnvillä listataan käytössä olevat Terraformin versiot ja asennetaan niistä kirjoitushetkellä uusin, eli versio 0.12.20.
brew install tfenv
tfenv list-remote
tfenv install 0.12.20
Palvelutunnusten luonti Googlen pilveen Terraformia varten
Jotta Terraform voi ajaa konfiguraatioita omalta koneeltasi pilviympäristöön, täytyy pilvipalveluun luoda tunnukset, joilla Terraform pääsee operoimaan ympäristöjä. Tällaista käyttötarkoitusta varten pilvipalveluun luodaan ns. palvelutunnukset (Service Account -tunnukset), joita hallinnoidaan erillään käyttäjän normaaleista tunnuksista. Palvelutunnukset on tarkoitettu nimenomaan ohjelman tai automaation käytettäviksi, eikä ihmisten käyttöön.
Seuraavassa esimerkissä palvelutunnukset luodaan Google Cloudin webbiselaimella käytettävän konsolin avulla. Samalla voit tarkistaa, että aiemmin komentoriviltä luomasi projekti näkyy oikein konsolissa.
Kirjaudu sisään Googlen selainpohjaiseen konsoliin osoitteessa https://console.cloud.google.com/. Valitse ensin aiemmin komentoriviltä luomasi projekti konsolin yläpalkista:
Valitse tämän jälkeen konsolista IAM & admin -> Service accounts -> Create service account:
Anna uudelle palvelutunnukselle nimi ja id, esimerkiksi:
- Service account name:
terraform-service-account-esim - Service account id:
terraform-service-account-esim
Lisää seuraavalla sivulla kyseiselle palvelutunnukselle oikeudet projektin resurssien muokkaamiseen valitsemalla Role: Project –> Editor. Kannattaa aina huomioida, että tarvittavat oikeudet rajataan mahdollisimman tiukasti, vaikka tässä esimerkissä asia ei oteta olennaisesti huomioon.
Luo tilin yhteydessä käytettävä tunnisteavain Create key -toiminnolla, ja lataa avain JSON-tiedostomuodossa omalle koneellesi:
Huomioi, että tämä tiedosto on avain valtakuntaan ja sen turvallisuudesta on pidettävä huolta. Käytännössä tämä avain antaa pääsyn GCP-resursseihisi, joten älä jaa avainta kenenkään kanssa ja säilytä sitä turvallisessa paikassa tietokoneellesi. Avain ja siihen liittyvä Service Account kannattaa poistaa käytön jälkeen, jos et aio jatkaa sen käyttöä piakkoin. Voit aina luoda uuden avaimen ja Service Account -tilin tarvittaessa.
Avaimen luomisen ja lataamisen jälkeen, palaamme takaisin komentoriville. Aseta ympäristömuuttuja osoittamaan kyseiseen avaimeen, koska tarvitset sitä jatkossa Terraformin käytön yhteydessä.
export GOOGLE_CLOUD_KEYFILE_JSON=~/polku/json/tiedostoon
Voi olla hyödyllistä laittaa kyseinen ympäristömuuttujan asetus käynnistyskomentosarjaan (esim. ~/.zshrc) varmistaaksesi, että se on aina asetettuna. Tämä toki riippuen siitä, tarvitsetko käyttöösi useita avaimia eri projekteihin tai käyttöoikeuksiin liittyen.
Terraformin valjastaminen käyttöön Googlen pilvipalveluiden kanssa
Luo seuraavaksi sopiva hakemisto, johon alat keräämään Terraformiin liittyviä määritystiedostoja. Luo tähän hakemistoon tyhjä main.tf -tiedosto, joka tulee toimimaan Terraformilla määritettävän ympäristön ytimenä.
Aloitetaan uuden ympäristön rakentaminen main.tf -tiedostoon määrittämällä Google Cloud käytettäväksi palveluntarjoajaksi. Alla olevassa esimerkissä käytetään Googlen Suomen konesalia (region = "europe-north1"). Huomioi, että Suomen konesali ei alueena sisälly Googlen Always free products -palveluihin. Tästä syystä voi olla, että haluat käyttää tiettyjä US-alueita, jotka kuuluvat edellä mainittuun sisältöön. Voit tarkistaa free tier -palvelut täältä: https://cloud.google.com/free/docs/gcp-free-tier
# Google pilvipalvelutarjoajana
provider "google" {
project = "yksilollinen-projektitunniste"
region = "europe-north1"
zone = "europe-north1-a"
}
Tallenna muutokset main.tf -tiedostoon. Siirry komentorivillä siihen hakemistoon, johon tallensit main.tf -tiedoston. Aja tämän jälkeen komentorivillä oheinen komento, joka lataa tarvittavat Terraform-tiedostot koneellesi ja valmistelee Terraformin käytön kyseisessä hakemistossa:
terraform init
Ensimmäinen virtuaalikone - Plan-vaihe
Uuden virtuaalikoneen määrittämistä varten tarvitset tietoosi, mitä vaihtoehtoja Googlen pilvipalvelussa on virtuaalikoneen pohjaksi, ja vaihtoehtojen joukosta sinun pitää valita haluamasi kuva (image), jota käytetään koneen luomisen yhteydessä. Seuraavassa esimerkissä listataan käytettävissä olevat Ubuntu-käyttöjärjestelmää hyödyntävät kuvat. Komennossa käytetty filtteröintioperaattori ~ tarkoittaa säännönmukaisia lausekkeita (regular expressions).
gcloud compute images list --filter="name~.*ubuntu.*"
Huomaa, että edellinen komento vaatii ensimmäisellä kerralla compute.googleapis.com -rajapinnan käyttöönoton, joten hyväksy kyseisen API:n käyttöönotto tarvittaessa.
Lisää uuden virtuaalikoneresurssin määritys main.tf -tiedostoon seuraavan esimerkin mukaisesti. Kopioi edellisessä kohdassa tulostuneesta virtuaalikoneiden listasta haluamasi kuvan projekti- ja nimi-tiedot image -kohtaan. Esimerkissä käytetään kuvaa, jonka projekti on ubuntu-os-cloud ja nimi on ubuntu-1910-eoan-v20200129. Määritä uuden koneen tyypiksi esimerkiksi pienin f1-micro ja lisää sille haluamasi nimi, esimerkissä käytetään nimeä infrastructure-as-code-sample-instance. Samassa yhteydessä voit myös määrittää käytettävän VPC-verkon. Oletuksena kaikissa projekteissa on käytössä default-niminen verkko, ellet ole erikseen sitä poistanut.
# Google pilvipalvelutarjoajana
provider "google" {
project = "yksilollinen-projektitunniste"
region = "europe-north1"
zone = "europe-north1-a"
}
# Uuden virtuaalikoneen luonti Terraformin avulla
resource "google_compute_instance" "instance" {
name = "infrastructure-as-code-sample-instance"
machine_type = "f1-micro"
# Oletuksena, että automaattisesti luotu verkko default on edelleen käytössä.
network_interface {
network = "default"
}
# Virtuaalikoneen perustuksessa käytettävän kuvan projekti ja nimi.
boot_disk {
initialize_params {
image = "ubuntu-os-cloud/ubuntu-1910-eoan-v20200129"
}
}
}
Tämän jälkeen voit kokeilla infrastruktuurimuutosten suunnittelua alla näkyvällä plan-komennolla. Kyseinen komento tarkastaa tekemiesi määritysten sisällön sekä ympäristön nykyisen tilan. Vertailemalla näitä kahta tilaa Terraform suunnittelee tarvittavat muutokset kyseiseen ympäristöön. Itse ympäristöä ei kuitenkaan vielä muuteta tässä vaiheessa, vaan se tehdään myöhemmin erillisellä apply-komennolla. Suunnittelukomennon yhteydessä määritetty -out -parametri kirjoittaa suunnittelun tulokset erilliseen tiedostoon, jotta varsinainen ympäristön muuttaminen voidaan varmasti tehdä samoilla tiedoilla, joita käytettiin suunnittelussa.
terraform plan -out tfplan
Tuloksena pitäisi tulla suunnitelma, joka kuvaa muutoksia ympäristöön.
# google_compute_instance.instance will be created
+ resource "google_compute_instance" "instance" {
+ can_ip_forward = false
+ cpu_platform = (known after apply)
+ deletion_protection = false
+ guest_accelerator = (known after apply)
+ id = (known after apply)
+ instance_id = (known after apply)
+ label_fingerprint = (known after apply)
+ machine_type = "f1-micro"
+ metadata_fingerprint = (known after apply)
+ min_cpu_platform = (known after apply)
+ name = "infrastructure-as-code-sample-instance"
+ project = (known after apply)
+ self_link = (known after apply)
...
Muutosten ajaminen pilviympäristöön - Apply-vaihe
Tarkistettuasi läpi muutokset, joita Terraform olisi tekemässä pilviympäristöön, voit ajaa ne erillisellä apply-komennolla. Muutosten ajaminen luo tai muuttaa tarvittavat resurssit pilvipalveluun.
terraform apply tfplan
Terraformin tekemät muutokset näkyvät komennon ajamisen jälkeen ruudulla. Muutoksen aiheuttama Terraformin sisäinen tila tallennetaan paikalliseen terraform.tfstate -tiedostoon, joka ei tule hävittää. Kyseisen tiedoston avulla voit myöhemmin poistaa luomasi resurssit helposti. Kun Terraformia käytetään laajemmassa mittakaavassa usean henkilön tiimissä, ympäristön tilatiedot kannattaa pitää tallennettuna yhteiskäyttöisessä pilvipalvelukohtaisessa paikassa.
Tässä vaiheessa voit käydä katsomassa Googlen selainpohjaisessa konsolissa, että uusi virtuaalikone todella ilmestyi Googlen pilvipalveluun. Löydät sen kohdasta Compute Engine -> VM Instances.
Onneksi olkoon, nyt olet saanut virtuaalikoneen luotua ohjelmallisesti! Voit samantien kokeilla tehdä muutoksia virtuaalikoneen määrityksiin. Voit laittaa esimerkiksi seuraavat määritykset koneen label-tietoihin.
...
resource "google_compute_instance" "instance" {
labels = {
environment = "development",
createdby = "terraform"
}
...
Tämän jälkeen voit kokeilla uudestaan plan ja apply -komentoja, jotta arvioida ensin tehtävät muutokset ympäristöön ja sen jälkeen toteuttaa ne.
terraform plan -out tfplan
Suunnitteluvaiheessa on erityisesti hyvä huomioida, että Terraform ilmaisee ~ -merkinnällä, että se olisi muuttamassa olemassa olevaa resurssia ja merkinnällä +, että se olisi lisäämässä jotakin.
~ labels = {
+ "createdby" = "terraform"
+ "environment" = "development"
}
Erityisen tarkkana tulee olla kohdissa, joissa Terraform on korvaamassa olemassa olevaa resurssia, jonka se ilmaisee merkinnällä -/+. Tällöin on tietenkin vaara, että jotain tietoa häviää kun kyseinen resurssi ensin poistetaan ja sitten lisätään takaisin.
Voit ajaa muutokset ympäristöön tutulla apply-komennolla, jonka lisää määritellyt label-arvot virtuaalikoneeseen.
terraform apply tfplan
Entäpä jos teen muutoksia käsin ohi Terraformin?
Nyt jos ajat planningin uudestaan, huomaat että Terraform ei ole suunnittelemassa mitään muutoksia ympäristöön. Toisin sanoen Terraformin tiedostoissa, tiedostoon tallennetussa tilassa tai varsinaisessa pilviympäristössä ei ole mitään, mikä vaatisi muutoksia ympäristöön ja näin ne vastaavat toisiaan.
terraform plan -out tfplan
...
No changes. Infrastructure is up-to-date.
This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.
Muutosten tekeminen ympäristöön Terraformin ohi ei ole suotavaa, mutta joskus tietenkin näin voi vahingossa käydä. Esimerkin omaisesti voimme lisätä ylimääräisen labelin äsken luotuun instanssiin Googlen selainpohjaisen pilvikonsolin kautta.
Nyt jos tämän muutoksen jälkeen ajamme uudestaan Terraformin plan-vaiheen huomaamme, että Terraform huomaa eron toivotun (main.tf) ja todellisen ympäristön välillä. Tästä syystä se ehdottaa plan-vaiheessa, että kyseinen käsin lisätty label poistettaisiin tiedoista - -merkinnällä (miinus).
terraform plan -out tfplan
...
# google_compute_instance.instance will be updated in-place
~ resource "google_compute_instance" "instance" {
…
~ labels = {
"createdby" = "terraform"
"environment" = "development"
- "manuaalisesti" = "lisatty-ohi-terraformin" -> null
}
...
Mikäli ajat plan-apply -syklin kokonaisuudessaan, niin kyseinen äskettäin käsin lisätty label poistetaan instanssin tiedoista automaattisesti ja näin ympäristön tila vastaa jälleen sille asetettua tavoitetta. Ajettuasi applyn uudestaan käy vielä tarkistamassa konsolista, että käsin lisäämäsi label todellakin poistui.
Luotujen resurssien poisto
Lopuksi on hyvä poistaa kaikki luodut resurssit, mikäli et enää tarvitse niitä. Tässä artikkelissa Terraformin avulla luotu instanssi voidaan myös poistaa Terraformin avulla. Samalla se poistaa kaikki Terraformin avulla kyseisessä kansiossa määritellyt ja käyttöönotetut resurssit. Huomattavaa tietenkin on, että destroy-komentoa pitää käyttää hyvin harkiten tuotannossa tai tuotannon kaltaisissa ympäristöissä.
terraform destroy
...
Plan: 0 to add, 0 to change, 1 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Kun vastaat tähän kysymykseen yes, kaikki Terraformin tässä yhteydessä luomat resurssit poistetaan Googlen pilvipalvelusta. Poistamisen jälkeen on kuitenkin hyvä vielä varmistaa konsolin kautta, että aiemmin konsolissa näkynyt VM instances -palvelin on todellakin hävinnyt palvelusta.
Lopuksi kannattaa vielä poistaa luomasi palvelutunnus Googlen konsolin IAM & Admin -> Service accounts -osiosta. Tai poista ainakin omalle koneelle lataamasi JSON-avain, ellet halua harjoitella gcloud-komennon tai Terraformin ajamista enemmänkin.
Mikäli instanssin poisto alkoi kaduttamaan, niin instanssin takaisinsaanti on muutaman sekunnin plan-apply -syklin takana. Toki tällöin kyseessä on saman mallin pohjalta luotava täysin uusi ympäristö ja aiempaan ympäristöön mahdollisesti tallentunut data on menetetty destroy-komennon yhteydessä.
Toivottavasti sait tästä kirjoituksesta vahvistusta omien Infrastructure-as-Code -ajatuksiesi tueksi! Me NordHerolla autamme, kun haluat ottaa pilvipalveluista kaiken hyödyn irti.