diff --git a/docs/4-user-guide/2-zarf-packages/3-the-zarf-init-package.md b/docs/4-user-guide/2-zarf-packages/3-the-zarf-init-package.md index ad2812d890..b564f182d8 100644 --- a/docs/4-user-guide/2-zarf-packages/3-the-zarf-init-package.md +++ b/docs/4-user-guide/2-zarf-packages/3-the-zarf-init-package.md @@ -4,12 +4,12 @@ sidebar_position: 3 # The Zarf 'init' Package -The init package is the zarf.yaml file that lives at the [root of the Zarf repository](https://github.com/defenseunicorns/zarf/blob/master/zarf.yaml). It is defined via composed components that all offer value for future packages to utilize. When the init package is deployed, it will create a `zarf` namespace within your k8s cluster and deploy various pods, services, and secrets to that namespace, depending on which optional components you choose to deploy. +The init package is the zarf.yaml file that lives at the [root of the Zarf repository](https://github.com/defenseunicorns/zarf/blob/main/zarf.yaml). It is defined via composed components that all offer value for future packages to utilize. When the init package is deployed, it will create a `zarf` namespace within your k8s cluster and deploy various pods, services, and secrets to that namespace, depending on which optional components you choose to deploy. ## Mandatory Components -Zarf's work necessitates that some components in the [init package](https://github.com/defenseunicorns/zarf/blob/master/zarf.yaml) are "always on" (a.k.a. required & cannot be disabled). These components are always deployed whenever you perform a `zarf init` command. Those include: +Zarf's work necessitates that some components in the [init package](https://github.com/defenseunicorns/zarf/blob/main/zarf.yaml) are "always on" (a.k.a. required & cannot be disabled). These components are always deployed whenever you perform a `zarf init` command. Those include: | | Description | | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | @@ -41,4 +41,4 @@ There are two ways to deploy optional components, you can either pass a comma se Deploying onto air-gapped environments is a [hard problem](../../1-understand-the-basics.md#what-is-the-air-gap), especially when the k8s environment you're deploying to doesn't have a container registry running for you to put your images into. This leads to a classic 'chicken or the egg' problem since the container registry image needs to make its way into the cluster but there is no container registry running on the cluster to push to yet because the image isn't in the cluster yet. In order to remain distro agnostic, we had to come up with a unique solution to seed the container registry into the cluster. -The `zarf-injector` [component](https://github.com/defenseunicorns/zarf/blob/master/packages/zarf-injector/zarf.yaml) within the init-package solves this problem by injecting a single rust binary (statically compiled) and a series of configmap chunks of a `registry:2` image into an ephemeral pod based on an existing image in the cluster. +The `zarf-injector` [component](https://github.com/defenseunicorns/zarf/blob/main/packages/zarf-injector/zarf.yaml) within the init-package solves this problem by injecting a single rust binary (statically compiled) and a series of configmap chunks of a `registry:2` image into an ephemeral pod based on an existing image in the cluster. diff --git a/docs/4-user-guide/3-zarf-schema.md b/docs/4-user-guide/3-zarf-schema.md index 24a0ce864e..d8b411cf9a 100644 --- a/docs/4-user-guide/3-zarf-schema.md +++ b/docs/4-user-guide/3-zarf-schema.md @@ -1665,4 +1665,4 @@ Must be one of: ---------------------------------------------------------------------------------------------------------------------------- -Generated from [zarf.schema.json](https://github.com/defenseunicorns/zarf/blob/master/zarf.schema.json) +Generated from [zarf.schema.json](https://github.com/defenseunicorns/zarf/blob/main/zarf.schema.json) diff --git a/docs/4-user-guide/4-vscode.md b/docs/4-user-guide/4-vscode.md index 0dc825133e..53603cd574 100644 --- a/docs/4-user-guide/4-vscode.md +++ b/docs/4-user-guide/4-vscode.md @@ -1,6 +1,6 @@ # Getting started - VS Code -Zarf uses its own [schema](https://github.com/defenseunicorns/zarf/blob/master/zarf.schema.json) to define its configuration files. This schema is used to describe package configuration options and can be used to validate the configuration files before they are used to build a Zarf package. +Zarf uses its own [schema](https://github.com/defenseunicorns/zarf/blob/main/zarf.schema.json) to define its configuration files. This schema is used to describe package configuration options and can be used to validate the configuration files before they are used to build a Zarf package. ## Adding schema validation diff --git a/docs/6-developer-guide/3-nerd-notes.md b/docs/6-developer-guide/3-nerd-notes.md index 0c84b31f04..a9121e768c 100644 --- a/docs/6-developer-guide/3-nerd-notes.md +++ b/docs/6-developer-guide/3-nerd-notes.md @@ -11,7 +11,7 @@ Zarf is written entirely in [go](https://go.dev/), except for a single 868Kb bin - Currently, the Registry and Git servers _are not HA_, see [#375](https://github.com/defenseunicorns/zarf/issues/376) and [#376](https://github.com/defenseunicorns/zarf/issues/376) for discussion on this - To avoid TLS issues, Zarf binds to `127.0.0.1:31999` on each node as a [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) to allow all nodes to access the pod(s) in the cluster - Until [#306](https://github.com/defenseunicorns/zarf/pull/306) is merged, during helm install/upgrade a [Helm PostRender](https://helm.sh/docs/topics/advanced/#post-rendering) function is called to mutate images and [ImagePullSecrets](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) so the deployed resources use the NodePort binding -- Zarf uses a custom injector system to bootstrap a new cluster. See the PR [#329](https://github.com/defenseunicorns/zarf/pull/329) and [ADR](https://github.com/defenseunicorns/zarf/blob/master/adr/0003-image-injection-into-remote-clusters-without-native-support.md) for more details on how we came to this solution. The general steps are listed below: +- Zarf uses a custom injector system to bootstrap a new cluster. See the PR [#329](https://github.com/defenseunicorns/zarf/pull/329) and [ADR](https://github.com/defenseunicorns/zarf/blob/main/adr/0003-image-injection-into-remote-clusters-without-native-support.md) for more details on how we came to this solution. The general steps are listed below: - Get a list of images in the cluster - Attempt to create an ephemeral pod using an image from the list - A small rust binary that is compiled using [musl](https://www.musl-libc.org/) to keep the max binary size as minimal as possible diff --git a/hack/zarf-jsfh-template/base.md b/hack/zarf-jsfh-template/base.md index 327bc00340..43d9c31d49 100644 --- a/hack/zarf-jsfh-template/base.md +++ b/hack/zarf-jsfh-template/base.md @@ -12,7 +12,7 @@ ---------------------------------------------------------------------------------------------------------------------------- {% if config.with_footer -%} -Generated from [zarf.schema.json](https://github.com/defenseunicorns/zarf/blob/master/zarf.schema.json){% if config.footer_show_time %} on {{ get_local_time() }}{% endif %} +Generated from [zarf.schema.json](https://github.com/defenseunicorns/zarf/blob/main/zarf.schema.json){% if config.footer_show_time %} on {{ get_local_time() }}{% endif %} {%- endif -%} {{ "\n" }}