For an on-paved road service, this is the only file in their deployment repo:
apiVersion: mycompany.com/v1alpha1
kind: WebService
metadata:
name: my-service
spec:
version: 13 # helm chart version
# everything here goes into values.yaml
values: # This is NOT an untyped object. The fields are defined and enforced with a JSON schema.
# This is all stuff I pulled from the onboarding script. Maybe we need it, maybe we don't.
artifactName:
artifactEndpoint:
registry:
assetId:
assetAlias:
l1:
l2:
mesh:
port:
sidecarPort:
policyId:
excludeInboundPorts:
excludeOutboundIpRanges:
kubernetesServiceName: # Default is {baseArtifactId}-desired-service
environmentOverrides:
- name: e2e
version: 14
values:
# All the fields from the top level spec.values, except environmentOverrides, can be overridden here.
# The following additional fields are only available as environment overrides.
# This stuff ends up in values-e2e.yaml
ingressEndpoint:
cluster:
namespace:
region:
iksType:
offPavedRoadKustomization:
- reason: "Can't do the Mesh thing I wanted to do."
patches:
# You get the entire kustomization spec, minus `helmCharts`.
- patch:
- name: prd
---
apiVersion: mycompany.com/v1alpha1
kind: CronJob
If you run a CLI with the Service yaml as an input, we prepare the following files…
$ service-render --help
Commands:
prepare - does all the steps that happen before running `kustomize build`
build {env} - renders manifests for the given env
build {env} --exclude-off-paved-road-patches - renders everything, but leaves off the paved road patches
build {env} --diff-off-paved-road-patches - renders with patches and then with patches, prints the diff
service-render prepare -i service.yaml
You get a directory tree like this:
service.yaml
e2e/
kustomization.yaml
values.yaml
values-e2e.yaml
prd/
kustomization.yaml
values.yaml
values-prd.yaml
/e2e/kustomization.yaml:
# we write a kustomization.yaml like this:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: my-service
chart: service
version: 14 # got overridden for this environment
releaseName: my-service
values:
- values.yaml
- values-e2e.yaml
/prd/kustomization.yaml:
# we write a kustomization.yaml like this:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
- name: my-service
chart: service
version: 13 # came from the base
releaseName: my-service
values:
- values.yaml
- values-prd.yaml
Pros:
Oct 21, 2024This proposal describes an opinioned set of API/tools to manage change promotion and rollback in a GitOps environment.
Sep 23, 2024Major concepts: cluster cachecache sync kubectl semaphore project cache orphaned resource index
Apr 24, 2024Manifest Hydrator This proposal describes a feature to make manifest hydration (i.e. the "rendered manifest pattern") a first-class feature of Argo CD. Open Questions The sourceHydrator field is mutually exclusive with the source and the sources field. Should we throw an error if they're both configured, or should we just pick one and ignore the others? How will/should this feature relate to the image updater? Is there an opportunity to share code, since both tools involve pushing to git? Should we enforce a naming convention for hydrated manifest branches, e.g. argo/...? This would make it easier to recommend branch protection rules, for example, only allow pushes to argo/* from the argo bot. Summary Manifest hydration tools like Helm and Kustomize are indispensable in GitOps. These tools transform "dry" (Don't Repeat Yourself) sources into plain Kubernetes manifests. The effects of a change to dry sources are not always obvious. So storing only dry sources in git leaves the user with an incomplete and confusing history of their application. This undercuts some of the main benefits of GitOps.
Apr 9, 2024or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up