chore(deps): Update to Docusaurus 3.0 (#271)

* update deps

Signed-off-by: Paul Schultz <pschultz@pobox.com>

* update breaking changes

Signed-off-by: Paul Schultz <pschultz@pobox.com>

---------

Signed-off-by: Paul Schultz <pschultz@pobox.com>

apps/website/blog/2022-12-21-newly-released-backstage-plugins/index.mdx

@@ -8,13 +8,13 @@ description: Keycloak and MultiCluster Engine plugins now available
 
 # Newly Released Backstage plugins from the Janus IDP community
 
-Not so long ago, [Red Hat pledged its intention](https://developers.redhat.com/articles/2022/10/24/red-hat-joins-backstageio-community) to join the Backstage community. Several weeks later we're starting to see the first fruits of the effort. The Janus community is pleased to announce the availability of the first 2 Backstage plugins created at Red Hat. These plugins target upstream community projects, namely [Keycloak](https://www.keycloak.org/) and [Open Cluster Management](https://open-cluster-management.io/). Both plugins are in the early stages of development and are not meant to be used yet in production environments, however [we welcome any feedback](https://github.com/janus-idp/backstage-plugins/issues) and suggestions as they continue to mature. Please join us on our path to building a better Internal Development Platforms for Kubernetes and OpenShift on the [Janus IDP community website](http://www.janus-idp.io).
+Not so long ago, [Red Hat pledged its intention](https://developers.redhat.com/articles/2022/10/24/red-hat-joins-backstageio-community) to join the Backstage community. Several weeks later we're starting to see the first fruits of the effort. The Janus community is pleased to announce the availability of the first 2 Backstage plugins created at Red Hat. These plugins target upstream community projects, namely [Keycloak](https://www.keycloak.org/) and [Open Cluster Management](https://open-cluster-management.io/). Both plugins are in the early stages of development and are not meant to be used yet in production environments, however [we welcome any feedback](https://github.com/janus-idp/backstage-plugins/issues) and suggestions as they continue to mature. Please join us on our path to building a better Internal Developer Platforms for Kubernetes and OpenShift on the [Janus IDP community website](http://www.janus-idp.io).
 
 Details related to the first Keycloak and Multicluster Engine plugins for Backstage can be found in the following sections:
 
 ## Keycloak plugin for Backstage
 
-The need for Identity management is a common concern for any internal development platform. Backstage already contains the functionality to connect to external identity providers to enable authentication and apply proper RBAC. However, these concerns are not the sole role of identity management in relation to development portals. These portals also focus on accountability, responsibility and relationship of users and contributors to their project. Backstage achieves that through entity relations within a service catalog. All actors and objects are modeled as entities in this catalog and the Keycloak plugin ensures that all of your Keycloak users and groups are properly represented and mapped within the catalog. It allows the Backstage instance to interface with Keycloak directly and perform automatic and recurring importing of assets. Once imported, these user and group entities can be used in the standard Backstage catalog model with the added benefits of Keycloak’s diverse identity brokering capabilities.
+The need for Identity management is a common concern for any Internal Developer Platform. Backstage already contains the functionality to connect to external identity providers to enable authentication and apply proper RBAC. However, these concerns are not the sole role of identity management in relation to development portals. These portals also focus on accountability, responsibility and relationship of users and contributors to their project. Backstage achieves that through entity relations within a service catalog. All actors and objects are modeled as entities in this catalog and the Keycloak plugin ensures that all of your Keycloak users and groups are properly represented and mapped within the catalog. It allows the Backstage instance to interface with Keycloak directly and perform automatic and recurring importing of assets. Once imported, these user and group entities can be used in the standard Backstage catalog model with the added benefits of Keycloak’s diverse identity brokering capabilities.
 
 ## MultiCluster Engine plugin for Backstage
 

apps/website/blog/2023-01-15-getting-started-with-the-backstage-helm-chart/index.mdx

@@ -7,7 +7,7 @@ description: Getting Started with the Backstage Helm Chart, first of a blog seri
 
 # Getting Started with the Backstage Helm Chart (Part 1)
 
-Red Hat [recently announced](https://developers.redhat.com/articles/2022/10/24/red-hat-joins-backstageio-community) its intention of joining the Backstage community to help shepherd the adoption of Internal Development Platforms more broadly. While there are many aspects that one needs to consider when establishing an IDP, where and how the platform will be deployed is certainly near the top of the list. Backstage can be deployed on a variety of target systems ranging from traditional infrastructure (physical servers or virtual machines) to more cloud native options. Given the popularity of Kubernetes these days, it has become a common choice for running applications and Backstage is no exception to the rule. The Janus project is Red Hat’s upstream community for running Internal Development Platforms and in addition to a series of [Backstage plugins](blog/2022-12-21-newly-released-backstage-plugins/index.mdx) that have been recently developed, it has been working with the community to simplify the process for deploying Backstage on Kubernetes. Deploying an application in Kubernetes can take on many forms, and given that the Helm package manager has become the de facto standard for deploying applications on Kubernetes, the Janus project in conjunction with the greater Backstage community have come together to establish a canonical [Helm chart](https://github.com/backstage/charts) for deploying and maintaining Backstage on Kubernetes. This article will describe how easy it is to get started with the Backstage Helm chart so that an instance of Backstage can be up and running on Kubernetes in no time.
+Red Hat [recently announced](https://developers.redhat.com/articles/2022/10/24/red-hat-joins-backstageio-community) its intention of joining the Backstage community to help shepherd the adoption of Internal Developer Platforms more broadly. While there are many aspects that one needs to consider when establishing an IDP, where and how the platform will be deployed is certainly near the top of the list. Backstage can be deployed on a variety of target systems ranging from traditional infrastructure (physical servers or virtual machines) to more cloud native options. Given the popularity of Kubernetes these days, it has become a common choice for running applications and Backstage is no exception to the rule. The Janus project is Red Hat’s upstream community for running Internal Developer Platforms and in addition to a series of [Backstage plugins](/blog/2022/12/21/newly-released-backstage-plugins) that have been recently developed, it has been working with the community to simplify the process for deploying Backstage on Kubernetes. Deploying an application in Kubernetes can take on many forms, and given that the Helm package manager has become the de facto standard for deploying applications on Kubernetes, the Janus project in conjunction with the greater Backstage community have come together to establish a canonical [Helm chart](https://github.com/backstage/charts) for deploying and maintaining Backstage on Kubernetes. This article will describe how easy it is to get started with the Backstage Helm chart so that an instance of Backstage can be up and running on Kubernetes in no time.
 
 ## Installing Helm
 

apps/website/blog/2023-01-17-enabling-keycloak-authentication-in-backstage/index.mdx

@@ -157,7 +157,7 @@ The next step is to obtain the Client Secret so that it can be used later on as
 
 ## Deploying Backstage using the Backstage Helm Chart
 
-Given that the required prerequisites have been completed and there is a container image of Backstage available and Keycloak has been configured as an Identity Provider, the final step is to deploy Backstage. As previously mentioned, Backstage can be deployed in a variety of ways, but in this case, a deployment to a Kubernetes cluster will be used and the easiest method for deploying Backstage to Kubernetes is to use the Backstage Helm chart as it not only streamlines the deployment process, but provides the capabilities to define the required configurations to enable OAuth authentication with Keycloak. A full writeup on the [Backstage Helm chart](https://github.com/backstage/charts/tree/main/charts/backstage) including the various configurations that it enables can be found [here](blog/2023-01-15-getting-started-with-the-backstage-helm-chart/index.mdx).
+Given that the required prerequisites have been completed and there is a container image of Backstage available and Keycloak has been configured as an Identity Provider, the final step is to deploy Backstage. As previously mentioned, Backstage can be deployed in a variety of ways, but in this case, a deployment to a Kubernetes cluster will be used and the easiest method for deploying Backstage to Kubernetes is to use the Backstage Helm chart as it not only streamlines the deployment process, but provides the capabilities to define the required configurations to enable OAuth authentication with Keycloak. A full writeup on the [Backstage Helm chart](https://github.com/backstage/charts/tree/main/charts/backstage) including the various configurations that it enables can be found [here](/blog/2023/01/15/getting-started-with-the-backstage-helm-chart).
 
 The OAuth2 proxy that bridges the integration between Backstage and Keycloak is deployed as a sidecar container alongside Backstage. Sidecar containers can be enabled by specifying the `backstage.extraContainer` Helm Value. The entire definition of the OAuth proxy container as well as the ability to templatize the required configurations is also supported.
 

apps/website/blog/2023-01-25-exploring-the-flexibility-of-the-backstage-helm-chart/index.mdx

@@ -7,7 +7,7 @@ description: Exploring the Flexibility of the Backstage Helm Chart
 
 # Exploring the Flexibility of the Backstage Helm Chart
 
-Getting Backstage up and running takes no time at all thanks to the Backstage Helm chart as described in the [first article](blog/2023-01-15-getting-started-with-the-backstage-helm-chart/index.mdx) in this series. However, even though Backstage has been deployed, it is hardly ready in its current state for production use. There are several key factors that need to be addressed:
+Getting Backstage up and running takes no time at all thanks to the Backstage Helm chart as described in the [first article](/blog/2023/01/15/getting-started-with-the-backstage-helm-chart) in this series. However, even though Backstage has been deployed, it is hardly ready in its current state for production use. There are several key factors that need to be addressed:
 
 1. Exposing Backstage properly outside the cluster
 2. Adding persistence
@@ -235,4 +235,4 @@ There are quite a number of additional configurations that are included within t
 
 Uninstall and reinstall the Backstage Helm chart once again so that the Software Collections image will be used to support PostgreSQL.
 
-As demonstrated throughout this article, the Helm chart for Backstage provides a robust set of capabilities in order to support customizing and orchestrating a deployment to a Kubernetes environment. By simplifying the steps that it takes to deploy Backstage, the benefits when establishing an Internal Development Platform can be realized.
+As demonstrated throughout this article, the Helm chart for Backstage provides a robust set of capabilities in order to support customizing and orchestrating a deployment to a Kubernetes environment. By simplifying the steps that it takes to deploy Backstage, the benefits when establishing an Internal Developer Platform can be realized.

apps/website/blog/2023-02-06-ingesting-keycloak-org-data-into-the-backstage-catalog/index.mdx

@@ -9,13 +9,13 @@ description: Ingesting Keycloak Organizational Data into the Backstage Catalog
 
 :::note
 This article is a followup to the article [Enabling Keycloak Authentication in
-Backstage](/blog/2023-01-17-enabling-keycloak-authentication-in-backstage/index.mdx). It is important that the steps
+Backstage](/blog/2023/01/17/enabling-keycloak-authentication-in-backstage). It is important that the steps
 outlined within this article are completed prior as described prior to starting this article.
 :::
 
 A directory service is a common component found in organizations big and small as it includes a facility for maintaining key assets including users, groups and their relationships. The Backstage catalog provides similar capabilities to assemble not only identity records, but other resources related to various software components. Items are added to the catalog manually or they are sourced from external locations. Several plugins associated with external providers including Azure, GitHub, GitLab and LDAP, support ingesting organizational data (Users and Groups) directly into the Backstage catalog.
 
-In a [prior article](/blog/2023-01-17-enabling-keycloak-authentication-in-backstage/index.mdx), it was described how Keycloak can be used to act as an identity provider to store users and groups along with enforcing that users accessing Backstage authenticate against the Keycloak instance. Even though users are authenticated into Backstage, records are not added to the Backstage catalog, thus restricting the ability to fully utilize the capabilities of Backstage. Fortunately, a plugin has been developed by the Janus community to perform similar functionality as the other external providers to integrate Keycloak user and group entities into the Backstage catalog.
+In a [prior article](/blog/2023/01/17/enabling-keycloak-authentication-in-backstage), it was described how Keycloak can be used to act as an identity provider to store users and groups along with enforcing that users accessing Backstage authenticate against the Keycloak instance. Even though users are authenticated into Backstage, records are not added to the Backstage catalog, thus restricting the ability to fully utilize the capabilities of Backstage. Fortunately, a plugin has been developed by the Janus community to perform similar functionality as the other external providers to integrate Keycloak user and group entities into the Backstage catalog.
 
 This article will describe the steps involved to implement its use within Backstage. The [keycloak-backend](https://github.com/janus-idp/backstage-plugins/tree/main/plugins/keycloak-backend) plugin is one of an increasing set of plugins found within the [backstage-plugins repository](https://github.com/janus-idp/backstage-plugins) that have been developed by the Janus community to expand the interoperability between Backstage and a variety of open source projects. These plugins are published within the [@janus-idp npm repository](https://www.npmjs.com/package/@janus-idp/backstage-plugin-keycloak-backend) which allows them to be added to Backstage with ease. Support for ingesting users and groups from Keycloak by way of the plugin only requires a few steps within Backstage itself.
 

apps/website/blog/2023-02-17-deploying-backstage-onto-openshift-using-helm/index.mdx

@@ -7,9 +7,9 @@ description: Deploying Backstage onto OpenShift Using the Backstage Helm Chart
 
 # Deploying Backstage onto OpenShift Using the Backstage Helm Chart
 
-Backstage is a framework for building developer portals and has become an important tool that is complementary with establishing an [Internal Development Platform](https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/) (IDP). Many of the same organizations who are seeking the benefits that Backstage and an IDP can provide are also using Kubernetes as a platform for building and running containerized workloads. As described within previous articles ([Part 1](/blog/2023-01-15-getting-started-with-the-backstage-helm-chart/index.mdx), [Part 2](/blog/2023-01-25-exploring-the-flexibility-of-the-backstage-helm-chart/index.mdx), the Backstage Helm chart can be used to not only simplify the process for deploying Backstage to Kubernetes, but also how its flexibility can adapt to a variety of conditions and constraints.
+Backstage is a framework for building developer portals and has become an important tool that is complementary with establishing an [Internal Developer Platform](https://internaldeveloperplatform.org/what-is-an-internal-developer-platform/) (IDP). Many of the same organizations who are seeking the benefits that Backstage and an IDP can provide are also using Kubernetes as a platform for building and running containerized workloads. As described within previous articles ([Part 1](/blog/2023/01/15/getting-started-with-the-backstage-helm-chart), [Part 2](/blog/2023/01/25/exploring-the-flexibility-of-the-backstage-helm-chart), the Backstage Helm chart can be used to not only simplify the process for deploying Backstage to Kubernetes, but also how its flexibility can adapt to a variety of conditions and constraints.
 
-While Kubernetes has become the de-facto container orchestration platform, there are a number of Kubernetes distributions on the market. The [Janus Project](https://janus-idp.io) is an upstream community sponsored by Red Hat and OpenShift (along with the upstream OKD) is their Kubernetes distribution. The features and capabilities that are included within OpenShift greatly benefit from a framework like Backstage as it enables end users the ability to simplify their interactions with each of these services. This article will describe the considerations that must be accounted for and the process to deploy the Backstage Helm chart to OpenShift.
+While Kubernetes has become the de-facto container orchestration platform, there are a number of Kubernetes distributions on the market. The [Janus Project](/) is an upstream community sponsored by Red Hat and OpenShift (along with the upstream OKD) is their Kubernetes distribution. The features and capabilities that are included within OpenShift greatly benefit from a framework like Backstage as it enables end users the ability to simplify their interactions with each of these services. This article will describe the considerations that must be accounted for and the process to deploy the Backstage Helm chart to OpenShift.
 
 ## OpenShift Environment Considerations
 
@@ -152,4 +152,4 @@ The prior command assumes that the Helm CLI and the Backstage Helm repository ha
 
 Once the Chart release is successful, confirm that not only that both Backstage and PostgreSQL pods are running, but that an edge terminated Route has been created to enable external access to the Backstage user interface. Open a web browser to the hostname defined within the Route to confirm the Backstage user interface can be accessed securely.
 
-With only a few small steps as demonstrated within this article and thanks to the Backstage Helm chart, Backstage and its required dependencies can be deployed to an OpenShift environment. In no time at all, teams can begin building and consuming developer portals that are built on a hardened and secure foundation to enable organizations the ability to realize the benefits offered by Internal Development Platforms.
+With only a few small steps as demonstrated within this article and thanks to the Backstage Helm chart, Backstage and its required dependencies can be deployed to an OpenShift environment. In no time at all, teams can begin building and consuming developer portals that are built on a hardened and secure foundation to enable organizations the ability to realize the benefits offered by Internal Developer Platforms.