Page tree
Skip to end of metadata
Go to start of metadata

Katso tämän ohjeen yksityiskohtainen läpikäynti Teknisen iltapäivän kevät 2019 videonauhoitteesta:

Weboodin kontitetun version asennus -video


Esivalmistelut (tarvitsee tehdä vain kerran)

 Avaa esivalmistelut...

Asenna Docker CE ja docker-compose: https://docs.docker.com/install/

 

Dockerin objekteja (imaget, kontit ja volumet) varten, kannattaa käyttää oma kiintolevyosiota, jossa tilaa 50-100 Gt. Weboodi tarvitsee vain alle 5 Gt, mutta tilanne saattaa muuttua jatkossa

Docker säilöö objektit oletuksena polkuun /var/lib/docker

Suositeltavaa on käyttää storage driverinä overlay 2:sta, mutta tämä vaatii kernelin version 4.0 or uudempi ja RHEL:n or CentOS:n tapauksessa versio 3.10.0-514 tai uudempi.

Tarkemmat ohjeet overlay2:n käyttöön:

https://docs.docker.com/storage/storagedriver/overlayfs-driver/

Tarkemmat ohjeet devicemapperin käyttöön (ei suositeltu enää)

https://docs.docker.com/storage/storagedriver/device-mapper-driver/

Esimerkiksi Red Hatin tapauksessa:

Asenna yum-utils.

sudo yum install -y yum-utils

 

Asenna device-mapper-persistent-data and lvm2 (vain jos haluat käyttää devicemapperia overlay2:n sijasta)

  sudo yum install device-mapper-persistent-data \
       lvm2




Lisää Dockerin registry

sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo


 
Asenna docker, docker-compose sekä containerd.

 sudo yum install -y docker-ce docker-compose docker-ce-cli containerd.io

Huom!

CentOS:lle Docker-compose täytyy asentaa erikseeen

 sudo curl -L "https://github.com/docker/compose/releases/download/1.23.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

sudo chmod +x /usr/local/bin/docker-compose

Dockerin konfigurointi

 Avaa dockerin konfigurointi...

Määritä Dockerin konfiguraatio tiedostoon /etc/docker/daemon.json, esim

Overlay2:lle

 

{
  "storage-driver": "overlay2"
}

 

Device-mapperille

{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.directlvm_device=/dev/sdX",
    "dm.thinp_percent=95",
    "dm.thinp_metapercent=1",
    "dm.thinp_autoextend_threshold=80",
    "dm.thinp_autoextend_percent=20",
    "dm.directlvm_device_force=false"
  ]
}

 


 HUOM: devicemapper on deprekoitu, ja tuki poistuu jossakin tulevassa versiossa.


 Käynnistä docker

 sudo systemctl start docker




Määritä docker käynnistymään uudelleenkäynnistyksen yhteydessä

 sudo systemctl enable docker

WebOodin asennus

 Avaa asennusohje

Luo WebOodia varten käyttäjä, joka uid on 101. Tämä on tärkeää mm. logitusta varten, esim:

 sudo groupadd -r -g 101 weboodi && \
 sudo useradd -r -u 101 -g weboodi weboodi 

Hae "asennuspaketti" Confluencesta/jostain myöhemmin päätettävästä paikasta

 

Hae asennuspaketti haluamaasi hakemistoon, esim /opt/weboodi

(tulevaisuudessa jakelukanavana saattaa olla Git-tietovarasto)

Asennuspaketissa on seuraavat tiedostot:

  •   docker-compose.yml, joka määrittelee konteissa pyörivän järjestelmän.
  •   .env, joka sisältää tarvittavat konfiguraatiovalinnat, listattuna alla taulukossa.

 

AvainSelite

org

organisaation tunniste, käytetään oikean Docker imagen valinnassa.
versionWebOodista käytettävä versio.
log4_config_pathTiedostopolku, josta log4.properties löytyy.
weboodi_config_pathTiedostopolku, josta weboodi.properties löytyy.
paytrail_config_pathTiedostopolku, josta paytrail.properties löytyy.
oodi_config_pathTiedostopolku, josta oodi.properties löytyy.
tomcat_log_pathIsäntäkoneen hakemistopolku, johon Tomcatin logit tallennetaan. Varmista, että weboodi-käyttäjällä on tähän hakemistoon kirjoitusoikeus.
weboodi_log_pathIsäntäkoneen hakemistopolku, johon Weboodin logit tallennetaan. Varmista, että weboodi-käyttäjällä on tähän hakemistoon kirjoitusoikeus.

tomcat_proxy_port

Isäntäkoneen portti, johon tuleva liikenne ohjataan Tomcatin porttiin 8009
tomcat_users_config_pathTiedostopolku, josta tomcat-users.xml löytyy.

context_config_path

Tiedostopolku, josta weboodin kontekstitiedosto löytyy löytyy.
httpd_log_pathIsäntäkoneen hakemistopolku, johon httpd:n logit tallennetaan.
httpd_conf_pathIsäntäkoneen hakemistopolku, jossa on lisäkonfiguraatio httpd:lle

 

(halutaanko jakaa myös skriptejä softan kenkimiseen, provisiontiansible löytyy jo)

Kirjaudu sisään Docker registryyn.

Kirjaudu sisään CSC:n Docker registryyn, jossa imaget säiltään komennolla

docker login reg.eden.csc.fi

Syötä CSC:ltä saamasi käyttäjätunnus ja salasana.

Uusien imagejen haku

HUOM! Docker-compose-komennot tulee ajaa siinä hakemistossa, jonka juuressa docker-compose.yml on.

Hae uusimmat imaget CSC:n registrystä ajamalla komento

docker-compose pull

WebOodin käynnistys (etupalvelin kontissa)

Käynnistä Tomcat- ja etupalvelinkontit

docker-compose up -d

siinä hakemistossa, jossa docker-compose.yml ja .env -tiedostot ovat.

Tämä komento hakeaa autoaattisesti oikean Docker imagen reg.eden.fi:stä, käynnistää tarvittavat kontit ja yhdistää ne toisiinsa.

WebOodin käynnistys (etupalvelin isäntäkoneella)

Alkuvalmistelut

Lisää Apachen configuraatioon ProxyPass ja ProxyPassReverse, joka ohjaa WebOodin polkuun tulevan liikenteen http://localhost:<valitsemasi_portti>/<weboodi_polku>.

Käynnistä Tomcat-kontti,

 

  docker-compose up -d weboodi-tomcat

WebOodin version vaihtaminen

Vaihda .env-tiedostosta muuttujan version arvo oikeaksi.

Hae uusimmat imaget CSC:n registrystä ajamalla komento, kirjaudu tarvittaessa sisään.

docker-compose pull

Aja järjestelmä alas

 docker-compose down

 

sekä, mikäli käytät kontitettua etupalvelinta

docker-compose up -d

 

tai,

 docker-compose up -d weboodi-tomcat

 

mikäli käytät isäntäkoneella asennettua etupalvelinta.

 

weboodi.tar.gz

 

 

  • No labels

2 Comments

  1. OPKn/HYn puolelta saimme tällaisia kommentteja:

    Tietoturva:

    - Kontin sisällä ajettava sovellusprosessi ei saa olla ajossa roottioikeuksilla yhtään sen enempää kuin ilman konttia ajettava sovellus. Vaikka kontin hiekkalaatikko eristääkin "rootin" omaan karsinaansa suojaten ajoympäristöä ja muita prosesseja ja kontteja, on korkattu sovellusprosessi liiallisilla oikeuksilla edelleen vakava riski esimerkiksi kyvyllään asentaa ajossa olevan kontin sisään uusia ohjelmistoja. Luonnollisesti murrettu sovellusprosessi on vakava tietoturvariski muutoinkin, mutta se ei tarkoita että kaikesta pitää tehdä hyökkääjälle helppoa. Kontitetulle sovellusprosessille on siis määriteltävä kontinsisäinen userid kontti-imagea luotaessa ja sovelluksen on testatusti toimittava näillä oikeuksilla. Koen tämän maininnan tärkeäksi, koska Docker-ekosysteemin piirissä isossa maailmassa tämä todellisuus vaikuttaa valitettavan monesti unohtuvan, ja heräsin tähän tosiasiaan itsekin huomattavan myöhään.

    - On selkeästi todettava, että Docker-image sisältää myös kaikki kontissa pyörivän sovelluksen käyttämät kirjastoriippuvuudet, ja on oltava kristallinkirkkaasti selvillä ja *aukikirjoitettuna* se, että vastuu kaikkien tietoturvakriittisten päivitysten asentamisesta on Docker-imagea paketoivalla taholla. Konttia ajavan tahon vastuu kontissa olevan sovelluksen ja sen kirjastoriippuvuuksien tietoturvapäivityksistä rajautuu vain siihen, että haetaan tarvittaessa (säännöllisesti ja riittävän usein) päivitetty image. Lisäksi on varmistuttava siitä, että Docker-imagea paketoiva taho myös päivittää sovelluksen, käytetyt kirjastot ja pohjaimagen riittävän usein, ja testaa paketin toiminnan. Teroitan ja tarkennan, että kontitetun sovelluksen käyttämät kirjastot siis *EIVÄT* päivity, vaikka konttia ajavan isäntäkoneen paketinhallinnassa asennettaisiinkin päivitys samaiseen kirjastoon. Kaikki päivitykset on leivottava Docker-imageen sen luontivaiheessa. Docker-image on siis luotava uusiksi riittävän useasti, luultavasti useammin kuin mitä WebOodin uusien versioiden julkaisusykli on. (Tietämättä tarkemmin mitä se sykli nykypäivänä on...)

    Muuta:

    - En missään tapauksessa luottaisi devicemapperiin dockerin kanssa - eli käytännössä täytyisi käyttää overlay -storagedriveria, ja tämä sitten tarkoittaa sitä että käytännössä RHEL/CentOS on oltava vähintään versiota 7.3. Devicemapper+Docker -yhdistelmän kanssa on maailmalta kuulunut huomattavasti todella huonoja asioita, pahimmillaan tietojen menetykseen johtaneita tiedostojärjestelmän solmuunmenemisiä. Tämä on hyvä tiedostaa, ja itse sanoisin suorilta käsin että Devicemapper ei ole tuettu ratkaisu, vaikka linkatulla wikisivulla sen käyttöön annetaankin ohjeistuksia tällä hetkellä.

    - Kaikki tiedostojärjestelmän polut, joihin sovellus kirjoittaa kontin sisällä (kaikki tiedostojärjestelmässä säilytettävä data jota ei haluta menettää kontin sammuessa, tai joka voi aiheuttaa levytilaongelmia kontin tyypillisen elinajan aikana - logit lienevät olennaisin, kun oikea data kuitenkin asuu tietokannassa kontin ulkopuolella), tulee dokumentoida selkeästi, jotta ko. polut voidaan mountata volumeina kontin ulkopuolelta käsin. Tämä myös tulee nähdä oletusarvoisena ajotapana kun paketointia tehdään ja kontissa ajoa ohjeistetaan.

    - Sovelluksen ajamisesta vastaavan ylläpidon olisi erittäin tärkeä saada nähdä, miten Docker-kontti luodaan (eli käytännössä voida nähdä Dockerfile) ja todella hyödyllistä myös sekä periaatteessa että käytännössä kyetä muokkaamaan sitä jos tarve tulee.

    Lisäksi:

    - Vielä on selvittämättä, mitä kivaa konttialustana tuo juuri nyt käyttöönottoon valmisteltava RHEL8. Linux-palvelinylläpidon palvelimissa on tähän asti ollut konttialustana Ubuntu.  Upeata olisi, jos kontitus olisi toteutettu siten, että alustana on RHEL ja kontin sisällä jokainen kikkula on peräisin RHEL reposta eikä ties mistä pilvenlaidalta. Tyrmistyin Docker kurssilla kun siellä napattiin noinvaan pilvenreunalta kamaa kontin sisään, alkaen shellistä nimeltä Alpine. Ero on raju: meidän RHEL pannuissa on jokaikinen paketti Red Hat:in allekirjoittama ja siten on tiedossa kuka paketin pykäsi. Pilvenlaidalta nykäistäessä vastuutaho on fyysistä näppäimistöä käpistelevällä ihan itsellään hallussa :) Jokatapauksessa konttitekniikassa Linux-palvelinylläpito on nähnyt tähän mennessä enemmän varoittavan huonoja esimerkkejä kuin hyviä sellaisia. En sano suoralta kädeltä EI, mutta ensin pitäisi saada tietää enemmän: miten ja miksi.


  2. Ja sitten vielä ne OPK-spesifit asiat, etteivät unohdu: meillä on nyt yhdellä virtuaalikoneella neljän eri yliopiston yhdeksän eri WebOodia joiden lokit kirjoittuvat omaan erilliseen mounttiin, WebOodi/Tomcatit ovat eri koneella kuin Apache (joka Apache hoitelee myös Oilin ja Examin liikennettä kokonaan toiselle virtuaalikoneelle), lisäksi jokaisella yo:lla on myös oma ip/virtualhost.