Change Alpha / Beta Language
This commit is contained in:
Phillip Wittrock
parent
297669f88e
commit
4613fbed81
|
|
@ -24,16 +24,17 @@
|
|||
|
||||
## App Structure
|
||||
|
||||
* [Layout With Directories (Beta)](pages/app_composition_and_deployment/structure_directories.md)
|
||||
* [Layout With Branches (Alpha)](pages/app_composition_and_deployment/structure_branches.md)
|
||||
* [Layout With Repositories (Alpha)](pages/app_composition_and_deployment/structure_repositories.md)
|
||||
* [Introduction](pages/app_composition_and_deployment/structure_introduction.md)
|
||||
* [Layout With Directories](pages/app_composition_and_deployment/structure_directories.md)
|
||||
* [Layout With Branches (Experimental)](pages/app_composition_and_deployment/structure_branches.md)
|
||||
* [Layout With Repositories (Experimental)](pages/app_composition_and_deployment/structure_repositories.md)
|
||||
* [Multi-Tier](pages/app_composition_and_deployment/structure_multi_tier_apps.md)
|
||||
|
||||
## App Deployment
|
||||
|
||||
* [Diffing Local and Remote State](pages/app_composition_and_deployment/diffing_local_and_remote_resources.md)
|
||||
* [Accessing Multiple Clusters](pages/app_composition_and_deployment/accessing_multiple_clusters.md)
|
||||
* [Publishing Config as Bases (Alpha)](pages/app_composition_and_deployment/publishing_bases.md)
|
||||
* [Publishing Config as Bases (Experimental)](pages/app_composition_and_deployment/publishing_bases.md)
|
||||
|
||||
## Resource Printing
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,5 @@
|
|||
{% panel style="warning", title="Warning: Alpha Recommendations" %}
|
||||
This chapter contains recommendations that are still being actively evaluated, and are
|
||||
expected to evolve.
|
||||
|
||||
Before using these recommendations, carefully evaluate if they are right for your environment.
|
||||
{% panel style="warning", title="Experimental" %}
|
||||
This chapter contains some recommendations that are actively being explored, and may evolve.
|
||||
{% endpanel %}
|
||||
|
||||
{% panel style="info", title="TL;DR" %}
|
||||
|
|
|
|||
|
|
@ -1,11 +1,5 @@
|
|||
{% panel style="warning", title="Warning: Alpha Recommendations" %}
|
||||
This chapter contains recommendations that are **still being actively evaluated, and are
|
||||
expected to evolve.**
|
||||
|
||||
The intent of this chapter is to share the way kubectl developers are thinking about solving
|
||||
this problem as they develop more solutions.
|
||||
|
||||
Before using these recommendations, carefully evaluate if they are right for your organization.
|
||||
{% panel style="warning", title="Experimental" %}
|
||||
This chapter contains some recommendations that are actively being explored, and may evolve.
|
||||
{% endpanel %}
|
||||
|
||||
|
||||
|
|
@ -19,17 +13,9 @@ Before using these recommendations, carefully evaluate if they are right for you
|
|||
|
||||
# Branch Structure Based Layout
|
||||
|
||||
The are several techniques for users to structure their Resource Config files.
|
||||
|
||||
| Type | Summary | Benefits |
|
||||
|----------------------------------------|-----------------------|----------------------------------------------------|
|
||||
| [Directories](structure_directories.md) | *Simplest approach* | Easy to get started and understand |
|
||||
| **[Branches](structure_branches.md)** | **More flexible** | **Loose coupling between version specific and live operational changes** |
|
||||
| [Repositories](structure_repositories.md) | *Fine grain control* | Isolated permissions model |
|
||||
|
||||
## Motivation
|
||||
|
||||
This chapter describes conventions for using **Branches** with Directories.
|
||||
This chapter describes *conventions* for using **Branches** with Directories.
|
||||
|
||||
**Advantages:**
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,3 @@
|
|||
{% panel style="warning", title="Warning: Beta Recommendations" %}
|
||||
This chapter contains recommendations that are **still being actively evaluated, and are
|
||||
expected to evolve.**
|
||||
|
||||
Before using these recommendations, carefully evaluate if they are right for your organization.
|
||||
{% endpanel %}
|
||||
|
||||
|
||||
{% panel style="info", title="TL;DR" %}
|
||||
- Use **directory hierarchy to structure Resource Config**
|
||||
- Separate directories for separate Environment and Cluster [Config Variants](../app_customization/bases_and_variants.md)
|
||||
|
|
@ -13,17 +5,19 @@ Before using these recommendations, carefully evaluate if they are right for you
|
|||
|
||||
# Directory Structure Based Layout
|
||||
|
||||
The are several techniques for users to structure their Resource Config files.
|
||||
|
||||
| Type | Summary | Benefits |
|
||||
|----------------------------------------|-----------------------|----------------------------------------------------|
|
||||
| **[Directories](structure_directories.md)** | **Simplest approach** | **Easy to get started and understand** |
|
||||
| [Branches](structure_branches.md) | *More flexible* | Loose coupling between version specific and live operational changes |
|
||||
| [Repositories](structure_repositories.md) | *Fine grain control* | Isolated permissions model |
|
||||
|
||||
## Motivation
|
||||
|
||||
This chapter describes conventions for using **Directories** alone.
|
||||
This chapter describes *conventions* when using **Directories** alone - without Branches or Repositories.
|
||||
|
||||
{% panel style="success", title="Which is right for my organization?" %}
|
||||
While this chapter is focussed on conventions when using Directories alone, these same conventions should
|
||||
also be used with Branches or Repositories.
|
||||
|
||||
For complex deployment environments where responsibility over Config spans responsibilities or abstraction
|
||||
layers owned by separate teams - modularization and isolation between teams may be necessary -
|
||||
(which may include using Branches and Repositories, or other techniques).
|
||||
{% endpanel %}
|
||||
|
||||
|
||||
**Advantages:**
|
||||
|
||||
|
|
@ -65,6 +59,7 @@ Structure:
|
|||
Techniques:
|
||||
|
||||
- Each Layer adds a [namePrefix](../app_management/namespaces_and_names.md#setting-a-name-prefix-or-suffix-for-all-resources) and [commonLabels](../app_management/labels_and_annotations.md#setting-labels-for-all-resources).
|
||||
- Each Layer adds labels and annotations.
|
||||
- Each deployable target sets a [namespace](../app_management/namespaces_and_names.md#setting-the-namespace-for-all-resources).
|
||||
- Override [Pod Environment Variables and Arguments](../app_customization/customizing_pod_templates.md) using `configMapGenerator`s with `behavior: merge`.
|
||||
- Perform Last-mile customizations with [patches / overlays](../app_customization/customizing_arbitrary_fields.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
{% panel style="info", title="TL;DR" %}
|
||||
- Resource Config is stored in one or more git repositories
|
||||
- Directory hierarchy, git branches and git repositories may be used for loose coupling
|
||||
{% endpanel %}
|
||||
|
||||
|
||||
# Resource Config Structure
|
||||
|
||||
The chapters in this section cover how to structure Resource Config using git.
|
||||
|
||||
Users may start with a pure Directory Hierarchy approach, and migrate to include Branches
|
||||
and / or Repositories as part of the structure.
|
||||
|
||||
## Background
|
||||
|
||||
Tools:
|
||||
|
||||
- *Bases:* provide **common or shared Resource Config to be factored out** that can be
|
||||
imported into multiple projects.
|
||||
- *Overlays and Customizations:* tailor **common or shared Resource Config to be modified** to
|
||||
a specific application, environment or purpose.
|
||||
|
||||
Applied Concepts:
|
||||
|
||||
- Resource Config may be initially structured using Directory Hierarchy for organization.
|
||||
- Use Bases with Overlays / Customizations for factoring across Directories
|
||||
- Different Deployment environments for the same app may be loosely coupled, using separate **Branches for separate
|
||||
environments**.
|
||||
- Use Bases with Overlays / Customization for factoring across Branches
|
||||
- Teams owning separate (shared) Config may be loosely coupled using separate **Repositories for
|
||||
separate teams**.
|
||||
- Use Bases with Overlays / Customization for factoring across Repositories
|
||||
|
||||
|
||||
Table:
|
||||
|
||||
| Technique | Decouple Changes | Best For | Workflow |
|
||||
|---------------------------------------------|-----------------------|----------------------------------------------------|----------|
|
||||
| [Directories](structure_directories.md) | NA | Simple organizational and deployment structure. | Changes are immediately propagated globally. |
|
||||
| [Branches](structure_branches.md) | *Across Environments* | Promoting changes across Environments. | Changes to Bases are pushed across multiple linear stages by the owners of Bases. |
|
||||
| [Repositories](structure_repositories.md) | *Across Teams* | Fetching changes across config shared across Teams. | Changes to Bases are pulled by individual consumers into their projects. |
|
||||
|
|
@ -1,11 +1,5 @@
|
|||
{% panel style="warning", title="Warning: Alpha Recommendations" %}
|
||||
This chapter contains recommendations that are **still being actively evaluated, and are
|
||||
expected to evolve.**
|
||||
|
||||
The intent of this chapter is to share the way kubectl developers are thinking about solving
|
||||
this problem as they develop more solutions.
|
||||
|
||||
Before using these recommendations, carefully evaluate if they are right for your organization.
|
||||
{% panel style="warning", title="Experimental" %}
|
||||
This chapter contains some recommendations that are actively being explored, and may evolve.
|
||||
{% endpanel %}
|
||||
|
||||
|
||||
|
|
@ -17,17 +11,9 @@ Before using these recommendations, carefully evaluate if they are right for you
|
|||
|
||||
# Repository Structure Based Layout
|
||||
|
||||
The are several techniques for users to structure their Resource Config files.
|
||||
|
||||
| Type | Summary | Benefits |
|
||||
|---------------------------------------------|-----------------------|----------------------------------------------------|
|
||||
| [Directories](structure_directories.md) | *Simplest approach* | Easy to get started and understand |
|
||||
| [Branches](structure_branches.md) | *More flexible* | Loose coupling between version specific and live operational changes |
|
||||
| **[Repositories](structure_repositories.md)** | **Fine grain control** | **Isolated permissions model** |
|
||||
|
||||
## Motivation
|
||||
|
||||
This chapter describes conventions for using **Repositories** with Directories.
|
||||
This chapter describes *conventions* for using **Repositories** with Directories.
|
||||
|
||||
**Advantages:**
|
||||
|
||||
|
|
@ -48,6 +34,12 @@ This chapter describes conventions for using **Repositories** with Directories.
|
|||
|
||||
## Directory Structure
|
||||
|
||||
{% panel style="info", title="Remote URLs vs Vendoring" %}
|
||||
- Repositories owned and controlled by the same organization may be referenced to by their URL
|
||||
- Repositories owned or controlled by separate organizations should be vendored and referenced
|
||||
by path to the vendor directory.
|
||||
{% endpanel %}
|
||||
|
||||
{% method %}
|
||||
|
||||
### Resource Config
|
||||
|
|
|
|||
Loading…
Reference in New Issue