Jenkinsin käyttöönotto Kubernetesissa

CI-palvelinten asentaminen ja hallinta on kriittinen tehtävä jokaiselle IT-tiimille. Kubernetes ja sen paketinhallintatyökalu Helm tarjoavat helpon tavan räätälöidä Jenkins-asennuksia. Katsotaan, miten se tehdään ja miten lisätään Windows-build-agentteja.

Konttiratkaisut (esim. Docker) auttavat kehittäjiäsi kehittämään sovelluksia ja toimittamaan ne testattaviksi tai käyttöönotettaviksi ilman, että heidän tarvitsee huolehtia ympäristön määrityksistä tai kohdata ”toimii-minun-koneellani” -ilmiötä.

Kubernetes (eli k8s) tarjoaa orkestrointikehyksen kontitetuille sovelluksille. Kehys varmistaa kontitetun sovelluksen käytettävyyden terveydentilan seurannalla ja palauttamalla vikaantuneet kontit.

Kontit ja k8s nopeuttavat kehitys-build-testaus-käyttöönotto-sykliäsi vähentämällä infrastruktuurin hallinnan kuormitusta. Uudet työkalut hyödyntävät k8s:ää ja kontteja, jotta infrastruktuuria, konfiguraatioita ja jopa sovellusten käyttöönottoja voidaan luoda ja hallita koodilla. Tällaisia työkaluja ovat Kops – k8s-klusterien hallintatyökalu – ja Helm (k8s:n paketinhallintatyökalu). Näiden työkalujen avulla voit automatisoida k8s-klusterisi luomisen ja hallinnan. Lisäksi niiden avulla voit ottaa sovelluksiasi helposti käyttöön ja hallita niitä k8s-klusterissa.

Kopsin avulla voit määritellä k8s-klusterisi Yaml-muotoisilla manifestitiedostoilla. Kun klusteri on luotu, Kops ylläpitää klusterisi tilaa S3-säilössä.

Helmin avulla voit hallita sovellusten käyttöönottoa k8s-klusterissasi. Se tarjoaa joukon valmiita paketteja, joita kutsutaan charteiksi ja jotka voit ottaa käyttöön k8s-klusterissasi sellaisenaan. Vaihtoehtoisesti Helmillä voit luoda oman chartin ja käyttää sitä uudelleen.

Miten Jenkins CI -palvelin otetaan käyttöön AWS:n k8s-klusterissa?

Tässä kirjoituksessa otamme Jenkins-CI-palvelimen käyttöön AWS:n k8s-klusterissa Helmin avulla ja yhdistämme siihen sitten Windows-agentteja. Jenkinsin käyttöönotto k8s:ssä edellyttää seuraavia vaiheita:

1. Luo k8s-klusteri AWS:ään Kopsilla tämän oppaan ohjeiden mukaan.

2. Kun klusteri on luotu, sinun on asennettava Kubectl ja sitten Helm koneelle, jolla hallitset klusteriasi. Asennuksen jälkeen Helm on alustettava, jotta se asentaa palvelimensa automaattisesti. Tätä palvelinta kutsutaan Tilleriksi käyttämässäsi k8s-klusterissa.

3. Nyt kun sinulla on klusteri ja Helm on asennettu ja alustettu, voit asentaa vakaan Jenkins-chartin k8s-klusteriin seuraavalla komennolla: helm install --name <<your-release-name>> stable/jenkins

Luo k8s-klusteri AWS:ään Kopsilla tämän oppaan ohjeiden mukaan.

Kun klusteri on luotu, sinun on asennettava Kubectl ja sitten Helm koneelle, jolla hallitset klusteriasi. Asennuksen jälkeen Helm on alustettava, jotta se asentaa palvelimensa automaattisesti. Tätä palvelinta kutsutaan Tilleriksi käyttämässäsi k8s-klusterissa.

Nyt kun sinulla on klusteri ja Helm on asennettu ja alustettu, voit asentaa vakaan Jenkins-chartin k8s-klusteriin seuraavalla komennolla: helm install --name <<your-release-name>> stable/jenkins

Siinä kaikki! Klusterissasi on nyt Jenkins-master, joka on avattu ulkomaailmalle kuormantasaajalla (tässä tapauksessa AWS ELB). Helmin tuloste kertoo, miten saat Jenkins-masterisi URL-osoitteen ja järjestelmänvalvojan salasanan.

Mitä taustalla tapahtui tuolla yhdellä Helm-komennolla?

Alla oleva kuva näyttää, mitä tapahtui. Helm loi k8s-klusteriisi deploymentin ja pari palvelua. Deployment määrittelee halutun tilan podille, joka sisältää Jenkins-masterin. Näin k8s voi käynnistää uuden podin, jossa Jenkins-master toimii Docker-kontissa, jos nykyinen pod lakkaa toimimasta. Koska podit ovat lyhytikäisiä, tässä vaiheessa luodut palvelut mahdollistavat sen, että muut podit ja sovellukset voivat tavoittaa Jenkins-masterin DNS-palvelunimellä taustalla olevan podin IP-osoitteen sijaan. Jenkins-masterin portti on avattu ulkoisesti, jotta siihen pääsee mistä tahansa internetistä, pilvipalveluntarjoajan kuormantasaajalla (tässä tapauksessa AWS ELB). Riippumatta siitä, mitä klusterin sisäisille podeille tapahtuu, pääset aina Jenkins-masteriisi kuormantasaajan IP-osoitteen kautta. Jenkins-agenttipalvelu on kuitenkin avattu Cluster IP:llä, joten siihen pääsee vain klusterin sisältä.

Mutta hetkinen! Miten voin räätälöidä Jenkins-konfiguraationi?

Ei huolta: Jenkins Helm -chartissa on määritettävien parametrien tiedosto, jota voit räätälöidä. Voit esimerkiksi määrittää, mitkä lisäosat asennetaan Jenkinsiin ja mitä Docker-imageja käytetään sekä masterille että agenteille.

Saatat miettiä, missä agentit ovat.

Käytimme Jenkins Helm -chartin mukana toimitettavaa oletuskonfiguraatiota. Tässä konfiguraatiossa Jenkinsissä on asennettuna Jenkins Kubernetes -lisäosa. Lisäosan avulla master voi luoda tarpeen mukaan agentteja Docker-kontteina podeihin. Kun työ odottaa suorittamista, master luo siis agentin lennossa k8s-klusteriisi. Agentti suorittaa työn, minkä jälkeen se poistetaan.

Nyt saatat miettiä, voiko käytössä olla Windows-agentteja, eikö niin?

Aiemmassa kirjoituksessa käsittelimme Windows-tuen nykytilaa k8s:ssä ja päädyimme siihen, ettei se vielä ole riittävän kypsä tuotannonkaltaisiin ympäristöihin, kun hallitset k8s-klusteriasi Kopsilla. Siksi suosittelimme, että Windows-isännät luodaan klusterin ulkopuolelle ja niiden annetaan kommunikoida k8s-klusteriisi käyttöönotettujen sovellusten kanssa. Seuraava kaavio havainnollistaa käyttämäämme arkkitehtuuria:

Loimme erillisen AWS VPC:n Windows-virtuaalikoneille, joissa ajetaan pysyviä Jenkins-slaveja.

Windows-slavejen yhdistäminen Jenkins-masteriin

Helm on altistanut Jenkins-agenttipalvelun (joka vastaa slavejen yhdistämisestä) vain klusterin käyttöön Cluster IP -palvelutyypillä. Helm olettaa, että kaikki slavet yhdistyvät k8s-klusterin sisältä. Kuten edellä kuvasimme, Windows-slavet yhdistyvät kuitenkin klusterin ulkopuolelta.

Jotta Jenkins-agenttipalvelu olisi Windows VPC:stä yhdistävien Windows-slavejen käytettävissä, käytettävissä on kaksi vaihtoehtoa:

1. Altista slave-agentti NodePort-palvelutyypilläNodePort altistaa palvelun tietyssä portissa kaikissa klusterin noodeissa. Tällöin palvelu on käytettävissä klusterin sisältä Cluster IP:iden kautta, k8s VPC:n sisältä AWS:n yksityisten IP-osoitteiden kautta sekä ulkoisesti (k8s VPC:n ulkopuolelta) minkä tahansa k8s-noodin julkisen IP-osoitteen kautta. Tämän lähestymistavan ongelma on, että k8s-noodit eivät ole pysyviä: kun ne poistuvat käytöstä, ne korvataan uusilla noodeilla ja siten myös uusilla ulkoisilla IP-osoitteilla.

2. Vaihtoehtoisesti altista slave-agentti LoadBalancer-palvelutyypilläKuormantasaaja yhdistää aina Windows VPC:stä Jenkins-agenttipalveluun palvelun sisäisestä IP-osoitteesta riippumatta. Tietoturvasyistä liikenne tulee jälleen sallia vain Windows VPC:stä.

Altista slave-agentti NodePort-palvelutyypilläNodePort altistaa palvelun tietyssä portissa kaikissa klusterin noodeissa. Tällöin palvelu on käytettävissä klusterin sisältä Cluster IP:iden kautta, k8s VPC:n sisältä AWS:n yksityisten IP-osoitteiden kautta sekä ulkoisesti (k8s VPC:n ulkopuolelta) minkä tahansa k8s-noodin julkisen IP-osoitteen kautta. Tämän lähestymistavan ongelma on, että k8s-noodit eivät ole pysyviä: kun ne poistuvat käytöstä, ne korvataan uusilla noodeilla ja siten myös uusilla ulkoisilla IP-osoitteilla.

Vaihtoehtoisesti altista slave-agentti LoadBalancer-palvelutyypilläKuormantasaaja yhdistää aina Windows VPC:stä Jenkins-agenttipalveluun palvelun sisäisestä IP-osoitteesta riippumatta. Tietoturvasyistä liikenne tulee jälleen sallia vain Windows VPC:stä.

Nyt k8s-klusterissasi voi olla Jenkins-master, joka pystyy luomaan Linux-slaveja tarpeen mukaan klusterin sisällä. Lisäksi se voi yhdistää k8s-klusterin ulkopuolella virtuaalikoneissa ajettaviin pysyviin Windows-slaveihin. Tulevassa kirjoituksessa käsittelemme Jenkinsin Windows-build-slavejen provisiointia Packerilla ja Terraformilla. Pysy kuulolla!