Palvelinten hallinta H7

Oma moduuli. Orjille sovellukset muistin määrän ja orjan id:n perusteella.

Tein tehtävän kotona pöytäkoneellani, jossa oli mm. Intel i5-3570K prosessori, 8GB RAM-muistia, Asus GTX 1060 (6GB) näytönohjain ja käyttöjärjestelmänä Win 10. Käytin aiempien tehtävien orjia, sekä tässä tehtävässä luomiani kahta uutta orjaa. Kaikki orjat oli luotu VirtualBox 6.1:llä. Kaikkiin orjiin oli asennettu Xubuntu 18.04.4 LTS. Muistia orjilla oli joko 1GB tai 2GB.


Oma moduli (iso tehtävä). Ratkaise jokin oikean elämän tai keksitty tarve omilla tiloilla/moduleilla. Voit käyttää Salttia tai muuta valitsemaasi modernia keskitetyn hallinnan ohjelmaa. Esitä tulos viimeisellä opetuskerralla, 5-10 min (keskiviikon ryhmä). Live demo olisi kiva. Raportoi modulisi tarkoitus, koodi ja testit.

Tehtävänanto nähtävillä osoitteessa:
http://terokarvinen.com/2020/configuration-managment-systems-palvelinten-hallinta-ict4tn022-spring-2020/

Aloitin tehtävän tekemisen 19.5.2020 klo 12:00 (UTC +3), mutta en tehnyt sitä yhtäjaksoisesti.



Oma moduuli

Tehtävänä oli luoda oma moduuli. Suurena haasteena oli keksiä, mihin tarkoitukseen moduuli tulisi. Ensikosketukseni Linuxiin tapahtui viisi kuukautta sitten, minkä vuoksi monet ohjelmat ym. ovat minulle vielä tuntemattomia. Oma pöytäkoneeni on jo suhteellisen vanha, minkä vuoksi esimerkiksi RAM-muistia on vähän. Aloin miettimään, toimivatko tietyt Linux-ohjelmat virtuaalikoneillani, joilla on 1-2Gb RAM:a. Tämän mietinnän jatkoksi pohdin, pystyisikö Saltin avulla asentamaan sovelluksia koneiden tehojen perusteella. Monet pelit, kuvankäsittelyohjelmat sekä videoeditointiohjelmat tarvitsevat paljon muistia toimiakseen kunnolla. Tässä kohtaa pohdin myös, miten saisin asennettua tietyille orjille NginX:n ja toisille Apachen.



grains.items

Annoin masterilla grains.items -komennon nähdäkseni, mitä asioita grainsillä voi hakea. Orjilta tuli erilaisia arvoja. Huomasin arvojen joukossa muistin määrän (mem_total). Päätin tehdä tilan, joka asentaisi tietyn kuvankäsittelysovelluksen, mikäli muistia olisi vähän, ja mikäli muistia olisi enemmän, niin asentuisi toinen kuvankäsittelysovellus. Otin hiukan mallia edellisessä harjoituksessa käyttämästäni tilasta, jolla asennettiin Apache Debianille ja RedHatille.


editing-tila

Tein masterille tilaa varten uuden kansion:

sudo mkdir /srv/salt/editing

Tein kansioon tilatiedoston init.sls, jonka sisällöksi kirjoitin:

{% if grains['mem_total'] > 1500 %}
darktable:
  pkg.installed
{% elif grains['mem_total'] < 1500 %}
gimp:
  pkg.installed
{% endif %}

Tilassa asennetaan darktable -sovellus, mikäli muistia on enemmän kuin 1500 (1,5GB) ja gimp, mikäli muistia on alle tuon määrän. Valitsin tuon muistimäärän, sillä aikomuksenani oli testata sen toimivuutta luomalla 1GB ja 2GB virtuaalikoneet. Todellisuudessa tuo raja-arvo olisi varmasti suurempi. Testasin (sudo salt ’*’ state.apply editing) tilan toimivuutta yhdellä orjalla, jossa oli 1GB RAMia. Tila asensi vain Gimpin ilman virheilmoituksia. Kävin testaamassa Gimpin toimivuuden vielä orjakoneelta. Tila vaikutti siis toimivan, vaikka minulla ei ollutkaan 2GB konetta tässä vaiheessa testattavaksi.

Päätin tässä vaiheessa siirtyä seuraavien tilojen luontiin.



Webbipalvelimet

Kuten aiemmin mainitsin, halusin erotella jotenkin, mille koneelle asennetaan Apache ja mille Nginx. Ajatuksenani oli nimetä orjien id tietyllä tavalla. Esimerkiksi sellaisille orjille, joiden id:ssä olisi sana apache, asennettaisiin Apache, kun taas orjalle, jonka id:ssä olisi sana nginx, asennettaisiin gninx. Id:tä voisin ehkä sitten käyttää jollakin tavalla saltin tilassa ohjeistamaan asennuspaketteja oikeisiin koneisiin. Mietin, voisiko grains.item id:tä käyttää jollakin tavalla. Keskusteltuani toisen kurssilaisen, Aki Ronkaisen, kanssa päätin kuitenkin tehdä jaottelun myöhemmin top.sls -tiedostossa, sillä se vaikutti yksinkertaisemmalta keinolta.



Nginx -tila

Olin aiemmissa tehtävissä tehnyt erillisiä tiloja webbipalvelimille, ssh:lle sekä motd:lle. Päätin kasata kyseisiä tiloja yhteen.

Minulla oli jo olemassa kaikki alla näkyvät tilat ja niiden kansiot ja tiedostot valmiina, joten muokkasin nginx-kansiossa ollutta init.sls -tiedostoa.

Kasaamani tila näytti lopulta tältä:

nginx:
  pkg.installed
/var/www/html/index.nginx-debian.html:
  file.managed:
    - source: salt/nginx/testi.html
running:
  service.running
    - name: nginx
openssh-server:
  pkg.installed
/etc/ssh/sshd_config:
  file.managed:
    -source: salt://ssh/sshd_config
sshd:
  service.running:
  - watch:
    - file: /etc/ssh/sshd_config
/etc/motd:
  file.managed:
    - source: salt://motd/motd
    - template: jinja

Tila asentaa nginx:n ja openssh:n ja tarkistaa, että ne ovat käynnissä. Nginx:n oletussivu vaihdetaan toiseen (Sisällöksi kirjoitin ”Tämä on nginx-webbipalvelin” ), ssh:n oletusportti vaihdetaan portiksi 8888 ja motd-viesti kerää templaten avulla orjakoneen tietoja näytettäväksi kun ssh:lla kirjaudutaan sisään.

Testasin tilaa yhdelle vanhoista orjistani, ja tarkastusten jälkeen kaikki vaikutti toimivan.



Apache-tila

Kasasin myös Apache-tilan aiemmista tiloista:

apache2:
  pkg.installed
/var/www/html/index.html:
  file.managed:
    - source: salt://apache/default-index.html
/etc/apache2/mods-enabled/userdir.conf:
  file.symlink:
    - target: ../mods-available/userdir.conf
/etc/apache2/mods-enabled/userdir.load:
  file.symlink:
    - target: ../mods-available/userdir.load
apache2service:
  service.running:
    - name: apache2
    - watch:
      - file: /etc/apache2/mods-enabled/userdir.conf
      - file: /etc/apache2/mods-enabled/userdir.load
openssh-server:
  pkg.installed
/etc/ssh/sshd_config:
  file.managed:
    - source: salt://ssh/sshd_config
sshd:
  service.running:
    -watch:
      - file: /etc/ssh/sshd_config
/etc/motd:
  file.managed:
    - source: salt://motd/motd
    - template: jinja

Tila asentaa Apachen, vaihtaa oletussivun, mahdollistaa käyttäjän luoda sivuja, asentaa ssh:n ja ottaa motd:n templatesta. Varmistaa myös, että apache ja ssh ovat käynnissä ja tarkkailee tiettyjä tiedostoja muutosten varalta. Vaihdettavaan oletussivuun kirjoitin ”Tämä on Apance-webbipalvelin”.

Testasin myös tämän tilan vanhalla orjallani, ja tehtyäni muutamat tarkistukset, kaikki tuntui toimivan.


Orjakoneet

Lopullista testiä varten tein VirtualBoxissa kaksi uutta orjakonetta, joista toiseen laitoin muisimääräksi 1GB ja toiseen 2GB. Orjilla annoin komennot:

sudo apt-get install update
sudo apt-get install upgrade

Asensin koneille Salt-minionin:

sudo apt-get install -y salt-minion

Kävin muokkaamassa molempien orjien konffitiedostoon masterin IP:n sekä orjien ID:n:

sudoedit /etc/salt/minion
master: "masterin ip-osoite"
id: ServerApache
master: "masterin ip-osoite"
id: ServerNginx2

ServerApachessa 2GB RAMia ja ServerNginX2:ssa 1GB RAMia. Muistin määrä on eri, jotta voin testata vielä editing.sls:n toimivuutta.

Käynnistin minionin uudestaan:

sudo systemctl restart salt-minion.service

Kävin hyväksymässä masterilla avaimet:

sudo salt-key -A

Testasin yhteyden toimivuuden:

sudo salt '*' cmd.run 'whoami'



top.sls

Tein top.sls tiedoston /srv/salt -kansioon seuraavalla sisällöllä:

base:
  '*Apache*':
    - apache
  '*Nginx*':
    - nginx
  '*':
    - editing

Tuossa siis apache-tila ajetaan, mikäli orjan id:ssä on jossakin kohtaa sana ”Apache”. Vastaavasti nginx-tila ajetaan, mikäli orjan id:ssä on jossakin kohtaa sana ”Nginx”. Kaikille orjille ajetaan editing-tila. Top.sls:stä lisää tietoa täällä. Ajatuksena tässä oli se, että kaikki koneet, joille halutaan Apache, niin niiden id:n kirjoitetaan apache ja vastaavasti NginX niille orjille, joiden id:ssä on nginx.

Koitin ajaa koko tekeleen komennolla sudo salt ’*’ state.highstate ja sain virheilmoituksen.

Melko pitkään mietin, missä vika. Koitin selvittää ongelmaa tutkimalla tätä sivustoa: https://docs.saltstack.com/en/latest/ref/states/top.html

Minulla oli kaikki tilatiedostot omissa kansioissaan, ja top.sls niiden ulkopuolella. En ole varma ymmärsinkö oikein, mutta kopioin kaikkien kolmen käyttämäni tilan .sls -tiedostot samaan paikkaan, jossa top.sls oli(/srv/salt/). Muutin varmuuden vuoksi niiden nimet (init.sls -> editing.sls, apache.sls ja nginx.sls). Ajoin highstate-komennon uudestaan, ja nyt kone jäi raksuttamaan. Reilun minuutin jälkeen tuli ilmoitukset onnistuneista tilojen suorittamisista. Toiselle koneelle ajettiin apache.sls ja editing.sls:stä darktable, ja toiselle nginx.sls ja editing.sls:stä gimp. Tavallisesti servereille tuskin asennettaisiin kuvankäsittelyohjelmia, mutta orjien rajallisesta määrästä johtuen täytyi hiukan oikoa.

Kävin orjilla tarkistamassa, että kaikki toimii. Ssh:lla pääsee kirjautumaan vain portin 8888 kautta ja motd on templatesta otettu, palvelimien oletussivu on vaihtunut, Apachella käyttäjä pystyy tekemään omia sivuja ja kummallakin koneella on eri kuvankäsittelyohjelma, jotka toimivat niin kuin on tarkoitettu. Kaikki toimi niin kuin pitikin.



En tiedä yhtään, vastasiko tämä tehtävänantoon. Oli jälleen todella haastavaa miettiä, millaisia ongelmia Saltin avulla voisi ratkoa, kun ei ole vielä päässyt käyttämään Linuxia tuotantoympäristössä ja muutenkin Linuxin opettelu on vasta alussa. Oli kuitenkin mielenkiintoista tehdä tätä tehtävää, ja samalla tuli opittua uutta.

Lopetin tehtävän tekemisen 20.5.2020 klo 07:00 (UTC +3). Tehtävää en tehnyt yhtäjaksoisesti, vaan pidin taukoja välissä. Aktiivista aikaa pohtimiseen, selvittelyyn, tekemiseen ja raportointiin meni noin 8-9 tuntia.




Lähteet

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out /  Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out /  Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out /  Muuta )

Muodostetaan yhteyttä palveluun %s

Create your website with WordPress.com
Aloitus
%d bloggaajaa tykkää tästä: