Skip to content

Draft: switch AWS deployment from Serverless to CDK - #121

Open
colorchestra wants to merge 20 commits into
developfrom
deploy-2026
Open

colorchestra wants to merge 20 commits into
developfrom
deploy-2026

Conversation

@colorchestra

Copy link
Copy Markdown
Collaborator

No description provided.

@netlify

netlify Bot commented May 5, 2026

Copy link
Copy Markdown

Deploy Preview for serene-narwhal-9b7b1c ready!

Name Link
🔨 Latest commit 479d725
🔍 Latest deploy log https://app.netlify.com/projects/serene-narwhal-9b7b1c/deploys/6a1c5c19c7e3970008456b39
😎 Deploy Preview https://deploy-preview-121--serene-narwhal-9b7b1c.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@netlify

netlify Bot commented May 5, 2026

Copy link
Copy Markdown

Deploy Preview for peaceful-raindrop-cb2462 ready!

Name Link
🔨 Latest commit 479d725
🔍 Latest deploy log https://app.netlify.com/projects/peaceful-raindrop-cb2462/deploys/6a1c5c19512fed00080fbb28
😎 Deploy Preview https://deploy-preview-121--peaceful-raindrop-cb2462.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@netlify

netlify Bot commented Sep 3, 2026

Copy link
Copy Markdown

Deploy Preview for serene-narwhal-9b7b1c ready!

Name Link
🔨 Latest commit 58bf37c
🔍 Latest deploy log https://app.netlify.com/projects/serene-narwhal-9b7b1c/deploys/6aaaa332669bca000761856a
😎 Deploy Preview https://deploy-preview-121--serene-narwhal-9b7b1c.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@netlify

netlify Bot commented Sep 3, 2026

Copy link
Copy Markdown

Deploy Preview for peaceful-raindrop-cb2462 ready!

Name Link
🔨 Latest commit 58bf37c
🔍 Latest deploy log https://app.netlify.com/projects/peaceful-raindrop-cb2462/deploys/6aaaa332689e8b0008baa746
😎 Deploy Preview https://deploy-preview-121--peaceful-raindrop-cb2462.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@jh0ker jh0ker left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claudia und ich haben uns das mal vorgenommen. Alles in allem glaube ich gut. Kannst ja mal über meine Kommentare schauen und überlegen, was davon du dir noch vornehmen möchtest und was wir aufschieben.

Comment thread cdk/lib/cdk-stack.ts
Comment on lines +193 to +194
// 403 und 404 auf 200 und "Upps!"-Seite umbiegen; Originalverhalten
// langfristig vllt. so ändern, dass das nur App-Pfade betrifft und nicht z.B. API-Pfade

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ja ich glaub das könnte tatsächlich ein Problem sein. Wir haben einen Service Worker der die Assets cached, wenn wir da einmal ein Asset laden was fehlt, wird er denke ich die "Upps!"-Seite als Response cachen. Das ist dann schwierig, wieder loszuwerden. Ist erstmal kein großes Problem, weil der Offline-Modus hinter einem Feature Flag sitzt, und nur dann auch der Service Worker anspringen sollte.

Aber trotzdem fragwürdig, ob das sinnvoll ist, das jetzt 1:1 zu übernehmen. Wir haben ja jetzt auch z. B. die OAC neu hinzugefügt, also ein 100% "sauberes" Refactoring, wo wir die alten Bugs mitschleppen, ist ja nicht zwingend unser Ziel oder?

Comment thread cdk/lib/cdk-stack.ts
certificate,
priceClass: cloudfront.PriceClass.PRICE_CLASS_100,
minimumProtocolVersion: cloudfront.SecurityPolicyProtocol.TLS_V1_2_2021,
defaultRootObject: 'index.html',

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wir haben noch andere Entrypoints, spezifisch /settings/ und /teilen/. Wäre eigentlich besser, wenn dann z. B. /teilen/ auch auf /teilen/index.html pointed. Vorher lief es ja über so einen Website-Endpoint, der das gemacht hat. Sind auch wieder eher so obskure Features, aber die gehen halt kaputt.

vgl. https://programmieren.wdrmaus.de/settings/ vs https://dev.maus.metahost.org/settings/index.html

concurrency:
group: deploy-${{ inputs.stage }}
cancel-in-progress: false
env:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wir hatten vorher die Environment-Variable BRANCH gesetzt. In webpack.config.js und env.js passieren damit Dinge, und die Piano-Integration nutzt die um zu entscheiden, ob es an den Testing- oder Production-Sink die Events schicken soll.
Ist vielleicht nicht verkehrt, das erstmal zu übernehmen, auch wenn ich da nicht gegen ein Refactoring wäre. In meinem Branch experiment/fix-local-dev-setup habe ich das teilweise schon addressiert (Bucket-Namen werden z. B. nicht mehr über BRANCH abgeleitet). Im Prinzip verbleibt nur noch die Piano-Geschichte und etwas toter Legacy-Code.

- name: CDK diff → Summary
working-directory: cdk
run: |
npx cdk diff --app cdk.out "MausApp-${{ inputs.stage }}" 2>&1 | tee diff.txt

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wenn der cdk diff failed verschluckt die Pipe den exit code und der Step bleibt grün. Ein set -o pipefail würde hier Abhilfe schaffen, alternativ wohl auch ein shell: bash auf dem Step.

Comment thread cdk/lib/cdk-stack.ts
})

// Deployment für Assets, die nicht gecachet werden sollen
new s3deploy.BucketDeployment(this, 'FrontendHtml', {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claudia hat hier ein paar Anmerkungen gemacht, eher nitpicky:

  • Warum reicht hier das default memoryLimit aus, wenn doch beide das selbe Asset-Bundle entpacken? Also zumindest könnte das hier auch eng werden.
  • Da das memoryLimit anders ist als das von FrontendStatic ist, werden wohl außerdem zwei Lambda Handlers erzeugt. Wenn man das selbe wählt, erzeugt er nur einen, der dann beide Deploys macht. Wäre also wohl effizienter, das selbe zu wählen.

Comment thread cdk/README.md

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scheint mir teilweise outdated zu sein (Bucket-Namen, DNS setup). Braucht man es noch? DEPLOYMENT.md ist glaub ich näher dran an der Realität.

Comment thread cdk/lib/cdk-stack.ts
Comment on lines +77 to +80
// aws-sdk v2 wird gebundlet, weil neuere Node-Runtimes es nicht mehr mitliefern
// TODO ist auch veraltet, austauschen: https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-sdk-for-javascript-v2/
nodeModules: ['aws-sdk', 'nanoid', 'shortid'],
externalModules: [],

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wenn ich das richtig verstehe installisiert er ja damit jetzt ein node_modules in die Lambdas, wo die Backend-Deps komplett drin sind und macht entsprechend auch ein npm ci während des synths.
Braucht es das wirklich, oder kann esbuild das nicht automatisch mit bundlen? Wenn wir in src/backend/lib/s3.js den Import noch anpassen, kann er wohl auch den Großteil droppen und nur den S3-Client mit bundlen, was auch die Bundlesize & cold-starts massiv reduziert.
Wir haben jetzt die Dependencies ja auch dreifach definiert: Hier, in cdk/package.json und der root package.json (auch jeweils mit Lockfile). Wenn wir esbuild alles machen lassen, dann bräuchten wir nur noch die eine im root.

Comment thread cdk/lib/cdk-stack.ts
Comment on lines +163 to +166
// TODO ist das sinnvoll? -> evtl auf GET_HEAD umstellen
// außer wir schreiben direkt so in den Bucket von Cloudfront (aber sollte ja eigentlich die Lambda machen)
allowedMethods: cloudfront.AllowedMethods.ALLOW_ALL,
//allowedMethods: cloudfront.AllowedMethods.ALLOW_GET_HEAD,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glaub auch, dass ein ALLOW_GET_HEAD ausreichen müsste.

Comment thread cdk/lib/config.ts
Comment on lines +28 to +30
prod: 'TODO_PROD_ACCOUNT_ID',
staging: 'TODO_STAGING_ACCOUNT_ID',
dev: '391322831368',

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scheint ja eher unwahrscheinlich, dass wir noch verschiedene Accounts nutzen werden oder? Kann man von mir aus auch weiter supporten. Die Account-ID könnten wir aber ja schon mal eintragen für alle, oder?

Comment thread cdk/test/cdk.test.ts

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants