SAM-deploy¶

SAM-deploy lar et team kjøre serverless-funksjoner (Lambda og Fargate) i AWS ved siden av Databricks-workspacet, typisk for å hente data som plattformen må hente selv. Dataspeilet slår på SAM-deploy per workspace. Med det følger rettigheter for deploy-rollen til GitHub Actions, en permission boundary med krav til navn, en bøtte for SAM-artefakter og et ECR-register.

Navnekravene og permission boundary-en gjelder alle workspaces med SAM-deploy. Mappestrukturen, secret-flyten og CI/CD-pipelinen beskriver oppsettet i padda-databrikker.

Verktøy¶

Du trenger følgende verktøy installert lokalt:

Mappestruktur¶

Hver serverless-funksjon bor i sin egen mappe under sam/ i deploy-repoet (padda-databrikker):

padda-databrikker/
└── sam/
    ├── my-api-collector/
    │   ├── template.yaml
    │   └── src/
    │       ├── app.py
    │       └── requirements.txt
    ├── my-container-function/
    │   ├── template.yaml
    │   └── src/
    │       ├── app.py
    │       ├── Dockerfile
    │       └── requirements.txt
    └── my-fargate-task/
        ├── template.yaml
        └── src/
            ├── app.py
            ├── Dockerfile
            └── requirements.txt

CI/CD-pipelinen oppdager automatisk alle mapper på dybde 1 under sam/ og deployer hver enkelt uavhengig.

Navnekonvensjoner¶

Alle ressursnavn må starte med workspace-navnet ditt som prefiks. Permission boundary støtter både - og _ som separator etter workspace-navnet. Erstatt <workspace-name> med det faktiske workspace-navnet ditt (f.eks. dig-eksempelteam-stage).

ECR-repositorier for container-baserte tjenester¶

Workspaces med enable_ecr_namespace i sam_deploy-modulen får ett ECR-repositorium per tjeneste. Repositoriet opprettes automatisk av ECR første gang workflowen pusher et image, via en repository creation template som plattformteamet eier i Terraform. Templaten setter lifecycle-policy (behold siste 10 images), pull-tilgang for Lambda og kostnadstagger.

Ny tjeneste med Dockerfile trenger ingen endring i padda-iac. Deploy-rollen kan ikke slette repositorier.

Permission boundary¶

Hver IAM-rolle i en SAM-template må inkludere en permission boundary. Boundary-ARN-en sendes automatisk av deploy-workflowen som PermissionsBoundaryArn-parameteren:

Parameters:
  PermissionsBoundaryArn:
    Type: String
    Description: Permission boundary ARN (settes automatisk av deploy-workflowen)

Resources:
  MyFunctionRole:
    Type: AWS::IAM::Role
    Properties:
      PermissionsBoundary: !Ref PermissionsBoundaryArn
      # ...

Boundary-en begrenser hvilke tilganger rollen kan ha. Den sikrer at workspace-funksjoner ikke kan eskalere privilegier utover det tiltenkte omfanget.

Secrets via SSM Parameter Store¶

Hemmeligheter håndteres gjennom GitHub Environment-secrets og synkroniseres til AWS SSM Parameter Store av deploy-workflowen.

Flyt¶

flowchart LR
    GH[GitHub Environment Secret\nSSM_DATABASE_URL] -->|deploy-workflow| SSM[SSM Parameter Store\n/<workspace-name>/database-url]
    SSM -->|boto3 ved kjøretid| Lambda

Navnekonvensjon¶

Deploy-workflowen transformerer secret-navn slik:

1. Fjern SSM_-prefikset
2. Gjør om til små bokstaver
3. Erstatt understrek med bindestrek

Legge til en ny secret¶

1. Gå til repoets Settings → Environments → stage → Add secret
2. Gi den navnet SSM_<DITT_PARAM_NAVN> (store bokstaver, understrek)
3. Sett verdien
4. Neste deploy synkroniserer den til SSM som /<workspace-name>/<ditt-param-navn>

Lese secrets ved kjøretid¶

Send SSM-parameterbanen som en miljøvariabel i template.yaml, og hent den med boto3:

Environment:
  Variables:
    DB_URL_PARAM: /<workspace-name>/database-url

import os
import boto3


def get_secret(param_name: str) -> str:
    ssm = boto3.client("ssm")
    response = ssm.get_parameter(Name=param_name, WithDecryption=True)
    return response["Parameter"]["Value"]


# Bruk
db_url = get_secret(os.environ["DB_URL_PARAM"])

CI/CD-pipeline¶

Deploy-pipelinen er definert i .github/workflows/deploy.yml i padda-databrikker.

Trigger¶

• Manuelt: workflow_dispatch
• Pull requests til main-, dev- eller stage-brancher

Slik fungerer det¶

flowchart TD
    A[Generer matrise] -->|oppdager sam/-mapper| B[Deploy hver funksjon]
    B --> C[Konfigurer AWS via OIDC]
    C --> D[Logg inn til ECR]
    D --> E[Synk SSM_-secrets til SSM]
    E --> F[sam build]
    F --> G{Inneholder 'fargate'?}
    G -->|Ja| H[Docker build & push til ECR]
    G -->|Nei| I[sam deploy]
    H --> I

1. Matrisegenerering — oppdager alle sam/*/-mapper og oppretter en parallell matrise
2. AWS-autentisering — bruker OIDC (ingen lagret legitimasjon) for å assume workspace deploy-rollen
3. ECR-innlogging — autentiserer Docker mot ECR-registeret
4. Secret-synk — synkroniserer alle SSM_-prefiksede GitHub-secrets til SSM Parameter Store
5. SAM build — bygger hver funksjon (installerer avhengigheter, pakker kode)
6. Docker build (bare Fargate) — bygger og pusher Docker-imaget til ECR
7. SAM deploy — deployer CloudFormation-stacken med permission boundary

Miljøvariabler¶

Følgende er konfigurert som GitHub Environment-variabler/-secrets for stage-miljøet:

Lokal testing¶

Zip-basert Lambda¶

cd sam/my-function
sam build
sam local invoke MyFunction

Container-basert Lambda¶

cd sam/my-container-function
sam build
sam local invoke MyContainerFunction

Fargate¶

Fargate-tasks kan ikke testes med sam local invoke. Test dem direkte med Docker:

cd sam/my-fargate-task/src
docker build -t my-fargate-task .
docker run --env LOG_LEVEL=INFO my-fargate-task

Runtimes og arkitekturer¶

Relatert innhold¶

Forklaringer:

• Arkitektur — hvorfor plattformen bruker serverless-tjenester for å hente data
• Serverless compute — Lambda og Fargate, og når du velger hva

Guider:

• Hente data via API — sette opp en funksjon som henter data til landing zone
• Håndtere secrets — hemmeligheter for Lambda og Fargate steg for steg

Referanser:

• Navnekonvensjoner — prefikskravene i sammenheng med plattformens øvrige navn
• Roller og rettigheter — identitetene GitHub Actions deployer med
• Landing zone — bøtta funksjonene skriver til