diff --git a/docs/10-platform-engineering/10.0-overview.md b/docs/10-platform-engineering/10.0-overview.md index 45ff6d8b..b507363e 100644 --- a/docs/10-platform-engineering/10.0-overview.md +++ b/docs/10-platform-engineering/10.0-overview.md @@ -71,6 +71,12 @@ Check out the following video for an overview of Platform Engineering: Platform Engineering is a natural evolution of DevOps principles, tailored to meet the demands of modern software development. By focusing on the creation of a shared, self-service platform, it addresses key challenges in complexity management, standardization, speed of delivery, and developer experience. A successful Internal Developer Platform incorporates essential components like self-service infrastructure, automated CI/CD, observability, security, and comprehensive developer resources, setting the stage for efficient and scalable software development practices. +## Knowledge Check + +
+
+
+ ## Deliverables - Explore real-world examples of companies implementing Platform Engineering principles. How have these companies benefited from adopting an Internal Developer Platform? diff --git a/docs/10-platform-engineering/10.1-backstage.md b/docs/10-platform-engineering/10.1-backstage.md index d4104384..e6501dcd 100644 --- a/docs/10-platform-engineering/10.1-backstage.md +++ b/docs/10-platform-engineering/10.1-backstage.md @@ -99,6 +99,12 @@ Currently your Backstage instance is not authenticating the user. You are an ano 2. Add GitHub Authentication to the sign-in page 3. Verify that you can login via GitHub +## Knowledge Check + +
+
+
+ ## Deliverables - By completing the above exercises, participants will gain hands-on experience setting up and navigating Spotify's Backstage. diff --git a/docs/10-platform-engineering/10.2-platforms.md b/docs/10-platform-engineering/10.2-platforms.md index a55cb6fd..b3fc0c8b 100644 --- a/docs/10-platform-engineering/10.2-platforms.md +++ b/docs/10-platform-engineering/10.2-platforms.md @@ -15,7 +15,6 @@ docs/10-platform-engineering/10.2-platforms.md: - ArgoCD - ExternalSecrets --- - # Platforms Backstage is a powerful Internal Developer Platform that excels at software discoverability and accelerates time to value and security adoption through its software templates. @@ -33,7 +32,7 @@ The architecture for this platform will be split into a library and a deploy rep that install and configure individual components of the platform, each independently versioned. The deploy repo will contain Terragrunt to orchestrate and deploy your versioned components. -![tvp architecture](./img10/tvp-arch.png ':class=img-center :alt=TVP Architecture') +![tvp architecture](./img10/tvp-arch.png ":class=img-center :alt=TVP Architecture") ### Library Repo @@ -125,12 +124,13 @@ The deploy repo structure separates infrastructure from applications, making it Before we can onboard an application we need to create our TVP. We will start by setting up our repos and building out a repeatable EKS cluster. + - Create the deploy repo: - Locally create the bootstrap infra required to have an OIDC ready role for managing infra in your AWS account. - Create GitHub Actions for PR plan and Apply of environment infrastructure. - Create the library repo: - Create GitHub Actions that will lint, format, and enforce conventional commits. Merges to main should - create versioned tags of your modules. + create versioned tags of your modules. - Create a VPC module - Create an EKS module - Using Terragrunt orchestrate and deploy your VPC and EKS module in the deploy repo @@ -140,7 +140,7 @@ repeatable EKS cluster. ## Exercise 2 -![ArgoCD Logo](https://argo-cd.readthedocs.io/en/stable/assets/logo.png ':class=img-center :alt=TVP Architecture') +![ArgoCD Logo](https://argo-cd.readthedocs.io/en/stable/assets/logo.png ":class=img-center :alt=TVP Architecture") Wonderful now you have an EKS cluster stood up with IaC. Now we are going to add ArgoCD to the cluster as our preferred method for deploying Kubernetes applications. First off what is ArgoCD? ArgoCD is a GitOps controller that manages Kubernetes resources by treating Git as the single source of truth. Unlike traditional CI/CD push-based deployments, @@ -160,6 +160,7 @@ and can manage applications across multiple clusters from a single interface. It Now that we have stood up ArgoCD we can let Argo manage our Kubernetes applications. There are many core applications that all application teams are going to want to have access. These applications generally fall to the platform teams. Some examples of these are: + - Metrics Server - OTEL Operators & Collectors - AWS Load Balancer Controller @@ -168,7 +169,7 @@ application teams are going to want to have access. These applications generally - Kyverno/OPA Gatekeeper - External Secrets Operator - Karpenter -etc + etc The list is long but the thing to note here is that these are all Kubernetes applications that are deployed ultimately via manifest files (Helm charts just result in manifest files). So given our cluster now has a Kubernetes GitOps Controller @@ -176,7 +177,9 @@ installed and configured we are going to let ArgoCD own the deployment of these - In your library repo create a new directory `applications/metrics-server` - Using what you have learned add file(s) that will source manifests from a pinned version of the [official repo for metrics-server](https://github.com/kubernetes-sigs/metrics-server) + > Verify that pushing the metrics-server application to your library repo generates a tagged version in the library repo + > - In your deploy repo create a new directory `applications/metrics-server` under your environment (ie: `prod/applications/metrics-server`) - Use Kustomize to reference your versioned application in the library repo - Next create an Argo Application manifest that will point to your deploy repo at `applications/metrics-server` @@ -184,20 +187,23 @@ installed and configured we are going to let ArgoCD own the deployment of these - Verify in the Argo UI that metrics-server was picked up, synced, and healthy. - Try changing the version of metrics server that you have pinned in your library repo and roll that change out the the cluster. -?> [ArgoCD's Credential Templates](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#credential-templates) are an easy way to authenticate to private/internal repos +?> [ArgoCD's Credential Templates](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#credential-templates) are an easy way to authenticate to private/internal repos ## Exercise 4 We have the framework for a platform now we need a way for teams to use our platform. In this exercise we will create a backstage template that injects a new Argo Application into our Deploy repo that references an external manifests repo. + - Create a simple Hello World NodeJS application and containerize it. Create workflows that semantically release, build, and publish the resulting image to a contrainer registry > Make this repo and the container registry public + > - Create a manifest repo that contains only the required k8s manifests to run your hello world application (likely just a Deployment and a Service) - Create a backstage template to onboard an 'app teams' application. Your template should do the following. - Take in the repo, version, and application name - Create a PR to your deploy repo that adds `prod/applications//kustomization.yaml` and `prod/applications//application.yaml` > Your application.yaml should point to `prod/applications/` at HEAD in your deploy repo. Your kustomization.yaml should point to - to the app teams repo at the version specified in the template. + > to the app teams repo at the version specified in the template. + > - Ensure that the person that onboarded the app is reflected in the Pull Request (PR Author, or otherwise) - Review and merge the pull request - Verify the application was successfully deployed to the cluster @@ -219,7 +225,7 @@ app dependencies. This is not the only tool that can do this and another popular 1) [Install Renovate](https://github.com/apps/renovate/new/installations) into your org 2) Create an application change that publishes a new version of your image 3) Configure renovate for the app teams manifest repo. Force Renovate to run from the developer site `https://developer.mend.io/github/` -and you should see renovate create a pull request to the app teams manifest repo updating the image version. Hold off on merging this + and you should see renovate create a pull request to the app teams manifest repo updating the image version. Hold off on merging this 4) Configure Renovate for the platform deploy repo to watch Kubernetes dependencies. 5) Merge the Renovate PR from the app manifest repo to publish a new version 6) Force a Renovate run on the platform deploy repo and you should see a PR to update the version of the app manifests used. @@ -244,3 +250,9 @@ not declarative. If you needed to rebuild the cluster there would be some manual 3) Declaratively configure ArgoCD Credential Template leveraging your secret stored in AWS Secret Manager 4) Add the secrets needed to pull from the private container registry to AWS Secret Manager 5) Configure Kubernetes to pull get the ImagePullSecret from External Secret Operator + +## Knowledge Check + +
+
+
diff --git a/src/quizzes/chapter-10/10.0/overview-quiz.js b/src/quizzes/chapter-10/10.0/overview-quiz.js new file mode 100644 index 00000000..d121890a --- /dev/null +++ b/src/quizzes/chapter-10/10.0/overview-quiz.js @@ -0,0 +1,64 @@ +const rawQuizdown = ` +--- +shuffleAnswers: true +shuffleQuestions: true +--- + +# What is an Internal Developer Platform (IDP)? + +1. [x] A self-service tool that offers application teams standardized ways to accomplish common tasks + > Correct. An IDP provides self-service tools that adhere to organizational standards and best practices. +1. [ ] A replacement for all DevOps engineers in an organization + > Incorrect. Platform Engineering complements DevOps, it doesn't replace DevOps engineers on cross-functional teams. +1. [ ] A cloud provider's managed Kubernetes service + > Incorrect. An IDP is an internal tool, not a cloud service. +1. [ ] A monitoring and alerting system + > Incorrect. While an IDP may integrate with monitoring, that's not its primary purpose. + +# What are "golden paths" (or paved pathways) in Platform Engineering? + +1. [x] Templated, well-designed solutions for common tasks that follow organizational best practices + > Correct. Golden paths provide standardized starting points that integrate nicely into the organization's platform. +1. [ ] The fastest network routes between data centers + > Incorrect. Golden paths refer to development workflows, not networking. +1. [ ] Mandatory processes that all teams must follow without exception + > Incorrect. Golden paths are recommended paths, but teams can still tread new ground when needed. +1. [ ] A certification program for platform engineers + > Incorrect. Golden paths are about templated solutions, not certifications. + +# What problem does Platform Engineering primarily solve? + +1. [x] Reducing cognitive load and complexity sprawl across cross-functional teams + > Correct. Platform Engineering addresses the complexity that comes from each team solving the same problems differently. +1. [ ] Eliminating the need for cloud infrastructure + > Incorrect. Platform Engineering still relies on cloud infrastructure. +1. [ ] Replacing continuous integration systems + > Incorrect. Platform Engineering typically provides standardized CI/CD, not replaces it. +1. [ ] Removing the need for application testing + > Incorrect. Testing is still essential regardless of platform engineering. + +# Why should a platform be treated as a product? + +1. [x] To ensure it's designed with users (developers) in mind and evolves with their needs + > Correct. Treating the platform as a product ensures internal adoption by making it a joy to use. +1. [ ] So it can be sold to external customers + > Incorrect. An IDP is for internal users, not external sales. +1. [ ] To maximize the number of features regardless of usability + > Incorrect. Product thinking prioritizes user needs over feature count. +1. [ ] To ensure only the platform team can make changes + > Incorrect. Good platforms allow teams to collaboratively improve them. + +# What is the relationship between a Platform team and application teams? + +1. [x] Platform team is like "admin" providing tools, application teams are "users" who use and extend them + > Correct. Platform teams ensure well-configured tools while application teams use them and evolve them as needed. +1. [ ] Platform team does all the work, application teams just write code + > Incorrect. Application teams still own their CI/CD, infrastructure usage, and application evolution. +1. [ ] They are completely separate with no interaction + > Incorrect. Platform teams build for application teams and should collaborate closely. +1. [ ] Application teams report to the platform team + > Incorrect. They are peer teams with different responsibilities. + +`; + +export { rawQuizdown } diff --git a/src/quizzes/chapter-10/10.1/backstage-quiz.js b/src/quizzes/chapter-10/10.1/backstage-quiz.js new file mode 100644 index 00000000..243eaf45 --- /dev/null +++ b/src/quizzes/chapter-10/10.1/backstage-quiz.js @@ -0,0 +1,86 @@ +const rawQuizdown = ` +--- +shuffleAnswers: true +shuffleQuestions: true +--- + +# What are the three main parts of a Backstage application? + +1. [x] Core, App, and Plugins + > Correct. Core is the base functionality, App is your customized instance, and Plugins extend functionality. +1. [ ] Frontend, Backend, and Database + > Incorrect. While Backstage has these components, the three parts refer to Core, App, and Plugins. +1. [ ] API, CLI, and GUI + > Incorrect. These are types of interfaces, not Backstage's architecture. +1. [ ] Dev, Stage, and Prod + > Incorrect. These are environments, not Backstage components. + +# What is the Software Catalog in Backstage? + +1. [x] A comprehensive inventory system that tracks ownership, metadata, and relationships of all software components + > Correct. The Software Catalog facilitates discovery and management of services, libraries, and more. +1. [ ] A marketplace for purchasing third-party software + > Incorrect. The catalog tracks internal software, not external purchases. +1. [ ] A list of approved programming languages + > Incorrect. The catalog tracks software components, not language policies. +1. [ ] A version control system + > Incorrect. Backstage integrates with version control but the catalog is for tracking components. + +# What do Software Templates provide in Backstage? + +1. [x] Standardized scaffolding for creating new projects that follow organizational best practices + > Correct. Templates ensure new software adheres to standards and streamline the development process. +1. [ ] Pre-written code that replaces the need for developers + > Incorrect. Templates provide starting points, not complete applications. +1. [ ] Email templates for team communication + > Incorrect. Software Templates are for creating new projects, not communication. +1. [ ] Database schema templates + > Incorrect. While templates could include schemas, they're primarily for scaffolding entire projects. + +# What is TechDocs in Backstage? + +1. [x] An integrated knowledge hub where teams create and access technical documentation alongside their code + > Correct. TechDocs enables seamless collaboration and information sharing across the organization. +1. [ ] A ticket tracking system + > Incorrect. TechDocs is for documentation, not ticket tracking. +1. [ ] A code review tool + > Incorrect. TechDocs handles documentation, not code reviews. +1. [ ] An API testing framework + > Incorrect. TechDocs is for documentation, not testing. + +# How are Plugins used in Backstage? + +1. [x] As modular extensions that enhance functionality and integrate additional services like CI/CD and monitoring + > Correct. Plugins allow teams to customize Backstage for their specific workflow needs. +1. [ ] They are required dependencies that cannot be removed + > Incorrect. Plugins are optional extensions that can be added or removed. +1. [ ] They replace the core Backstage functionality + > Incorrect. Plugins extend the core, they don't replace it. +1. [ ] They are only available from Spotify + > Incorrect. Plugins can be community-sourced or internally developed. + +# Who typically maintains a Backstage App instance? + +1. [x] The Platform team + > Correct. The App is the customized instance that is generally maintained by a Platform team. +1. [ ] Spotify's open source team + > Incorrect. Spotify maintains the Core, but each organization maintains their own App. +1. [ ] Individual developers + > Incorrect. While developers use Backstage, the Platform team typically maintains the instance. +1. [ ] Cloud providers + > Incorrect. Backstage is self-hosted, not a cloud provider service. + +# What programming language is Backstage written in? + +1. [x] TypeScript + > Correct. Backstage is a monorepo React application written in TypeScript. +1. [ ] Python + > Incorrect. Backstage uses TypeScript. +1. [ ] Java + > Incorrect. Backstage uses TypeScript. +1. [ ] Go + > Incorrect. Backstage uses TypeScript. + +`; + +export { rawQuizdown } diff --git a/src/quizzes/chapter-10/10.2/platforms-quiz.js b/src/quizzes/chapter-10/10.2/platforms-quiz.js new file mode 100644 index 00000000..44a6a13f --- /dev/null +++ b/src/quizzes/chapter-10/10.2/platforms-quiz.js @@ -0,0 +1,75 @@ +const rawQuizdown = ` +--- +shuffleAnswers: true +shuffleQuestions: true +--- + +# What is the primary benefit of separating infrastructure into a library repo and a deploy repo? + +1. [x] Components can be developed and versioned independently without affecting production + > Correct. This separation allows platform teams to develop and test components separately, with each component independently versioned. +1. [ ] It reduces the total number of Git repositories needed + > Incorrect. This approach actually uses more repositories, but provides better separation of concerns. +1. [ ] It eliminates the need for CI/CD pipelines + > Incorrect. Both repos still need CI/CD pipelines for linting, testing, and deployment. +1. [ ] It allows developers to bypass code review + > Incorrect. Code review is still important in both repositories. + +# What is the Rendered Manifests Pattern? + +1. [x] Pre-rendering Helm/Kustomize templates in CI and committing plain YAML to Git + > Correct. This makes PRs easier to review since you see the actual manifests, not just template changes. +1. [ ] Having ArgoCD render templates at deploy time + > Incorrect. This is the default behavior, not the Rendered Manifests Pattern. +1. [ ] Storing manifests as binary files + > Incorrect. Manifests are always stored as text (YAML). +1. [ ] Generating manifests manually without any templating + > Incorrect. The pattern still uses templating tools, but renders them before committing. + +# What does IRSA (IAM Roles for Service Accounts) enable? + +1. [x] Pods can authenticate to AWS services using temporary credentials without storing long-lived secrets + > Correct. IRSA links Kubernetes service accounts to IAM roles via an OIDC provider. +1. [ ] Users can log into the AWS console from kubectl + > Incorrect. IRSA is for pod-level authentication, not user authentication. +1. [ ] S3 buckets can be mounted directly as volumes + > Incorrect. While there are solutions for this, it's not what IRSA provides. +1. [ ] EKS clusters can span multiple AWS regions + > Incorrect. IRSA is about authentication, not cluster topology. + +# What is the App of Apps pattern in ArgoCD? + +1. [x] A hierarchical structure where one root Application manages other Applications + > Correct. This pattern helps organize and bootstrap multiple applications from a single entry point. +1. [ ] Running multiple ArgoCD instances in the same cluster + > Incorrect. The pattern is about organizing Applications, not ArgoCD instances. +1. [ ] Deploying the same application to multiple clusters + > Incorrect. That's multi-cluster deployment, not App of Apps. +1. [ ] Using multiple Git repositories for one application + > Incorrect. The pattern is about Application hierarchy, not repository structure. + +# Why is Terragrunt used in the deploy repo? + +1. [x] To reduce configuration complexity and improve code reuse when orchestrating Terraform modules + > Correct. Terragrunt is a lightweight wrapper that helps manage Terraform deployments with less duplication. +1. [ ] To replace Terraform entirely + > Incorrect. Terragrunt wraps Terraform, it doesn't replace it. +1. [ ] To deploy Kubernetes manifests directly + > Incorrect. Terragrunt is for Terraform orchestration, not direct Kubernetes deployment. +1. [ ] To provide a GUI for infrastructure management + > Incorrect. Terragrunt is a CLI tool, not a GUI. + +# What problem does External Secrets Operator solve? + +1. [x] It allows secrets to be managed declaratively by syncing from external secret stores like AWS Secrets Manager + > Correct. This eliminates manual secret configuration and makes the cluster fully reproducible. +1. [ ] It encrypts all network traffic in the cluster + > Incorrect. That's handled by service mesh or network policies, not External Secrets. +1. [ ] It provides a UI for viewing secrets + > Incorrect. External Secrets syncs secrets, it doesn't provide a viewing UI. +1. [ ] It automatically rotates SSH keys + > Incorrect. While it can sync rotated secrets, it doesn't perform the rotation itself. + +`; + +export { rawQuizdown }