Merge "Fix spelling errors in docs folders"
This commit is contained in:
		@@ -19,7 +19,7 @@ Airship 1.0 Deploy and Update Site Flow
 | 
			
		||||
   and finally site-level repositories.  These may be entirely different
 | 
			
		||||
   repositories with different permissions.  Pegleg facilitates cloning
 | 
			
		||||
   all of these at the correct revisions according to the definition for
 | 
			
		||||
   that site. Pegleg can be driven via a jenkins pipeline, which can be
 | 
			
		||||
   that site. Pegleg can be driven via a Jenkins pipeline, which can be
 | 
			
		||||
   further abstracted in something like an NC3C dashboard, or it can be
 | 
			
		||||
   driven on the command line directly by imitating the behavior in the
 | 
			
		||||
   pipeline.
 | 
			
		||||
@@ -73,7 +73,7 @@ Airship 1.0 Deploy and Update Site Flow
 | 
			
		||||
|vspace|
 | 
			
		||||
 | 
			
		||||
3. Once pegleg has decrypted the secrets in the document set within an
 | 
			
		||||
   ephemeral jenkins pipeline, pegleg collect is called to assemble them
 | 
			
		||||
   ephemeral Jenkins pipeline, pegleg collect is called to assemble them
 | 
			
		||||
   all, and finally that is piped to the shipyard client which will
 | 
			
		||||
   publish them via REST API to a Shipyard API service running within the
 | 
			
		||||
   site. There are two scenarios under which Shipyard may be running in
 | 
			
		||||
 
 | 
			
		||||
@@ -88,7 +88,7 @@ which is used by projects such as ``kubectl``, ``kpt``, and ``airshipctl``.
 | 
			
		||||
Airshipctl incorporates Kustomize into its higher-order functionality, so
 | 
			
		||||
that it's invoked as part of ``airshipctl phase run``, rendering
 | 
			
		||||
manifests into a deployable form before deploying them directly to a
 | 
			
		||||
Kubernetes apiserver.  However, Airship follows the design decision for
 | 
			
		||||
Kubernetes api server.  However, Airship follows the design decision for
 | 
			
		||||
its YAMLs to be fully renderable using the stock ``kustomize`` command.
 | 
			
		||||
 | 
			
		||||
The basic building block for Kustomize manifests is called a "kustomization",
 | 
			
		||||
@@ -119,7 +119,7 @@ ReplacementTransformer
 | 
			
		||||
Kustomize is very good at layering patches on top of resources, but has
 | 
			
		||||
some weakness when performing substitution/replacement type operations,
 | 
			
		||||
i.e., taking information from one document and injecting it into another
 | 
			
		||||
document.  This operation is very critical to Airship from a de-duplication
 | 
			
		||||
document.  This operation is very critical to Airship from a deduplication
 | 
			
		||||
perspective, since the same information (e.g. a Kubernetes version or
 | 
			
		||||
some networking information) would be needed in multiple resources.
 | 
			
		||||
Replacement helps satisfy the DRY principle.  Although Kustomize has a few
 | 
			
		||||
@@ -147,7 +147,7 @@ While ReplacementTransformer modifies existing resources, the Templater
 | 
			
		||||
is a Kustomize "generator" plugin that creates brand new resources based
 | 
			
		||||
on a Go Template.  This is helpful when you have a number of resources
 | 
			
		||||
that are nearly identical, and allows the common parts to be
 | 
			
		||||
de-duplicated into a template.  An example of this would be resources
 | 
			
		||||
deduplicated into a template.  An example of this would be resources
 | 
			
		||||
that are specific per-host (like Metal3 ``BareMetalHost``).
 | 
			
		||||
 | 
			
		||||
The ReplacementTransformer and Templater can also be combined in a chain,
 | 
			
		||||
@@ -164,7 +164,7 @@ Encryption, Decryption, and Secret Generation
 | 
			
		||||
Encryption and decryption is handled via the `sops` KRM Function maintained
 | 
			
		||||
by the KPT community.  This function in turn uses the Mozilla SOPS tool
 | 
			
		||||
to perform asymmetric key-based decryption on encrypted values within
 | 
			
		||||
YAML resources.  
 | 
			
		||||
YAML resources.
 | 
			
		||||
 | 
			
		||||
In addition, passwords, keys, and other sensitive secrets can be generated
 | 
			
		||||
from scratch on a site-by-site basis.  This helps ensure that secrets are
 | 
			
		||||
 
 | 
			
		||||
@@ -51,7 +51,7 @@ already configured with default values for a typical deployment or inferred
 | 
			
		||||
from other configuration files or site manifests. In most situations, users
 | 
			
		||||
do not need to manually set the values for these environment variables.
 | 
			
		||||
 | 
			
		||||
 * ``KUBECONFIG``: The location of kubeconfig file. Default value:
 | 
			
		||||
 * ``KUBECONFIG``: The location of the kubeconfig file. Default value:
 | 
			
		||||
   ``$HOME/.airship/kubeconfig``.
 | 
			
		||||
 * ``KUBECONFIG_TARGET_CONTEXT``: The name of the kubeconfig context for the
 | 
			
		||||
   target cluster. Default value: "target-cluster". You can find it defined
 | 
			
		||||
 
 | 
			
		||||
		Reference in New Issue
	
	Block a user