Serverless Preview Environments @ Boston DevOps
0 likes143 views
This document discusses how to create serverless preview environments for testing every commit in a continuous integration/continuous delivery (CI/CD) workflow. Some key points: 1. Preview environments are short-lived environments that allow validating deployments without impacting production. This provides rapid developer feedback. 2. Serverless architectures are well-suited for preview environments since deployments are fast, the environments automatically scale down to zero cost when not in use, and only pay for resources used. 3. Techniques like using a wildcard domain and mapping the app and version as subpaths allow creating unique previews without separate networking for each. Storage services like S3 can host the preview artifacts with near-instant
![nginx URL rewriter config
nginx.conf
server_name
"~^(?<app_hash>[a-f0-9]{7})-<?<app_name([^.]+)>.preview.acme.com$"
location / {
rewrite ^/$ /$app_name/$app_hash/index.html last;
}
location /${app_name} {
proxy_pass https://storage.googleapis.com/my-previews;
}](https://image.slidesharecdn.com/serverless-preview-environments-boston-devops-200227161829/85/Serverless-Preview-Environments-Boston-DevOps-25-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Serverless Preview Environments @ Boston DevOps (20)
Ad
More from Joseph Lust (7)
Ad
Recently uploaded (20)
Serverless Preview Environments @ Boston DevOps
- 1. Serverless Preview Environments how to test every commit Joseph Lust mabl engineer @lustcoder Boston DevOps Meetup - 26 Feb 2020
- 2. About Me: Joe Lust Engineer ■ Building the web for two decades ■ Cloud native since 2011 ■ Currently building mabl testing cloud on GCP ■ Co-organizer GDG Cloud Boston Meetup @lustcoder
- 4. TL;DR 4 -
- 5. Why? Because developers are lazy 5 courtesy xkcd END 2 END TESTING” TESTING!
- 6. Why? Because developers are lazy really busy 6 courtesy xkcd END 2 END TESTING” TESTING!
- 7. Continuous Integration - Typical (ideal) Setup 7 Merge / Push Unit Tests DeployIntegration Env Integration Tests Production Env Merge / Tag Deploy Smoke Tests Alive! Fire!!! Unmerge!
- 8. Continuous Integration - Typical Setup (real life) 8 Merge / Push Unit Tests DeployIntegration Env Integration Tests Production Env Merge / Tag Deploy Smoke Tests Alive! Fire!!! Unmerge! real life is less than ideal and often manual
- 9. What is a preview environment? ■ On demand, short lived environment ■ Used to validate deployments / changes ■ No / minimal impacted if it’s broken ▲ Discard when done ▲ No environment huggers ■ AKA ▲ Ephemeral Environment ▲ Temporary Environment 9
- 10. Why do you need preview environments? ■ Rapid developer feedback ▲ Push and forget ■ Visually intractable PRs ▲ Review pixels, not CSS files ■ Confidence on merging to master ▲ Break feature branches, not master 10 * for React Single Space Applications (SPAs)
- 11. Why do you need preview environments? (demo) ■ Improve PRs ▲ Don’t tell them your change works, prove that it works ▲ Demo PR ▲ Reference app 11
- 12. Why Not? ■ Deployments are slow ■ So many domains/networks! ■ So many servers! ■ So many environments! ■ So much $$$$ 12
- 13. Serverless to the rescue ■ Deployments are slow ■ So many domains/networks! ■ So many servers! ■ So many environments! ■ So much $$$$ 13 Wow, such serverless
- 14. Why serverless just works ■ No Provisioning ■ Transparent Scaling ■ Pay only for Use ▲ Scales to zero 14
- 15. Why serverless just works ■ No Provisioning ■ Transparent Scaling ■ Pay only for Use 15
- 16. Solving the domains/networking problem ■ You don’t need separate domain/networking per app/version ▲ Even if your SPA expects to be at the root path ■ Use a wildcard domain! ▲ Only one DNS entry ever needed! ▲ One IP address for everything! ■ Map your app and version into the domain 16 a32df28-accounting.preview.acme.com ■ a23df28 ← Git Commit (version) ■ Accounting ← App Name
- 17. Solving the domains/networking problem (variant) ■ You don’t need separate domain/networking per app/version ▲ Even if your SPA expects to be at the root path ■ Use a single domain! ▲ Only one DNS entry ever needed! ▲ One IP address for everything! ■ Map your app and version into the path ▲ makes all your paths longer 17 preview.acme.com/accounting/a32df28 ■ a23df28 ← Git Commit (version) ■ Accounting ← App Name
- 18. Solving the domains/path considerations ■ Does your app assume it’s at a root path “/” ▲ Do your routers / path parsers make path layout assumptions? ■ How will your authentication provider handle many domains/paths ■ How will monitoring tools differentiate environments? 18 preview.acme.com/accounting/a32df28 a32df28-accounting.preview.acme.com
- 19. Solving the deployment problem ■ Forget about servers ■ Forget about containers ▲ They’re huge! ■ Drop your SPA artifacts in a bucket ▲ e.g. Google Cloud Storage ▲ or AWS S3 ▲ or Azure Blob Storage 19
- 20. gsutil -m cp -r -Z -a public-read . gs://my-previews/${APP_NAME}/${APP_HASH}/ “deploy” in 5 seconds - GCS cli
- 21. aws s3 sync --acl public-read . s3://my-previews/${APP_NAME}/${APP_HASH}/ “deploy” in 5 seconds - S3 cli
- 22. Handling fancy routing ■ Why might you need a server? ▲ mapping wildcard domains to a single bucket ■ SPAs only need basic URL rewriting ▲ / → /index.html ▲ /foo → /index.html ■ Use a trivial nginx server to rewrite the URLs for ALL apps ■ Run your container on a serverless provider ▲ e.g. Cloud Run or Google Compute Engine ▲ Don’t need Kubernetes 22
- 23. Handling fancy routing (variant) ■ Use a Node.js server to do redirecting ▲ host in FaaS solution ▲ Scales to $0 when not called ■ Use a serverless container solution ▲ GCP Cloud Run ▲ KNative* 23
- 24. nginx URL rewriter Dockerfile FROM nginx COPY html /usr/share/nginx/html COPY nginx/default.conf /etc/nginx/conf.d/default.conf COPY nginx/nginx.conf /etc/nginx/nginx.conf
- 25. nginx URL rewriter config nginx.conf server_name "~^(?<app_hash>[a-f0-9]{7})-<?<app_name([^.]+)>.preview.acme.com$" location / { rewrite ^/$ /$app_name/$app_hash/index.html last; } location /${app_name} { proxy_pass https://storage.googleapis.com/my-previews; }
- 26. Solving the cost problem ■ Serving costs → zero when not used* ■ Network costs → low already, test from same region for zero cost ■ Storage costs → use a bucket lifecycle rule to delete (e.g. 30 days) ■ Real life example for a mabl app ▲ 203 environments deployed ▲ 5¢ monthly cost* 26 *Add in micro instance for nginx routing for $14/mo - 1 instance for all preview environments
- 27. Just add eye balls 👀 ■ GitHub webhook to trigger on each build completion ▲ Everyone can see your preview environment! ▲ You can point your tests @ the preview environment ■ Just use a serverless Cloud Function webhook to send comments 2727
- 28. Just add eye balls 👀 testing automation ■ GitHub webhook to trigger as a build step ■ Point your testing provider/tool of choice @ your preview URL ■ Fail the build if it doesn’t pass ▲ Automatic per commit feedback to developer 2828 e.g. test feedback Checks inserted into Pull Requests by mabl bot
- 29. Summary: from the top 1. CI/CD builds the commit 2. Push artifact to bucket 3. Use app/commit centric URL ▲ Tell everyone e.g. email, Slack, Pull Request comment ▲ Fire E2E UI Tests! 4. Fail the build on failure 👍👎 e.g. https://741004b.preview-dev.mabl.com 2929
- 30. Questions?
- 31. Create a free account at mabl.com