From eca97decbcd8312a4d87545e51294ea1b5965201 Mon Sep 17 00:00:00 2001 From: Colin Jamison Date: Mon, 5 Jan 2026 11:09:08 -0800 Subject: [PATCH 1/2] feat: some tips based on New Goblins experience with the platform. --- docs/10-platform-engineering/10.2-platforms.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/10-platform-engineering/10.2-platforms.md b/docs/10-platform-engineering/10.2-platforms.md index a55cb6fd..ebf6d660 100644 --- a/docs/10-platform-engineering/10.2-platforms.md +++ b/docs/10-platform-engineering/10.2-platforms.md @@ -127,13 +127,16 @@ Before we can onboard an application we need to create our TVP. We will start by 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. + + > This should also create and configure your remote state. + - 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 a VPC module - Create an EKS module - Using Terragrunt orchestrate and deploy your VPC and EKS module in the deploy repo + - Write a workflow for the deploy repo that will execute your terragrunt plan and apply. - Verify that everyone can configure their kubeconfig and authenticate to the EKS module ?> Make both the deploy and the library repo private. This is just out of an abundance of caution as you will have workflows that will likely have very elevated permissions. @@ -142,7 +145,7 @@ repeatable EKS cluster. ![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. +Wonderful! Now you have an EKS cluster stood up with IaC. Next, 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, ArgoCD uses a pull-based model where it runs inside your cluster and continuously monitors your Git repositories for changes. When it detects drift between the desired state in Git and the actual state in the cluster, it automatically reconciles the differences. This approach offers several key advantages: enhanced security since no external @@ -156,6 +159,8 @@ and can manage applications across multiple clusters from a single interface. It ?> Default admin password is stored as a Kubernetes secret on the cluster +?> Something to consider: is deploying k8s applications via terraform (ArgoCD or other) a good long term solution? Is it following proper GitOps principles? To fix this, once your platform is more developed consider trying to get ArgoCD to manage itself after it's initial install. + ## Exercise 3 Now that we have stood up ArgoCD we can let Argo manage our Kubernetes applications. There are many core applications that all @@ -204,8 +209,6 @@ injects a new Argo Application into our Deploy repo that references an external ?> You will need to add some scaffolder plugins to accomplish this software template. [Roadie publishes some good scaffolder plugins](https://roadie.io/docs/scaffolder/scaffolder-actions-directory/#roadiehqutilsfswrite) -#### UNCHARTED TERRITORY - ## Exercise 5 Congratulations you have a very minimal yet powerful platform now. You have a centrally managed Kubernetes cluster that can be developed From 77cab3b6ed010aae117793e88ff89cb584862abf Mon Sep 17 00:00:00 2001 From: Colin Jamison Date: Mon, 5 Jan 2026 15:56:21 -0800 Subject: [PATCH 2/2] fix: move the argocd question also a drive-by grammar fix --- docs/10-platform-engineering/10.2-platforms.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/10-platform-engineering/10.2-platforms.md b/docs/10-platform-engineering/10.2-platforms.md index ebf6d660..6be5bf43 100644 --- a/docs/10-platform-engineering/10.2-platforms.md +++ b/docs/10-platform-engineering/10.2-platforms.md @@ -159,8 +159,6 @@ and can manage applications across multiple clusters from a single interface. It ?> Default admin password is stored as a Kubernetes secret on the cluster -?> Something to consider: is deploying k8s applications via terraform (ArgoCD or other) a good long term solution? Is it following proper GitOps principles? To fix this, once your platform is more developed consider trying to get ArgoCD to manage itself after it's initial install. - ## Exercise 3 Now that we have stood up ArgoCD we can let Argo manage our Kubernetes applications. There are many core applications that all @@ -189,6 +187,9 @@ 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. +?> Something to consider: is deploying ArgoCD via terraform a good long term solution? Is it following proper GitOps principles? + To fix this, once your platform is more developed consider trying to get ArgoCD to manage itself after it's initial install. + ?> [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 @@ -202,7 +203,7 @@ injects a new Argo Application into our Deploy repo that references an external - 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. + 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