-
Notifications
You must be signed in to change notification settings - Fork 0
Dataplattform: Deploy til sandbox
Denne guiden viser deg hvordan du kan deploye alle tjenestene som Dataplattform bruker i din egen sandbox. Versjonen av Dataplattform du setter opp vil speile dev-miljøet. Merk at om du følger denne guiden vil du ikke få en fullverdig versjon av Dataplattform kjørende i sandboxen din -- det vil blant annet mangle autentisering- og autoriseringsflyt som du finner på for eksempel new-dev.dataplattform.knowit.no -- men til de fleste utviklingsformål vil den nesten-fullverdige versjonen du setter opp her fungere helt fint.
Men det første du bør gjør er å sette opp en billing alert på miljøet, det kan være greit å sette opp en grense på f.eks 10-20 $ så kan du få en melding fort dersom du skulle ha satt opp noen ressurser som bruker mye penger. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html Følger du denne guiden vil det være mulig å sette opp en SNS-topic som sender deg en epost om de estimerte kostnadene skulle bli høyere en terskelen,
Forutsetningene for å følge denne guiden er at du har fått tilgang til din egen AWS-sandbox og dev-miljøet vårt(Begge deler kan du be om ved å posten en melding #drift på slack.), samt at du har satt opp utviklingsverktøyene som beskrevet i quick starten. I tillegg har du din egen kopi av main-branchen lokalt. Alle kommandoene som er nevnt her kjøres fra rotmappa i prosjektet.
Før du begynner trenger du å ha installert Docker og ha dette kjørende i bakgrunnen. Eksempel på installering i macOS:
brew install --cask docker(Ovenstående er ikke nok på Mac. Jeg tror denne installerer Docker i /Applications evt i en eller annen startup folder slik at du må logge ut eller logge inn. Jeg endte opp med å laste ned en .dmg fra docker.com og kjøre denne. Du må få en Docker bruker fra #drift også.)
I tillegg trenger du å installere Yarn. Eksempel på installering i macOS:
brew install yarnEksempel på installering / oppdatering av Yarn i Windows med WSL:
curl --compressed -o- -L https://yarnpkg.com/install.sh | bashSjekk at versjon 1.22.19 (eller nyere) ble installert ved å kjøre følgende:
yarn --versionNB: Bruker skal opprettes i din egen sandbox!
- Åpne konsollet til sandboxen din i AWS og gå inn på IAM -> Users og trykk på Add users.
- Gi brukeren navnet
dev-deploy-botog huk av for Access key - Programmatic access. Trykk på Next. - Trykk på Attach existing policies directly, og huk av AdministratorAccess.
- Trykk Next og Create user til du er ferdig, og lagre Access key ID og Secret access key
- Konfigurer AWS-kommandolinjeverktøyet til å bruke credentials som du fikk i steget over.
En bruker med AdministratorAccess er som regel ikke å anbefale siden den ikke følger prinsippet granting of least privilege, men for denne guiden er det OK.
Har du ikke opprettet en bruker før i IAM kan du lese om dette her, og du kan finne ut hvordan du konfigurerer kommandolinjeverktøyet her. Når du konfigurerer kommandolinjeverktøyet er det viktig at du velger eu-central-1 som region.
Din versjon av Dataplattform vil kjøre på et subdomene basert på new-dev.dataplattform.knowit.no. For å klargjøre sandboxen din for dette kjører du kommandoen
dataplattform prepare-sandbox --domain-name mittbrukernavn.new-dev.dataplattform.knowit.noder du erstatter mittbrukernavn med ditt brukernavn. I bakgrunnen setter kommandoen opp en Hosted Zone, et SSL-sertifikat og noen parametre i Parameter Store. I tillegg opprettes en tekstfil, my_name_servers.txt, som skal benyttes i neste seksjon.
Dette scriptet oppretter noen AWS-ressurser i bakgrunnen som deploy-scriptet avhenger av. Hvis kommandoen skulle feile med noe ala KeyError: 'ResourceRecord', kan det være at det virker å kjøre den en gang til.
Dersom kommandoen over ikke virker, så kan stegene også utføres manuelt:
- Velg et domenenavn på formatet {BRUKERNAVN}.new-dev.dataplattform.knowit.no
- Åpne AWS konsollet og gå inn på Certificate Manager. Sett region til å være
us-east-1. Velg Request certificate, trykk Next, og fyll inn domenenavnet fra steg 1. Velg Add another name to this certificate, og legg til *.{BRUKERNAVN}.new-dev.dataplattform.knowit.no. Trykk Request. Ta vare på IDen til det nye sertifikatet. - Åpne Route 53 i AWS og gå inn på Hosted zones. Opprett en ny public hosted zone med navnet
{BRUKERNAVN}.new-dev.dataplattform.knowit.no. - Opprett en fil i rotmappa til Dataplattform prosjektet med navn
my_name_servers.txt - Åpne detaljene for hosted zone som du opprettet i steg 3. Trykk Hosted zone details, kopier linjene under Name servers og lim de inn i
my_name_servers.txt - Åpne Systems Manager og gå inn på Parameter Store.
- Opprett en parameter med navn
/dev/routes/domain_nameog verdi lik domenenavnet fra steg 1. Denne parameteren må settes i eu-central-1 regionen. - Opprett en parameter med navn
/dev/USEA1/sslIdentifierog verdi lik id'en til sertifikatet du opprettet i steg 2 (id er på formatetcertificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, ikke hele arn-verdien). Denne parameteren må settes i både eu-central-1 og us-east-1 regionen.
Du må nå konfigurere en DNS-peker fra dev-miljøet til din sandbox. Start med å gå inn på kion.awsapps.com/start#/ og velge AWS-kontoen knowit-dataplattform-dev. Inne i AWS-konsollen gjør du følgende:
- Gå inn i Route53.
- Gå inn i Hosted zones.
- Trykk deg inn på Hosted zone som har domenenavn
new-dev.dataplattform.knowit.no. - Trykk på Create Record.
- I Record name-feltet skriver du
mittbrukernavnsom definert tidligere. - Velg NS som Record type.
- I Value-feltet limer du inn verdiene fra
my_name_servers.txt. - Trykk på
Create records. - Gå inn i 'Certificate Manager' under din sandbox. Pass på at region us-east-1 er valgt. Klikk på hamburger menyen til venstre og velg List Certificates. og klikk på ditt sertifikat. Trykk 'Create records in Route 53'.
I løpet av 5-10 minutter skal sertifikatet som ble opprettet av kommandoen du kjørte i forrige seksjon gå fra status Pending validation til Issued. Dette kan du sjekke selv i sandbox-kontoen din i AWS-konsollen under tjenesten Certificate Manager. NB: Sertifikatet opprettes i regionen us-east-1, så husk å velge riktig region når du sjekker statusen til sertifikatet. Når sertifikatet har endret status til Issued kan du gå videre til neste seksjon.
Flere av tjenestene bruker en KMS-nøkkel for kryptering av data. Av sikkerhetsmessige årsaker må denne nøkkelen opprettes manuelt. Her må du være på region eu-central-1 og din egen sandbox.
- Kjør kommandoen under. Dette vil opprette en fil kalt
my_key_policy.json
dataplattform generate-key-policy -r Level4GlueRole dev-athena-Athena-Setup-role dev-dora-ingest-role- I AWS konsollet går du inn på Key Management Service og trykker Create key
- Nøkkelen skal være symmetrisk, av type KMS, og single-region. Trykk Next
- Alias skal være KMSBucketKey. Trykk Next
- Trykk Next helt til du kommer til Review-steget.
- I feltet Key policy fyller du inn innholdet i filen
my_key_policy.json. Trykk Finish. - Kopiér nøkkel ID til nøkkelen du nettopp lagde.
- Gå inn på Systems Manager, og deretter trykk på Parameter Store.
- Opprett en ny parameter med navn
/dev/kms/key-id, og verdi lik nøkkel ID som du kopierte i steg 7.
Før du kan deploye tjenestene må du opprette en fil som heter config.yml i mappen services/infrastructure/deploymentBucket. Innholdet i denne filen skal se slik ut
bucketName: globalt-unikt-bøttenavnder du erstatter globalt-unikt-bøttenavn med et bøttenavn som ikke finnes i AWS fra før, ettersom bøttenavn må være globalt unike (egentlig må bøttenavnet være unikt innenfor en partisjon, men jeg er ikke i det pedantiske hjørnet i dag.)
Kjør kommandoen under. Dette kan ta en stund, så la den stå å kjøre og sjekk innom av og til for å se at den ikke har feilet.
dataplattform deploy -i services/infrastructure/quicksight services/infrastructure/dora-glue -s services/infrastructure services/utils services/apiFor dataplattform deploy kommandoen brukes -i argumentet til å oppgi spesifikke tjenester som skal ignoreres. -s Kommandoen brukes til å oppgi hvilke tjenestemapper som skal deployes. Du kan lese mer om denne kommandoen i dataplattform.cli dokumentasjonen
Grunnen til at vi gjør det på denne måten er for å unngå å deploye unødvendig mye til sandbox. Alle ingestorene ligger i tjenestemappen services/ingestion, så vi har valgt å la denne utebli siden det som oftest ikke er nødvendig å deploye alle ingestorer til en sandbox. Det er heller ikke nødvendig å deploye tjenestene Quicksight og Dora til sandbox, så vi har valgt å ignorere disse.
Dersom dataplattform deploy kommandoen feiler uten å gi deg en fornuftig feilmelding, et tips er å gå inn på CloudFormation konsollet i AWS. Finn stacken som er forsøkt deployet, ofte ligger den under Failed eller Deleted. Når du finner den, trykk deg inn på den og åpne Events fanen. Ofte finner man bedre forklaringer på problemet her.
Windows: Hvis deploy ikke returnerer noenting (bare " og deployment complete) så kan det være at den ikke liker linjeskift, kan hjelpe å fjerne "\n" fra commands i get_deployment_commands funkjsonen i deploy.py.
Dersom du skal videreutvikle en ingestor, f. eks. cv-partner ingestoren, så må denne deployes etter at kommandoen over har kjørt ferdig. I tillegg må du se i Dataplattform: Parametre i AWS om ingestoren krever at du setter inn parametre manuelt før ingestoren deployes.
Når alt er klart kjører du følgende kommando
dataplattform deploy -s services/ingestion/{INGESTOR}For å legge inn tabeller i databasen må du manuelt registrere de i sandboxen din. Her er et eksempel for ubw_customer_per_resource:
cd /dataplattform-directory/services/ingestion/ubwCustomerPerResource/
dataplattform register-table ubw_customer_per_resourceDette skal lage en crawler som igjen registrerer tabellen ubw_customer_per_resource. Filområdet i S3 legges til tabellen som et "target" for crawleren. Denne crawleren kan da "crawle" dataene og lage metadata. Om alt gikk bra, vil du få en tilbakemelding i Json-format tilsvarende denne:
{
"status": "new",
"name": "dev_level_3_crawler",
"role": "arn:aws:iam::444444444444:role/dev-glue-level-3-glue-access",
"database": "dev_level_3_database",
"targets": [
{
"Path": "s3://dev-datalake-bucket-444444444444/data/level-3/ubw/customer_per_resource/structured/ubw_customer_per_resource",
"Exclusions": [
"*_metadata"
]
}
]
}Deretter kan følgende kommando kjøres for å oppdatere registrerte tabeller:
dataplattform database -e dev -a 3 update-tables
# -e: Environment
# -a: Access level, hvor 3 vil si level 3
Om stegene tidligere er fulgt, vil tilbakemeldingen være noe lignende:
Table update starting ...
Estimated time left: 15.0 seconds
Status: SUCCEEDED
{
"run_time": 47.69,
"created": 1,
"updated": 0
}
Tables:
[
"ubw_customer_per_resource"
]
For å lage testdata, må det endre Json-filer som inneholder testdata for den ønskede tabellen.
Eksempelvis for ubw_customer_per_resource kan man finne testdata i /dataplattform-directory/services/ingestion/ubwCustomerPerResource/tests/test_data.json.
Videre må endringene i mock-data deployes og lambda-funksjoner invokes med følgende kommandoer:
cd /dataplattform-directory/
sls deploy --stage dev # Deployer oppdateringene til din sandbox
sls invoke --stage dev -f mock # Invoker lambda-funksjonen mockDersom alt gikk bra, får du en Json-respons med statuskode: 200.
Til slutt oppdateres databasen når du skriver følgende i terminalen:
dataplattform database -e dev -a 3 update-tablesNavn på tabellene kan finnes nederst i en *process_lambda.py-fil. Disse skal ligge under lib for hver ingestion der det lages en tabell.
Om alt fungerer som normalt, skal du nå kunne se den registrerte tabellen og testdataene i Athena.