UNCLASSIFIED - NO CUI

Skip to content
Snippets Groups Projects
Commit fb1bf76c authored by Caitlin Bowman-Clare's avatar Caitlin Bowman-Clare Committed by Michael Martin
Browse files

Update docs/understanding-bigbang/concepts/deployment.md,...

parent a1685533
No related branches found
No related tags found
3 merge requests!4866deleted,!4850deleted,!4838Update docs/understanding-bigbang/concepts/deployment.md,...
Hide whitespace changes
Inline Side-by-side
docs/understanding-bigbang/concepts/deployment.md
+ 20
− 20
View file @ fb1bf76c
......@@ -4,7 +4,7 @@
## GitOps
Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really) approach to deployment. All configuration changes will be pulled and reconciled with what is stored in the Git repository. The only exception to this is the initial manifests (e.g. `dev.yaml`) which points to the Git repository and path.
Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really) approach to deployment. All configuration changes will be pulled and reconciled with what is stored in the Git repository. The only exception to this is the initial manifests (e.g., `dev.yaml`) which points to the Git repository and path.
## Installation
......@@ -15,40 +15,40 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
kustomize build ./dev
```
1. If you have not already done so, push configuration changes to Git
1. If you have not already done so, push configuration changes to Git.
```shell
git push
```
1. Validate the Kubernetes context is correct
1. Validate the Kubernetes context is correct.
```shell
# This should match the environment you intend to deploy
kubectl config current-context
```
1. Deploy the Big Bang manifest to the cluster
1. Deploy the Big Bang manifest to the cluster.
```shell
kubectl apply -f dev.yaml
```
1. [Monitor the deployment](#monitor)
1. [Monitor the deployment](#monitor).
## Upgrade
All changes to the Big Bang cluster should be made through Git. After changes are pushed, Big Bang will automatically reconcile the difference with the cluster.
All changes to the Big Bang cluster should be made through Git. After changes are pushed, Big Bang will automatically reconcile the difference with the cluster.
> It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them. This is based on the `interval` value set for polling. You can force Big Bang to immediately check for changes by running the [sync.sh](../../..//scripts/sync.sh) script.
> It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them. This is based on the `interval` value set for polling. You can force Big Bang to immediately check for changes by running the [sync.sh](../../..//scripts/sync.sh) script.
Changes to values can be tested in each environment using the named folders to override values and/or point to specific repo branches or tags. After testing, the changes can be placed into the `./base` folder if the change is shared between all environments.
Changes to values can be tested in each environment using the named folders to override values and/or point to specific repo branches or tags. After testing, the changes can be placed into the `./base` folder if the change is shared between all environments.
## Monitor
The following commands will help you monitor the progress of the Big Bang deployment. Review the [flowchart](./glossary.md#Diagram), if needed, to understand the progression. Use the [Troubleshooting Guide](./troubleshooting.md) if you have failures.
The commands detailed in this section will help you monitor the progress of the Big Bang deployment. Review the [flowchart](./glossary.md#Diagram), if needed, to understand the progression. Use the [Troubleshooting Guide](./troubleshooting.md) if you have failures.
1. Verify Flux is running
1. Verify Flux is running.
```shell
kubectl get deploy -n flux-system
......@@ -61,7 +61,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
helm-controller 1/1 1 1 106s
```
1. Verify the environment was pulled from the Git repo
1. Verify the environment was pulled from the Git repo.
```shell
kubectl get gitrepository -A
......@@ -71,7 +71,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang environment-repo https://repo1.dso.mil/big-bang/customers/template.git True Fetched revision: main/185e252f4452d897531ab0314adc7a189562be31 2m7s
```
1. Verify the environment Kustomization properly worked
1. Verify the environment Kustomization properly worked.
```shell
kubectl get kustomizations -A
......@@ -81,7 +81,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang environment True Applied revision: main/185e252f4452d897531ab0314adc7a189562be31 6m41s
```
1. Verify the ConfigMaps were deployed
1. Verify the ConfigMaps were deployed.
```shell
kubectl get configmap -l kustomize.toolkit.fluxcd.io/namespace -A
......@@ -92,7 +92,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang environment-d2tgb27f56 1 19m
```
1. Verify the Secrets were deployed
1. Verify the Secrets were deployed.
```shell
kubectl get secrets -l kustomize.toolkit.fluxcd.io/namespace -A
......@@ -103,7 +103,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang environment-bb-mhddkt46bd Opaque 1 18m
```
1. Verify the Big Bang Helm Chart was pulled
1. Verify the Big Bang Helm Chart was pulled.
```shell
kubectl get gitrepositories -A
......@@ -113,7 +113,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang https://repo1.dso.mil/big-bang/bigbang.git True Fetched revision: master/8a4a1ddd0c9edf316f5362680cf2921baf0c3451 25m
```
1. Verify the Big Bang Helm Chart was deployed
1. Verify the Big Bang Helm Chart was deployed.
```shell
kubectl get hr -A
......@@ -123,7 +123,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang bigbang True Release reconciliation succeeded 28m
```
1. Verify Big Bang package Helm charts are pulled
1. Verify Big Bang package Helm charts are pulled.
```shell
kubectl get gitrepository -A
......@@ -141,7 +141,7 @@ The following commands will help you monitor the progress of the Big Bang deploy
bigbang cluster-auditor https://repo1.dso.mil/big-bang/product/packages/cluster-auditor.git True Fetched revision: chart-release/598c35670db0cbdb3a48063b2d558965afe73185 8m23s
```
1. Verify the packages get deployed
1. Verify the packages get deployed.
```shell
# Use watch since it take a long time to deploy
......@@ -188,6 +188,6 @@ The following commands will help you monitor the progress of the Big Bang deploy
istio-operator pod/istio-operator-79f966cfc-rjhhc 0/1 ContainerCreating 0 8s
```
1. Wait until all Helm Releases, Deployments, and Pods are Ready. Be patient, this can take 15-30 minutes.
1. Wait until all Helm Releases, Deployments, and Pods are ready. Be patient, this can take 15-30 minutes.
> The Git repositories are monitored periodically (default is 10m) for changes. If a change is detected, the configuration will be reconciled using Flux. The monitoring techniques above can be used to monitor the reconciliation.
> The Git repositories are monitored periodically (default is 10m) for changes. If a change is detected, the configuration will be reconciled using Flux. The monitoring techniques above can be used to monitor the reconciliation.
docs/understanding-bigbang/concepts/encryption.md
+ 18
− 16
View file @ fb1bf76c
......@@ -2,7 +2,7 @@
[[_TOC_]]
Big Bang follows a [GitOps](https://www.weave.works/technologies/gitops/) approach to managing the Big Bang Kubernetes cluster configuration. Using GitOps, we must securely store secrets in Git using encryption. The private key, which is stored in key storage, is used by the continuous deployment tool to decrypt and deploy the secrets for use in the cluster.
Big Bang follows a [GitOps](https://www.weave.works/technologies/gitops/) approach to managing the Big Bang Kubernetes cluster configuration. Using GitOps, we must securely store secrets in Git using encryption. The private key, which is stored in key storage, is used by the continuous deployment tool to decrypt and deploy the secrets for use in the cluster.
## SOPS
......@@ -10,11 +10,11 @@ Big Bang follows a [GitOps](https://www.weave.works/technologies/gitops/) approa
> The private key used in SOPS should **NEVER** be stored in Git along side the encrypted secrets.
SOPS supports the ability to [add multiple keys](https://dev.to/stack-labs/manage-your-secrets-in-git-with-sops-common-operations-118g) to the same file so multiple key pairs can use the same secret. This is useful for environments which may have different keys, but use the same secrets. For each key used, SOPS writes the public key, used to encrypt, and an encrypted copy of the data to the file. Decryption requires use of one of the private keys used. After editing, the embedded public keys are used to re-encrypt the file for all key pairs.
SOPS supports the ability to [add multiple keys](https://dev.to/stack-labs/manage-your-secrets-in-git-with-sops-common-operations-118g) to the same file so multiple key pairs can use the same secret. This is useful for environments which may have different keys, but use the same secrets. For each key used, SOPS writes the public key, used to encrypt, and an encrypted copy of the data to the file. Decryption requires use of one of the private keys used. After editing, the embedded public keys are used to re-encrypt the file for all key pairs.
## Create Encryption Keys
To setup Big Bang with SOPS, a key pair must be created. The private key is used for decryption and must be securely stored but accessible to the cluster. The public key is used for encryption. Follow the appropriate instructions below to create your key pair.
To set up Big Bang with SOPS, a key pair must be created. The private key is used for decryption and must be securely stored but accessible to the cluster. The public key is used for encryption. Follow the appropriate instructions provided below to create your key pair.
| Key Management | Key Pair Instructions | Notes |
|--|--|--|
......@@ -23,25 +23,25 @@ To setup Big Bang with SOPS, a key pair must be created. The private key is use
| [Google Cloud Platform (GCP) Key Management Service (KMS)](https://cloud.google.com/security-key-management) | [Link](https://github.com/mozilla/sops#encrypting-using-gcp-kms) |
| [HashiCorp Vault](https://www.vaultproject.io/) | [Link](https://github.com/mozilla/sops#23encrypting-using-azure-key-vault) |
> \*GPG is not recommended for production use because the private key can be misplaced or compromised too easily
> GPG is not recommended for production use because the private key can be misplaced or compromised too easily.
## Configure SOPS
SOPS uses `.sops.yaml` as a configuration file for which keys to use for newly created files. Once a file is created, the key fingerprints are stored in the file and must be re-keyed to use any changes to `.sops.yaml`.
SOPS uses `.sops.yaml` as a configuration file for which keys to use for newly created files. Once a file is created, the key fingerprints are stored in the file and must be re-keyed to use any changes to `.sops.yaml`.
1. Follow the [SOPS instructions](https://github.com/mozilla/sops#210using-sopsyaml-conf-to-select-kmspgp-for-new-files) to configure `.sops.yaml` based on the encryption method you used. Multiple keys of the same type can be added using the block scalar yaml construct, `>-`, and separating them by a comma and newline.
1. Follow the [SOPS instructions](https://github.com/mozilla/sops#210using-sopsyaml-conf-to-select-kmspgp-for-new-files) to configure `.sops.yaml` based on the encryption method you used. Multiple keys of the same type can be added using the block scalar yaml construct, `>-`, and separating them by a comma and newline.
> If you are using the Big Bang sample files, make sure to remove the development Big Bang key.
2. Add the following regex to only encrypt data in the yaml files
2. Add the following regex to only encrypt data in the yaml files:
```yaml
creation_rules:
- encrypted_regex: "^(data|stringData)$"
```
3. Save `.sops.yaml` in the root of folder of your configuration
4. If you have existing secrets, use the following to re-key them with the configuration in `.sops.yaml`
3. Save `.sops.yaml` in the root of folder of your configuration.
4. If you have existing secrets, use the following to re-key them with the configuration in `.sops.yaml`.
```shell
# You must have the old private key to rekey the file
......@@ -50,11 +50,11 @@ SOPS uses `.sops.yaml` as a configuration file for which keys to use for newly c
## Deploy Private Key
> This must be completed before deploying Big Bang or else deploying Secrets will fail.
> This must be completed before deploying Big Bang or else deploying secrets will fail.
### GPG
1. Deploy your SOPS private key to a secret named `sops-gpg` in the cluster
1. Deploy your SOPS private key to a secret named `sops-gpg` in the cluster.
```shell
gpg --export-secret-keys --armor <new key fingerprint> | kubectl create secret generic sops-gpg -n bigbang --from-file=yourkey.asc=/dev/stdin
......@@ -101,7 +101,7 @@ Big Bang needs to know how to retrieve the private key so it can deploy the encr
### GPG
By default, the `Kustomization` resource uses a Secret named `sops-gpg` for the private key as shown here:
By default, the `Kustomization` resource uses a Secret named `sops-gpg` for the private key as shown in the following:
```yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
......@@ -117,7 +117,7 @@ spec:
### AWS KMS
Configure the `Kustomization` resource to use sops for decryption:
Configure the `Kustomization` resource to use SOPS for decryption.
```yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
......@@ -134,7 +134,7 @@ spec:
If Big Bang is deployed within AWS, KMS key access can be handled via IAM roles and permissions on the cluster resources themselves.
However, if the deployment is in a different environment from the KMS keys, AWS credentials may need to be provided via a secret as follows.
Configure the flux-system `kustomize-controller` component with AWS credential environment variables using `kustomize`. Specific instructions for doing this may vary by deployment and environment but [an example](https://repo1.dso.mil/big-bang/customers/template/-/tree/main) is covered in the bigbang template repo. Broadly speaking, adding environment variables to the `kustomize-controller` component can be accomplished by adding a patch to the `flux/kustomization.yaml` for the target deployment or environment. An example of such a `kustomization.yaml` is shown below:
Configure the flux-system `kustomize-controller` component with AWS credential environment variables using `kustomize`. Specific instructions for doing this may vary by deployment and environment but [an example](https://repo1.dso.mil/big-bang/customers/template/-/tree/main) is covered in the bigbang template repo. Broadly speaking, adding environment variables to the `kustomize-controller` component can be accomplished by adding a patch to the `flux/kustomization.yaml` for the target deployment or environment. An example of such a `kustomization.yaml` is shown in the following:
```yaml
bases:
......@@ -165,6 +165,8 @@ patchesStrategicMerge:
key: access_key_secret
```
> Values should come from the `sops-aws-creds` secret created in [AWS KMS](#aws-kms) above
> Values should come from the `sops-aws-creds` secret created in [AWS KMS](#aws-kms) above.
TBD - Instructions on how to update for GCP, Vault
## Instructions on how to update for GCP and Vault
TBD
docs/understanding-bigbang/concepts/git-ops-engine.md
+ 6
− 6
View file @ fb1bf76c
......@@ -2,11 +2,11 @@
## Management of Big Bang
Big Bang will be deployed and managed with [Flux 2](https://github.com/fluxcd/flux2) and provide [Argo](https://github.com/argoproj/argo-cd/) for application developers to use for managing custom applications built on a Big Bang cluster. Big Bang will **not** advocate for use of Flux by mission app owners.
Big Bang will be deployed and managed with [Flux 2](https://github.com/fluxcd/flux2) and provide [Argo](https://github.com/argoproj/argo-cd/) for application developers to use for managing custom applications built on a Big Bang cluster. Big Bang will **not** advocate for use of Flux by mission app owners.
### Big Bang and Flux
Big Bang is composed of Open Source and licensed products. [Helm](https://helm.sh/), as a member of the [CNCF](https://www.cncf.io/), is the de facto standard for packaging applications for Kubernetes. As a result, several vendors support the release of their product **as helm charts** and have built their packaging and lifecycle management to expect to be the engine for driving that management. As a result, Big Bang has adopted Helm as its internal deployment framework for Big Bang packages and requires Helm to be treated as a first class citizen.
Big Bang is composed of Open Source and licensed products. [Helm](https://helm.sh/), as a member of the [CNCF](https://www.cncf.io/), is the de facto standard for packaging applications for Kubernetes. As a result, several vendors support the release of their product **as helm charts** and have built their packaging and lifecycle management to expect to be the engine for driving that management. As a result, Big Bang has adopted Helm as its internal deployment framework for Big Bang packages and requires Helm to be treated as a first class citizen.
The Flux 2 Engine has native Helm support, meaning the controller deployed as part of "Flux 2" leverages the same Helm code as the CLI.
......@@ -17,15 +17,15 @@ The Flux 2 Engine has native Helm support, meaning the controller deployed as pa
Argo, has taken the ownership of rendering and managing the lifecycle of applications that does not work exactly as expected by helm. As a result, there are several vendor Helm Charts that **do not deploy successfully** with Argo because of how Argo shims Helm Hooks to Argo specific sync phases.
* GitLab initial secret creation is performed via a [subchart](https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/charts/shared-secrets)
* Kube Prometheus Stack - [prometheusrule admission webhook](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#prometheusrules-admission-webhooks) is created via a helm `install` hook
* Confluent - A deletion hook is part of a subchart gets run at different point in the lifecycle
* Kube Prometheus Stack: [prometheusrule admission webhook](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#prometheusrules-admission-webhooks) is created via a helm `install` hook
* Confluent: A deletion hook is part of a subchart gets run at different point in the lifecycle
As new features of Helm get developed and leveraged by the community, we would need to lean on the time and availability of the Argo developers to re-implement the capabilities.
#### App of App Pattern and Secrets
Argo requires all configuration options to be embedded into the ApplicationCR. Because of this, sensitive values that need to be passed into "inner" packages are forced to reside in the Custom Resource rather than referenced as a Secret.
Argo requires all configuration options to be embedded into the Application CR. Because of this, sensitive values that need to be passed into "inner" packages are forced to reside in the Custom Resource rather than referenced as a Secret.
## Argo Is Still A Package
As defined in the list of [Big Bang Packages](../../packages.md), Big Bang comes deployed with Argo for use by mission applications to continue to deploy and manage their applications. Similarly, even though Big Bang uses Helm internally for management of Big Bang packages, Big Bang does not advocate for Helm for use by applications run on clusters with Big Bang.
As defined in the list of [Big Bang Packages](../../packages.md), Big Bang comes deployed with Argo for use by mission applications to continue to deploy and manage their applications. Similarly, even though Big Bang uses Helm internally for management of Big Bang packages, Big Bang does not advocate for Helm for use by applications run on clusters with Big Bang.
docs/understanding-bigbang/concepts/glossary.md
+ 20
− 17
View file @ fb1bf76c
......@@ -8,7 +8,7 @@
### Big Bang
Big Bang is a declarative, continuous delivery tool for core DoD hardened and approved [packages](#packages) into a Kubernetes cluster. Big Bang follows a [GitOps](#gitops) approach to configuration management, using [Flux v2](#flux-v2) to reconcile Git with the cluster. Environments (e.g. dev, prod) and packages (e.g. istio) can be fully configured to suit the deployment needs.
Big Bang is a declarative, continuous delivery tool for core DoD hardened and approved [packages](#packages) into a Kubernetes cluster. Big Bang follows a [GitOps](#gitops) approach to configuration management, using [Flux v2](#flux-v2) to reconcile Git with the cluster. Environments (e.g., dev and/or prod) and packages (e.g., istio) can be fully configured to suit the deployment needs.
### Big Bang Components
......@@ -16,23 +16,23 @@ Big Bang is made of several components that operate together. These include a [
### Flux v2
[Flux v2](https://toolkit.fluxcd.io/) is the tool used by Big Bang to reconcile sources of configuration in Git with actual code deployment. Flux includes resources to reconcile Git repositories, [Kustomizations](https://kustomize.io/) to Kubernetes manifests, and [Helm Chart](https://helm.sh/docs/topics/charts/) releases. Flux automatically monitors changes in these items and reconciles with the Kubernetes cluster.
[Flux v2](https://toolkit.fluxcd.io/) is the tool used by Big Bang to reconcile sources of configuration in Git with actual code deployment. Flux includes resources to reconcile Git repositories, [Kustomizations](https://kustomize.io/) to Kubernetes manifests, and [Helm Chart](https://helm.sh/docs/topics/charts/) releases. Flux automatically monitors changes in these items and reconciles with the Kubernetes cluster.
### GitOps
[GitOps](https://www.weave.works/technologies/gitops/) is a way to declaratively manage a Kubernetes cluster using a single source of truth in Git. All Kubernetes configuration is stored in Git. And, a tool (e.g. [Flux](#flux-v2)) is used to automatically monitor and reconcile the configuration with the running Kubernetes cluster. This allows all changes to the cluster to be version controlled and pipelined.
[GitOps](https://www.weave.works/technologies/gitops/) is a way to declaratively manage a Kubernetes cluster using a single source of truth in Git. All Kubernetes configuration is stored in Git. A tool (e.g. [Flux](#flux-v2) is used to automatically monitor and reconcile the configuration with the running Kubernetes cluster. This allows all changes to the cluster to be version controlled and pipelined.
### SOPS
[SOPS](https://github.com/mozilla/sops) is a way to encrypt values in YAML, JSON, ENV, INI, or BINARY files so that sensitive data can be securely shared. Big Bang uses SOPS to encrypt pull secrets, certificates, and other secrets so that it can be stored into the Git repository securely. Big Bang (via Flux) uses the private key, stored in a secure area (e.g. KMS) to decrypt the secrets and deploy them into the cluster for use.
[SOPS](https://github.com/mozilla/sops) is a way to encrypt values in YAML, JSON, ENV, INI, or BINARY files so that sensitive data can be securely shared. Big Bang uses SOPS to encrypt pull secrets, certificates, and other secrets so that it can be stored into the Git repository securely. Big Bang (via Flux) uses the private key, stored in a secure area (e.g., KMS) to decrypt the secrets and deploy them into the cluster for use.
### Kustomize
[Kustomize](https://kustomize.io/) is a tool that assists with configuration management for Kubernetes manifest files. It uses overlays and patching to customize a base set of manifests for deployment. Big Bang uses Kustomize to setup the environment (e.g. dev, prod) configuration.
[Kustomize](https://kustomize.io/) is a tool that assists with configuration management for Kubernetes manifest files. It uses overlays and patching to customize a base set of manifests for deployment. Big Bang uses Kustomize to setup the environment (e.g., dev and/or prod) configuration.
### Helm
[Helm](https://helm.sh/) is a tool that assists with configuration management for Kubernetes manifest files. It uses charts, which includes templates and values, to create a set of manifests for deployment. Big Bang uses Helm charts to deploy all of its packages.
[Helm](https://helm.sh/) is a tool that assists with configuration management for Kubernetes manifest files. It uses charts, which includes templates and values, to create a set of manifests for deployment. Big Bang uses Helm charts to deploy all of its packages.
---
......@@ -60,30 +60,33 @@ In addition, the following packages can be added onto the default deployment:
## Architecture
The diagram below shows a typical deployment of Big Bang into a Kubernetes cluster. The items in blue require user interaction. The remaining items are automated by Big Bang.
The diagram provided in this section shows a typical deployment of Big Bang into a Kubernetes cluster. The items in blue require user interaction. The remaining items are automated by Big Bang.
### Configuration
1. The user must [setup an encryption key pair](./encryption.md) for SOPS and store the private key securely (e.g. KMS). This should **NOT** be stored in Git.
1. The user must [setup an encryption key pair](./encryption.md) for SOPS and store the private key securely (e.g., KMS). This should **NOT** be stored in Git.
1. The user should then [configure Big Bang](../configuration/configuration.md) values and secrets for the targeted Kubernetes cluster.
1. All secrets should be encrypted with SOPS to protect them.
1. Once all of the configuration has been completed, it must be pushed to a Git repository.
### Deployment
1. With everything in Git, the user can [deploy BigBang](./deployment.md) using a Kubernetes manifest.
1. With everything in Git, the user can [deploy Big Bang](./deployment.md) using a Kubernetes manifest.
1. The manifest holds two Flux resources, one pointing to the Git repository holding the custom environment, and one telling Flux to run Kustomize on a targeted folder within the repo.
1. The repository is reconciled first, pulling the files from Git.
1. Next, Kustomize is run on the environment configuration.
1. The Kustomize files use Big Bang's Git repo as a base before applying overlays and patches for the configuration.
1. Flux uses SOPS to decrypt any secrets before deploying the manifests.
1. After completing the Kustomization process, Flux deploys two ConfigMaps, two Secrets, and flux resources for Big Bang.
a. The repository is reconciled first, pulling the files from Git.
b. Next, Kustomize is run on the environment configuration.
- The Kustomize files use Big Bang's Git repo as a base before applying overlays and patches for the configuration.
- Flux uses SOPS to decrypt any secrets before deploying the manifests.
- After completing the Kustomization process, Flux deploys two ConfigMaps, two Secrets, and flux resources for Big Bang.
1. Big Bang's flux resources include a Git repository holding the Helm chart and a Helm Release resource that tells Flux how to deploy the Helm chart.
1. The repository is reconciled first, pulling the Helm chart from Git.
1. The Helm Release will check for the Helm chart and the Secrets / ConfigMaps deployed before performing a Helm install.
a. The repository is reconciled first, pulling the Helm chart from Git.
b. The Helm Release will check for the Helm chart and the Secrets/ConfigMaps deployed before performing a Helm install.
1. Once the Helm release deploys the Helm chart for Big Bang, each package that is enabled will have a Flux Git Repository and Helm Release resource deployed.
1. All of the package Git repositories containing Helm charts will be pulled so that Flux can reconcile dependencies.
1. Each package's Helm Release has dependencies built in. Flux will reconcile these dependencies and deploy the Helm chart for the package once all of the dependencies are ready.
1. Each package's Helm Release has dependencies built in. Flux will reconcile these dependencies and deploy the Helm chart for the package once all of the dependencies are ready.
1. Once all of the packages are ready, Big Bang will monitor Git periodically for changes and reconcile using the methods above.
### Diagram
......
docs/understanding-bigbang/concepts/troubleshooting.md
+ 5
− 5
View file @ fb1bf76c
# Troubleshooting
Big Bang can take a long time to run. After making changes, it could take 10-15 minutes to take effect. Use the [sync.sh](../../../scripts/sync.sh) script to speed this up.
Big Bang can take a long time to run. After making changes, it could take 10-15 minutes to take effect. Use the [sync.sh](../../../scripts/sync.sh) script to speed this up.
Big Bang is configured to retry failed package installations and upgrades. Before concluding you have a failure, make sure you allow Big Bang to attempt to resolve dependencies and retry.
Big Bang is configured to retry failed package installations and upgrades. Before concluding you have a failure, make sure you allow Big Bang to attempt to resolve dependencies and retry.
## Iron Bank authentication
## Iron Bank Authentication
| Symptom | Cause | Resolution |
|--|--|--|
| Despite entering correct credentials, get `unauthorized: authentication required` from Iron Bank | Using a non-robot account with an expired token | Login with the non-robot account manually at `registry1.dso.mil`, then retry. For production, contact the Iron Bank team to obtain a robot account and update pull credentials to use it in your environment |
| Despite entering correct credentials, get `unauthorized: authentication required` from Iron Bank. | Using a non-robot account with an expired token. | Login with the non-robot account manually at `registry1.dso.mil`, then retry. For production, contact the Iron Bank team to obtain a robot account and update pull credentials to use it in your environment. |
## Flux install
## Flux Install
Helpful debugging commands:
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

UNCLASSIFIED - NO CUI