This is part 2 in a series of Big Bang 2.0 blog posts. If you haven't already, read through part 1 [here](./big-bang-2-0.md) which provides some backstory on why the team thought 2.0 was necessary and what changes are included. This post will dive more into the specific breaking changes and how these will affect you as a user.
## Values Key Changes
As mentioned in the first post, a number of values keys will be changing in order to standardize naming. Some of these keys already changed in BB 1.x, but had backwards compatibility previously. In 2.0 usage of the new keys will be required. When evaluating the upgrade for your own deployment, these are the specific key translations/changes you will need to make if you were using them in 1.x:
-`istiooperator` -> `istioOperator`
-`kyvernopolicies` -> `kyvernoPolicies`
-`kyvernoreporter` -> `kyvernoReporter`
-`logging` -> `elasticsearchKibana`
-`eckoperator` -> `eckOperator`
-`mattermostoperator` -> `mattermostOperator`
-`nexus` -> `nexusRepositoryManager`
Note that your upgrade to 2.0 will fail if you do not modify your values as seen above. Big Bang is now maintaining a [values schema](https://helm.sh/docs/topics/charts/#schema-files) to enforce strict adherence to the allowed/required keys within Big Bang. For reference Big Bang's values schema is located [here](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/chart/values.schema.json).
## Namespace Changes
Connected with name standardization as well as package isolation, several packages will be moving to different namespaces in 2.0. These packages are all "state-less" with no persistent storage, so there is no requirement to backup anything from the previous version before upgrading. Specific packages moving:
- Fluentbit: Moving from `logging` namespace to `fluentbit` namespace
- Promtail: Moving from `logging` namespace to `promtail` namespace
- Gitlab Runner: Moving from `gitlab` namespace to `gitlab-runner` namespace
Also note that Fluentbit (if connecting to Elasticsearch) and Gitlab Runner now have a dependency on Kyverno if relying on the "auto" authentication/token setup. In both cases Kyverno is leveraged to copy secrets between namespaces. This does not mean that you need to use `kyvernoPolicies` as well - you could continue to use Gatekeeper for policy enforcement and deploy Kyverno exclusively for this use case (although we do encourage Kyverno adoption). If you do not want to deploy Kyverno there are several alternative options listed below.
Gitlab Runner Alternatives:
- Get a token from your Gitlab instance and add it via values (`addons.gitlabRunner.values.runnerRegistrationToken`)
- Manually copy the secret from the `gitlab` namespace to the `gitlab-runner` namespace
Fluentbit Alternatives:
- Leverage `fluentbit.values.additionalOutputs.elasticsearch` and `fluentbit.values.additionalOutputs.disableDefault`=`true` to setup a connection with Elastic, rather than using the auto-connection
- Manually copy secrets from the `logging` namespace to the `fluentbit` namespace. You will need to copy both the certs secret (`logging-ek-es-http-certs-public`) as well as the auth secret (`logging-ek-es-elastic-user`)
Beyond the new requirement for Kyverno, changes to a namespace can affect labels and pod/svc names in some cases, so be aware of this if you are leveraging these packages in connection with anything on top of Big Bang. All components within Big Bang have been adjusted to account for these changes already.
## Default Package Changes
As mentioned in the previous post - Big Bang will deploy by default with a new opensource set of core packages in 2.0. If you are using any of the below packages and want to continue using them in 2.0, make note of the changes you will need to perform:
- Twistlock: Set `twistlock.enabled` to true; set `neuvector.enabled` to false
- Fluentbit: Set `fluentbit.enabled` to true; set `promtail.enabled` to false
- Elasticsearch/Kibana: Set `elasticsearchKibana.enabled` to true; set `loki.enabled` to false
- Gatekeeper: Set `gatekeeper.enabled` and `clusterAuditor.enabled` to true; set `kyverno.enabled`, `kyvernoReporter.enabled`, and `kyvernoPolicies.enabled` to false
- Jaeger: Set `jaeger.enabled` to true; set `tempo.enabled` to false
Provided you make the above adjustments you will be able to deploy with the same set of packages you were using in 1.x.
## HelmRelease / GitRepository Name Changes
Beyond the above mentioned name changes you may also notice some `HelmRelease` and `GitRepository` names change in 2.0. For the most part these should have no effect on anything directly in Big Bang, but they are important to be aware of if you maintain automation/applications on top of what is provided by Big Bang. Changes to the `HelmRelease` name specifically could affect pod/svc names and labels, so these are enumerated below:
That's it! This blog post lays out all of the breaking changes in 2.0, and hopefully also provides you with a clear path forward for what you need to change before upgrading.
Continue reading about Big Bang 2.0 in [part 3 of this series](./2-0-new-features.md), which is focused specifically on the new features included in 2.0.
This is part 3 in a series of Big Bang 2.0 blog posts. If you haven't already, read through part 1 [here](./big-bang-2-0.md) which provides some backstory on 2.0 and part 2 [here](./2-0-breaking-changes.md) which will get you prepared for the breaking changes in 2.0. This post will dive more into some of the new features releasing with 2.0.
## Package Extensibility
As mentioned in the first post in this series, 2.0 will provide new extensibility for deploying additional packages (beyond what is providing in Big Bang core/addons). The ["extra package deployment guide"](../docs/guides/deployment-scenarios/extra-package-deployment.md) provides a lot of details on what is included and how to use it, so we won't reproduce all of that here. As a teaser for that more extensive document, 2.0 provides a new way to deploy extra packages, as seen in the example below which deploys podinfo directly from the GitHub source:
```yaml
packages:
podinfo:
git:
repo:https://github.com/stefanprodan/podinfo.git
tag:6.3.4
path:charts/podinfo
```
We strongly encourage you look at using this for deploying any extra packages, whether they are from the Big Bang Community or directly from GitHub and other sources.
## OCI HelmRepositories
As mentioned previously Helm repositories will now be an option for deployment in 2.0. While we do encourage users to test and adopt this, Git repository sources will remain the default for 2.0 so you will not see any immediate changes unless you choose to test it out as laid out in the brief guide below.
To setup a `HelmRepository` source you will want to add a `helmRepositories` config to your values:
```yaml
helmRepositories:
-name:"registry1"
repository:"oci://registry1.dso.mil/bigbang"
existingSecret:"private-registry"
type:"oci"
```
By using the `existingSecret: "private-registry"` you will be re-using your `registryCredentials` for authentication. If using a robot account you may need to get a new one issued with a broader scope since previous robot accounts only provided access to `registry1.dso.mil/ironbank`.
In order to start using the `HelmRepository`, you'll need to switch the `sourceType` for a package. The below example switches it for `istio`:
```yaml
istio:
sourceType:"helmRepo"
```
Currently you would need to set the `sourceType` individually for each package, but once making that change your `HelmRelease` will be setup to pull from the `HelmRepository` instead of the `GitRepository`. As a side-note, you can also pull from other Helm repositories (even non-OCI type ones) and leverage this alongside the new `packages` functionality to deploy from any imaginable Helm repo.
Why should you be interested in switching? Big Bang is currently publishing all package Helm charts (including community packages) to our OCI Helm Repository (`registry1.dso.mil/bigbang`). This means that you can pull all of your charts from a single source object in cluster, rather than having a `GitRepository` per package. In the future we also plan to sign these charts and have Flux validate the signatures in cluster. If you're an airgap user this also has some future benefits depending on tooling, you may no longer need a Git server running to spin up Big Bang.
## Renovate for Upgrades
The last feature we want to highlight in this post is the new inclusion of Renovate for upgrades. This again is pretty well laid out in existing documentation [here](../docs/guides/renovate/deployment.md) so we won't dive too deep into configurations and how to use it in this post. We encourage you to take a look at that deployment document and explore the [package itself](https://repo1.dso.mil/big-bang/product/packages/renovate) to see how it might help you with updates. We've also updated the [customer template repo](https://repo1.dso.mil/big-bang/customers/template) with a sample Renovate config to show how it could be used directly in a config repo.
What is Big Bang 2.0? Why are we doing it? 2.0 is the second major release since Big Bang 1.0 released in December 2020. This blog post should provide you with both the why behind what we're doing as well as what the changes involved are - and what that means for you as a user.
...
...
@@ -53,3 +59,5 @@ This is a change in the underlying architecture of Big Bang, but it will be offe
## Where can I learn more?
Big Bang's 2.0 epic is a great place to start [here](https://repo1.dso.mil/groups/big-bang/-/epics/217). Beyond this we encourage users to get involved via the [BBTOC](https://repo1.dso.mil/platform-one/bbtoc).
Continue reading about Big Bang 2.0 in [part 2 of this series]((./2-0-breaking-changes.md), which is focused specifically on the breaking changes included in 2.0.
