Tag: ansible


Palvelinten hallinta kotitehtävät 4 (Syksy 2017)


Palvelinten hallinta kotitehtävät 4 (Syksy 2017)

Lähde  Tero Karvinen 2017: Palvelinten Hallinta, http://terokarvinen.com

Harjoitusympäristönä asennettu sekä livetikulta ajettu kustomoitu Xubuntu 16.04 LTS 3

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

 

Viikon harjoitusten tavoitteena oli kokeilla Puppetin lisäksi kahta muuta keskitetyn hallinnan järjestelmää, Ansiblea ja Salt:ia.

Molemmat järjestelmät asennettiin ja niiden toimintaa testattiin yksinkertaisen “moduulin” avulla.

 

a) Kokeile Ansiblea

 

Testilaitteistona kaksi kappaletta Hyper-V:llä luotuja virtuaalikoneita, joille oli asennettu 64-bittinen Xubuntu 16.04.3 LTS versiot. Tavoitteena oli asentaa koneelle 1 Ansible ja määritellä asetukset niin, että luotu yksinkertainen moduuli voitiin ajaa koneella 2.

Harjoitus aloitettiin asentamalla “herra” -koneelle Ansible ja OpenSSH suojausavainten luontia varten

$ sudo apt-get update

$ sudo apt-get -y install openssh-server openssh-client ssh ansible

Seuraavaksi määriteltiin “orja” -virtuaalikoneen IP-osoite Ansiblen hosts -tiedostoon ryhmän [orja] alle

$ sudoedit /etc/ansible/hosts

 

Toiselle virtuaalikoneelle asennettiin samat SSH-ohjelmat, mutta Ansiblea ei tarvinnut asentaa kohdelaitteelle. Tässä vaiheessa varmistettiin vielä, että herra pystyi pingaamaan orjaa.

Seuraavaksi luotiin herrakoneelle salausavain, joka siirrettiin orjakoneelle. Avaimen toiminta testattiin ottamalla SSH-yhteys herrakoneelta orjakoneelle.

ssh-keygen -t rsa

ssh-copy-id orja@192.168.1.175

ssh orja@192.168.1.175

SSH-yhteys onnistui ilman salasanaa, mistä voitiin päätellä että avaimen siirto onnistui. Jatkettiin harjoitusta testaamalla orjakoneen pingausta Ansiblen avulla.

$ ansible orja -m ping

Tuloksena saatiin seuraava virheilmoitus

 

Lisäämällä -vvvv komentoon saatiin lisätietoja virheilmoituksesta.

 

Virheilmoituksesta ei suoraan saatu selvää, mikä ongelmana oli. Virheilmoituksen google-hakutulosten perusteella ongelman voi kiertää lisäämällä käyttäjän komentoon. Testausta jatkettiin seuraavalla komennolla:

$ ansible orja -m ping -u orja

Tällä kertaa komento meni läpi. Oletettavasti käyttäjää ei tarvitse lisätä komentoon jos käyttäjänimi on sama kummallakin laitteella. Seuraavaksi luotiin yksinkertainen Ansible playbook ajettavaksi orja-koneella.

$ nano hellosimo.yml

Tiedostoon määriteltiin hostit, joilla ks. playbook ajetaan sekä tehtävät jotka halutaan ajettavan. Tällä kertaa tehtävä oli luoda tekstitiedosto halutulla sisällöllä haluttuun kohteeseen.

---
- name: hellosimo
  hosts: orja
  tasks:
  - name: Luo /tmp/hellosimo.txt tiedosto halutulla sisällolla
    copy: content="Hello Simo!\n" dest=/tmp/hellosimo.txt

Luotu playbook ajettiin komennolla ansible-playbook hellosimo.yml -u orja. Komento meni läpi ilman ongelmia ja Ansiblen tulostus paljasti, että hostiin 192.168.1.175 tehtiin muutoksia. Siirtymällä orjakoneelle ja hakemalla tiedoston /tmp/hellosimo.txt voitiin todeta, että luotu playbook oli ajettu onnistuneesti orjakoneella.

 

Lähteet:

Ansible – A “hello world” Playbook

Joona Leppälahti – CCM/Ansible raportti

b) Kokeile Salt:tia

 

Tavoitteena oli luoda Vagrantin ja Virtualboxin avulla virtuaalikone, josta tehtäisiin rautakoneen Salt-minion, eli orjakone. Harjoitus aloitettiin poistamalla edelliset virtuaalikonekokeilut.

$ vagrant destroy
$ rm Vagrantfile
$ vagrant init bento/ubuntu-16.04
$ vagrant up
$ vagrant ssh

Seuraavaksi asennettiin luodulle virtuaalikoneelle salt-minion ja määriteltiin sen herraksi testikoneen IP-osoite.

$ sudo apt-get update && sudo apt-get -y install salt-minion
$ sudoedit /etc/salt/minion

$ sudo service salt-minion restart

minion -asetustiedosto sisältää pelkkää kommenttia, jonka voi tyhjentää tai säästää myöhempää käyttöä varten. Virtuaalikoneen minion -tiedosto tyhjennettiin ja lisättiin rivi master: IP-osoite osoittamaan rautakoneen IP-osoitteeseen. Lopuksi käynnistettiin salt-minion -palvelu uudestaan, jotta orja ymmärtäisi hakea uutta määriteltyä isäntää. Tämän jälkeen siirryttiin testikoneelle asentamaan salt-master ja muokkaamaan asetuksia.

$ sudo apt-get update && sudo apt-get -y install salt-master
$ sudo salt-key list

vagrant.vm -orjakone löytyi hyväksymättömien avainten listasta (ks. kuva). Avaimen hyväksymisen jälkeen ajettiin komento, jolla hyväksytyillä orjakoneilla voitiin ajaa komentoja.

 

$ sudo salt-key --accept vagrant.vm
$ sudo salt '*' cmd.run "hostname -I"

Komennolla ajettiin siis kaikissa (‘*’) hyväksytyissä salt-slave -koneissa komento “hostname -I”. Tällä kertaa orjia ei ollut kuin yksi. Lopputuloksena voitiin todeta, että herra- ja orjakoneen asetukset toimivat ja harjoitusta voitiin jatkaa. Lopuksi testailtiin komentoja orjakoneille. Paketin asennus ja tietojen hankkiminen orjakoneelta onnistuivat mainiosti.

$ sudo salt '*' pkg.install tree    //paketin asennus
$ sudo salt '*' disk.usage    //kovalevyn tietoja

Lähteenä käytettiin SaltStackin Salt in 10 Minutes -tutoriaalia ja Tero Karvisen kirjoitusta.

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html

Simo Suominen


Palvelinten hallinta kotitehtävät 1


Palvelinten hallinta kotitehtävät 1

Lähde  Tero Karvinen 2017: Linux kurssi, http://terokarvinen.com

Harjoitusympäristönä asennettu Xubuntu 16.04, Xenial Xerus

Harjoituskoneen tiedot:

Emolevy X79A-GD65 (8D)

Prosessori Intel(R) Core(TM) i7-3930K

16GiB RAM

Näytönohjain GeForce GTX 690

Tee ja testaa moduli, joka käyttää ainakin kahta eri resurssia (esim. file ja package)

Harjoitustyön tavoiteena oli asentaa Puppet ja testata asennettua ohjelmaa luomalla yksinkertainen moduli. Aloitettiin asennuksella ja tarvittavien kansioiden luonnilla.

$ sudo apt-get update

$ sudo apt-get -y install puppet //asennus

$ sudo mkdir -p /etc/puppet/modules/simotest/manifests/ //luotiin tarvittavat kansiot


$ sudoedit /etc/puppet/modules/simotest/manifests/init.pp //avattiin muokattavaksi moduulia varten tarvittava tiedosto

Harjoitusta varten luotiin moduuli, joka loi tiedoston tmp -kansioon ja kirjoitti tiedostoon lauseen tekstiä. Lisäksi moduuli ajoi komennon apt-get update. Lopuksi moduuli asensi paketit ‘vlc’, ‘curl’ ja ‘lynx’. Jos paketit olivat jo asennettuna, moduuli varmisti, että ne ovat myös päivitetty uusimpaan versioon. Alla on nähtävissä tiedoston sisältö.

class simotest {

    file {"/tmp/hellosimo2":                #tiedoston luonti
     content => "Hello again, Simo!\n",        #tiedoston sisältö
    }

    exec { 'apt-update':                    #komento
     command => '/usr/bin/apt-get update'    #komennon polku
    }

    $paketit = [ 'vlc', 'curl', 'lynx' ]    #asennettavien pakettien kuvaus

    package { $paketit: ensure => 'latest'    #pakettien asennus

    }

}

Moduuli ajettiin komennolla sudo puppet apply -e ‘class {“simotest”:}’

Lopuksi testattiin, että moduulin tekemät muutokset toimivat. Asennetut ohjelmistot löytyivät testikoneelta ja luodun tiedoston sisältö saatiin esiin komennolla cat /tmp/hellosimo2.

Lähteet: Puppet Cookbook

Vapaaehtoinen: Tärkeimmät resurssit. Tee moduleja, jotka käyttävät resursseja package, file, service, user, exec

Harjoitusta jatkettiin käyttämällä edellisen harjoituksen modulia pohjana. Seuraavaa moduulia varten luotiin kansiot /etc/puppet/modules/simotest2/manifests/. Alkuperäiseen moduliin lisättiin user ja service resurssit. Tässä tapauksessa moduli varmistaa, että cron-palvelu on päällä ja luo testuser -käyttäjätunnuksen sekä tälle kotihakemiston.

class simotest2 {

    file {"/tmp/hellosimo2":                #tiedoston luonti
     content => "Hello again, Simo!\n",        #tiedoston sisältö
    }

    exec { 'apt-update':                    #komento
     command => '/usr/bin/apt-get update'    #komennon polku
    }

    $paketit = [ 'vlc', 'curl', 'lynx' ]    #asennettavien pakettien kuvaus

    package { $paketit: ensure => 'latest'    #pakettien asennus
    
    }

    service { 'cron':                        #palvelun nimi
     ensure => 'running',                    #varmistetaan, että palvelu on päällä ja käynnistyy uudestaan jos näin vaaditaan
    
    }
    
    user { 'testuser':                        #käyttäjätunnus
     ensure => present,
     comment => 'Testi Käyttäjä',            #koko nimi
     home => '/home/testuser',                #kotihakemisto
     managehome => true                        #kotihakemiston käyttöönotto
    }
    
}

Moduuli ajettiin komennolla sudo puppet apply -e ‘class {“simotest2”:}’

Komennolla cut -d: -f1 /etc/passwd saatiin kaikki käyttäjät näkyville ja voitiin todeta, että käyttäjä testuser löytyy listalta. Palvelun toiminnan varmistaminen testattiin pysäyttämällä palvelu komennolla sudo service cron stop. Kun moduuli ajettiin tämän jälkeen debug-tilassa komennolla puppet apply -e ‘class {“simotest2”:}’ –verbose –debug saatiin esille seuraavat rivit:

Debug: Executing '/bin/systemctl is-active cron'
Debug: Executing '/bin/systemctl start cron'
Notice: /Stage[main]/Simotest2/Service[cron]/ensure: ensure changed 'stopped' to 'running'
Debug: /Stage[main]/Simotest2/Service[cron]: The container Class[Simotest2] will propagate my refresh event
Info: /Stage[main]/Simotest2/Service[cron]: Unscheduling refresh on Service[cron]
Debug: Class[Simotest2]: The container Stage[main] will propagate my refresh event

Cron-palvelun uudelleenkäynnistyminen varmistettiin vielä komennolla sudo service cron status.

Lähteet: Puppet Cookbook

Vapaaehtoinen: Oikeaa elämää. Ratkaise jokin yksinkertainen oikean elämän ongelma Puppetilla. Esimerkiksi asenna jokin työpöytä- tai komentoriviohjelma ja tee siihen säädöt.

HUOM! Tehtävä päivitetty 13.4.2017

Ongelma: Elämä ilman mainosten estoa verkkoselaimessa on kurjaa. Ratkaisu: Yksinkertainen Puppet-moduuli, joka muokkaa Firefoxin asetuksia ja asentaa Ublock Origin -mainostenestolisäosan automaattisesti. Moduuli luotiin käyttäjän puppet-kansioon ja siirrettiin se ajettavaksi /etc/puppet/modules -kansioon. Moduuli luotiin skriptin avulla. Skripti loi annetun nimen mukaan moduulin ja tarvittavat kansiot sekä init.pp -tiedoston. Skripti make löytyy käyttäjän GitHubista. Lähteenä harjoituksessa käytettin M. Selvisen WordPress-sivua aiheesta.

init.pp -tiedoston sisältö:

class firefox { 

    package { 'xul-ext-ublock-origin':
        ensure => 'installed',
        require => Package['firefox'],
    }

    
    package { 'firefox':
        ensure => 'installed',
    }

    file { '/etc/firefox/syspref.js':
        content => template('firefox/syspref.js.erb'),
        notify => Service['firefox'],
        require => Package['xul-ext-ublock-origin'],

    }
    
    service { 'firefox':
#        ensure  => 'true',
#        enable  => 'true',
        require => Package['firefox'],
        provider => 'systemd',
    }

}

Lähteen avulla selvisi, että tiedostoon /etc/firefox/syspre.js täytyi tehtä muutoksia, jotta lisäosa asentuu ilman ongelmia. Lisäys tehtiin kopioimalla ks. tiedosto moduulin templates-kansioon .erb -päätteellä ja lisäämällä seuraava rivi uuteen tiedostoon:

user_pref(“xpinstall.signatures.required”, false);

Luotu moduuli kopioitiin skriptin avulla /etc/puppet/modules -kansioon ja ajettiin toisen skriptin avulla. Uudelleenkäynnistyksen jälkeen Ublock Origin oli otettu käyttöön selaimessa.

Katso video esim. Puppetista ja toisesta vastaavasta järjestelmästä (esim. Salt) ja kirjoita niistä analyyttinen ja vertaileva kirjoitus.

Harjoitusta varten valittiin video keskitetyn hallinnan järjestelmästä/järjestelmistä. Tämän jälkeen tutustuttiin videon sisältöön ja pyrittiin analysoimaan sen sisältöä. Kohdevideoksi valittiin Edurekan toteuttama video, jossa verrattiin neljän eri hallintajärjestelmän ominaisuuksia. Edureka on Intiassa 2011 perustettu interaktiiviseen opetukseen erikoistunut yritys, joka tarjoaa kursseja IT-ammattilaisille. (lähde). Video on julkaistu 19.12.2016, joten sitä voidaan pitää ajankohtaisena.

Videossa vertailtiin Chef, Puppet, Ansible ja SaltStack -hallintajärjestelmiä. Vertailtavat osa-alueet olivat skaalautuvuus, käyttöönoton helppous, saatavuus, hallinta ja yhteentoimivuus.

Skaalautuvuus (Scalability)

Skaalautuvuudella tarkoitettiin mahdollisuutta konfiguroida vaihtelevia määriä laitteita ja videon mukaan jokainen palvelu pystyy suoriutumaan tästä erinomaisesti.

Asennuksen helppous (Ease of Setup)

Sekä Puppet, Chef että SaltStack toimivat Master – Slave -periaatteella. Nämä järjestelmät vaativat omat ohjelmistonsa master-servereille ja orjakoneissa pyörii myös oma ohjelmisto. Ansible taas perustuu SSH-yhteyden luomiseen orjakoneille, jolloin tarvitaan ainoastaan yksi ohjelmisto master-serverille. Ansiblen käyttöönotto on näin ollen videon mukaan “A cakewalk” – eli helpompi kuin kilpailijoilla.

Saatavuus (Availability)

Saatavuudella tarkoitettiin toiminnan jatkuvuutta tilanteessa, jossa masterkone putoaa pois pelistä. Jokaisella hallintajärjestelmällä on videon mukaan useaan masteriin perustuva arkkitehtuuri, jolloin pääserverin pudotessa pois pelistä varaserveri on aina määritelty ja käytössä.

Hallinta (Management)

Hallinnan vertailussa käytiin läpi push- ja pull-metodeja laitekonfiguraatioiden siirrossa client-koneille. Puppet ja Chef toimivat videon mukaan pull-metodilla, jossa client-koneet hakevat konfiguraationsa serveriltä (master). Ansible ja SaltStack taas työntävät konfiguraationsa client-koneille.

Lisäksi viitattiin palveluiden käyttävän kielen ymmärrettävyyteen. Puppet (Puppet DSL) ja Chef (Ruby) saivat videolla risuja hankalasta DSL -kielestä, kun taas Python-pohjaiset Ansible ja SaltStack tarjosivat helpomman tavan luoda hallita konfiguraatioita.

Yhteentoimivuus(Interoperatibility)

Yhteentoimivuudella tarkoitettiin mahdollisuuksia toimia eri käyttöjärjestelmillä. Kaikkien palveluiden masterserveri täytyi olla Linux/Unix -laitteella, mutta client-koneet voivat olla myös Windows-laitteita.

Lopputulos + pohdinta

Videon loppupisteissä Ansible ja SaltStack saivat hieman korkeammat pisteet käyttöönoton ja hallinnan helppouden perusteella. Pisteytyksen jälkeen palveluita verrattiin vielä mm. GitHub-yhteisön aktiivisuuden, Google -trendien, yritysesimerkkien sekä hintojen perusteella. Videon tekijä muistuttaa videon lopussa, että loppujen lopuksi “paras” hallintaohjelmisto yrityksen käyttöön on se, joka sopii parhaiten yrityksen toimintaympäristöön ja tarpeisiin.

Video hyvin tehty ja selkeä ja käytti hyvin esimerkkejä hyödyksi. Videon sanoma oli uskottava eikä se yrittänyt kehua mitään palveluista yli muiden. Video oli äänite virtuaaliluennolta ja se sisälsi täydentäviä kysymyksiä oppilailta. Näin palvelinten hallinnan kurssin alussa en löytänyt suoranaisia asiavirheitä ja uskon, että videota voi suositella kaikille hallintaohjelmista kiinnostuneille aloitteilijoille.

 

 

 

Tätä dokumenttia saa kopioida ja muokata GNU General Public License (versio 3 tai uudempi) mukaisesti. http://www.gnu.org/licenses/gpl.html        Simo Suominen