Implementering af en applikation oprettet med OutSystems Agile Platform

Læs de foregående rater i serien: Kom godt i gang med OutSystems Agile Platform, Lær det grundlæggende i OutSystems Agile Platform, beskrive OutSystems Agile Platform Service Studio-oplevelse og Arbejde med OutSystems Agile Platforms Integrations Studio.

Når jeg havde Rat Catcher på et bestemt funktionalitetsniveau, følte jeg, at det var på tide at placere det et sted offentligt for andre at se det; Dette betød dog, at det var tid til at implementere applikationen. Gennem udviklingsprocessen havde jeg udført implementeringer til den lokale server til testformål. Jeg vil fortælle dig om mine oplevelser med at oprette et implementeringsmiljø for den offentlige beta - specifikt hvad jeg gjorde rigtigt, og hvor jeg begik et par fejl.

Da jeg var klar til min første offentlige implementering, tænkte jeg ikke helt på eller overvejede min infrastruktur; For at være ærlig er mit iscenesættelsesmiljø sammensat af billige. Jeg har en meget lavt drevet Windows 2008 R2-server med et par små VM'er på (en til Team Foundation Server, en anden som en FreeBSD-mail / webserver), der også fungerer som en lokal filserver, webserver for nogle små Websteder og en domænecontroller. For at maksimere denne server's ressourcer besluttede jeg at installere OutSystems Agile Platform-komponenter direkte til serveren.

Selvom dette var en perfekt funktionel opsætning, passede det virkelig ikke mine behov særlig godt. Det største problem for mig er, at Agile Platform Server skal installeres på standard IIS-webstedet. Efter min erfaring, hvis dette er et krav til en applikation, skal serveren være dedikeret til den opgave, bare hvis der nogensinde er et lignende krav fra en anden applikation. Certificate Authority-systemet på en Windows-server er et godt eksempel. Ønsker jeg virkelig at begynde at bekymre mig om at låse IIS på en per-katalogbasis eller få min CA's websted udsat for omverdenen? Sikkert ikke. Så jeg søgte efter måder at undgå dette krav. I slutningen af ​​dagen, mens jeg fik det (noget) til at fungere, var jeg ikke tilfreds med resultaterne. Jeg kan bare ikke lide at prøve at bekæmpe mine systemer - det fører altid til problemer ned ad vejen.

Så jeg forpligtede mig til at oprette en anden VM på serveren - denne er dedikeret til at være min Agile Platform-server. Hvis du aldrig har installeret Agile Platform på en Windows-server før, skal du ikke bekymre dig ... installationsprogrammet håndterer det hele for dig, ligesom det gør på skrivebordet. En ting jeg ikke kunne lide ved Agile Platform i version 4 var, at installationen var en smule vanskelig. Holdet gjorde et fantastisk stykke arbejde med version 5 og fik installationen til at være glat og let. Jeg startede med en barebones 2008 R2-installation, hvor alt hvad jeg skulle gøre, var at slutte det til domænet, konfigurere NIC og få det opdateret med programrettelser. Agile Platform-installationsprogrammet tilføjer endda de nødvendige Windows-roller og -tjenester som IIS.

Når jeg fik VM opsat, havde jeg brug for en måde at dirigere min webtrafik til. I mit nuværende scenarie har jeg kun en statisk, offentlig IP-adresse, som jeg har rettet til min domænecontroller / fysiske VM-vært. Jeg oprettede et websted på serveren, der var bundet til de DNS-navne, jeg bruger til min betatest. Derefter brugte jeg IIS URL Rewrite-modulet til at dirigere trafik til VM og skabe en omvendt proxy ( figur A ). Du kan se den konfiguration, jeg brugte i skærmbilledet (lofn-ratcatcher.titaniumcrowbar.com er en FQDN, som VM vil svare på og er bundet til "Standardwebsted" på serveren). Hele processen tog mig mindre end 10 minutters indsats værd efter min afslutning. Figur A

URL-omskrivningsmodulets indgående regel er nødvendig for at omdirigere trafik til min VM. (Klik på billedet for at forstørre det.)

Når jeg havde oprettet VM, var det tid til at teste den og konfigurere den til brug. Jeg pegede min browser på adressen til Servicecenter (http://fqdn.server.name/ServiceCenter) og voila den kom op som forventet. Dette bekræftede, at min installation og min omdirigering fungerede korrekt. Jeg udførte straks min oprindelige konfiguration af Service Center:

  • Server navn
  • E-mail-konfiguration
  • Skift administratoradgangskode
Dernæst ønskede jeg at sikre, at eksterne besøgende ikke kan få adgang til Servicecenteret. Er Servicecenteret sikkert? Selvfølgelig er det - når du ændrer administratoradgangskoden. På samme tid er det en sund sikkerhed at helt blokere nogen, der aldrig skal have adgang til noget fra endda at prøve. Endnu en gang, URL omskrives til redning. Jeg oprettede en ny regel ( figur B ) og flyttede den derefter op for at have forrang for den første regel, jeg lavede. Fordi serveren er tilgængelig med et andet navn internt, end det er synligt eksternt, er jeg stadig i stand til at få adgang til Service Center ved hjælp af det interne navn på serveren. En anden hurtig test viser os, at vi ikke kan få adgang til Servicecenteret ved hjælp af det eksterne FQDN, men vi kan komme til det med det interne FQDN. Figur B

URL-omskrivningsregel for at blokere adgangen til Servicecenteret. (Klik på billedet for at forstørre det.)
Der er en anden måde at nærme sig dette spørgsmål på. I Service Studio kan du definere en hvilken som helst given skærm for kun at være internt tilgængelig; faktisk er hele Servicecentret oprettet til at være internt tilgængeligt. Hvis du går til din Startmenu på serveren du vil distribuere til, finder du konfigurationsværktøjet; derfra kan du indstille adresser (eller et adresseområde) på dit interne netværk ( figur C ). Når dette er indstillet, blokeres eventuelle forespørgsler fra dette område til internt begrænsede områder (inklusive alt servicecenter). Dette fungerer ikke godt for mig i mit aktuelle scenarie, fordi alle anmodningerne til platformserveren med omdirigeringen ser ud til at komme fra den omvendte proxyserver; så jeg bliver nødt til at inkludere hele mit netværk undtagen en server i mit interne interval. I slutningen af ​​dagen, for min særlige konfiguration, føler jeg, at det er lettere at bare holde mig ved at blokere den ved reverse proxy. Fig

Agile platformkonfigurationsværktøj. (Klik på billedet for at forstørre det.)

Da serveropsætningen var afsluttet, var det tid til at indsætte Rat Catcher til den nye server. I Service Studio klikkede jeg på knappen Forbind til server og indtastede den interne FQDN på serveren og admin-brugernavnet og adgangskoden. Men jeg blev derefter konfronteret med et nyt problem: manglende referencer. Service Studio-projektet indeholder koden til selve applikationen, men ikke for de nødvendige udvidelser. Nogle af de referencer, jeg havde brug for, var fra komponenter, der blev downloadet fra Agile Network, og nogle blev skrevet af mig selv i Integration Studio. Jeg downloadede dem igen fra Agile Network og åbnede dem derefter i Integration Studio for at offentliggøre dem til den nye server. (Jeg kunne have downloadet dem fra Servicecenteret på min lokale maskine.) Jeg offentliggjorde også mine udvidelser til den nye server. Når jeg gjorde dette, var jeg i stand til at gå tilbage til Service Studio og udgive Rat Catcher til den nye platform.

Sådan gjorde jeg min første installation, men det viser sig, at der er en meget bedre måde at håndtere implementeringer på. I Service Center kan du definere en ny løsning, og dens afhængigheder beregnes automatisk for dig. Når en løsning er lavet, kan du offentliggøre den for at være live på serveren; dette udfører versionering, så du kan udføre rollbacks om nødvendigt. Derudover kan du downloade hele løsningen (inklusive alle afhængigheder) som en OSP-fil til distribution til andre servere. På denne måde vil du være i stand til at have diskrete versioner, der let kan distribueres til andre systemer uden at skulle bekymre dig om at fange afhængighedstræerne opdaterede, og om nødvendigt kan OSP-filen pakkes ud og dens dele inspiceres.

Nu, den sidste test ... åbner Rat Catcher ved hjælp af den eksterne FQDN. Og se og se, Rat Catcher er nu tilgængelig for offentligheden til at teste ( figur D ). Du er velkommen til at prøve det og fortæl mig hvad du synes. Jeg har stadig en masse arbejde at gøre; for det første er jeg nødt til at integrere en betalingsprocessor i systemet, og jeg har virkelig brug for at få siderne spiret op, som du kan se. Figur D

Rat Catcher i live og klar til verden til at prøve det. (Klik på billedet for at forstørre det.)

Dette er en start, og takket være Agile-platformen gik det fra en idé bagpå mit hoved til offentlig beta på meget kort tid målt på arbejdstimer (som et projekt om natten og weekender tog det stadig et stykke tid ser på kalenderen).

I den næste rate i serien vil jeg diskutere noget af det arbejde, jeg var nødt til at gøre for at gøre denne applikation klar til prime time.

J.Ja

Videregivelse af Justin's brancheforhold: Justin James har en kontrakt med Spiceworks om at skrive guider til produktkøb; han har en kontrakt med OpenAmplify, som ejes af Hapax, om at skrive en række blogs, tutorials og artikler; og han har en kontrakt med OutSystems om at skrive artikler, prøvekode osv.

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

Få ugentlige udviklingstips i din indbakke Hold dine udviklerværdigheder skarpe ved at tilmelde dig TechRepublics gratis webudvikler-nyhedsbrev, der leveres hver tirsdag. Tilmeld automatisk i dag!

© Copyright 2020 | mobilegn.com