OutSystems Agile -alustalla luodun sovelluksen käyttöönotto

Lue sarjan aikaisemmat erät: Aloittaminen OutSystems Agile -alustalla, OutSystems Agile -alustan perusteiden oppiminen, OutSystems Agile Platform Service Studio -kokemuksen kuvaileminen ja työskentely OutSystems Agile -ympäristön integraatiostudion kanssa.

Kun minulla oli Rat Catcher tietyllä toiminnallisuustasolla, tunsin, että oli aika laittaa se jonnekin yleisölle, jotta muut voivat nähdä sen; tämä tarkoitti kuitenkin, että oli aika ottaa sovellus käyttöön. Koko kehitysprosessin ajan olin suorittanut käyttöönottoja paikalliselle palvelimelle testaustarkoituksia varten. Kerron teille kokemuksistani julkisen beeta-asennusympäristön luomisessa - erityisesti mitä tein oikein ja missä tein muutaman virheen.

Kun olin valmis ensimmäiseen julkiseen käyttöönottoon, en ajatellut tai harkinnut täysin infrastruktuuriani; ollakseni rehellinen, lavastusympäristöni on koottu halpaan. Minulla on erittäin vähän virtaa kuluttava Windows 2008 R2 -palvelin, jossa on pari pientä VM: tä (yksi Team Foundation Server -palvelimelle, toinen FreeBSD-posti- / Web-palvelimelle), joka toimii myös paikallisena tiedostopalvelimena, Web-palvelimena joillekin pienille Web-sivustot ja verkkotunnuksen ohjain. Tämän palvelimen resurssien maksimoimiseksi päätin ottaa OutSystems Agile Platform -komponentit käyttöön suoraan palvelimelle.

Vaikka tämä oli täysin toimiva asennus, se ei todellakaan vastannut tarpeitasi kovin hyvin. Suurin ongelma on minulle, että ketterä Platform Server -palvelin on otettava käyttöön oletus-IIS-verkkosivustolla. Kokemukseni mukaan, jos tämä on sovelluksen vaatimus, palvelimen tulisi olla omistettu kyseiselle tehtävälle, vain siltä varalta, että toisesta sovelluksesta tulee koskaan samanlainen vaatimus. Windows-palvelimen Certificate Authority -järjestelmä on loistava esimerkki. Haluatko todella joko huolehtia IIS: n lukitsemisesta hakemistokohtaisesti vai onko CA-sivustoni alttiina ulkomaailmalle? Luultavasti ei. Joten etsin keinoja välttää tämä vaatimus. Päivän lopussa, kun sain sen (jonkin verran) toimimaan, en ollut tyytyväinen tuloksiin. En vain halua yrittää taistella järjestelmiini - se johtaa aina ongelmiin tiellä.

Joten sitouduin asettamaan palvelimelle uuden VM: n - tämä on omistettu ketterälle Platform-palvelimelleni. Jos et ole koskaan aiemmin ottanut Agile-alustaa käyttöön Windows-palvelimella, älä huoli ... asennusohjelma käsittelee kaiken puolestasi, aivan kuten työpöydällä. Yksi asia, josta en pitänyt Agile Platform -versiosta 4, oli se, että asennus oli vähän hankala. Tiimi teki uskomattoman työn version 5 kanssa ja sai asennuksen sujuvaksi ja helpoksi. Aloitin barebones 2008 R2 -asennuksella, jossa minun täytyi vain liittyä siihen verkkotunnukseen, määrittää NIC ja päivittää se päivityksillä. Agile Platform -asennusohjelma lisää jopa vaadittavat Windows-roolit ja palvelut, kuten IIS.

Kun sain VM: n käyttöön, tarvitsin tavan ohjata Web-liikenteeni siihen. Minulla on nykyisessä tilanteessa vain yksi staattinen julkinen IP-osoite, jonka olen ohjannut toimialueen ohjaimeen / fyysiseen VM-isäntään. Loin palvelimelle verkkosivun, joka oli sidottu DNS-nimiin, joita käytän betatestiini. Sitten käytin IIS URL Rewrite -moduulia ohjaamaan liikennettä VM: ään luomalla käänteisen välityspalvelimen ( kuva A ). Voit nähdä kuvakaappauksessa käyttämäni kokoonpanon (lofn-ratcatcher.titaniumcrowbar.com on FQDN, johon VM vastaa ja joka on sidottu palvelimen oletusverkkosivustoon). Koko prosessi kesti vähemmän kuin 10 minuutin ponnistelukseni loppupuolella. Kuvio A

URL-uudelleenkirjoitusmoduulin saapuva sääntö, jota tarvitaan liikenteen ohjaamiseksi VM: ään. (Napsauta kuvaa suurentaaksesi.)

Kun olin määrittänyt VM: n, oli aika testata se ja määrittää se käytettäväksi. Osoitin selaimesi Service Center -osoitteeseen (http://fqdn.server.name/ServiceCenter) ja voila se tuli aivan odotetusti. Tämä vahvisti, että asennukseni ja uudelleenohjaukseni toimivat oikein. Suoritin heti Service Centerin alkuperäiset määritykset:

  • Palvelimen nimi
  • Sähköpostin määritykset
  • Vaihda järjestelmänvalvojan salasana
Seuraavaksi halusin varmistaa, että ulkopuoliset vierailijat eivät pääse Palvelukeskukseen. Onko Service Center turvassa? Toki se on - kun olet vaihtanut järjestelmänvalvojan salasanan. Samanaikaisesti on hyvä tietoturva estää kokonaan joku, jolla ei koskaan pitäisi olla pääsyä joihinkin yrittämättä. Jälleen kerran, URL Rewrite pelastaa. Loin uuden säännön ( kuva B ) ja siirrin sen sitten ylöspäin etusijalle ensimmäiseen tekemääni sääntöyn nähden. Koska palvelimeen pääsee sisäisesti eri nimellä kuin ulkoisesti näkyy, voin silti käyttää Service Centeriä palvelimen sisäisen nimen avulla. Toinen nopea testi osoittaa meille, että emme pääse Service Centeriin ulkoisella FQDN: llä, mutta pääsemme siihen sisäisen FQDN: n avulla. Kuvio B

URL: n uudelleenkirjoitussääntö estää pääsyn Palvelukeskukseen. (Napsauta kuvaa suurentaaksesi.)
On toinen tapa lähestyä tätä asiaa. Service Studiossa voit määrittää minkä tahansa näytön olevan vain sisäisesti käytettävissä; itse asiassa koko palvelukeskus on asetettu saataville sisäisesti. Jos siirryt Käynnistä-valikkoon palvelimella, johon haluat ottaa käyttöön, löydät määritystyökalun; sieltä voit asettaa sisäisen verkon osoitteet (tai osoitealueen) ( kuva C ). Kun tämä on asetettu, kaikki pyynnöt tämän alueen ulkopuolelta sisäisesti rajoitetuille alueille (mukaan lukien kaikki palvelukeskukset) estetään. Tämä ei toimi minulle hyvin nykyisessä tilanteessa, koska uudelleenohjauksen myötä kaikki Platform Server -palvelimelle osoitetut pyynnöt näyttävät tulevan käänteisestä välityspalvelimesta; Joten minun olisi sisällytettävä koko verkkoani paitsi yksi palvelin sisäiseen alueeseeni. Päivän lopussa tietyn kokoonpanoni kannalta mielestäni on helpompaa pysyä estämällä sitä käänteisessä välityspalvelimessa. Kuvio C

Ketterä alusta -kokoonpanotyökalu. (Napsauta kuvaa suurentaaksesi.)

Palvelimen asennuksen valmistuttua oli aika asentaa Rat Catcher uuteen palvelimeen. Napsautin Service Studiossa Yhdistä palvelimeen -painiketta ja kirjoitin palvelimen sisäiselle FQDN-tunnukselle ja järjestelmänvalvojan käyttäjänimelle ja salasanalle. Mutta kohtasin silloin uuden ongelman: puuttuvia viitteitä. Service Studio -projekti sisältää koodin itse sovellukselle, mutta ei tarvittaville laajennuksille. Jotkut tarvitsemani referenssit olivat Agile Network -sovelluksesta ladattujen komponenttien joukosta, ja jotkut kirjoitin itse Integration Studiossa. Latasin ne uudelleen ketterästä verkosta ja avasin ne sitten Integration Studiossa julkaistakseen ne uudelle palvelimelle. (Voisin ladata ne Service Centeristä paikalliselle koneelleni.) Julkisin myös laajennukseni uudelle palvelimelle. Kun tein tämän, sain palata Service Studio -palveluun ja julkaista Rat Catcherin uudelle alustalle.

Näin tein alkuperäisen käyttöönoton, mutta osoittautuu, että on olemassa paljon parempi tapa käsitellä käyttöönottoja. Palvelukeskuksessa voit määritellä uuden ratkaisun, ja sen riippuvuudet lasketaan automaattisesti sinulle. Kun ratkaisu on tehty, voit julkaista sen reaaliaikaisena palvelimella; tämä suorittaa versioinnin, joten voit suorittaa palautuksia tarvittaessa. Lisäksi voit ladata koko ratkaisun (mukaan lukien kaikki riippuvuudet) OSP-tiedostona, joka voidaan asentaa muihin palvelimiin. Tällä tavalla sinulla voi olla erillisiä versioita, jotka voidaan helposti ottaa käyttöön muihin järjestelmiin tarvitsematta huolehtia riippuvuuspuiden ajan tasalla pitämisestä, ja tarvittaessa OSP-tiedosto voidaan purkaa ja tarkistaa sen osat.

Nyt viimeinen testi ... Rat Catcherin avaaminen ulkoisella FQDN: llä. Ja katso, Rat Catcher on nyt yleisön saatavilla testata ( kuva D ). Voit vapaasti kokeilla sitä ja kertoa minulle mielipiteesi. Minulla on vielä paljon työtä tekemistä; Ensinnäkin minun on integroitava maksuprosessori järjestelmään, ja minun on todellakin saatava sivut lohkoteltuksi, kuten näette. Kuvio D

Rat Catcher elossa ja valmis maailmalle kokeilemaan sitä. (Napsauta kuvaa suurentaaksesi.)

Tämä on alku ja ketterän alustan ansiosta se siirtyi pääni takana olevasta ideasta julkiseen beetaversioon hyvin lyhyessä ajassa, työtuntien mittaamana (öisin ja viikonloppuina toteutettavana projektina, kesti vielä hetken tarkastellaan kalenteria).

Sarjan seuraavassa erässä keskustelen eräistä töistä, jotka minun piti tehdä saadaksesi tämän sovelluksen valmiiksi parhaaseen aikaan.

J.Ja

Justinin teollisuuden kuuluminen: Justin James on tehnyt sopimuksen Spiceworksin kanssa tuotteiden osto-ohjeiden kirjoittamisesta; hänellä on sopimus Hapaxin omistaman OpenAmplifyn kanssa blogisarjojen, tutoriaalien ja artikkeleiden kirjoittamisesta; ja hänellä on sopimus OutSystemsin kanssa artikkeleiden kirjoittamisesta, näytekoodista jne.

-------------------------------------------------- -------------------------------------

Hanki viikoittaisia ​​kehitysvinkkejä postilaatikkoosi Pidä kehittäjätaidosi terävänä kirjautumalla TechRepublicin ilmaiseen Web Developer -uutiskirjeeseen, joka toimitetaan joka tiistai. Tilaa automaattisesti tänään!

© Copyright 2020 | mobilegn.com