diff --git a/README.md b/README.md index 27fbc0c..0bc3bfc 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,22 @@ # Riley Swish Challenge - DevSecOps Style Automated Respository +## Index + +- [Objective](#objective) +- [Technical Requirements](#technical-requirements) +- [Docker Overview](#docker-overview) +- [User Story / Implementation Notes](#user-story--implementation-notes) + - [Why am I using ubuntu22.04 and not a multi-stage build?](#why-am-i-using-ubuntu2204-and-not-a-multi-stage-build) +- [Why did you leave our GPU requirement out?](#why-did-you-leave-our-gpu-requirement-out) +- [Minikube setup](#minikube-setup) + - [HPA](#hpa) + - [How do we scale resources based on events rather than resources?](#how-do-we-scale-resources-based-on-events-rather-than-resources) + - [How do we scale nodes though?!](#how-do-we-scale-nodes-though) + - [Observability/Logging](#observabilitylogging) + - [Bringing data to Memory?](#bringing-data-to-memory) +- [Room for improvement](#room-for-improvement) +- [Actions and How to Use This Repo](#actions-and-how-to-use-this-repo) +- [Trivy + Dependabot](#trivy--dependabot) ## Objective The objective of this repo is to create an automated DevSecOps styled repo for use in k8s. This should contain automated code reporting and fixes, and the ability to build docker images in a workflow pipeline via Github Actions @@ -86,7 +103,7 @@ python-swish-r-hpa Deployment/python-swish-r-deploy cpu: 2%/50% 1 HPA is for scaling based on _pod_ metrics, and is provided by metrics-server. -### How do we scale resoources based on events rather than resources? +### How do we scale resources based on events rather than resources? - I mostly go for KEDA in this situation. Remember, HPA is for scaling based on your pods metrics reported usage and only scales replicasets(this is a k8s managed resource from our Deployments defined replica count). KEDA scales based on external events and works really well with HPA from my experience. @@ -110,3 +127,50 @@ the actual answer to this. ## Room for improvement - Lots probably! For respect of everyones time(yours and mine both), I wanted to keep this mostly simple. + + +## Actions and How to Use This Repo +There is a total of 3 usable actions in this workflow. + + + +### Ephemeral Docker Build and Push + Generate K8s artifacts +- `dev_dispatch.yml` - This is a manual dispatch workflow that builds base ubuntu/debian images with python2,python3,R installed, per our Technical Requirements. This builds with no arguments, and you can click Run Workflow if you do not need to change the defaults. It looks like the below - + + +Image + +This also produces the k8s manifests you rendered in the pipeline within the outputted build artifact - +Image + +This outputs the following rendered with your values: +deploy.yaml, hpa.yaml, service.yaml + + +You definitely could output the k8s manifests in the summary too, but it just looks messy. + + +### Build and Push to Dockerhub +- `dockerhub.yml` - This actions builds and pushes to dockerhub on every push to the main branch. +You may want to make this a manual trigger depending on the use case, or where you are placing the governance +in the git repo. I made this automatically push to hub for automation demo reasons. + + +### Trivy + Dependabot +- `trivy.yml` - This scans every new PR for CVE's on the image, and opens a dependabot PR if any are found related to +the image's open source packages, github actions, and Docker bases. + +Image + +There is no code in this repo, so there is no need for code scanning enabled. In a more real prod setup, we would obviously want to enable scanning on the code. + +Going to *Insights > Dependency* Graph will show you not only the Dependency Graph, but also generate an SBOM if you need it. + + +Dependabot config is pretty basic, as explained above for what it scans. +It opens PRs based on recommended fixes, and you can certainly set them to auto-merge but I prefer to review them. + +Image + + +In theory, as long as we stay vigilant and actually use dependanbot PRs to remedy the CVEs it finds and opens, we are in a decent spot for automated security.