feat: Add pattern for Amazon VPC Lattice

.github/workflows/dependency-review.yml

@@ -24,4 +24,4 @@ jobs:
       - name: 'Checkout Repository'
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.5.4
       - name: 'Dependency Review'
-        uses: actions/dependency-review-action@01bc87099ba56df1e897b6874784491ea6309bc4 # v3.1.4
+        uses: actions/dependency-review-action@c74b580d73376b7750d3d2a50bfb8adc2c937507 # v3.1.5

.github/workflows/scorecards.yml

@@ -63,14 +63,14 @@ jobs:
       # Upload the results as artifacts (optional). Commenting out will disable uploads of run results in SARIF
       # format to the repository Actions tab.
       - name: "Upload artifact"
-        uses: actions/upload-artifact@c7d193f32edcb7bfad88892161225aeda64e9392 # v4.0.0
+        uses: actions/upload-artifact@1eb3cb2b3e0f29609092a73eb033bb759a334595 # v4.1.0
         with:
           name: SARIF file
           path: results.sarif
           retention-days: 5
 
       # Upload the results to GitHub's code scanning dashboard.
       - name: "Upload to code-scanning"
-        uses: github/codeql-action/upload-sarif@b374143c1149a9115d881581d29b8390bbcbb59c # v3.22.11
+        uses: github/codeql-action/upload-sarif@e5f05b81d5b6ff8cfa111c80c22c5fd02a384118 # v3.23.0
         with:
           sarif_file: results.sarif

docs/patterns/vpc-lattice.md

@@ -0,0 +1,7 @@
+---
+title: Amazon VPC Lattice
+---
+
+{%
+   include-markdown "../../patterns/vpc-lattice/README.md"
+%}

patterns/blue-green-upgrade/README.md

@@ -36,7 +36,7 @@ We are leveraging [the existing EKS Blueprints Workloads GitHub repository sampl
 See the Architecture of what we are building
 
 <p align="center">
-  <img src="static/archi-blue-green.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/archi-blue-green.png"/>
 </p>
 
 Our sample is composed of four main directory:
@@ -55,7 +55,7 @@ We are leveraging the [gitops-bridge-argocd-bootstrap](https://github.com/gitops
 
 The gitops-bridge will create a secret in the EKS cluster containing all metadatas that will be dynamically used by ArgoCD ApplicationSets at deployment time, so that we can adapt their configuration to our EKS cluster context.
 
-<img src="static/gitops-bridge.excalidraw.png" width=100%>
+<img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/gitops-bridge.excalidraw.png" width=100%>
 
 Our objective here is to show you how Application teams and Platform teams can configure their infrastructure and workloads so that application teams are able to deploy autonomously their workloads to the EKS clusters thanks to ArgoCD, and platform team can keep the control of migrating production workloads from one cluster to another without having to synchronized operations with applications teams, or asking them to build a complicated CD pipeline.
 
@@ -71,7 +71,7 @@ Our objective here is to show you how Application teams and Platform teams can c
   - Before moving to the next step, you will need to register a parent domain with AWS Route 53 (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-register.html) in case you don’t have one created yet.
 - Accessing GitOps git repositories with SSH access requiring an SSH key for authentication. In this example our workloads repositories are stored in GitHub, you can see in GitHub documentation on how to [connect with SSH](https://docs.github.com/en/authentication/connecting-to-github-with-ssh).
   - Your GitHub private ssh key value is supposed to be stored in plain text in AWS Secret Manager in a secret named `github-blueprint-ssh-key`, but you can change it using the terraform variable `workload_repo_secret` in [terraform.tfvars.example](terraform.tfvars.example).
-  - <img src="static/github-ssh-secret.png" width=50%>
+  - <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/github-ssh-secret.png" width=50%>
 
 ## Quick Start
 
@@ -140,7 +140,7 @@ Our clusters are configured with existing ArgoCD Github repository that is synch
 - [Workloads repository](https://github.com/aws-samples/eks-blueprints-workloads)
 
 <p align="center">
-  <img src="static/eks-argo.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/eks-argo.png"/>
 </p>
 
 We are going to look after one of the application deployed from the workload repository as example to demonstrate our migration automation: the `Burnham` workload in the team-burnham namespace.
@@ -266,11 +266,11 @@ Now that we have setup our 2 clusters, deployed with ArgoCD and that the weighed
 1. At first, 100% of burnham traffic is set to the **eks-blue** cluster, this is controlled from the `eks-blue/main.tf` & `eks-green/main.tf` files with the parameter `route53_weight = "100"`. The same parameter is set to 0 in cluster eks-green.
 
 <p align="center">
-  <img src="static/burnham-records.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/burnham-records.png"/>
 </p>
   Which correspond to :
 <p align="center">
-  <img src="static/archi-blue.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/archi-blue.png"/>
 </p>
 
 All requests to our endpoint should response with `eks-blueprint-blue` we can test it with the following command:
@@ -289,11 +289,11 @@ eks-blueprint-blue
 2. Let's change traffic to 50% eks-blue and 50% eks-green by activating also value 100 in **eks-green** locals.tf (`route53_weight = "100"`) and let's `terraform apply` to let terraform update the configuration
 
 <p align="center">
-  <img src="static/burnham-records2.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/burnham-records2.png"/>
 </p>
   Which correspond to :
 <p align="center">
-  <img src="static/archi-blue-green.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/archi-blue-green.png"/>
 </p>
 
 All records have weight of 100, so we will have 50% requests on each clusters.
@@ -325,11 +325,11 @@ The default TTL is for 60 seconds, and you have 50% chance to have blue or green
 3. Now that we see that our green cluster is taking requests correctly, we can update the eks-blue cluster configuration to have the weight to 0 and apply again. after a few moment, your route53 records should look like the below screenshot, and all requests should now reach eks-green cluster.
 
 <p align="center">
-  <img src="static/burnham-records3.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/burnham-records3.png"/>
 </p>
   Which correspond to :
 <p align="center">
-  <img src="static/archi-green.png"/>
+  <img src="https://raw.githubusercontent.com/aws-ia/terraform-aws-eks-blueprints/main/patterns/blue-green-upgrade/static/archi-green.png"/>
 </p>
 
 At this step, once all DNS TTL will be up to date, all the traffic will be coming on the eks-green cluster. You can either, delete the eks-blue cluster, or decide to make upgrades on the blue cluster and send back traffic on eks-blue afterward, or simply keep it as a possibility for rollback if needed.

patterns/vpc-lattice/01_client-server-communication/README.md

@@ -0,0 +1,39 @@
+# Amazon VPC Lattice - Simple Client to Server Communication
+
+This pattern demonstrates how to expose an EKS cluster hosted application to an internal consumer through Amazon VPC Lattice.
+
+## Scenario
+
+With this soluton we showcase how to configure Amazon VPC Lattice using the AWS Gateway API Controller in order to manage Amazon VPC Lattice resources through native K8S Gateway API objects. This pattern deploys two distinct VPCs with a client application running in one of them and a server application in the other. The server application is deployed inside an EKS cluster and made exposed to the client application through Amazon VPC Lattice which establishes connectivity between the two applications. Further we demonstrate how to configure a custom domain name for the exposed service using Amazon Route53 and the external-dns project.
+
+![diagram](assets/diagram.png)
+
+
+## Deploy
+
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
+
+## Validate
+
+In order to test the connectivty between the client and server, please follow the steps outlined below:
+
+1. Login to the management console of your AWS account and navigate to the EC2 service
+2. Select your the EC2 Instance with the name **client**, click **Connect**, choose **Session Manager** and click **Connect**
+3. Within the console test the connecvity to the server application by entering the following command:
+
+    ```sh
+    $ curl -i http://server.example.com
+    HTTP/1.1 200 OK
+    date: Thu, 14 Dec 2023 08:29:39 GMT
+    content-length: 54
+    content-type: text/plain; charset=utf-8
+
+    Requesting to Pod(server-6f487b9bcd-5qm4v): server pod
+
+    ```
+
+## Destroy
+
+{%
+   include-markdown "../../../docs/_partials/destroy.md"
+%}

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/.helmignore

@@ -0,0 +1,23 @@
+# Patterns to ignore when building packages.
+# This supports shell glob matching, relative path matching, and
+# negation (prefixed with !). Only one pattern per line.
+.DS_Store
+# Common VCS dirs
+.git/
+.gitignore
+.bzr/
+.bzrignore
+.hg/
+.hgignore
+.svn/
+# Common backup files
+*.swp
+*.bak
+*.tmp
+*.orig
+*~
+# Various IDEs
+.project
+.idea/
+*.tmproj
+.vscode/

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/Chart.yaml

@@ -0,0 +1,5 @@
+apiVersion: v2
+name: demo-application
+description: A Helm chart to deploy the demo-application
+type: application
+version: 1.0.0

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/templates/deployment.yaml

@@ -0,0 +1,22 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: server
+  labels:
+    app: server
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: server
+  template:
+    metadata:
+      labels:
+        app: server
+    spec:
+      containers:
+      - name: server
+        image: public.ecr.aws/x2j8p8w7/http-server:latest
+        env:
+        - name: PodName
+          value: "server pod"

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/templates/gateway-class.yaml

@@ -0,0 +1,6 @@
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: GatewayClass
+metadata:
+  name: amazon-vpc-lattice
+spec:
+  controllerName: application-networking.k8s.aws/gateway-api-controller

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/templates/gateway.yaml

@@ -0,0 +1,11 @@
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: Gateway
+metadata:
+  name: my-services
+  namespace: apps
+spec:
+  gatewayClassName: amazon-vpc-lattice
+  listeners:
+    - name: http
+      protocol: HTTP
+      port: 80

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/templates/httproute.yaml

@@ -0,0 +1,20 @@
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: server
+  namespace: apps
+spec:
+  hostnames:
+    - server.example.com
+  parentRefs:
+    - name: my-services
+      sectionName: http
+  rules:
+    - backendRefs:
+        - name: server
+          kind: Service
+          port: 8090
+      matches:
+        - path:
+            type: PathPrefix
+            value: /

patterns/vpc-lattice/01_client-server-communication/charts/demo-application/templates/service.yaml

@@ -0,0 +1,11 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: server
+spec:
+  selector:
+    app: server
+  ports:
+    - protocol: TCP
+      port: 8090
+      targetPort: 8090