Hyppää sisältöön

Welcome to our weekly research support coffee hour on Zoom! Click here for more information.

Warning!

Puhti scratch disk is becoming very full (80+ % ) resulting in performance degradation. Everybody is advised to only keep actively processed data on scratch, all other data should be deleted, transferred to host institute or stored in Lumi-O. No new quota will be granted. Click here for a tool for examining your disk usage.

Levykuvan luominen

On useita syitä tehdä oma Docker-image, mutta pääasiassa niitä on kaksi. Sovellukselle, jota haluat ajaa, ei ole saatavilla Docker-imagea, tai image on saatavilla, mutta se ei toimi OpenShiftissä. Koska OpenShift on suunniteltu jaetuksi klusteriksi, jossa eri tiimien käyttäjät ajavat sovelluksia samalla laitteistolla, OpenShiftin täytyy asettaa rajoituksia ja ajaa asioita eri tavalla kuin tavallisessa Kubernetes-klusterissa.

Rahdin rekisterissä imagen kokoraja on 5 Gt. Mitä suurempi image on, sitä hankalampaa sen kanssa on työskennellä. Sen noutaminen kestää kauemmin, ja se täyttää solmun image-välimuistin nopeammin. Yli 1 Gt:n imagea pidetään jo erittäin suurena. Katso artikkeli Docker-imagejen pitämisestä pieninä

Imagejen rakentaminen paikallisesti

Tässä esimerkissä käytämme virallista nginx-imagea, joka on rakennettu Alpine Linux -jakelun päälle, ja teemme tarvittavat muutokset, jotta se toimii OpenShiftissä.

Imagen rakentamiseen paikallisesti tietokoneella tarvitaan kolme vaihetta.

  • Ensin täytyy kirjoittaa Dockerfile, esimerkiksi tämä:
FROM nginx:alpine

# support running as arbitrary user which belongs to the root group
RUN chmod g+rwx /var/cache/nginx /var/run /var/log/nginx && \
    chown nginx:root /var/cache/nginx /var/run /var/log/nginx && \
    # users are not allowed to listen on privileged ports
    sed -i.bak 's/listen\(.*\)80;/listen 8081;/' /etc/nginx/conf.d/default.conf && \
    # Make /etc/nginx/html/ available to use
    mkdir -p /etc/nginx/html/ && chmod 777 /etc/nginx/html/ && \
    # comment user directive as master process is run as user in OpenShift anyhow
    sed -i.bak 's/^user/#user/' /etc/nginx/nginx.conf

WORKDIR /usr/share/nginx/html/
EXPOSE 8081

USER nginx:root

Dockerfile:

  1. Antaa kirjoitusoikeudet root-ryhmälle (ei root-käyttäjälle) useisiin hakemistoihin, joihin nginxin täytyy voida kirjoittaa (/var/cache/nginx, /var/run, /var/log/nginx ja /etc/nginx/html/). Sovelluksia ajetaan satunnaisella käyttäjällä ja root-ryhmällä.
  2. Muuttaa portin, jota nginx kuuntelee, koska vain root saa kuunnella etuoikeutettuja portteja (<1024).
  3. Ja lopuksi kommentoi pois user-konfiguraatiodirektiivin.

Alkuperäisessä nginx:alpine-imagessa on 5 kerrosta, ja lisäämme siihen uuden (RUN).

Yksinkertaisempi Dockerfile-esimerkki voisi olla:

FROM alpine

RUN apk add git

Tämä vain asentaa gitin alpine-imagen päälle ja lisää myös uuden kerroksen.

Katso Dockerfile -viitedokumentaatio.

Sitten imagen docker.io/user/name:tag rakentamiseen täytyy käyttää seuraavaa komentoa:

docker build . -t docker.io/user/name:tag

Ja lopuksi imagen julkaisemiseen:

docker push docker.io/user/name:tag

Kontti-imagejen rakentaminen Rahdissa

Alla olevissa menetelmissä käytetään Rahtia imagejen rakentamiseen.

Paikallisen kansion käyttäminen rakentamiseen

Tällä menetelmällä voidaan rakentaa image paikallisesta kansiosta, joka sisältää Dockerfilen ja muut tarvittavat projektitiedostot. Se on hyödyllinen silloin, kun Rahdin ei ole mahdollista tai tarkoituksenmukaista kloonata repositoriota suoraan.

Tämä olettaa, että olet valtuuttanut Rahdin komentorivisession ja luonut projektin Rahtiin. Ohjeet tähän löytyvät luvusta Komentorivityökalun käyttö.

Vaiheet:

Luo Rahti-kohtaiset määritykset komennolla oc new-build. Varmista, ettet ole hakemistossa, joka on git-versionhallinnan alainen:

$ oc new-build --to=my-hello-image:devel --name=my-hello --binary
    * A Docker build using binary input will be created
      * The resulting image will be pushed to image stream tag "my-hello-image:devel"
      * A binary build was created, use 'start-build --from-dir' to trigger a new build

--> Creating resources with label build=my-hello ...
    imagestream.image.openshift.io "my-hello-image" created
    buildconfig.build.openshift.io "my-hello" created
--> Success

Sitten tarvitset Dockerfile-tiedoston. Voit käyttää mitä tahansa aiemman esimerkin Dockerfile-tiedostoa tai mitä tahansa muuta käytettävissä olevaa tiedostoa. Jotta OpenShift rakentaa imagen, siirry komennolla cd kansioon, jossa Dockerfile sijaitsee, ja käynnistä build komennolla oc start-build. Se ottaa kaikki nykyisen hakemiston tiedostot ja tulostaa build-prosessin paikalliseen päätteeseen:

oc start-build my-hello --from-dir=./ -F

Image näkyy internetiin osoitteessa image-registry.apps.2.rahti.csc.fi/<project-name>/my-hello-image:devel Docker-yhteensopiville asiakasohjelmille, mutta sen noutamiseen täytyy ensin tunnistautua.

Komentorivikäytössä Docker-yhteensopivien asiakasohjelmien kanssa Docker-repositorion salasana on pääsytunniste, joka näytetään Rahdin komentorivisession valtuutuksen yhteydessä, ja käyttäjänimi voi olla unused.

docker login -u g -p $(oc whoami -t) image-registry.apps.2.rahti.csc.fi

Source-to-Image-mekanismin käyttäminen

OpenShift mahdollistaa koodin rakentamisen ja käyttöönoton ilman Dockerfile-tiedoston kirjoittamista. Tätä kutsutaan nimellä Source to Image eli s2i. Sitä käytetään ajamalla oc new-app URL#branch, jossa #branch on valinnainen. Käytetään esimerkiksi virallista Python-esimerkkikoodia:

$ oc new-app https://github.com/CSCfi/nodejs-16-rahti-example.git
--> Found Docker image 9d200cd (7 weeks old) from Docker Hub for "node:16.15.0"

    * An image stream tag will be created as "node:16.15.0" that will track the source image
    * A Docker build using source code from https://github.com/CSCfi/nodejs-16-rahti-example.git will be created
      * The resulting image will be pushed to image stream tag "nodejs-16-rahti-example:latest"
      * Every time "node:16.15.0" changes a new build will be triggered
    * This image will be deployed in deployment config "nodejs-16-rahti-example"
    * Port 8080/tcp will be load balanced by service "nodejs-16-rahti-example"
      * Other containers can access this service through the hostname "nodejs-16-rahti-example"
    * WARNING: Image "node:16.15.0" runs as the 'root' user which may not be permitted by your cluster administrator

--> Creating resources ...
    imagestream.image.openshift.io "node" created
    imagestream.image.openshift.io "nodejs-16-rahti-example" created
    buildconfig.build.openshift.io "nodejs-16-rahti-example" created
    deploymentconfig.apps.openshift.io "nodejs-16-rahti-example" created
    service "nodejs-16-rahti-example" created
--> Success
    Build scheduled, use 'oc logs -f bc/nodejs-16-rahti-example' to track its progress.
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
     'oc expose svc/nodejs-16-rahti-example' 
    Run 'oc status' to view your app.

Tee sitten ehdotuksen mukaisesti ja julkaise uusi sovellus ulkomaailmaan:

$ oc expose svc/nodejs-16-rahti-example
route.route.openshift.io/nodejs-16-rahti-example exposed

Uuden reitin konenimen saat komennolla:

oc get route nodejs-16-rahti-example

Jos syötät konenimen selaimeen, näet "Hello World!" -viestin.

Uusi build voidaan käynnistää komentoriviltä:

oc start-build nodejs-16-rahti-example

Tai käyttämällä webhookeja

Inline-Dockerfile-menetelmän käyttäminen

On mahdollista luoda uusi build käyttäen komentorivillä annettua Dockerfilea. Tällöin Dockerfile itsessään upotetaan Build-objektiin, joten ulkoista Git-repositoriota ei tarvita.

oc new-build -D $'FROM almalinux:10'

Tässä esimerkissä rakennamme imagen, joka on kopio AlmaLinux 10:stä.

On myös mahdollista luoda build annetusta Dockerfile-tiedostosta:

cat Dockerfile | oc new-build -D -

Tuonti Gitistä (yksityiset repositoriot) selainkäyttöliittymällä

Siirry kohtaan Builds -> BuildConfigs -> Create BuildConfig

Yksityisen Git-repositorion käyttöönotto Rahtiin edellyttää tarvittavan tunnistautumisen määrittämistä, jotta yksityiseen repositorioosi päästään käsiksi. Ilman asianmukaista tunnistautumista näet virheen "URL is valid but cannot be reached" (näkyy alla olevissa kuvissa). Näin ratkaiset tämän kahdella tunnistautumismenetelmällä:

create_from_private_repo

Vaihtoehto 1: Tunnisteen käyttäminen Git-tunnistautumiseen

  1. Luo henkilökohtainen pääsytunniste:

    • GitHub:

      • Siirry GitHub-tilisi asetuksiin.
      • Siirry kohtaan "Developer settings" > "Personal access tokens".
      • Napsauta "Generate new token".
      • Valitse tarvitsemasi käyttöoikeusalueet (yleensä tarvitset repo-alueen yksityisiä repositorioita varten).
      • Luo tunniste ja kopioi se.
    • GitLab:

      • Siirry GitLab-profiilisi asetuksiin.
      • Siirry kohtaan "Access Tokens".
      • Anna tunnisteelle nimi, valitse tarvittavat käyttöoikeusalueet (esim. api, read_repository) ja luo tunniste.
      • Kopioi tunniste.
  2. Lisää tunniste Rahtiin:

    • Valitse kohdassa "Source Secret" "Create new Secret"
    • Anna salaisuudelle nimi, valitse kohdassa "Authentication type" "Basic Authentication"
    • Liitä tunniste ja luo

create_rahti_source_secret

Vaihtoehto 2: Yksityisen SSH-avaimen käyttäminen Git-tunnistautumiseen

  1. Luo SSH-avainpari (jos sinulla ei vielä ole sellaista):

    • Avaa pääte ja suorita seuraava komento uuden SSH-avainparin luomiseksi:
      ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
      
    • Tämä luo kaksi tiedostoa: yksityisen avaimen (id_rsa) ja julkisen avaimen (id_rsa.pub).
  2. Lisää julkinen avaimesi Git-palveluusi:

    • GitHub:

      • Siirry GitHub-tilisi asetuksiin.
      • Siirry kohtaan "SSH and GPG keys".
      • Napsauta "New SSH key" ja liitä id_rsa.pub-tiedoston sisältö.
    • GitLab:

      • Siirry GitLab-profiilisi asetuksiin.
      • Siirry kohtaan "SSH Keys".
      • Lisää uusi SSH-avain ja liitä id_rsa.pub-tiedoston sisältö.
  3. Lisää yksityinen SSH-avain Rahtiin:

    • Valitse kohdassa "Source Secret" "Create new Secret"
    • Anna salaisuudelle nimi, valitse kohdassa "Authentication type" "SSH Key"
    • Liitä yksityisen SSH-avaimesi (id_rsa) sisältö ja luo
    • create_rahti_from_private_repo_validated

Tuonti Gitistä (yksityiset repositoriot) komentorivillä

Tämä olettaa, että käyttäjät ovat luoneet SSH-avaimet ja rekisteröineet julkisen avaimensa GitHubiin.

Kirjaudu OpenShiftin komentorivikäyttöliittymään (oc):

oc login <cluster-url>

Luo uusi projekti:

oc new-project <project-name> --display-name=<display-name> --description="csc_project:<project-id>"

Luo SSH-avainsalaisuus:

oc create secret generic <secret-name> --from-file=ssh-privatekey=<path-to-private-key> --type=kubernetes.io/ssh-auth

Linkitä salaisuus builder-palvelutiliin:

oc secrets link builder <secret-name>

Ota sovellus käyttöön:

oc new-app <repository-url> --name=<application-name>

Seuraa buildia:

  • seuraa lokeja

    oc logs -f buildconfig.build.openshift.io/<application-name>
    

  • Ensimmäinen build epäonnistuu todennäköisesti tunnistautumisongelmien vuoksi, joten aseta build-salaisuus eksplisiittisesti:

    oc set build-secret --source bc/<application-name> <secret-name>
    

  • Käynnistä uusi build:

    oc start-build <application-name> --follow
    

Julkaise sovellus:

oc expose deployment <application-name> --name=<service-name> --port=<port> --target-port=<target-port>
oc expose svc/<service-name>

Avaa sovellus:

  • Käytä URL-osoitetta, jonka saat komennolla:
    oc get route <application-name>
    

Vianmääritys

Jos buildisi epäonnistuu Rahdissa, se voi tarkoittaa, että sovelluksesi tarvitsee enemmän muistia kuin oletuksena tarjotaan. Valitettavasti resurssirajoja ja -pyyntöjä ei voi asettaa suoraan komentoriviltä sovellusta käyttöönotettaessa. Sinun täytyy käyttää YAML-määritystiedostoa tai selainkäyttöliittymää näiden asetusten määrittämiseen.

Voit luoda yaml-tiedoston ja ottaa sen käyttöön komennolla oc apply -f {your_yaml_file}.yaml tai muokata nykyistä BuildConfig-objektiasi Rahdin selainkäyttöliittymässä. Administrator-näkymässä siirry kohtaan Builds > BuildConfigs ja napsauta BuildConfigiasi. Valitse YAML-välilehti.

Kohdassa spec sinun pitäisi nähdä resources: {}. Lisää tähän limits.cpu, limits.memory, requests.cpu ja requests.memory:

resources:
  limits:
    cpu: 1
    memory: 8Gi
  requests:
    cpu: 200m
    memory: 1600Mi

Huomaa, että ne eivät voi poiketa toisistaan yli 5-kertaisesti (oletussuhde, lisätietoja täällä).

Tallenna ja suorita build uudelleen. Jos se onnistuu, tarkista metriikat ja katso, kuinka paljon muistia käytettiin. Voit säätää muistirajan 10–20 % suuremmaksi kuin käytetty määrä.

Suomenkielinen tekoälykäännös

Sisällössä voi esiintyä virheellistä tietoa tekoälykäännöksestä johtuen.

Klikkaa tästä antaaksesi palautetta