You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The chart-index Helm chart allows to manage most of the APL helm chart dependencies (a.k.a. core apps).
2
+
The chart-index is so-called library Helm chart and cannot be installed by itself. It only defines dependencies in the `chart/chart-index/Chart.yaml` file. Each dependency follows the following format:
3
+
```
4
+
- name: <chart name>
5
+
version: <chart version>
6
+
repository: <chart url>
7
+
```
8
+
,thus Helm knows the chart registry URL, chart name and version.
9
+
10
+
In the future, the chart-index is going to be combined with Renovate to discover new versions.
11
+
12
+
Currently, adding a new version of the core app is performed manually:
13
+
1. In the `chart/chart-index/Chart.yaml` file, change a given version in the `dependencies` list.
14
+
2. Call `npm run charts-update`, so Helm charts archives are downloaded to the `charts/` directory
15
+
3. In charts directory unpack the archive to the corresponding directory
16
+
4. Commit your changes: git commit -m'feat: chart upgrade <app-name>'
17
+
5. Perform smoke tests `npm run validate-templates`
18
+
6. Carefully compare the rendered manifests (your feature branch vs main) by executing `bin/compare.sh`
19
+
20
+
21
+
Note 1: some Helm charts do not have an official Helm chart repository. Those helm charts cannot be upgraded via the `chart-index`.
22
+
Note 2: some charts resides in different directory name than the original app name, e.g.: argo-cd app resides in charts/argocd directory
Copy file name to clipboardExpand all lines: docs/development.md
+21-21
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ Effective development starts with an understanding the code structure and the re
9
9
-[Integrating core apps](#Integrating-core-apps)
10
10
-[Working with the team-ns chart](#working-with-the-team-ns-chart)
11
11
-[Testing](#testing)
12
-
-[Otomi CLI](#otomi-cli)
12
+
-[APL CLI](#otomi-cli)
13
13
-[Troubleshooting](#troubleshooting)
14
14
15
15
# Navigating through code
@@ -20,21 +20,21 @@ Effective development starts with an understanding the code structure and the re
20
20
apl-core
21
21
├── .values # Boilerplate for initializing git repository
22
22
├── adr # Architectural Decision Records [read more](https://adr.github.io/madr/)
23
-
├── bin # Otomi CLI entrypoint (deprecated)
24
-
├── binzx # Otomi CLI entrypoint
25
-
├── chart # Helm chart for installing Otomi
26
-
├── charts # All other Helm charts that comprise Otomi
23
+
├── bin # APL CLI entrypoint (deprecated)
24
+
├── binzx # APL CLI entrypoint
25
+
├── chart # Helm chart for installing APL and upgrading APL Helm charts
26
+
├── charts # All other Helm charts that comprise APL
27
27
├── docs # Documentation
28
28
├── helmfile.d/helmfile-*.yaml # Helmfile specs ordered by name and executed accordingly by otomi commands
29
29
├── helmfile.d/snippets # Reusable code snippets
30
30
├── helmfile.tpl # Additional Helmfiles that do not have corresponding chart and are not parsed on otomi apply|template command
31
31
├── k8s # Kubernetes manifests that before any other chart
32
-
├── src # Otomi CLI source code
32
+
├── src # APL CLI source code
33
33
├── tests # Values used for testing purposes
34
34
├── upgrades.yaml # Upgrade presync hooks
35
35
├── values # Value templates that serves as input to corresponding Helm charts
36
36
├── values-changes.yaml # Definitions for performing data migrations
37
-
├── values-schema.yaml # JSON schema that defines Otomi interface
37
+
├── values-schema.yaml # JSON schema that defines APL interface
38
38
└── versions.yaml # Version tags of otomi-api, otomi-console and otomi-tasks
39
39
```
40
40
@@ -56,13 +56,13 @@ Whenever you see `<<: *somename` then it means that [node anchor](<(https://yaml
56
56
57
57
# Values repo and data flow
58
58
59
-
A values repo is provided by a user. If Otomi is a function then `values repo` is input arguments. It is composed of many YAML files containing the configuration for various apps and teams.
59
+
A values repo is provided by a user. If APL is a function then `values repo` is input arguments. It is composed of many YAML files containing the configuration for various apps and teams.
60
60
61
-
While rendering kubernetes manifests Otomi leverages Helmfile.
61
+
While rendering kubernetes manifests APL leverages Helmfile.
62
62
63
63
> Helmfile is a declarative spec for deploying helm charts. You are encouraged to read more about Helmfile at https://github.com/helmfile/helmfile.
64
64
65
-
In Otomi, all Helmfile specs are defined in the `helmfile.d/` directory and executed in alphabetical order. The majority of Helmfile specs has the following structure:
65
+
In APL, all Helmfile specs are defined in the `helmfile.d/` directory and executed in alphabetical order. The majority of Helmfile specs has the following structure:
66
66
67
67
```go-template
68
68
#helmfiled./999-helmfile.yaml
@@ -106,7 +106,7 @@ flowchart LR
106
106
107
107
From the flow diagram, we can distinguish four stages of data, before `Kubernetes manifests` are rendered. These are: `Values repo`, `Helmfile bases`, `Helmfile release`, and `Helm chart`.
108
108
109
-
**Values repo**: It contains files that define input parameters for Otomi. This is where you can define teams, team, services, enabled applications and their configurations, etc. A user sets the `$ENV_DIR` env variable, so Otomi knows about its location.
109
+
**Values repo**: It contains files that define input parameters for APL. This is where you can define teams, team, services, enabled applications and their configurations, etc. A user sets the `$ENV_DIR` env variable, so APL knows about its location.
110
110
111
111
**Helmfile bases**: From the flow diagram, three files incorporate the content of the `.Values` - a Helmfile variable, which is accessible while using Go templates. These files are merged together in the following order: `snippets/default.yaml` -> `snippets/env.gotmpl` -> `snippets/derived.gotmpl`.
112
112
@@ -124,7 +124,7 @@ Almost each Helmfile spec loads `snippets/templates.gotmpl` file, which contains
124
124
125
125
# Validating data from the values repo
126
126
127
-
Otomi validates all parameters that a user can set in values repo by means checking values against JSON schema defined in the `values-schema.yaml` file. The validation can performed by calling `otomi validate-values` CLI command.
127
+
APL validates all parameters that a user can set in values repo by means checking values against JSON schema defined in the `values-schema.yaml` file. The validation can performed by calling `otomi validate-values` CLI command.
128
128
129
129
The schema is also a great source of documentation as most of the defined properties have corresponding documentation.
130
130
@@ -270,7 +270,7 @@ If your app has some parameters that a user should manipulate then make sure you
270
270
271
271
## Configuring Namespaces
272
272
273
-
Otomi defines Kubernetes namespaces and their labels in the `core.yaml` file, at the `k8s.namespaces` property.
273
+
APL defines Kubernetes namespaces and their labels in the `core.yaml` file, at the `k8s.namespaces` property.
274
274
275
275
## Configuring Ingress
276
276
@@ -307,19 +307,19 @@ Every team is deployed as a separate Helmfile release, thus targeting a specific
307
307
otomi template -l name=team-ns-demo
308
308
```
309
309
310
-
# Otomi CLI
310
+
# APL CLI
311
311
312
312
## Developing CLI
313
313
314
314
TBD
315
315
316
316
## Using CLI while developing templates
317
317
318
-
Using Otomi CLI can be very helpful while integrating apps or developing new features that involve the execution of Helmfile because it allows you to render and validate manifests. It is possible to use Otomi CLI in development mode, so the Otomi CLI reflects changes made in your local `apl-core` directory.
318
+
Using APL CLI can be very helpful while integrating apps or developing new features that involve the execution of Helmfile because it allows you to render and validate manifests. It is possible to use APL CLI in development mode, so the APL CLI reflects changes made in your local `apl-core` directory.
319
319
320
-
To run Otomi CLI in the development mode, you must:
320
+
To run APL CLI in the development mode, you must:
321
321
322
-
- execute Otomi CLI commands from a root directory of the `apl-core` project
322
+
- execute APL CLI commands from a root directory of the `apl-core` project
323
323
- export `ENV_DIR`
324
324
325
325
First, run `npm install` to build all modules required for CLI.
3. Now open `$ENV_DIR` directory in your favorite IDE. Otomi has bootstrapped the skeleton of the repo with default values.
347
+
3. Now open `$ENV_DIR` directory in your favorite IDE. APL has bootstrapped the skeleton of the repo with default values.
348
348
4. Last but not least provide information about your k8s cluster in `$ENV_DIR/env/cluster.yaml` file. Note, it can be fake data if you are not willing to deploy your changes to the cluster.
349
349
350
350
```
@@ -360,7 +360,7 @@ cluster:
360
360
otomi validate-values
361
361
```
362
362
363
-
Voila. You have built your values repo and can use it for Otomi development.
363
+
Voila. You have built your values repo and can use it for APL development.
364
364
365
365
Below you can find some useful use cases:
366
366
@@ -406,15 +406,15 @@ otomi x helmfile -l name=myapp write-values
406
406
407
407
# Troubleshooting
408
408
409
-
Some cloud providers are suing custom plugins to refresh the token. Since Otomi CLI executes by default in container some plugins may not be available. In order to solve this issue you can instruct Otomi CLI to execute directly on your host.
409
+
Some cloud providers are suing custom plugins to refresh the token. Since APL CLI executes by default in container some plugins may not be available. In order to solve this issue you can instruct APL CLI to execute directly on your host.
0 commit comments