Vedlegg E3 Produksjonssettingsrapport milepæl 2 Dokumentet inneholder beskrivelse produksjonssetting av milepel 2 den 07.04.2013.
INNHOLDSFORTEGNELSE INNHOLDSFORTEGNELSE 2 1. INNLEDNING 3 2. OPPSUMMERING 3 3. PRODSETTINGEN 3 3.1 BRANNMURÅPNINGER 3 3.2 INSTALLASJON AV SENSOR 3 3.3 UTRULLING AV NY DATABASEKONFIGURASJON 4 3.4 INSTALLASJON AV FRONTEND, WEBSERVICE OG CORE 4 3.5 INSTALASJONSSTATUS 6 Rapport prodsetting M2 2013-04-07.docx Side: 2 av 6
1. INNLEDNING Denne rapporten beskriver produksjonssettingen i SpareBank1 sitt testmiljø. Rapporten beskriver også eventuelle avvik og tiltak for å ungå disse problemene. Denne produksjonsettingen er i SpareBank 1 sitt testmiljø. Serverene programvaren skal kjøre på har installert CentOS som følger SpareBank 1 sin standard for test. 2. OPPSUMMERING Produksjonsettingen av PySniff milepel 2 ble gjennomført og alt gikk i denne sammehengen bra. Underveis var det enkelt problematikk som var nødvendig å løse, og deler av produksjonsettingen ble også utsatt til påfølgene dag for å kunne verifisere tekniske utfordringer med driftspersonalet hos oppdragsgiver før gjennomført installasjon. Etter forrige leveranse har mange av de problemene som oppstod blitt rettet, og de korrekte brannmuråpningene har blir redgjort for slik at det nå er mulig å benytte applikasjonen i den kombinasjonen som er intensjonelt planlagt. Databasen på origo5 kunne derfor i denne produksjonsettingen bli tatt i bruk og rekonfigurert for å passe endringene. Frontend er satt opp til å benytte tilegget til apache webserver, mod_wsgi og inneholder også ny funksjonalitet som logging, nye grafer og bedre kommunikasjonsflyt med baksystemet. 3. PRODSETTINGEN Etter forrige leveranse er det en del endringer i alle ledd av applikasjonen. Det er her mange funksjonelle endringer, og omstruktureringer av kode som gjør det nødvendig med denne nye produksjonsettingen. 3.1 Brannmuråpninger Etter forrige produksjonsetting ble blant annet databasen installert på begge serverene på grunn av manglende brannmuråpninger. De manglende brannmuråpningene gjorde også at det ikke var mulig å koble direkte til origo4 for å vise nettsiden. Løsningen på dette er å konfigurere iptables til å tillate de korrekte portene. Dette gjøres ved å opprette en fil i prosjektet med navn /opt/pysniff/firewall.conf som har et innhold som tilsier hvilke porter som skal være åpnet. For å tillate tilkobling på port 80 for HTTP trafikk er det linjen «tcp 80» som skal være i denne filen. For å rette brannmurtilgangen til databasen ble det opprettet en fil på origo5 under /etc/sysconfig/iptables.d/pysniff_firewall.conf som inneholder de respekterte endringene for å tillate tilkobling på port 5432 tcp. Etter disse endringene, har applikasjonen alle de nødvendige kravene for å kjøres. 3.2 Installasjon av sensor Et av hovedmomentene med denne produksjonsettingen var å installere sensoren på en av de produksjonslike testserverene til SpareBank 1. Målet med dette er å kunne teste applikasjonen i et miljøet der applikasjonene til oppdragsgiver kjører, da det er viktig å verifisere stabil drift og ikke minst at applikasjonen ikke påvirker den generelle driften. På applikasjonserveren til SpareBank 1 ble det opprettet en egen bruker til applikasjonen, slik at det skal følge oppdragsgivers retningslinjer for applikasjonsdrift. Denne brukeren fikk rettigheter til å kjøre programmer som root, og også shell. Dette er ikke en god løsning, og det ble i etterkant besluttet at sensoren må kjøre under brukeren root da det ikke skal være andre brukere med root rettigheter på serveren. Sensoren krever at det installeres en versjon av python som ikke er standard i CentOS og RedHat operativsystemet som kjører på serverene, og dette utgjør et problem for installasjon av sensor. Det er eldre versjoner av programvaren som er nødvendig, men da applikasjonen ikke er testet for bruk på eldre programvare er det ikke mulig å garantere stabil drift, noe som gjør at vi ikke har muligheten til å Rapport prodsetting M2 2013-04-07.docx Side: 3 av 6
produksjonsette sensoren på en applikasjonserver som er nødvendig for den daglige driften. For også å unå å risikere driftsavbrudd eller problematikk ved installasjon de nødvendige ekstra pakkene ble det besluttet å avvente driftsavdelingen for mulighetene rundt dette. Installasjon og avklaring ble gjennomført etter en del runder med driftsavdelingen vedrørende installasjon, og de nødvendige prosedyrer påfølgende arbeidsdag. 3.3 Utrulling av ny databasekonfigurasjon Da problematikk ved åpning av brannmur var rettet er det mulig å benytte databaseserveren som kjører på origo5 i stedet for den lokale som kjører på origo4. Da det er gjort endringer etter forrige leveranse, som blant annet skal gjøre det mulig for å aggregere data ved bruk av en ny database ble hele databasen satt opp på nytt. Det ble først kjørt script for å opprettet databasen. Deretter ble det opprettet ramdisk som databasen kjører på for lagring. Ramdisken benyttes kun for lagring av layer1 data som er laget uagreggerte data lagres på. For at databasen skal være ferdig konfigurert er det nødvendig å sette opp manuelt med brukere og brukerkonfigurasjon. Dette ble gjennomført ok, og databasen kjørte som normalt. Det viste seg også at det måtte gjøres endringer i den lokale konfigurasjonen til PostgreSQL som tillater eksterne klienter for å koble seg opp mot databasen. Dette gjorde at ipadressen til origo4 måtte legges opp i pg_hba.conf, som er brannmurkonfigurasjonen til PostgreSQL. Dette ble også gjort for subnettet der sensoren kjører for å tillate direkte kommunikasjon fra denne. Etter disse konfigurasjonsendringene var databasen oppe og kjørte uten problemer. 3.4 Installasjon av frontend, webservice og core Etter forrige produksjonsetting ble applikasjonen installert under /opt/pysniff/. Dette er korrekte plassering etter oppdragsgivers standard. For å følge denne strukturen, og samtidig ha backup fra forrige installasjon ble det tatt kopi av denne mappen slik at det lett skulle være mulig å rulle tilbake til forrige versjon. Dette er ingen god løsning, men dette er en mellomting mellom å pakke applikasjonen til pakkesystemet til centos/redhat, som er en relativt kompisert affære når det kommer til de standardene som skal benyttes, og det å benytte git med tilkobling til eksternt repository på github. Da det sistnevnte ikke er mulig gjøres det på denne måten da applikasjonen ikke er satt ut i produksjonmiljøet. For å rydde opp i installasjonsmappen ble pythons virituelle miljøer slått sammen fra å være et for hver delapplikasjon, til å være ett for hele applikasjonen. Da det ikke kreves forskjellige versjoner av noen av pakkene er dette den beste løsningen for å gjøre det mulig å vedlikeholde de installerte pakkene. Pakkene som var lastet ned fra forrige leveranse ble derfor installert i det virituelle miljøet /opt/pysniff/pysniff_env. Dev branch ble lastet ned fra github.com, og inneholder all kode og nødvendige filer i.zip mappen. Denne ble overført via winscp til origo4. Denne ble pakket ut til /home/sniffer/prod0.2/pysniff-dev/ for å gjøre det optimalt å flytte programkoden til /opt/. Før applikasjonkoden ble flyttet til installasjonplasseringen ble de induviduelle applikasjonene som kjørte fra før stoppet. Det ble gjort i følgende rekkefølge: 1. Frontend ble stoppet ved å sende SIGINT «Keyboard interrupt» til manage.py som er development serveren til Django/Frontend. Deretter ble screenen den kjørte i killed. 2. Webservice ble stoppet med «Keyboard interrupt» da den får kjørt ferdig de resterende prosesser og avsluttes på en god måte. Screenen som den kjørte i ble killed. 3. For å avslutte PostgreSQL ble det forsøkt å benytte «sudo /etc/init.d/postgresql stop», men dette gikk ikke. Derfor ble først «postmaster» applikasjonen drept ved å finne programmets PID («ps aux grep postmaster») før de resterende applikasjonene som kjøres av brukeren «post» ble avsluttet. Koden som lå i /opt/pysniff ble etter dette fjernet fra mappen slik at den nye koden kunne legges inn, uten å måtte overskrive gammel kode. Rapport prodsetting M2 2013-04-07.docx Side: 4 av 6
Det viste seg også at sensoren kjørte på denne serveren fra forrige leveranse, og da programfilene ble flyttet fra /opt/pysniff/ ble denne stoppet på en dårlig måte. Da det skulle installeres en ny versjon som ikke var avhengig av noen av filene, var derimot ikke dette noe stort problem. Applikasjoninnholdet ble etter dette flyttet fra /home/sniffer/prod0.2/pysniff-dev/ til /opt/pysniff/. Ettersom de nødvendige pakkene allerede var installert i miljøet (environment) kunne applikasjonen startes uten videre. Derfor ble først webservicen startet i en egen screen. Screenen ble denne gangen startet med kommandoen «screen S pysniff_webservice» for å kunne skille de forskjellige screnene fra hverandre når flere applikasjoner kjører i screen på serveren. Oppstart av webservicen var etter dette ok, og den returnerte verdier fra helsesjekk. For oppstart av frontend kreves det litt mer arbeid da applikasjonen benytter en eksensjon til apache, «mod_wsgi» som gjør det mulig å kjøre python programmer som websider ved bruk av apache webserveren. Da det ble besluttet å gjøre endringen av python environmentet fra de induviduelle environmentene til «/opt/pysniff/pysniff_env» var det også nødvendig å skrive om konfigurasjonen fra dev branchen i git til å refleketere disse endringene. Det som måtte endres var derfor en adresse som refleketerer til python environmentet i frontend/pysniff.wsgi filen, samt i apache configen til pysniff plassert under /etc/httpd/conf.d/origo4.test.sparebank1.no.conf. Origo4.test.sparebank1.no.conf ble flyttet fra prosjektet til httpd mappen slik at denne skulle kunne startes av apache. Denne er testet til å passe til utviklingsmiljøet, men da det ikke er mulig å teste dette i oppdragsigvers testmiljø, er det nødvendig med enkelte rettelser av konfigurasjonen. Etter start av apache, med kommandoen «sudo /etc/init.d/httpd start» startet apache ok, men ved forsøk på å koble opp mot webserveren feilet denne stille, uten å returnere noe fornufig og uten feilmeldinger i loggene til apache under «/var/log/httpd/access_log og error_log». Det ble da oppdaget at filen hadde fått feil navn ved flytting og ikke hadde med postfixen «.conf» som er nødvendig for å kunne laste inn virtualhost konfigurasjonen til apache. Da dette var rettet oppstod det et problem ved at det ikke var mulig å laste ned tilleggsfiler fra applikasjonen ved besøk på url. Årsaken til dette er manglende videresendign av urlen «/static/» som refererer til de statiske filene konfigurert i djangos urls.py fil. For å rette dette ble det lagt inn et alias til denne plasseringen i virtualhost konfigurasjonen i apache. Denne ser slik ut «alias /static/ /opt/pysniff/frontend/pysniff/static/». I tillegg til konfigurasjonedringen til frontend er det også behov for logging spesfikt fra frontend applikasjonen. Denne er konfigurert til å bli lagret under /var/log/pysniff/, men da apache kjører som brukeren «apache» er også mappen nødt til å reflektere rettighetene til denne brukeren. Valget er derfor om brukeren apache skal legges inn i gruppen til «pysniff» eller om det skal opprettes en egen loggruppe for håndtering av dette. For å utsette denne problematikken og gjøre det mulig for de andre delene av PySniff til å logge til /var/log/pysniff/ ble loggingen flyttet til /var/log/pysniff/frontend/ med undermappene «trace» og «httpd» som respektivt inneholder loggingen fra selve applikasjonen og loggene som kommer fra virtualhost konfigurajsonen til apache. Etter at disse punktene var rettet kjører delapplikasjonen frontend slik den skal. Den siste applikasjonen som det i denne leveransen skal settes opp er core. Da snifferen er satt ut i produksjon på en annen applikasjonserver er det behov for kontroll over dataene som ligger i layer 1 i databasen. Dette gir core applikasjonen i form av funksjonalitet for å periodisk gjøre operasjoner på databasen. Resultatet av dette er at dataene som er i lag 1 slettes med et intervall på en dag. Dette gjør også at oppsettet av agreggering er en enkel sak i neste produksjonsetting. For oppsett av core kreves det ekstra pakker fra pypi (som er python sin pakkesentral). Det ble derfor gjennomgått hvile pakker som allerede var installert i virtualenvironmentet, og det ble da oppdaget at av de pakkene som var installert var det i enkelte tilfeller gamle pakker og betaversjoner. Disse ble derfor lastet ned på nytt med siste versjon, slik at disse kunne oppdateres. Rapport prodsetting M2 2013-04-07.docx Side: 5 av 6
Etter at disse var oppdatert, hadde i mellomtiden ikke webservicen blitt stoppet, og ettersom webservicen benytter pakker fra environmentet for å koble mot databasen, hadde denne kræsjet. Derfor måtte webservicen startes igjen etter installasjonen. For å starte core applikasjonen er det først behov for å endre konfigurasjonen for å reflektere de riktige konfigurasjonene for miljøte. Dette inkluderer stien til hvor applikasjonen ligger, hvor loggfiler skal ligge og hvilken instillingsfil som skal benyttes. Etter at disse endringene var utført ble core startet med kommandoen «python pysniffd.py start». 3.5 Instalasjonsstatus Delapplikasjon Python Database (PostgreSQL) Frontend Webservice Core Sensor Status Rapport prodsetting M2 2013-04-07.docx Side: 6 av 6