https://github.com/jgwest/gitops-repository-template
https://github.com/jgwest/gitops-repository-template
Last synced: about 2 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/jgwest/gitops-repository-template
- Owner: jgwest
- Created: 2021-10-07T03:15:41.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2023-02-23T21:46:03.000Z (about 2 years ago)
- Last Synced: 2025-01-29T22:30:45.509Z (4 months ago)
- Size: 20.5 KB
- Stars: 0
- Watchers: 4
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# GitOps Repository Template v2
This is an example of what the AppStudio GitOps repository might look like for a simple application. This example contains two components ('component A' and 'component B'), and two environments ('dev' and 'staging').
In particular:
- New environments should be added and removed from `components/(component name)/overlays/(environment name)`
- Each `components/(component name)` folder needs to have the environment added (presuming it is supported in that environment)
- The GitOps repository can contain multiple components (for example, the 'frontend' and 'backend' of a single application.)
- Environment-specific component configuration should be defined in `component/(component name)/overlays/(environment name)`
- For example, environment variables of the component that are set only in production, or only in development (eg different database credentials for different environments)
- Replicas/container image/ports/env vars should only be defined in the `components/(component name)/overlays/(environment name)`.
- Otherwise this repository uses the standard kustomize `base`/`overlays` pattern, where `base` contain resource definitions, and `overlays` contain patches against those resource definitions (which eliminates the need to duplicate data across multiple resources)
Differences from [template v1](https://github.com/redhat-appstudio/gitops-repository-template):
- Components as the atomic unit of deployment, rather than Application
- The `environments/` folder at the root of the repo has been removed. All environment information is per-component, and contained under `components/(component name)/overlays/(environment name)`
- Base compoment resources (`components/(component name)/base`) no longer contain default values for fields such as containerImage, replicas, env vars, ports (these values should all be provided in per-environment overlays, under `component/(component name)/overlays/(environment name)`).
## Resources
There are two types of resources defined in this repository:
- **Components**:
- A component contains one or more Kubernetes resources (Deployments/ConfigMaps/etc), representing a component of an application to deploy.
- For example, the 'frontend' and 'backend' of a single application (both would be components, here)
- Component resources may be customized (by kustomize) based on the environment they are targeting, for example, different environment variables in staging/production containing different database service credentials.
- Components are defined under `components/`
- **Environments**
- Components are deployed within environments.
- But note, unlike v1: There is no `kustomization.yaml` listing all the Components contained within in an environment (this is handled at the AppStudio API CR level)
- This previously existed in v1, under `environments/` folder, but is no longer required, since components are now the atomic unit of deployment.
- Environments do not contain Kubernetes resources of their own; all resources must be contained within a Component.
- I don't believe AppStudio ever had a requirement for environment resources, but I have made this assumption explicit, here.
- Example: A standalone ConfigMap that is part of an Environment, but not part of Component.
- Environments are defined by their customizations to components: `components/(component name)/overlays/(environment name)`
- Within the GitOps repository, the only purpose of environments is to add values to component K8s resources, such as env vars, container image, ports, added to Deployments/Services/Routes. See an example of this in this repo.
## Primary Kustomize Entrypoints
**_Note_:** this has changed from an earlier version of this repository, where the entrypoint was within the `environments/overlay/` folder
The full contents of the GitOps repository can be generated by calling `kustomize build` on the _component_ to deploy.
For example:
- `kustomize build components/componentA/overlays/dev`: Output 'componentA' resources, when targetting the 'dev' environment
- `kustomize build components/componentB/overlays/staging`: Output 'componentB' resources, when targetting the 'staging' environment
## Tree Diagram
Here is the hierarchy of resources within the repository:
```
.
├── components
│ ├── componentA
│ │ ├── base
│ │ │ ├── deployment-sample-workload.yaml
│ │ │ ├── kustomization.yaml
│ │ │ ├── route-sample-workload.yaml
│ │ │ └── service-sample-workload.yaml
│ │ └── overlays
│ │ ├── dev
│ │ │ └── kustomization.yaml
│ │ └── staging
│ │ └── kustomization.yaml
│ └── componentB
│ ├── base
│ │ ├── deployment-sample-workload.yaml
│ │ ├── kustomization.yaml
│ │ ├── route-sample-workload.yaml
│ │ └── service-sample-workload.yaml
│ └── overlays
│ ├── dev
│ │ └── kustomization.yaml
│ └── staging
│ └── kustomization.yaml
└── README.md
```
## Try it out
#### Prerequisites:
- Ensure you have `kustomize` installed, and that `kubectl` is pointing to a valid *OpenShift* cluster.
You can try it out by running the following commands:
```bash
# Dev Environment -------------------------------------------------------------
# Create the target namespace
kubectl create namespace my-namespace
# FYI: Output the K8s resources that will be applied for the environment
kustomize build components/componentA/overlays/dev
# Apply the resources (then wait a moment)
kustomize build components/componentA/overlays/dev | kubectl apply -n my-namespace -f -
# Retrieve the routes of the components
kubectl get routes -n my-namespace
# You should now be able to access the Route, and see the environments variables output by that Route.
# Notice that RESOURCE_ENVIRONMENT env var matches the environment name, 'dev'.
# Staging Environment ---------------------------------------------------------
# Create the target namespace
kubectl create namespace my-namespace
# FYI: output the K8s resources that will be applied for the environment
kustomize build components/componentB/overlays/staging
# Apply the resources (then wait a moment)
kustomize build components/componentB/overlays/staging | kubectl apply -n my-namespace -f -
# Retrieve the routes of the components
kubectl get routes -n my-namespace
# You should now be able to access the Route, and see the environments variables output by that Route.
# Notice that RESOURCE_ENVIRONMENT env var matches the environment name, 'staging'.
```