Compare commits
No commits in common. "development" and "development" have entirely different histories.
developmen
...
developmen
224 changed files with 129 additions and 2806 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -1 +0,0 @@
|
|||
node_modules
|
||||
4
.vscode/settings.json
vendored
4
.vscode/settings.json
vendored
|
|
@ -1,5 +1,4 @@
|
|||
{
|
||||
"peacock.color": "#832561",
|
||||
"workbench.colorCustomizations": {
|
||||
"activityBar.activeBackground": "#ab307e",
|
||||
"activityBar.background": "#ab307e",
|
||||
|
|
@ -18,5 +17,6 @@
|
|||
"titleBar.activeForeground": "#e7e7e7",
|
||||
"titleBar.inactiveBackground": "#83256199",
|
||||
"titleBar.inactiveForeground": "#e7e7e799"
|
||||
}
|
||||
},
|
||||
"peacock.color": "#832561"
|
||||
}
|
||||
14
devbox.json
14
devbox.json
|
|
@ -1,14 +0,0 @@
|
|||
{
|
||||
"$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.14.0/.schema/devbox.schema.json",
|
||||
"packages": ["nodejs@latest"],
|
||||
"shell": {
|
||||
"init_hook": [
|
||||
"echo 'Welcome to devbox!' > /dev/null"
|
||||
],
|
||||
"scripts": {
|
||||
"test": [
|
||||
"echo \"Error: no test specified\" && exit 1"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
73
devbox.lock
73
devbox.lock
|
|
@ -1,73 +0,0 @@
|
|||
{
|
||||
"lockfile_version": "1",
|
||||
"packages": {
|
||||
"github:NixOS/nixpkgs/nixpkgs-unstable": {
|
||||
"resolved": "github:NixOS/nixpkgs/2d9e4457f8e83120c9fdf6f1707ed0bc603e5ac9?lastModified=1741462378&narHash=sha256-ZF3YOjq%2BvTcH51S%2BqWa1oGA9FgmdJ67nTNPG2OIlXDc%3D"
|
||||
},
|
||||
"nodejs@latest": {
|
||||
"last_modified": "2025-03-16T16:17:41Z",
|
||||
"plugin_version": "0.0.2",
|
||||
"resolved": "github:NixOS/nixpkgs/8f76cf16b17c51ae0cc8e55488069593f6dab645#nodejs_23",
|
||||
"source": "devbox-search",
|
||||
"version": "23.10.0",
|
||||
"systems": {
|
||||
"aarch64-darwin": {
|
||||
"outputs": [
|
||||
{
|
||||
"name": "out",
|
||||
"path": "/nix/store/dihlffh62qmgzsrxq1igwxicdyr3fn8a-nodejs-23.10.0",
|
||||
"default": true
|
||||
},
|
||||
{
|
||||
"name": "libv8",
|
||||
"path": "/nix/store/ks94i4365833bykrzg3d3mqxnciygyrn-nodejs-23.10.0-libv8"
|
||||
}
|
||||
],
|
||||
"store_path": "/nix/store/dihlffh62qmgzsrxq1igwxicdyr3fn8a-nodejs-23.10.0"
|
||||
},
|
||||
"aarch64-linux": {
|
||||
"outputs": [
|
||||
{
|
||||
"name": "out",
|
||||
"path": "/nix/store/m7j1lf8a4z5bfla1m78pa3y12888hl7b-nodejs-23.10.0",
|
||||
"default": true
|
||||
},
|
||||
{
|
||||
"name": "libv8",
|
||||
"path": "/nix/store/kfvlfxx83n2w2fyb8hiz4p4dc165r035-nodejs-23.10.0-libv8"
|
||||
}
|
||||
],
|
||||
"store_path": "/nix/store/m7j1lf8a4z5bfla1m78pa3y12888hl7b-nodejs-23.10.0"
|
||||
},
|
||||
"x86_64-darwin": {
|
||||
"outputs": [
|
||||
{
|
||||
"name": "out",
|
||||
"path": "/nix/store/nj0d1lc4nanqj7v4ibcgd26m3p5yfb0h-nodejs-23.10.0",
|
||||
"default": true
|
||||
},
|
||||
{
|
||||
"name": "libv8",
|
||||
"path": "/nix/store/k5rvmvqyibamfxa7cfzjfd5ldmi38kf3-nodejs-23.10.0-libv8"
|
||||
}
|
||||
],
|
||||
"store_path": "/nix/store/nj0d1lc4nanqj7v4ibcgd26m3p5yfb0h-nodejs-23.10.0"
|
||||
},
|
||||
"x86_64-linux": {
|
||||
"outputs": [
|
||||
{
|
||||
"name": "out",
|
||||
"path": "/nix/store/m7imcmwi4hschl257dzc33gxciqlf4bm-nodejs-23.10.0",
|
||||
"default": true
|
||||
},
|
||||
{
|
||||
"name": "libv8",
|
||||
"path": "/nix/store/wy7ysxmd2ygdc5zpbhf9ripwgvvvnwsd-nodejs-23.10.0-libv8"
|
||||
}
|
||||
],
|
||||
"store_path": "/nix/store/m7imcmwi4hschl257dzc33gxciqlf4bm-nodejs-23.10.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
title: Technical doc
|
||||
arrange:
|
||||
- concepts
|
||||
- architecture
|
||||
- product
|
||||
- project
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 626 KiB |
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
title: Architecture
|
||||
weight: 1
|
||||
description: High level EDP Architecture
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
> This architecture chart was discussed in the Berlin arch workshop Jan. 21st 2025
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Additional notes
|
||||
|
||||
With respect to the meaning of 'Platform as a product' there are following notes to EDP as a product:
|
||||
|
||||
* Product items are
|
||||
1. EDP Foundry
|
||||
a) oppionated extreme, (aka 'locked down version')
|
||||
b) 'construction set' ('baukasten') extreme
|
||||
c) provide documentation
|
||||
2. all EDP's themsselves
|
||||
* 'product' in terms of a ciustomer view means two aspects:
|
||||
* they get it provisionned, i.e. we do the bootstrapping
|
||||
* they have it in maintenines state, i.w. we do the maintaining (compare to github: there is no github version to the customer!)
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
title: Concepts
|
||||
arrange:
|
||||
- overview.md
|
||||
- general
|
||||
- customer-developer
|
||||
- edp-developer
|
||||
|
Before Width: | Height: | Size: 154 KiB After Width: | Height: | Size: 154 KiB |
|
Before Width: | Height: | Size: 944 KiB After Width: | Height: | Size: 944 KiB |
|
Before Width: | Height: | Size: 160 KiB After Width: | Height: | Size: 160 KiB |
|
Before Width: | Height: | Size: 732 KiB After Width: | Height: | Size: 732 KiB |
|
Before Width: | Height: | Size: 554 KiB After Width: | Height: | Size: 554 KiB |
|
Before Width: | Height: | Size: 1.3 MiB After Width: | Height: | Size: 1.3 MiB |
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 113 KiB After Width: | Height: | Size: 113 KiB |
|
Before Width: | Height: | Size: 364 KiB After Width: | Height: | Size: 364 KiB |
|
Before Width: | Height: | Size: 208 KiB After Width: | Height: | Size: 208 KiB |
|
|
@ -1,8 +1,7 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Concepts
|
||||
weight: 1
|
||||
description: The underlying platforming concepts of the Edge Developer Framework (EDF) solution, i.e. the problem domain
|
||||
---
|
||||
|
||||
The underlying platforming concepts of the Edge Developer Framework (EDF) solution, i.e. the problem domain
|
||||
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
title: edgeDeveloper Framework
|
||||
arrange:
|
||||
- storyline.md
|
||||
- introduction.md
|
||||
- edge-developer-framework.md
|
||||
- platforming.md
|
||||
- orchestrators.md
|
||||
- cnoe.md
|
||||
- cnoe-showtime.md
|
||||
- conclusio.md
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
{
|
||||
"name": "project-management"
|
||||
}
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
title: General Concepts
|
||||
weight: 1
|
||||
description: The underlying platforming concepts of the Edge Developer Framework (EDF) solution, i.e. the problem domain
|
||||
---
|
||||
|
||||
The underlying platforming concepts of the Edge Developer Framework (EDF) solution, i.e. the problem domain
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
## CNOE Backstage commit history
|
||||
|
||||
This page describes the features and changes added to CNOE Backstage, along with a brief summary of what was done in each commit.
|
||||
Commits and changes that are important for implementation of the EDP Backstage will be marked with <span style="color:red"> red </span> color and commits
|
||||
that may be relevant, but not in priority, will be marked with <span style="color:green"> green </span> color. Commits are listed from newest to oldest.
|
||||
|
||||
|
||||
### <span style="color:green">№19. Commit name: Imported roadiehq http request plugin </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/135c0cb26f3e004a27a11edb6a4779035aff9805)<br>
|
||||
This commit adds the `@roadiehq/scaffolder-backend-module-http-request` plugin. This plugin provides Scaffolder actions
|
||||
that allow sending web requests within Backstage templates.
|
||||
|
||||
[Description and usage examples](https://roadie.io/backstage/plugins/scaffolder-http-requests/)
|
||||
|
||||
[RoadieHQ's Backstage plugins repository](https://github.com/RoadieHQ/roadie-backstage-plugins)
|
||||
|
||||
#### Code changes:
|
||||
The dependency was added to `package.json`:
|
||||
```
|
||||
"@roadiehq/scaffolder-backend-module-http-request": "^4.3.5"
|
||||
```
|
||||
|
||||
This means the project now includes this module and can import it in the code.
|
||||
|
||||
The module was registered in `packages/backend/src/index.ts`:
|
||||
|
||||
```
|
||||
backend.add(
|
||||
import('@roadiehq/scaffolder-backend-module-http-request/new-backend'),
|
||||
);
|
||||
```
|
||||
|
||||
This integrates the module into the Backstage backend.
|
||||
|
||||
<span style="color:green">This commit introduces functionality that may be useful for extending our Backstage templates with web request capabilities </span>
|
||||
|
||||
### №18. Commit name: add mkdoc to docker image
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/9232d633b2698fffa6d0a73b715e06640d170162)<br>
|
||||
In this commit, several changes were made to the Dockerfile:
|
||||
1. Mkdoc was added to the Dockerfile as part of the build process, enabling seamless integration for generating and managing project documentation during the containerization process. [Information about mkdocs](https://www.mkdocs.org/)
|
||||
2. Refactoring of the Dockerfile. Optimization of the build structure
|
||||
|
||||
### №17. Commit name: move argo workflows to ci/cd tab. remove unused components
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/e8b84831e99f13033beb11530149fbb24d846f29)<br>
|
||||
In this commit no new functionality was added. Refactoring commit
|
||||
|
||||
### №16. Commit name: Updated argoworkflows to query workflows based on component annotation
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/5f3a54f571ea6f210ebb3418611e1ac4e6e3e7c5)<br>
|
||||
This commit is mostly refactoring
|
||||
1. Refined the structure of the `argoWorkflowsPlugin` by updating `createPlugin` and `createRoutableExtension` definitions. <br>Files changed: `plugins/argo-workflows/src/plugin.ts` and `plugins/argo-workflows/src/api/index.ts`
|
||||
|
||||
2. Reformatted and standardized code style
|
||||
|
||||
|
||||
### <span style="color:green">№15. Commit name: Extended plugin to support more k8s objects </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/2cde0a09caf55fe907463b0b8b4a6321482b322e)<br>
|
||||
This commit contains improvements to the plugin for working with k8s. All changes are in file `packages/backend/src/plugins/k8s-apply.ts`
|
||||
#### Changes:
|
||||
1. <b>Manifest Handling Optimization</b>. Simplified writing manifest to file based on input type (string or object).
|
||||
2. <b>Support for Multiple Manifests</b>. Writes each manifest from a list to a separate file with a unique name.
|
||||
3. <b>Kubernetes Config Generation</b>. Adds logic for creating Kubernetes config with server, certificate, and token details.
|
||||
4. <b>kubectl Command Execution</b>. Executes kubectl apply or kubectl create for each manifest in the list.
|
||||
5. <b>Error Handling</b>. Throws an error if a valid cluster name is not specified.
|
||||
|
||||
### №14. Commit name: Fix for k8s-apply plugin config issue
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/6329ea80b1b0bb2e22f78333ae6462f147e1f4a1)<br>
|
||||
This commit contains fixes to the plugin for working with k8s. All changes are in file `packages/backend/src/plugins/k8s-apply.ts`
|
||||
|
||||
### <span style="color:red"> №13. Commit name: bump backstage version to 1.28.4 </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/db5d40f2848aaa8ca22a15fbdb7a06cfd986a162)<br>
|
||||
In this commit, the Backstage version for the build was updated. Along with this, the dependency versions in the
|
||||
package.json files for Backstage, the Backstage backend, and for the custom CNOE plugins (appache-spark, argo-workflows, cnoe-ui, terraform-backend, and terraform) were also updated.
|
||||
Additionally, in some places, the plugin imports were replaced with the current ones, such as in the file `packages/app/src/App.tsx`.
|
||||
|
||||
<span style="color:red">This commit is important, because here is an example of the update of the backstage version and actualizing of the dependencies </span>
|
||||
|
||||
### №12. Commit name: fix typos
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/6f1e1764859ad29c042b9ed015cc71cd8dcc6543)<br>
|
||||
This commit contains only fixes of the typos.
|
||||
|
||||
### №11. Commit name: add actions for PRs
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/2361b299f2291f55062fde61afd06dbf9542fbef)<br>
|
||||
Added `.github/workflows/pr.yaml` defining actions to run on pull request events. The workflow includes steps for checking out the repository, setting up Node.js, installing dependencies, and running TypeScript checks.
|
||||
|
||||
### №10. Commit name: fix tsc errors
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/d328b6986b4721b31c606e1da3ba93afce1864b7)<br>
|
||||
Bugfixes and improvements of the logging and tests for the custom `terraform-backend` plugin of the CNOE.
|
||||
|
||||
### №9. Commit name: Add terraform plugin into backstage-app
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/10b78fca7a474b24b5e8124697a01bdf76b152ca)<br>
|
||||
In this commit, Terraform was integrated into CNOE Backstage. To achieve this, two custom plugins, `terraform` and `terraform-backend`, were created in the `/plugins` directory.
|
||||
|
||||
#### The following steps were taken to integrate these plugins into Backstage:
|
||||
1. The Terraform plugin was added as an internal dependency (`"@internal/plugin-terraform"`) in the project's dependencies file (`packages/app/package.json`).
|
||||
2. In `packages/app/src/App.tsx`, the Terraform Page component was imported from the plugin, and a route for this page was created with the path `/terraform`.
|
||||
3. In the entity page component (`packages/app/src/components/catalog/EntityPage.tsx`), the Terraform plugin component was imported and integrated.
|
||||
4. The Terraform backend plugin (`"@internal/backstage-plugin-terraform-backend"`) was added as an internal dependency in the Backstage backend dependencies file (`packages/backend/package.json`).
|
||||
5. In the Backstage backend creation file (`packages/backend/src/index.ts`), the plugin was imported and added to the backend object.
|
||||
|
||||
### <span style="color:red"> №8. Commit name: upgrade to backstage 1.26.5 </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/c2ff2abd11c6f719c51b50d04878b108ba70d40e)<br>
|
||||
The name of this commit is misleading because, in addition to updating the Backstage version and actualizing dependency files and imports, several other changes were made.
|
||||
#### Changes besides version update:
|
||||
1. Fully rewritten Backstage backend creation (`packages/backend/src/index.ts`). After the changes, the backend is now created using the createBackend function from the `@backstage/backend-defaults` plugin.
|
||||
|
||||
2. <span style="color:red"> Keycloak OIDC </span> <br>The authentication mechanism has been rewritten using Keycloak OIDC (<span style="color:red">file location: packages/backend/src/plugins/auth.ts</span>). The object responsible for authentication is named `authModuleKeycloakOIDCProvider`.
|
||||
|
||||
3. <span style="color:red"> Custom CNOE Scaffolder Actions (for Gitea and ArgoCD) </span> <br> Mechanism for creating and adding custom CNOE Scaffolder Actions, which are used as actions for Backstage templates, has been rewritten (<span style="color:red">file location: packages/backend/src/plugins/scaffolder.ts</span>)
|
||||
|
||||
<span style="color:red">This commit is important, because here we can find locations of the CNOE custom actions for templates and implemintation of the keycloak auth for Backstage </span>
|
||||
|
||||
### №7. Commit name: update readme
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/b8e4f08914af17a48ed6b8b83a3621a9f4b4181d)<br>
|
||||
In this commit only README was updated
|
||||
|
||||
### <span style="color:green"> №6. Commit name: use cnoe theme </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/12eef8100d2521a6f665ef603ebe8196b12c8e96)<br>
|
||||
|
||||
In this commit design of user interface was updated and integrated into the Backstage app
|
||||
#### Changes:
|
||||
1. Interface styles were update in plugin cnoe-ui in files: `plugins/cnoe-ui/src/components/themes/light-theme.ts` and `plugins/cnoe-ui/src/components/themes/dark-theme.ts`
|
||||
2. UI style is connected to Backstage in file `packages/app/src/App.tsx`
|
||||
3. Routs to CNOE logo for interface are created in file `packages/app/src/components/Root/Root.tsx`
|
||||
|
||||
<span style="color:green"> This commit could be intersting for the team, because here we can see how to connect custom ui to backstage and how to remove CNOE logo </span>
|
||||
|
||||
### <span style="color:red"> №5. Commit name: Add workflow to automate backstage builds </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/9ee3514e51c1a354b7fe85a90117faf8328bfa0b)<br>
|
||||
In this commit were added github workflow for building backstage image and Dockerfile (files: `.github/workflows/build-and-push.yaml` and `Dockerfile`)
|
||||
|
||||
### <span style="color:red"> №4. Commit name: Include plugin scaffolder actions directly in src </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/139a3674c035bfe9f486f50aa8cb3deee8b25fd5)<br>
|
||||
#### Changes:
|
||||
1. Test Backstage templates were created
|
||||
2. `k8s-apply` plugin were added to backend of the Backstage (file: `packages/backend/src/plugins/k8s-apply.ts`)
|
||||
3. `sanitize` plugin were added to backend of the Backstage (file: `packages/backend/src/plugins/sanitize.ts`)
|
||||
4. `scaffolder` plugin were added to backend of the Backstage (file: `packages/backend/src/plugins/scaffolder.ts`)
|
||||
5. `verify` plugin were added to backend of the Backstage (file: `packages/backend/src/plugins/verify.ts`
|
||||
|
||||
<span style="color:red">This commit is important, because we will need scaffolder plugin in EDP backstage for using actions in backstage templates</span>
|
||||
### <span style="color:red"> №3. Commit name: working integrations </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/4b61eaef5920da8b0110af8e6f2997354b8af63a)<br>
|
||||
#### Changes:
|
||||
1. Created custom CNOE plugin for integration with apache-spark (`/plugins/appache-spark`)
|
||||
2. Created custom CNOE plugin for integration with apache-spark (`/plugins/argo-workflows`)
|
||||
3. Created custom CNOE plugin for integration with apache-spark (`/plugins/cnoe-ui`)
|
||||
4. In Backstage backend in file with custom gitea actions (<span style="color:red"> packages/backend/src/plugins/gitea-actions.ts </span>) were commented out: <span style="color:green">checkGiteaContentUrl, checkDurationLimit and checkAvailabilityGiteaRepository </span>
|
||||
5. Integration with ArgoCD was added into backend of the Backstage as a backend plugin (<span style="color:red"> packages/backend/src/plugins/argocd.ts</span>)
|
||||
6. In `packages/app/src/App.tsx` `argo-workflows plugin` and `apache-spark` plugin were integrated into Backstage and routs for their pages were created
|
||||
7. To the backstage component for the catalog items (`packages/app/src/components/catalog/EntityPage.tsx`) were integrated components from `argo-wrkflows` plugin. <br> <span style="color:red"> And was added component EntityArgoCDOverviewCard from @roadiehq/backstage-plugin-argo-cd which is a visual component for showing ArgoCD status of the catalog items, which are registered in ArgoCD.</span> [Link to plugin's repo](https://github.com/RoadieHQ/roadie-backstage-plugins/tree/main/plugins/frontend/backstage-plugin-argo-cd).
|
||||
8. New plugins were added to the dependencies
|
||||
|
||||
<span style="color:red">This commit is important, because here we can find an implementation of the ArgoCD plugin for the Backstage backend and how it's integrated to a backstage. And here we can see integration of the component for showing ArgoCD status from @roadiehq/backstage-plugin-argo-cd plugin
|
||||
|
||||
### <span style="color:red"> №2. Commit name: working gitea scaffolding </span>
|
||||
[Link to a commit](https://github.com/cnoe-io/backstage-app/commit/fe842bed997f317979da7fd42093bc62b3e491b7)<br>
|
||||
#### Changes:
|
||||
1. Implemented integration with gitea (<span style="color:red">file: packages/backend/src/plugins/gitea-actions.ts</span>)
|
||||
2. Implemented integration with the kubernetes (<span style="color:red">file: packages/backend/src/plugins/kubernetes.ts</span>)
|
||||
|
||||
<span style="color:red">This commit is important, because here was implemented gitea and kubernetes integration that should be ported to EDP Backstage</span>
|
||||
### №1. Commit name: Initial commit
|
||||
|
||||
|
|
@ -1,103 +0,0 @@
|
|||
---
|
||||
title: Backstage Update Tutorial
|
||||
---
|
||||
|
||||
The first Backstage update was performed as described in the ticket https://jira.telekom-mms.com/browse/IPCEICIS-2299 from version 1.28 to version 1.36.1.
|
||||
|
||||
This document provides a detailed guide on the process to update Backstage locally on your machine from version 1.36.1 to 1.38.1.
|
||||
Later updates can be performed accordingly. (The fixing of deprecated imports should not be necessary, again.)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Prerequisites](#prerequisites)
|
||||
2. [Setting Up Backstage](#setting-up-backstage)
|
||||
3. [Updating Backstage](#updating-backstage)
|
||||
4. [Fix deprecated import](#fix-deprecated-import)
|
||||
5. [Running Backstage](#running-backstage)
|
||||
|
||||
## Prerequisites <a name="prerequisites"></a>
|
||||
|
||||
Before you start, make sure you have the following installed on your machine:
|
||||
|
||||
1. **Node.js**: Backstage requires Node.js. You can download it from the [Node.js website](https://nodejs.org/).
|
||||
2. **Yarn**: Backstage uses Yarn as its package manager.
|
||||
3. **Git**
|
||||
4. **Docker**
|
||||
|
||||
## Setting Up Backstage <a name="setting-up-backstage"></a>
|
||||
|
||||
To download the latest version of our Backstage-EDP app, use git to clone it from the OSC repository at https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/backstage-edp.git.
|
||||
|
||||
Make sure yarn ist installed locally. If it hasn't been installed yet, run in the project path:
|
||||
```bash
|
||||
yarn install
|
||||
```
|
||||
|
||||
## Updating Backstage <a name="updating-backstage"></a>
|
||||
|
||||
In the project path run:
|
||||
```bash
|
||||
yarn backstage-cli versions:bump
|
||||
```
|
||||
|
||||
This will update all relevant components to the newest versions.
|
||||
|
||||
## Fix deprecated import <a name="fix-deprecated-import"></a>
|
||||
|
||||
In a text editor of your choice open the file <I>'/backstage-edp/packages/backend/src/plugins/proxy.ts'</I> and implement the two following changes.
|
||||
|
||||
### Update import
|
||||
|
||||
First (due to changes in the library) replace the deprecated import
|
||||
|
||||
```typescript
|
||||
import { createRouter } from '@backstage/plugin-proxy-backend';
|
||||
```
|
||||
|
||||
with the following import:
|
||||
|
||||
```typescript
|
||||
import { createRouter } from '@roadiehq/backstage-plugin-argo-cd-backend';
|
||||
```
|
||||
|
||||
### Update method call createRouter()
|
||||
|
||||
Secondly (due to a changed signature) replace the <B>old</B> call of method createRouter()
|
||||
|
||||
```typescript
|
||||
return await createRouter({
|
||||
logger: env.logger,
|
||||
config: env.config,
|
||||
discovery: env.discovery
|
||||
});
|
||||
```
|
||||
|
||||
with the following <B>new</B> method call:
|
||||
|
||||
```typescript
|
||||
return await createRouter({
|
||||
logger: env.logger,
|
||||
config: env.config
|
||||
});
|
||||
```
|
||||
|
||||
## Running backstage <a name="running-backstage"></a>
|
||||
|
||||
After completing all updates and fixes, run backstage to verify everything was updated correctly.
|
||||
|
||||
In the project path run:
|
||||
```bash
|
||||
docker build --no-cache -t backstage-cnoe .
|
||||
```
|
||||
|
||||
Start the backend from a console:
|
||||
```bash
|
||||
yarn run start-backend
|
||||
```
|
||||
|
||||
Start the frontend from a console:
|
||||
```bash
|
||||
yarn run start
|
||||
```
|
||||
|
||||
The backstage frontend should now open in your browser.
|
||||
|
|
@ -1,149 +0,0 @@
|
|||
<mxfile host="app.diagrams.net" agent="Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0" version="26.1.0">
|
||||
<diagram name="Page-1" id="R-WNyvjY5vV_Vzrg3hek">
|
||||
<mxGraphModel dx="2534" dy="835" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1100" pageHeight="850" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-71" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="-20" y="10" width="1420" height="830" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-2" value="<font style="font-size: 20px;">Docker w</font><font style="font-size: 20px;">ithout service network</font>" style="text;strokeColor=none;fillColor=none;html=1;fontSize=24;fontStyle=1;verticalAlign=middle;align=left;" parent="1" vertex="1">
|
||||
<mxGeometry y="40" width="330" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-3" value="<font style="font-size: 16px;">./edpbuilder.sh --type kind --stacks all \<br>&nbsp; --domain factory-192-168-198-2.traefik.me \<br>&nbsp; --domain-gitea gitea-factory-192-168-198-2.traefik.me</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry y="170" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-7" value="<font style="font-size: 16px;">EDP</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry y="120" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-8" value="<font style="font-size: 16px;">192.168.198.2</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="180" y="120" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-12" value="<font style="font-size: 16px;">./docker-proxy-start.sh</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="350" y="170" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-13" value="<font style="font-size: 16px;">Docker Cache Proxy</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="350" y="120" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-14" value="<font style="font-size: 16px;">192.168.198.3</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="530" y="120" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-15" value="<font style="font-size: 16px;">./edpbuilder.sh --type kind --stacks core \<br>&nbsp; --domain factory-192-168-198-4.traefik.me \<br>&nbsp; --domain-gitea gitea-factory-192-168-198-4.traefik.me</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="170" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-16" value="<font style="font-size: 16px;">Foundry</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="120" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-17" value="<font style="font-size: 16px;">192.168.198.4</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="880" y="120" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-18" value="<font style="font-size: 16px;">./edpbuilder.sh --type kind --stacks all \<br>&nbsp; --domain factory-192-168-198-5.traefik.me \<br>&nbsp; --domain-gitea gitea-factory-192-168-198-5.traefik.me</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1050" y="170" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-19" value="<font style="font-size: 16px;">EDP</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1050" y="120" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-20" value="<font style="font-size: 16px;">192.168.198.5</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="1230" y="120" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-41" value="<font style="font-size: 20px;">Docker w</font><font style="font-size: 20px;">ith service network</font>" style="text;strokeColor=none;fillColor=none;html=1;fontSize=24;fontStyle=1;verticalAlign=middle;align=left;" parent="1" vertex="1">
|
||||
<mxGeometry y="320" width="330" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-42" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry y="450" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-43" value="<font style="font-size: 16px;">EDP</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry y="400" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-44" value="<font style="font-size: 16px;">192.168.198.2</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="180" y="400" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-45" value="<font style="font-size: 16px;">./docker-proxy-start.sh</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="350" y="450" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-46" value="<font style="font-size: 16px;">Docker Cache Proxy</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="350" y="400" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-47" value="<font style="font-size: 16px;">192.168.198.3</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="530" y="400" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-48" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="450" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-49" value="<font style="font-size: 16px;">Foundry</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="400" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-50" value="<font style="font-size: 16px;">192.168.198.4</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="880" y="400" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-51" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1050" y="450" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-52" value="<font style="font-size: 16px;">EDP</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="1050" y="400" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-53" value="<font style="font-size: 16px;">192.168.198.5</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="1230" y="400" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-54" value="<font style="font-size: 16px;">./edpbuilder.sh --type kind --stacks all \<br>&nbsp; --domain factory-192-168-197-3.traefik.me \<br>&nbsp; --domain-gitea gitea-factory-192-168-197-3.traefik.me</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="350" y="710" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-67" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" parent="1" source="PfNbgjtPqerxexKKpkkC-55" target="PfNbgjtPqerxexKKpkkC-42" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="530" y="590" />
|
||||
<mxPoint x="165" y="590" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-55" value="<font style="font-size: 16px;">EDP</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="350" y="660" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-56" value="<font style="font-size: 16px;">192.168.197.3</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="530" y="660" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-57" value="<font style="font-size: 16px;">./edpbuilder.sh --type kind --stacks&nbsp;</font><font style="font-size: 16px;">core</font><font style="font-size: 16px;"> \<br>&nbsp; --domain factory-192-168-197-2.traefik.me \<br>&nbsp; --domain-gitea gitea-factory-192-168-197-2.traefik.me</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry y="710" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-58" value="<font style="font-size: 16px;">Foundry</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry y="660" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-59" value="<font style="font-size: 16px;">192.168.197.2</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="180" y="660" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-60" value="<font style="font-size: 16px;">./edpbuilder.sh --type kind --stacks all \<br>&nbsp; --domain factory-192-168-197-4.traefik.me \<br>&nbsp; --domain-gitea gitea-factory-192-168-197-4.traefik.me</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="710" width="330" height="100" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-61" value="<font style="font-size: 16px;">EDP</font>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="660" width="180" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-66" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0;exitDx=0;exitDy=0;entryX=0.558;entryY=0.98;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="PfNbgjtPqerxexKKpkkC-62" target="PfNbgjtPqerxexKKpkkC-51" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="1230" y="560" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="880" y="640" />
|
||||
<mxPoint x="1234" y="640" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-62" value="<font style="font-size: 16px;">192.168.197.4</font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="880" y="660" width="150" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-68" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0;exitY=0;exitDx=0;exitDy=0;entryX=0.527;entryY=1.01;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" source="PfNbgjtPqerxexKKpkkC-59" target="PfNbgjtPqerxexKKpkkC-48" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="180" y="620" />
|
||||
<mxPoint x="874" y="620" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-69" value="<font style="font-size: 16px;">KIND Net <font>192.168.198.0/24</font></font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="860" y="10" width="270" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="PfNbgjtPqerxexKKpkkC-70" value="<font style="font-size: 16px;">Service Net <font>192.168.197.0/25</font></font>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="1130" y="10" width="270" height="50" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 146 KiB |
|
|
@ -1,198 +0,0 @@
|
|||
<mxfile host="app.diagrams.net" agent="Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0" version="26.1.0">
|
||||
<diagram name="Seite-1" id="1aZQnKV8tCKqu9HPROxU">
|
||||
<mxGraphModel dx="1434" dy="835" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="1169" pageHeight="827" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-1" value="<div><font style="font-size: 20px;">edpbuilder KIND Self-service Network</font></div>" style="text;strokeColor=none;fillColor=none;html=1;fontSize=24;fontStyle=1;verticalAlign=middle;align=center;" parent="1" vertex="1">
|
||||
<mxGeometry x="352" width="465" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-7" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="10" y="50" width="1150" height="650" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">Device</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-8">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="535" y="50" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-9" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="50" y="145" width="150" height="145" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-10" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="50" y="390" width="150" height="142.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-11" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="230" y="110" width="920" height="570" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">Virtual Machine</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-12">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="610" y="110" width="160" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-13" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="250" y="145" width="150" height="145" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-14" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="250" y="310" width="150" height="140" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-15" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="250" y="512.5" width="150" height="147.5" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-22" value="" style="endArrow=none;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-50" target="NgepU7C5GcFRt7vnx28o-52" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-23" value="Docker Service Network" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="480" y="292.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-24" value="<div>Docker Host</div><div>Network</div>" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="480" y="452.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-25" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-54" target="NgepU7C5GcFRt7vnx28o-23" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-26" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-52" target="NgepU7C5GcFRt7vnx28o-23" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-27" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-56" target="NgepU7C5GcFRt7vnx28o-24" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-28" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-45" target="NgepU7C5GcFRt7vnx28o-24" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-29" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="640" y="160" width="500" height="500" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">Docker</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-30">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="835" y="160" width="110" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-48" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="670" y="215" width="210" height="395" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-31" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="660" y="227.5" width="210" height="395" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">KIND Cluster</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-32">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="227.5" width="135" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-33" value="Service Net" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="700" y="292.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-34" value="<div>Docker KIND</div><div>Network</div>" style="rounded=1;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="955" y="512.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-35" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="910" y="267.5" width="210" height="180" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<div><font style="font-size: 16px;">Docker Proxy Cache</font></div>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-36">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="920" y="267.5" width="190" height="42.5" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-37" value="KIND Net" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="955" y="347.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-38" value="Host Port" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="705" y="402.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-39" value="KIND Net" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="705" y="512.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-40" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-39" target="NgepU7C5GcFRt7vnx28o-34" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-41" value="" style="endArrow=none;html=1;rounded=0;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-34" target="NgepU7C5GcFRt7vnx28o-37" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-42" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-24" target="NgepU7C5GcFRt7vnx28o-38" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-43" value="" style="endArrow=none;html=1;rounded=0;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="NgepU7C5GcFRt7vnx28o-23" target="NgepU7C5GcFRt7vnx28o-33" edge="1">
|
||||
<mxGeometry width="50" height="50" relative="1" as="geometry">
|
||||
<mxPoint x="740" y="350" as="sourcePoint" />
|
||||
<mxPoint x="790" y="300" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">kubectl</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-44">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="275" y="512.5" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-45" value="VM Host IP" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="265" y="572.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">Browser</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-49">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="75" y="145" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-50" value="VM IP" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#ffe6cc;strokeColor=#d79b00;" parent="1" vertex="1">
|
||||
<mxGeometry x="65" y="207.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">Tiny Proxy</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-51">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="270" y="145" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-52" value="Service Net" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="265" y="207.5" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">Browser</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-53">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="275" y="310" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-54" value="Service Net" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="265" y="370" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<UserObject label="<font style="font-size: 16px;">kubectl</font>" placeholders="1" name="Variable" id="NgepU7C5GcFRt7vnx28o-55">
|
||||
<mxCell style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;overflow=hidden;fontSize=20;" parent="1" vertex="1">
|
||||
<mxGeometry x="75" y="392.5" width="100" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</UserObject>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-56" value="VM IP" style="shape=process;whiteSpace=wrap;html=1;backgroundOutline=1;fillColor=#ffe6cc;strokeColor=#d79b00;" parent="1" vertex="1">
|
||||
<mxGeometry x="65" y="455" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-59" value="<div align="right">VM IP: e.g. 192.168.196.97</div>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#ffe6cc;strokeColor=#d79b00;" parent="1" vertex="1">
|
||||
<mxGeometry x="65" y="720" width="510" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-60" value="<div align="right">VM Host IP: 127.0.0.1, host.docker.internal</div>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" parent="1" vertex="1">
|
||||
<mxGeometry x="65" y="780" width="510" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-61" value="Service Net: static 192.168.197.0/25" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
|
||||
<mxGeometry x="595" y="720" width="510" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="NgepU7C5GcFRt7vnx28o-62" value="<div align="right">KIND Net: DHCP 192.168.198.0/24</div>" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
|
||||
<mxGeometry x="595" y="780" width="510" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 132 KiB |
|
|
@ -1,170 +0,0 @@
|
|||
# Host to Kind routing
|
||||
|
||||
When we subnetwork inside a VM (e.g. WSL), you won't get a connection from the host (e.g. Windows) to the kind network inside the VM.
|
||||
|
||||
### tldr;
|
||||
|
||||
Add a route in windows to your docker network (e.g. 192.168.199.0/24) over the vm network connector:
|
||||
```powershell
|
||||
# in windows admin mode
|
||||
|
||||
# 192.168.199.0/24: the network you want to route to, here: the dockernetwork inside vm
|
||||
# 172.29.216.239 : the router address which routes the above network, here: the gateway inside the vm to windows
|
||||
PS C:\Users\stl> route add 192.168.199.0/24 172.29.216.239
|
||||
```
|
||||
|
||||
#### Outcome
|
||||
|
||||
Now in windows you can reach Docker network addresses inside your VM:
|
||||
|
||||
```powershell
|
||||
PS C:\Users\stl> ping 192.168.199.33
|
||||
|
||||
Ping wird ausgeführt für 192.168.199.33 mit 32 Bytes Daten:
|
||||
Antwort von 192.168.199.33: Bytes=32 Zeit<1ms TTL=64
|
||||
```
|
||||
|
||||
## Intro
|
||||
|
||||
|
||||
So let' say you created a edp setup by
|
||||
|
||||
```bash
|
||||
# in WSL
|
||||
|
||||
$ ./edpbuilder.sh --type kind --stacks all --domain client-192-168-199-35.traefik.me --domain-gitea gitea-client-192-168-199-35.traefik.me
|
||||
```
|
||||
|
||||
you will not be able to send tcp/ip packets from the host (windows) to the kind network gateway, which is inside the docker network of your vm:
|
||||
|
||||
```powershell
|
||||
# in windows
|
||||
|
||||
PS C:\Users\stl> ping gitea-client-192-168-199-35.traefik.me
|
||||
|
||||
Ping wird ausgeführt für gitea-client-192-168-199-35.traefik.me [192.168.199.35] mit 32 Bytes Daten:
|
||||
Zeitüberschreitung der Anforderung.
|
||||
```
|
||||
|
||||
## Goal: Windows can access EDP
|
||||
|
||||
So what we want is a situation like the following:
|
||||
|
||||
In the following screenshot we have at left a browser in windows, and at the right a terminal in wsl. In both a request to `client-192-168-199-35.traefik.me`is working:
|
||||
|
||||
|
||||
|
||||
## Setup Route from windows to WSL
|
||||
|
||||
What we need is a route from windows to the docker containers inside the WSL.
|
||||
|
||||
So first check your docker network address:
|
||||
|
||||
```bash
|
||||
# in wsl
|
||||
|
||||
$ ip r
|
||||
default via 172.29.208.1 dev eth0 proto kernel
|
||||
172.29.208.0/20 dev eth0 proto kernel scope link src 172.29.216.239
|
||||
192.168.199.0/28 dev docker0 proto kernel scope link src 192.168.199.1
|
||||
192.168.199.32/27 dev br-8e96da84337e proto kernel scope link src 192.168.199.33
|
||||
```
|
||||
|
||||
What you see is
|
||||
|
||||
* the network connection to the host with the gateway `172.29.216.239`
|
||||
* the docker network `192.168.199.0/28` ranging from 192.168.199.1 to 192.168.199.14 (28 = 255.255.240.0)
|
||||
* and the kind network `192.168.199.32/27` ranging from 192.168.199.33 to 192.168.199.62 (27 = 255.255.224).
|
||||
|
||||
In Windows we see that the docker network is reachabel via gateway `172.29.208.1` which is inside network `172.29.208.0/20`:
|
||||
|
||||
```powershell
|
||||
PS C:\Users\stl> ipconfig
|
||||
...
|
||||
Ethernet-Adapter vEthernet (WSL):
|
||||
|
||||
Verbindungsspezifisches DNS-Suffix:
|
||||
IPv4-Adresse . . . . . . . . . . : 172.29.208.1
|
||||
Subnetzmaske . . . . . . . . . . : 255.255.240.0
|
||||
Standardgateway . . . . . . . . . :
|
||||
...
|
||||
```
|
||||
|
||||
## add route
|
||||
|
||||
Now we add the route:
|
||||
|
||||
```powershell
|
||||
# in windows
|
||||
|
||||
PS C:\Users\stl> route add 192.168.199.0/24 172.29.216.239
|
||||
OK!
|
||||
```
|
||||
|
||||
and can check it with
|
||||
|
||||
```powershell
|
||||
# in windows
|
||||
|
||||
PS C:\Users\stl> route print
|
||||
...
|
||||
===========================================================================
|
||||
Aktive Routen:
|
||||
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
|
||||
0.0.0.0 0.0.0.0 10.34.216.1 10.34.219.176 25
|
||||
...
|
||||
192.168.199.0 255.255.255.0 172.29.216.239 172.29.208.1 16
|
||||
...
|
||||
===========================================================================
|
||||
```
|
||||
|
||||
and have network `192.168.199.0/24` to be routed by `172.29.216.239` over `172.29.208.1`.
|
||||
|
||||
## Test
|
||||
|
||||
Now you should be able to ping from windows to wsl:
|
||||
|
||||
```powershell
|
||||
# in windows, send ping
|
||||
|
||||
PS C:\Users\stl> ping gitea-client-192-168-199-35.traefik.me
|
||||
|
||||
Ping wird ausgeführt für gitea-client-192-168-199-35.traefik.me [192.168.199.35] mit 32 Bytes Daten:
|
||||
Antwort von 192.168.199.35: Bytes=32 Zeit<1ms TTL=63
|
||||
Antwort von 192.168.199.35: Bytes=32 Zeit<1ms TTL=63
|
||||
Antwort von 192.168.199.35: Bytes=32 Zeit<1ms TTL=63
|
||||
Antwort von 192.168.199.35: Bytes=32 Zeit<1ms TTL=63
|
||||
|
||||
Ping-Statistik für 192.168.199.35:
|
||||
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
|
||||
(0% Verlust),
|
||||
Ca. Zeitangaben in Millisek.:
|
||||
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
|
||||
```
|
||||
|
||||
```bash
|
||||
# in wsl, receive ping
|
||||
|
||||
tcpdump -n -i eth0 icmp and src host 172.29.208.1
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Trouble shooting
|
||||
|
||||
If icmp or http doesn't work check that a fw is off:
|
||||
|
||||
```bash
|
||||
# in wsl
|
||||
|
||||
sudo ufw diable
|
||||
```
|
||||
|
||||
Also be sure that ip forwarding is on in wsl:
|
||||
|
||||
```bash
|
||||
# in wsl
|
||||
|
||||
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
|
||||
|
||||
```
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 93 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 385 KiB |
|
|
@ -1,5 +0,0 @@
|
|||
# Local networking
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# Localdev Registry
|
||||
|
||||
This [repository](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW/localdev-registry) provides documentation and code for the usage of docker image pulling caching mechanisms.
|
||||
|
||||
## Overview: Usage scenarios
|
||||
|
||||
This are two mechanisms: Registry mirroring and registry proxying.
|
||||
While the first redirects image pull requests to a real registry clone serving OCI requests and thus behaves as a representative, the second justs caches HTTP responses and acts as an object cache speeding up traffic.
|
||||
|
||||
As we need these two mechanisms in two settings 'local kind' and 'local docker', there result four scenarios which need to be implemented:
|
||||
|
||||
1. kind-mirror
|
||||
1. kind-proxy-cache
|
||||
1. docker-mirror
|
||||
1. docker-proxy-cache
|
||||
|
||||
There is information about how to use and deploy these scenarios manually on the local box, and there is code for automating the deployment either by shell commands or in edpbuilder provissioning code.
|
||||
|
||||
## How to use this documentation
|
||||
|
||||
As of sprint 1, you can
|
||||
1. read the [conceptual overview](./1-registry-mirror-and-cache-proxy-theory.md)
|
||||
1. [set up one or a combination of the usage scenarions manually on your box](./2-registry-mirror-and-cache-proxy-manual-installation.md)
|
||||
|
||||
Additionally there is a documentation about ['hacking' a local mirror](./3-registry-mirror-and-cache-proxy-hacks.md), if you like to test the mirroring scenarios independently of external mirror registries.
|
||||
|
|
@ -1,200 +0,0 @@
|
|||
# Introduction
|
||||
|
||||
This documentation describes how docker/OCI image pulls on a local linux box can be configured to connect to mirrors or pull through cache proxies.
|
||||
|
||||
The audience is developers who want to have faster or more reliable pulls, and want to avoid rate limits from external registries.
|
||||
|
||||
## Overview
|
||||
|
||||
This documantation has three parts:
|
||||
|
||||
1. backgound, (docker) image basics - this file
|
||||
1. Installation of mirrors and caches
|
||||
1. some hacks, e.g. a local mirror
|
||||
|
||||
## It's all about Processes!
|
||||
|
||||
We talk about 'docker images' and the way we 'pull' them from 'registries'.
|
||||
|
||||
So let's first go one step back and think about the context we use these terms and why.
|
||||
|
||||
The reason is that we want to run containers as processes and that they somehow need to come into life, and images are very low level artifacts on top of running conatiners.
|
||||
|
||||
> This is our developer's intention! We want processes running our application code!
|
||||
|
||||
|
||||
|
||||
### Spawn processes by different stacks
|
||||
|
||||
The funny thing is that however you spawn a process you see it at the end as a normal linux process:
|
||||
|
||||
#### Run by a shell
|
||||
|
||||
```bash
|
||||
bash -c 'exec -a my-job-bash sleep infinity' &
|
||||
```
|
||||
|
||||
#### Run by Docker
|
||||
|
||||
```bash
|
||||
docker run --restart=always -d ubuntu bash -c 'exec -a my-job-docker sleep infinity'
|
||||
```
|
||||
|
||||
#### Run by Kubernetes
|
||||
|
||||
```bash
|
||||
kubectl run k8sjob --image=ubuntu -- bash -c 'exec -a my-job-k8s sleep infinity'
|
||||
```
|
||||
|
||||
#### Outcome
|
||||
|
||||
Your process list should look sth. like this ! :-)
|
||||
|
||||
```bash
|
||||
~ $ ps ax | grep myjob
|
||||
22529 pts/1 S 0:00 my-job-bash infinity
|
||||
23154 ? Ss+ 0:00 my-job-docker infinity
|
||||
24163 ? Ss 0:00 my-job-k8s infinity
|
||||
```
|
||||
|
||||
### Extra
|
||||
|
||||
Try to kill the jobs and look what happens!
|
||||
|
||||
## Container Images
|
||||
|
||||
In the case of the Docker and Kubernetes 'Orchestrating overhead' we need 'images' as a base for the runtime.
|
||||
|
||||
> Hint: You can analyze a local image with https://github.com/containers/skopeo
|
||||
|
||||
* https://earthly.dev/blog/docker-image-storage-on-host/
|
||||
* https://www.freecodecamp.org/news/where-are-docker-images-stored-docker-container-paths-explained/
|
||||
|
||||
```bash
|
||||
~ $ docker image ls
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
ubuntu latest a04dc4851cbc 3 weeks ago 78.1MB
|
||||
kindest/node latest 2d9b4b74084a 2 months ago 1.05GB
|
||||
ghcr.io/catthehacker/ubuntu act-latest 0fbcdbe238bf 2 months ago 1.47GB
|
||||
registry 2 282bd1664cf1 16 months ago 25.4MB
|
||||
ubuntu 18.04 f9a80a55f492 21 months ago 63.2MB
|
||||
act-actions-action1-dockeraction latest f9a80a55f492 21 months ago 63.2MB
|
||||
rpardini/docker-registry-proxy 0.6.2 6bbe4e47a504 4 years ago 12.3MB
|
||||
registry.k8s.io/pause latest 350b164e7ae1 10 years ago 240kB
|
||||
|
||||
~ $ docker exec -it cluster-with-registry-mirror-control-plane crictl image ls
|
||||
IMAGE TAG IMAGE ID SIZE
|
||||
docker.io/kindest/kindnetd v20241212-9f82dd49 d300845f67aeb 39MB
|
||||
docker.io/kindest/local-path-helper v20241212-8ac705d0 baa0d31514ee5 3.08MB
|
||||
docker.io/kindest/local-path-provisioner v20241212-8ac705d0 04b7d0b91e7e5 22.5MB
|
||||
docker.io/library/ubuntu latest a04dc4851cbcb 29.8MB
|
||||
registry.k8s.io/coredns/coredns v1.11.3 c69fa2e9cbf5f 18.6MB
|
||||
registry.k8s.io/etcd 3.5.16-0 a9e7e6b294baf 57.7MB
|
||||
registry.k8s.io/kube-apiserver-amd64 v1.32.0 73afaf82c9cc3 98MB
|
||||
registry.k8s.io/kube-apiserver v1.32.0 73afaf82c9cc3 98MB
|
||||
registry.k8s.io/kube-controller-manager-amd64 v1.32.0 f3548c6ff8a1e 90.8MB
|
||||
registry.k8s.io/kube-controller-manager v1.32.0 f3548c6ff8a1e 90.8MB
|
||||
registry.k8s.io/kube-proxy-amd64 v1.32.0 aa194712e698a 95.3MB
|
||||
registry.k8s.io/kube-proxy v1.32.0 aa194712e698a 95.3MB
|
||||
registry.k8s.io/kube-scheduler-amd64 v1.32.0 faaacead470c4 70.6MB
|
||||
registry.k8s.io/kube-scheduler v1.32.0 faaacead470c4 70.6MB
|
||||
registry.k8s.io/pause 3.10 873ed75102791 320kB
|
||||
```
|
||||
|
||||
### Distributable Images are stored in Registries
|
||||
|
||||
* Images which not have been built in the local host image store come from registries.
|
||||
* They are complex compounds where the parts are stored in a `image repository`.
|
||||
* For now it's not important how they are composed - we are just interested to understand how we pull them.
|
||||
* **The parts we are pulling is our subject to cache!**
|
||||
|
||||
|
||||
|
||||
### Image Name Syntax
|
||||
|
||||
The naming conventions are a bit fuzzy. The best definition is this one:
|
||||
|
||||
*`registry/namespace/repo:tag`*
|
||||
|
||||
|
||||
|
||||
## Engine
|
||||
|
||||
Next let's find out which components do the pull, so that we know what needs to be configured to use our mirror and caching components.
|
||||
|
||||
Images are prepared and processed by so called 'container engines', so that we have a running container at the end. These engines comply both to the OCI specification (for the underlying runtime), and secondly to the CRI spectification (for Kubernetes, to abstract away the container engine stuff).
|
||||
|
||||
### Different possibilities for the engine
|
||||
|
||||
<!--https://docs.google.com/presentation/d/1S-JqLQ4jatHwEBRUQRiA5WOuCwpTUnxl2d1qRUoTz5g p.37 -->
|
||||
|
||||
|
||||
## OCI/CRI stack
|
||||
|
||||
As we want to run kind and docker we focus on engines which are both Docker and Kubernetes compliant.
|
||||
|
||||
<!-- https://www.kreyman.de/index.php/others/linux-kubernetes/232-unterschiede-zwischen-docker-containerd-cri-o-und-runc -->
|
||||
|
||||
|
||||
This is possible by `containerd`, and then we have these two engine stacks with respect to Docker and Kubernetes:
|
||||
> Originally containerd came from Docker, but it has a Plugin called 'cri-shim'
|
||||
|
||||
### Docker - container engine stack
|
||||
|
||||
* dockerd - container daemon
|
||||
* containerd - high-level container runtime
|
||||
* runc - low-level container runtime
|
||||
|
||||
### Kubernetes - container engine stack
|
||||
|
||||
* option 1 CRI-O-based:
|
||||
* CRI-O - high-level container runtime
|
||||
* runc - low-level container runtime
|
||||
* option 2 containerd-based:
|
||||
* containerd - high-level container runtime
|
||||
* runc - low-level container runtime
|
||||
|
||||
The purposeful significance of containerd is also shown [in this even broader picture of tools and runtimes](https://sarusso.github.io/blog/container-engines-runtimes-orchestrators.html):
|
||||
|
||||
|
||||
|
||||
|
||||
### Kind uses containerd
|
||||
|
||||
The CRI part of the stack is implemented in our Kind and Docker case by containerd (and runc)
|
||||
|
||||
```bash
|
||||
~ $ k get nodes -o wide
|
||||
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
|
||||
cluster-with-registry-mirror-control-plane Ready control-plane 7h4m v1.32.0 172.18.0.4 <none> Debian GNU/Linux 12 (bookworm) 6.8.0-53-generic containerd://1.7.24
|
||||
```
|
||||
|
||||
### How this relates to images
|
||||
|
||||
As a side note: How the engine operates on images to pass it to the dring component `runc` is nicely shown here:
|
||||
|
||||
<!--https://docs.google.com/presentation/d/1S-JqLQ4jatHwEBRUQRiA5WOuCwpTUnxl2d1qRUoTz5g p.36 -->
|
||||
|
||||
|
||||
|
||||
## Outcome
|
||||
|
||||
In a local
|
||||
|
||||
* Linux host setup
|
||||
|
||||
with
|
||||
|
||||
* Kind-Kubernetes and
|
||||
* Docker
|
||||
|
||||
as container engines we can focus on dockerd and containerd when we want to handle image pulling.
|
||||
|
||||
We must also focus on dockerd (not only containerd, although it's also in der docker engine included) as dockerd overwrites the containerd mirror config.
|
||||
|
||||
## references
|
||||
|
||||
* https://collabnix.com/monitoring-containerd
|
||||
* https://github.com/containerd/containerd/blob/main/docs/cri/registry.md#configure-registry-credentials-example---gcr-with-service-account-key-authentication
|
||||
* https://medium.com/@charled.breteche/caching-docker-images-for-local-kind-clusters-252fac5434aa
|
||||
* https://maelvls.dev/docker-proxy-registry-kind/
|
||||
|
|
@ -1,256 +0,0 @@
|
|||
# Installation
|
||||
|
||||
This documentation describes how docker/OCI image pulls on a local linux box can be configured to connect to mirrors or pull through cache proxies.
|
||||
|
||||
The audience is developers who want to have faster or more reliable pulls, and want to avoid rate limits from external registries.
|
||||
|
||||
## Introduction
|
||||
|
||||
There are four different scenarios, which can be combined arbitrarily:
|
||||
|
||||
| Registry type | kind | docker |
|
||||
| --- | --- | --- |
|
||||
| mirror | scenario 1 | scenario 3 |
|
||||
| cache | scenario 2 | scenario 4 |
|
||||
|
||||
The scenarios can be combined arbitrarily, but when use use sceario 1 you shouldn't forget to also use the mirror in kind:
|
||||
|
||||
| combination | s2 (kind + cache) | s3 (docker + mirror) | s4 (docker + cache) |
|
||||
| --- | --- | --- | --- |
|
||||
| s1 (kind + mirror) | Mirror and Cache only for kind, you probably don't use docker too much | Both Docker and Kind are mirrored and dont have a cache | |
|
||||
| s2 (kind + cache) | | doesn't make sense without s1 | both kind and docker are cached and dont need a mirror, you probably are in free internet |
|
||||
| s3 (docker + mirror) | | | doesn't make sense without s1 |
|
||||
|
||||
## Preliminaries
|
||||
|
||||
We will need two container images stored in our container host repo before we do changes to the pull configuration.
|
||||
|
||||
So be sure that you have them already successfully pulled, or do it right now:
|
||||
|
||||
```bash
|
||||
# precondition: your current docker config is able to pull images from docker.io
|
||||
docker pull registry:2
|
||||
docker pull rpardini/docker-registry-proxy:0.6.2
|
||||
```
|
||||
|
||||
## Scenario 1: Registry Mirror on Kind for MMS company network
|
||||
|
||||
### What you need
|
||||
|
||||
You need to know the registries you want to mirror, and the address of the mirror, which here will be the MMS artifactory mirror. (remark: see in the last chapter for a test registry as mirror on your box.)
|
||||
|
||||
> Hint: Typically only 'docker.io' needs to be mirrored.
|
||||
|
||||
### Install
|
||||
|
||||
The installation is done by setting the `containerd` configuartion with a registry-mirror entry during kind setup.
|
||||
|
||||
```bash
|
||||
# in MMS:
|
||||
MIRROR_NAME=common-docker.artifacts.mms-at-work.de
|
||||
KIND_CLUSTER_NAME=cluster-with-registry-mirror
|
||||
```
|
||||
|
||||
In the follwing kind config we only mirror `docker.io`. You can append [as much mirror-entries as you want[(https://github.com/containerd/containerd/blob/main/docs/cri/registry.md#configure-registry-credentials-example---gcr-with-service-account-key-authentication)].
|
||||
|
||||
```bash
|
||||
cat <<EOF | kind create cluster --name $KIND_CLUSTER_NAME --config=-
|
||||
kind: Cluster
|
||||
apiVersion: kind.x-k8s.io/v1alpha4
|
||||
containerdConfigPatches:
|
||||
- |-
|
||||
[plugins."io.containerd.grpc.v1.cri"]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
|
||||
endpoint = ["${MIRROR_NAME}"]
|
||||
EOF
|
||||
```
|
||||
|
||||
> Hint: To get logs in info or debug level see section 'hacks'
|
||||
> Hint: You can also change to `containerd config in a running node. Then just restart the containerd with `systemctl restart containerd`
|
||||
|
||||
## Outcome
|
||||
|
||||
Now a typical company network blocker is removed - all containerd's (in every cluster node) knows how to bypass the Dockerhub rate limit by requetsing `docker.io` images first from the mirror:
|
||||
|
||||
)
|
||||
|
||||
The drawback is that you still need the bandwidth to the mirror. So if you are in homeoffice you still will pull each new image on each new kind cliuster creation over the network.
|
||||
|
||||
## Scenario 2: Registry Cache Proxy on Kind
|
||||
|
||||
Now it gets more tricky or let's say 'even more local': We will install a [cache proxy](`https://github.com/rpardini/docker-registry-proxy) as docker container process on our host.
|
||||
|
||||
### What you need
|
||||
|
||||
You need the [Caching proxy](`https://github.com/rpardini/docker-registry-proxy). We will install it on your node.
|
||||
|
||||
### Install
|
||||
|
||||
```bash
|
||||
CACHE_PROXY_NAME=docker_registry_proxy
|
||||
DOCKER_KIND_NETWORK=kind
|
||||
```
|
||||
|
||||
#### Caching Proxy
|
||||
|
||||
Run the caching proxy `https://github.com/rpardini/docker-registry-proxy`:
|
||||
|
||||
```bash
|
||||
# we start the caching proxy. It will also cache the mirror, if used
|
||||
# tip: this container is very long running and stores the cached data in a subfolder from your pwd.
|
||||
# So it's recommended to start it in a higher level folder.
|
||||
docker run -itd \
|
||||
--restart always \
|
||||
--name $CACHE_PROXY_NAME \
|
||||
--network $DOCKER_KIND_NETWORK \
|
||||
--hostname $CACHE_PROXY_NAME \
|
||||
-p 0.0.0.0:${HOST_PORT:-3128}:3128 \
|
||||
-e ENABLE_MANIFEST_CACHE=true \
|
||||
-v $(pwd)/docker_mirror_cache:/docker_mirror_cache \
|
||||
-v $(pwd)/docker_mirror_certs:/ca \
|
||||
-e REGISTRIES="$MIRROR_NAME k8s.gcr.io gcr.io quay.io docker.elastic.co" \
|
||||
rpardini/docker-registry-proxy:0.6.2
|
||||
```
|
||||
|
||||
#### Kind cluster
|
||||
|
||||
Next start your kind cluster if not running yet. You also can use the cluster from above with the mirror set.
|
||||
|
||||
> When you run a test registry mirror (see section 'hacks'), then you need either to provide the mirror's certificate inside the proxy server or you setup the proxy server with tls_no_verify (`-e VERIFY_SSL=false`). In the former everything will work as suspected, in the latter the mirror will complain about a missing TLS connectivity to the proxy.
|
||||
|
||||
#### Configure nodes of the Kind cluster
|
||||
|
||||
Now each node's `containerd` needs to be configured to use the Cache proxy on the host:
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
|
||||
# https://github.com/rpardini/docker-registry-proxy#kind-cluster
|
||||
|
||||
SETUP_URL=http://$CACHE_PROXY_NAME:3128/setup/systemd
|
||||
pids=""
|
||||
for NODE in $(kind get nodes --name "$KIND_CLUSTER_NAME"); do
|
||||
docker exec "$NODE" sh -c "\
|
||||
curl $SETUP_URL \
|
||||
| sed s/docker\.service/containerd\.service/g \
|
||||
| sed '/Environment/ s/$/ \"NO_PROXY=127.0.0.0\/8,10.0.0.0\/8,172.16.0.0\/12,192.168.0.0\/16\"/' \
|
||||
| bash" & pids="$pids $!" # Configure every node in background
|
||||
done
|
||||
wait $pids # Wait for all configurations to end
|
||||
```
|
||||
|
||||
## Outcome
|
||||
|
||||
As the proxy is configured all requests - either mirror or registry - go directly to the proxy.
|
||||
|
||||
The proxy checks whether first a mirror is to be connected if the image is not in the cache or is to be updated.
|
||||
|
||||
)
|
||||
|
||||
## Scenario 3: Registry Mirror on Docker
|
||||
|
||||
> Be aware that Docker only enables a mirror for `docker.io`
|
||||
|
||||
### What you need
|
||||
|
||||
You need to know he address of the mirror. Here we reuse the ${MIRROR_NAME} from scenario 2.
|
||||
|
||||
Only `docker.io` will be mirrored, this is a restriction of docker.
|
||||
|
||||
### Run
|
||||
|
||||
```bash
|
||||
# as root
|
||||
|
||||
cat << EOD > /etc/docker/daemon.json
|
||||
{
|
||||
"metrics-addr" : "127.0.0.1:9323",
|
||||
"experimental" : true,
|
||||
"features": { "buildkit": true },
|
||||
"registry-mirrors": ["${MIRROR_NAME}"],
|
||||
"insecure-registries" : []
|
||||
}
|
||||
EOD
|
||||
```
|
||||
|
||||
```bash
|
||||
# as root
|
||||
systemctl restart docker
|
||||
```
|
||||
|
||||
## Outcome
|
||||
|
||||
)
|
||||
|
||||
## Scenario 4: Registry Cache Proxy on Docker
|
||||
|
||||
Last not least we connect our hosts docker engine to the proxy cache.
|
||||
|
||||
### What you need
|
||||
|
||||
You need the Caching proxy. We will reuse it from scenario 2.
|
||||
|
||||
### Run
|
||||
|
||||
We run the same systemd-settings for containerd as we did for containerd in the kind nodes.
|
||||
|
||||
```bash
|
||||
# as root
|
||||
|
||||
mkdir -p /etc/systemd/system/docker.service.d
|
||||
cat << EOD > /etc/systemd/system/docker.service.d/http-proxy.conf
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://localhost:3128/"
|
||||
Environment="HTTPS_PROXY=http://localhost:3128/"
|
||||
Environment="NO_PROXY=localhost,127.0.0.1,gitea.poc.edp.localtest.me"
|
||||
EOD
|
||||
|
||||
curl http://localhost:3128/ca.crt > /usr/share/ca-certificates/docker_registry_proxy.crt
|
||||
|
||||
if fgrep -q "docker_registry_proxy.crt" /etc/ca-certificates.conf ; then
|
||||
echo "certificate refreshed"
|
||||
else
|
||||
echo "docker_registry_proxy.crt" >> /etc/ca-certificates.conf
|
||||
fi
|
||||
|
||||
update-ca-certificates --fresh
|
||||
```
|
||||
|
||||
Now reload and restart:
|
||||
|
||||
```bash
|
||||
# as root
|
||||
|
||||
systemctl daemon-reload
|
||||
systemctl restart docker
|
||||
```
|
||||
|
||||
## Outcome
|
||||
|
||||
As the proxy is configured all requests - either mirror or registry - go directly to the proxy.
|
||||
|
||||
The proxy checks whether first a mirror is to be connected if the image is not in the cache or is to be updated.
|
||||
|
||||
)
|
||||
|
||||
In the `docker info` output you see proxy and mirror setting:
|
||||
|
||||
```bash
|
||||
~ $ docker info
|
||||
Client: Docker Engine - Community
|
||||
Version: 27.0.2
|
||||
|
||||
Server:
|
||||
...
|
||||
|
||||
HTTP Proxy: http://localhost:3128/
|
||||
HTTPS Proxy: http://localhost:3128/
|
||||
No Proxy: localhost,127.0.0.1,gitea.poc.edp.localtest.me
|
||||
Experimental: true
|
||||
Insecure Registries:
|
||||
127.0.0.0/8
|
||||
Registry Mirrors:
|
||||
https://registry-1.docker.io.mirror.test/
|
||||
```
|
||||
|
|
@ -1,179 +0,0 @@
|
|||
# Hacks
|
||||
|
||||
This documentation describes how docker/OCI image pulls on a local linux box can be configured to connect to mirrors or pull through cache proxies.
|
||||
|
||||
The audience is developers who want to have faster or more reliable pulls, and want to avoid rate limits from external registries.
|
||||
|
||||
This part is called 'hacks' and describes some more hands-on components and investigations on the command line.
|
||||
|
||||
|
||||
## Create an own registry mirror to test a kind mirror setting
|
||||
|
||||
May be you don't have or need a mirror, but you would like to run all sceanrios of part 2 and thus need a local mirror.
|
||||
Or you would like to investigate the handshaking between mirror and cache and thus need the logs of the mirror.
|
||||
|
||||
```bash
|
||||
# the name of our mirror
|
||||
MIRROR_NAME=registry.docker.io.mirror.test
|
||||
# the mirror will be accessable by its host name in the kind network
|
||||
DOCKER_KIND_NETWORK=kind
|
||||
```
|
||||
|
||||
## The registry needs TLS
|
||||
|
||||
```bash
|
||||
# create a temporary directory
|
||||
mkdir registry-certs
|
||||
```
|
||||
|
||||
```bash
|
||||
# cert config
|
||||
cat <<EOF>openssl-${MIRROR_NAME}.cnf
|
||||
[req]
|
||||
default_bits = 2048
|
||||
default_keyfile = domain.key
|
||||
distinguished_name = req_distinguished_name
|
||||
x509_extensions = v3_ca
|
||||
req_extensions = v3_ca
|
||||
prompt = no
|
||||
|
||||
[req_distinguished_name]
|
||||
countryName = DE
|
||||
stateOrProvinceName = SomeState
|
||||
localityName = SomeCity
|
||||
organizationName = MyCompany
|
||||
organizationalUnitName = IT
|
||||
commonName = ${MIRROR_NAME}
|
||||
|
||||
[v3_ca]
|
||||
subjectAltName = @alt_names
|
||||
|
||||
[alt_names]
|
||||
DNS.1 = ${MIRROR_NAME}
|
||||
EOF
|
||||
```
|
||||
|
||||
```bash
|
||||
# create self signed cert
|
||||
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout registry-certs/${MIRROR_NAME}.key -out registry-certs/${MIRROR_NAME}.crt -config openssl-${MIRROR_NAME}.cnf
|
||||
```
|
||||
|
||||
### Now run the registry
|
||||
|
||||
```bash
|
||||
# run registry as mirror
|
||||
docker run -d \
|
||||
--name ${MIRROR_NAME} \
|
||||
--network $DOCKER_KIND_NETWORK \
|
||||
-p 443:443 \
|
||||
-v $(pwd)/registry-certs:/certs \
|
||||
-e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
|
||||
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/${MIRROR_NAME}.crt \
|
||||
-e REGISTRY_HTTP_TLS_KEY=/certs/${MIRROR_NAME}.key \
|
||||
-e REGISTRY_PROXY_REMOTEURL="https://registry-1.docker.io" \
|
||||
registry:2
|
||||
```
|
||||
|
||||
### Next run the kind cluster
|
||||
|
||||
```bash
|
||||
# create kind cluster
|
||||
cat <<EOF | kind create cluster --name cluster-with-registry-mirror --config=-
|
||||
kind: Cluster
|
||||
apiVersion: kind.x-k8s.io/v1alpha4
|
||||
containerdConfigPatches:
|
||||
- |-
|
||||
[plugins."io.containerd.grpc.v1.cri"]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
|
||||
endpoint = ["${MIRROR_NAME}"]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.configs]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.configs."${MIRROR_NAME}".tls]
|
||||
insecure_skip_verify = true
|
||||
EOF
|
||||
```
|
||||
|
||||
### Log the registry and do a deployment
|
||||
|
||||
```bash
|
||||
# in another terminal
|
||||
docker logs -f ${MIRROR_NAME}
|
||||
```
|
||||
|
||||
```bash
|
||||
# check images in the cluster before deployment
|
||||
docker exec -it cluster-with-registry-mirror-control-plane crictl image ls
|
||||
|
||||
# do deployment
|
||||
kubectl run busybox --image=busybox -- /bin/sh -c "sleep 3600"
|
||||
|
||||
# check images in the cluster again, you should see busybox
|
||||
docker exec -it cluster-with-registry-mirror-control-plane crictl image ls
|
||||
```
|
||||
|
||||
## journalctl
|
||||
|
||||
You also can check the containerd logs:
|
||||
|
||||
```bash
|
||||
docker exec -it cluster-with-registry-mirror-control-plane journalctl -u containerd
|
||||
```
|
||||
|
||||
See also:
|
||||
* Logging variants: https://www.baeldung.com/ops/containerd-check-logs
|
||||
* Monitoring containerd: https://collabnix.com/monitoring-containerd/
|
||||
|
||||
### debug journalctl
|
||||
|
||||
* https://gvisor.dev/docs/
|
||||
* https://gvisor.dev/docs/user_guide/containerd/configuration/
|
||||
|
||||
```bash
|
||||
cat <<EOF | kind create cluster --name cluster-with-registry-mirror --config=-
|
||||
kind: Cluster
|
||||
apiVersion: kind.x-k8s.io/v1alpha4
|
||||
containerdConfigPatches:
|
||||
- |-
|
||||
[debug]
|
||||
level="debug"
|
||||
[plugins."io.containerd.grpc.v1.cri"]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
|
||||
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
|
||||
endpoint = ["${MIRROR_NAME}"]
|
||||
EOF
|
||||
```
|
||||
|
||||
## Integrate registry proxy
|
||||
|
||||
If you have a running registry proxy which also proxies the mirror, e.g. started like
|
||||
|
||||
```bash
|
||||
CACHE_PROXY_NAME=docker_registry_proxy
|
||||
|
||||
docker run -itd \
|
||||
--restart always \
|
||||
--name $CACHE_PROXY_NAME \
|
||||
--network $DOCKER_KIND_NETWORK \
|
||||
--hostname $CACHE_PROXY_NAME \
|
||||
-p 0.0.0.0:${HOST_PORT:-3128}:3128 \
|
||||
-e ENABLE_MANIFEST_CACHE=true \
|
||||
-v $(pwd)/docker_mirror_cache:/docker_mirror_cache \
|
||||
-v $(pwd)/docker_mirror_certs:/ca \
|
||||
-e REGISTRIES="$MIRROR_NAME k8s.gcr.io gcr.io quay.io docker.elastic.co" \
|
||||
rpardini/docker-registry-proxy:0.6.2
|
||||
```
|
||||
|
||||
then you need to make the proxy aware of the mirror's certificate.
|
||||
|
||||
### set mirror ca in proxy
|
||||
|
||||
The proxy is ssl veryfying upstreams. So we need to place the ca of the mirror.
|
||||
|
||||
```bash
|
||||
docker cp registry-certs/registry-1.docker.io.mirror.test.crt docker_registry_proxy:/
|
||||
docker exec -it docker_registry_proxy bash -c 'cat /registry-1.docker.io.mirror.test.crt >> /etc/ssl/certs/ca-certificates.crt'
|
||||
docker exec -it docker_registry_proxy bash -c 'kill -SIGHUP $(cat /run/nginx.pid)'
|
||||
|
||||
```
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 355 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 146 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 473 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 505 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 521 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 551 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 485 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 459 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 184 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 159 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Project
|
||||
weight: 5
|
||||
description: How we organize work and proceed as team, which decisions we made, what outputs and outcomes we have
|
||||
---
|
||||
|
||||
How we organize work and proceed as team, which decisions we made, what outputs and outcomes we have
|
||||
|
|
@ -18,7 +18,7 @@ Let's start with a look into the history of platform engineering. A good startin
|
|||
|
||||
They create lots of [beautiful articles and insights](https://humanitec.com/blog), their own [platform products](https://humanitec.com/products/) and [basic concepts for the platform architecture](https://humanitec.com/platform-engineering) (we'll meet this later on!).
|
||||
|
||||
<img src="./3_platforming/humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
|
||||
<img src="./humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
|
||||
|
||||
|
||||
### Further nice reference to the raise of platforms
|
||||
|
|
@ -41,7 +41,7 @@ When looking at these 'capabilities', we have CNCF itself:
|
|||
|
||||
There is a CNCF working group which provides the definition of [Capabilities of platforms](https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms) and shows a first idea of the layered architecture of platforms as **service layer for developers** ("product and application teams"):
|
||||
|
||||
<img src="./3_platforming/platforms-def.drawio.png" width="600">
|
||||
<img src="./platforms-def.drawio.png" width="600">
|
||||
|
||||
|
||||
> Important: As Platform engineer also notice the [platform-eng-maturity-model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/)
|
||||
|
|
@ -50,7 +50,7 @@ There is a CNCF working group which provides the definition of [Capabilities of
|
|||
|
||||
Or, in another illustration for the platform as a developer service interface, which also defines the **'Platform Engineering Team'** inbetween:
|
||||
|
||||
<img src="./3_platforming/platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
|
||||
<img src="./platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
|
||||
|
||||
## How to set up Platforms
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ Build or buy - this is also in pltaform engineering a tweaked discussion, which
|
|||
{{% pageinfo color="info" %}}
|
||||
### What comes next?
|
||||
|
||||
[Next](./orchestrators.md) we'll see how these concepts got structured!
|
||||
[Next](../orchestrators/) we'll see how these concepts got structured!
|
||||
{{% /pageinfo %}}
|
||||
|
||||
## Addendum
|
||||
|
Before Width: | Height: | Size: 904 KiB After Width: | Height: | Size: 904 KiB |
|
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 160 KiB After Width: | Height: | Size: 160 KiB |
|
Before Width: | Height: | Size: 600 KiB After Width: | Height: | Size: 600 KiB |
|
|
@ -6,8 +6,7 @@ description: Next level platforming is orchestrating platforms
|
|||
|
||||
## Summary
|
||||
|
||||
When defining and setting up platforms next two intrinsic problems arise:
|
||||
|
||||
When defining and setting up platforms next two intrinsic problems arise:
|
||||
1. it is not declarative and automated
|
||||
2. it is not or least not easily changable
|
||||
|
||||
|
|
@ -22,7 +21,7 @@ This is something extremely new since late 2023 - the rise of the automation of
|
|||
|
||||
It was Humanitec creating a definition of platform architecture, as they needed to defien what they are building with their 'orchestrator':
|
||||
|
||||
|
||||
<img src="./vendor-neutral-idp-final.gif" width="600" alt="https://developer.humanitec.com/introduction/overview/">
|
||||
|
||||
## Declarative Platform Orchestration
|
||||
|
||||
|
|
@ -30,13 +29,16 @@ Based on the refence architecture you next can build - or let's say 'orchestrate
|
|||
|
||||
https://humanitec.com/reference-architectures
|
||||
|
||||
|
||||
|
||||
<img src="./platform-architectures.webp" width="600" alt="https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp">
|
||||
|
||||
> Hint: There is a [slides tool provided by McKinsey](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures) to set up your own platform deign based on the reference architecture
|
||||
|
||||
> What comes next?
|
||||
> [Next](./cnoe.md) we'll see how we are going to do platform orchestration with CNOE!
|
||||
|
||||
{{% pageinfo color="info" %}}
|
||||
### What comes next?
|
||||
|
||||
[Next](../cnoe/) we'll see how we are going to do platform orchestration with CNOE!
|
||||
{{% /pageinfo %}}
|
||||
|
||||
## Addendum
|
||||
|
||||
|
|
@ -44,4 +46,6 @@ https://humanitec.com/reference-architectures
|
|||
|
||||
You remember the [capability mappings from the time before orchestration](../platforming)? Here we have a [similar setup based on Humanitecs platform engineering status ewhite paper](https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2):
|
||||
|
||||
|
||||
<img src="./platform-tooling-humanitec-platform-report-2024.PNG" width="600" alt="https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf">
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 98 KiB After Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 723 KiB After Width: | Height: | Size: 723 KiB |
|
Before Width: | Height: | Size: 397 KiB After Width: | Height: | Size: 397 KiB |
|
Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 63 KiB |
|
Before Width: | Height: | Size: 167 KiB After Width: | Height: | Size: 167 KiB |
|
Before Width: | Height: | Size: 120 KiB After Width: | Height: | Size: 120 KiB |
|
Before Width: | Height: | Size: 174 KiB After Width: | Height: | Size: 174 KiB |
|
Before Width: | Height: | Size: 196 KiB After Width: | Height: | Size: 196 KiB |
|
Before Width: | Height: | Size: 188 KiB After Width: | Height: | Size: 188 KiB |
|
Before Width: | Height: | Size: 243 KiB After Width: | Height: | Size: 243 KiB |
|
Before Width: | Height: | Size: 79 KiB After Width: | Height: | Size: 79 KiB |
|
Before Width: | Height: | Size: 275 KiB After Width: | Height: | Size: 275 KiB |
|
Before Width: | Height: | Size: 190 KiB After Width: | Height: | Size: 190 KiB |
|
Before Width: | Height: | Size: 66 KiB After Width: | Height: | Size: 66 KiB |
|
Before Width: | Height: | Size: 207 KiB After Width: | Height: | Size: 207 KiB |
|
Before Width: | Height: | Size: 397 KiB After Width: | Height: | Size: 397 KiB |
|
Before Width: | Height: | Size: 137 KiB After Width: | Height: | Size: 137 KiB |
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue