#### _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/). Please direct all code changes, issues and comments to https://repo1.dso.mil/platform-one/big-bang/customers/template_**
> _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/). Please direct all code changes, issues and comments to <https://repo1.dso.mil/platform-one/big-bang/customers/template>_**
This folder contains a template that you can replicate in your own Git repo to get started with Big Bang configuration. If you are new to Big Bang it is recommended you start with the [Big Bang Quickstart](https://repo1.dso.mil/platform-one/quick-start/big-bang) before attempting customization.
...
...
@@ -9,7 +9,7 @@ The main benefits of this template include:
- Isolation of the Big Bang product and your custom configuration
- Allows you to easily consume upstream Big Bang changes since you never change the product
- Big Bang product tags are explicitly referenced in your configuration, giving you control over upgrades
-[GitOps](https://www.weave.works/technologies/gitops/) for your deployments configrations
-[GitOps](https://www.weave.works/technologies/gitops/) for your deployments configurations
- Single source of truth for the configurations deployed
- Historical tracking of changes made
- Allows tighter control of what is deployed to production (via merge requests)
...
...
@@ -21,7 +21,7 @@ The main benefits of this template include:
- Secrets (e.g. pull credentials) can be shared across deployments.
> NOTE: SOPS [supports multiple keys for encrypting the same secret](https://dev.to/stack-labs/manage-your-secrets-in-git-with-sops-common-operations-118g) so that each environment can use a different SOPS key but share a secret.
### Prerequisites
## Prerequisites
To deploy Big Bang, the following items are required:
...
...
@@ -64,7 +64,7 @@ git checkout -b template-demo
### Create GPG Encryption Key
To make sure your pull secrets are not comprimized when uploaded to Git, you must generate your own encryption key:
To make sure your pull secrets are not compromised when uploaded to Git, you must generate your own encryption key:
> Keys should be created without a passphrase so that Flux can use the private key to decrypt secrets in the Big Bang cluster.
...
...
@@ -101,7 +101,7 @@ The `base/configmap.yaml` is setup to use the domain `bigbang.dev` by default.
```shell
cd base
# Encrypt the existing certifiate
# Encrypt the existing certificate
sops -e bigbang-dev-cert.yaml > secrets.enc.yaml
# Save encrypted TLS certificate into Git
...
...
@@ -149,7 +149,7 @@ git commit -m "chore: added iron bank pull credentials"
git push
```
> Your private key to decrypt these secrets is stored in your GPG key ring. You must **NEVER** export this key and commit it to your Git repository since this would comprimise your secrets.
> Your private key to decrypt these secrets is stored in your GPG key ring. You must **NEVER** export this key and commit it to your Git repository since this would compromise your secrets.
### Configure for GitOps
...
...
@@ -245,7 +245,7 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
# Verify secrets and configmaps are deployed
# At a minimum, you will have the following:
# secrets: sops-gpg, private-git, common-bb, and environment-bb
# configmaps: conmmon, environment
# configmaps: common, environment
kubectl get -n bigbang secrets,configmaps
# Watch deployment
...
...
@@ -257,7 +257,7 @@ Big Bang follows a [GitOps](https://www.weave.works/blog/what-is-gitops-really)
```
> If you cannot get to the main page of Kiali, it may be due to an expired certificate. Check the expiration of the certificate in `base/configmap.yaml`.
>
> For troubleshooting deployment problems, refer to the [Big Bang](https://repo1.dsop.io/platform-one/big-bang/bigbang) documentation.
You now have successfully deployed Big Bang. Your next step is to customize the configuration.
...
...
@@ -284,7 +284,7 @@ You now have successfully deployed Big Bang. Your next step is to customize the
1. Big Bang will automatically pick up your change and make the necessary changes.
```shell
# Watch deployment for twislock to be deployed
# Watch deployment for twistlock to be deployed
watch kubectl get hr,po -A
# Test deployment by opening a browser to "twistlock.bigbang.dev" to get to the Twistlock application
...
...
@@ -383,7 +383,7 @@ For additional configuration options, refer to the [Big Bang](https://repo1.dsop
### Additional resources
Using Kustomize, you can add additional resources to the deployment if needed. Read the [Kustomization](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/) documentation for futher details.
Using Kustomize, you can add additional resources to the deployment if needed. Read the [Kustomization](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/) documentation for further details.
## Secrets
...
...
@@ -405,7 +405,7 @@ You will need to update `.sops.yaml` with your configuration based on the links
If you need to [rotate your GPG encryption keys](#create-gpg-encryption-key) for any reason, you will also need to re-encrypt any encrypted secrets.
1. Update `.sops.yaml` configuration file
`.sops.yaml` holds all of the key fingerpints used for SOPS. Update `pgp`'s value to the new key's fingerprint. You can list your locally stored fingerprints using `gpg -k`.
`.sops.yaml` holds all of the key fingerprints used for SOPS. Update `pgp`'s value to the new key's fingerprint. You can list your locally stored fingerprints using `gpg -k`.
```yaml
creation_rules:
...
...
@@ -472,7 +472,7 @@ In our template, we have a `dev` and a `prod` environment with a shared `base`.
- Shared Iron Bank pull credential
- Different database passwords for `dev` and `prod`
- Differnet SOPS keys for `dev` and `prod`
- Different SOPS keys for `dev` and `prod`
1. Setup `.sops.yaml` for multiple folders:
...
...
@@ -547,6 +547,6 @@ To start, we may have the following in each folder:
Big Bang `dev` value changes can be made by simply modifying `dev/configmap.yaml`. `base` and `dev` create two separate configmaps, named `common` and `environment` respectively, with the `environment` values taking precedence over `common` values in Big Bang.
The same concept applies to `dev` secret changes, with two separate secrets named `common-bb` and `environment-bb` used for values to Big Bang, with the `environment-bb` values taking prcedence over the `common-bb` values in Big Bang.
The same concept applies to `dev` secret changes, with two separate secrets named `common-bb` and `environment-bb` used for values to Big Bang, with the `environment-bb` values taking precedence over the `common-bb` values in Big Bang.
If a new resource must be deployed, for example a TLS cert, you must add a `resources:` section to the `kustomization.yaml` to refer to the new file. See the base directory for an example.
#### _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/). Please direct all code changes, issues and comments to https://repo1.dso.mil/platform-one/big-bang/customers/template_
> _This is a mirror of a government repo hosted on [Repo1](https://repo1.dso.mil/) by [DoD Platform One](http://p1.dso.mil/). Please direct all code changes, issues and comments to <https://repo1.dso.mil/platform-one/big-bang/customers/template>_
The terraform/terragrunt code in this directory will setup all the infrastructure for a Big Bang deployment in Amazon Web Services (AWS). It starts from scratch with a new VPC and finishes by deploying a multi-node [RKE2 Cluster](https://docs.rke2.io/). The infrastructure and cluster provisioned can then be used to deploy Big Bang.
> This code is intended to be a forkable starting point / example for users to get their infrastructure setup quickly. It is up to the users to futher customize and secure the infrastructure for the intended use.
> This code is intended to be a forkable starting point / example for users to get their infrastructure setup quickly. It is up to the users to further customize and secure the infrastructure for the intended use.
## Layout
...
...
@@ -15,7 +15,7 @@ terraform
└── main # Shared terraform code
└── us-gov-west-1 # Terragrunt code for a specific AWS region
├── region.yaml # Regional configuration
└── prod # Teragrunt code for a specific environment (e.g. prod, stage, dev)
└── prod # Terragrunt code for a specific environment (e.g. prod, stage, dev)
└── env.yaml # Environment specific configuration
```
...
...
@@ -35,7 +35,7 @@ terraform
- Validate your configuration
```bash
```shell
cd ./terraform/us-gov-west-1/prod
terragrunt run-all validate
# Successful output: Success! The configuration is valid.
...
...
@@ -43,7 +43,7 @@ terraform
- Run the deployment
```bash
```shell
# Initialize
terragrunt run-all init
...
...
@@ -57,7 +57,7 @@ terraform
- Connect to cluster
```bash
```shell
# Setup your cluster name (same as `name` in `env.yaml`)
export CNAME="bigbang-dev"
...
...
@@ -100,17 +100,17 @@ Prior to deploying Big Bang, you should setup the following in the Kubernetes cl
### Storage Class
By default, Big Bang will use the cluster's default `StorageClass` to dynamically provision the required persistent volumes. This means the cluster must be able to dynamically provision PVCs. Since we're on AWS, the simplest method is to use the [AWS EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) Storage Class using Kubernetes' in tree [AWS cloud provider](https://kubernetes.io/docs/concepts/storage/storage-classes/#aws-ebs).
By default, Big Bang will use the cluster's default `StorageClass` to dynamically provision the required persistent volumes. This means the cluster must be able to dynamically provision persistent volume claims (PVCs). Since we're on AWS, the simplest method is to use the [AWS EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) Storage Class using Kubernetes' in tree [AWS cloud provider](https://kubernetes.io/docs/concepts/storage/storage-classes/#aws-ebs).
> Without a default storage class, some Big Bang components, like Elasticsearch, Jaeger, or Twistlock, will never reach the running state.
@@ -125,7 +125,7 @@ kubectl patch storageclass <name of your storage class> -p '{"metadata": {"annot
To ensure ingress into the cluster, load balancers must be configured to ensure proper port mappings for `istio`. The simplest method is the default scenario, where the cluster (`rke2` in this example) is running the appropriate cloud provider capable of dynamically provisioning load balancers when requesting `Services` of `type: LoadBalancer`. This is the default configuration in BigBang, and if you choose to continue this way, you can skip the following steps.
However, for brevity in this example, we are introducing an alternative, where the load balancer is preprovisioned and owned by terraform (from your earlier apply step). This provides more control over the load balancer, but also requires the extra step of informing `istio` on installation of the required ports to expose on each node that the pre-created load balancer should forward to. It's important to note these are the _exact_ same steps that the cloud provider would take if we let Kubernetes provision things for us.
However, for brevity in this example, we are introducing an alternative, where the load balancer is pre-provisioned and owned by terraform (from your earlier apply step). This provides more control over the load balancer, but also requires the extra step of informing `istio` on installation of the required ports to expose on each node that the pre-created load balancer should forward to. It's important to note these are the _exact_ same steps that the cloud provider would take if we let Kubernetes provision things for us.
The following configuration in Big Bang's values.yaml will setup the appropriate `NodePorts` to match the [Quickstart](#quickstart) configuration.
...
...
@@ -280,11 +280,11 @@ end
## Debug
After Big Bang deployment, if you wish to access your deployed web applications that are not exposed publically, add an entry into your /etc/hosts to point the host name to the elastic load balancer.
After Big Bang deployment, if you wish to access your deployed web applications that are not exposed publicly, add an entry into your /etc/hosts to point the host name to the elastic load balancer.
> This bypasses load balancing since you are using the resolved IP address of one of the connected nodes in the pool
# Retrieve IP address of load balancer for /etc/hosts
export ELBIP=`dig $LBDNS +short | head-1`
# Now add the hostname of the web appliation into /etc/hosts (or `C:\Windows\System32\drivers\etc\hosts` on Windows)
# Now add the hostname of the web application into /etc/hosts (or `C:\Windows\System32\drivers\etc\hosts` on Windows)
# You may need to log out and back into for hosts to take effect
printf"\nAdd the following line to /etc/hosts to alias Big Bang core products:\n${ELBIP} twistlock.bigbang.dev kibana.bigbang.dev prometheus.bigbang.dev grafana.bigbang.dev tracing.bigbang.dev kiali.bigbang.dev alertmanager.bigbang.dev\n\n"
```
...
...
@@ -320,7 +320,7 @@ terragrunt run-all destroy
## Optional Terraform
Depending on your needs, you may want to deploy additional infrastructure, such as Key Stores, S3 Buckets, or Databases, that can be used with your deployment. In the [options](./options) directory, you will find terraform / terragrunt snippits that can assist you in deploying these items.
Depending on your needs, you may want to deploy additional infrastructure, such as Key Stores, S3 Buckets, or Databases, that can be used with your deployment. In the [options](./options) directory, you will find terraform / terragrunt snippets that can assist you in deploying these items.
> These examples may required updates to be compatible with the [Quickstart](#quickstart)
