blob: 533f60e29b09a7bc18fb340a7566ec80aca1591a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
.. This work is licensed under a Creative Commons Attribution 4.0
.. International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2018-2020 Amdocs, Bell Canada, Orange, Samsung
.. Modification copyright (C) 2022 Nordix Foundation
.. Links
.. _Helm Charts: https://artifacthub.io/packages/search
.. _aai: https://github.com/onap/oom/tree/master/kubernetes/aai
.. _name.tpl: https://github.com/onap/oom/blob/master/kubernetes/common/common/templates/_name.tpl
.. _namespace.tpl: https://github.com/onap/oom/blob/master/kubernetes/common/common/templates/_namespace.tpl
.. _oom_helm_chart_info:
Helm Charts
###########
A Helm chart is a collection of files that describe a related set of Kubernetes
resources. A simple chart might be used to deploy something simple, like a
memcached pod, while a complex chart might contain many micro-service arranged
in a hierarchy as found in the `aai`_ ONAP component.
Charts are created as files laid out in a particular directory tree, then they
can be packaged into versioned archives to be deployed. There is a public
archive of `Helm Charts`_ on ArtifactHUB that includes many technologies applicable
to ONAP. Some of these charts have been used in ONAP and all of the ONAP charts
have been created following the guidelines provided.
An example structure of the OOM common helm charts is shown below:
.. code-block:: bash
common
├── cassandra
│ ├── Chart.yaml
│ ├── resources
│ │ ├── config
│ │ │ └── docker-entrypoint.sh
│ │ ├── exec.py
│ │ └── restore.sh
│ ├── templates
│ │ ├── backup
│ │ │ ├── configmap.yaml
│ │ │ ├── cronjob.yaml
│ │ │ ├── pv.yaml
│ │ │ └── pvc.yaml
│ │ ├── configmap.yaml
│ │ ├── pv.yaml
│ │ ├── service.yaml
│ │ └── statefulset.yaml
│ └── values.yaml
├── common
│ ├── Chart.yaml
│ ├── templates
│ │ ├── _createPassword.tpl
│ │ ├── _ingress.tpl
│ │ ├── _labels.tpl
│ │ ├── _mariadb.tpl
│ │ ├── _name.tpl
│ │ ├── _namespace.tpl
│ │ ├── _repository.tpl
│ │ ├── _resources.tpl
│ │ ├── _secret.yaml
│ │ ├── _service.tpl
│ │ ├── _storage.tpl
│ │ └── _tplValue.tpl
│ └── values.yaml
├── ...
└── postgres-legacy
├── Chart.yaml
├── charts
└── configs
The common section of charts consists of a set of templates that assist with
parameter substitution (`name.tpl`_, `namespace.tpl`_, etc) and a set of
charts for components used throughout ONAP. When the common components are used
by other charts they are instantiated each time or we can deploy a shared
instances for several components.
All of the ONAP components have charts that follow the pattern shown below:
.. code-block:: bash
name-of-my-component
├── Chart.yaml
├── component
│ └── subcomponent-folder
├── charts
│ └── subchart-folder
├── resources
│ ├── folder1
│ │ ├── file1
│ │ └── file2
│ └── folder1
│ ├── file3
│ └── folder3
│ └── file4
├── templates
│ ├── NOTES.txt
│ ├── configmap.yaml
│ ├── deployment.yaml
│ ├── ingress.yaml
│ ├── job.yaml
│ ├── secrets.yaml
│ └── service.yaml
└── values.yaml
Note that the /components sub dir may include a hierarchy of sub
components and in themselves can be quite complex.
You can use either `charts` or `components` folder for your subcomponents.
`charts` folder means that the subcomponent will always been deployed.
`components` folders means we can choose if we want to deploy the subcomponent.
This choice is done in root `values.yaml`:
.. code-block:: yaml
---
global:
key: value
component1:
enabled: true
component2:
enabled: true
Then in `Chart.yaml` dependencies section, you'll use these values:
.. code-block:: yaml
---
dependencies:
- name: common
version: ~x.y-0
repository: '@local'
- name: component1
version: ~x.y-0
repository: 'file://components/component1'
condition: component1.enabled
- name: component2
version: ~x.y-0
repository: 'file://components/component2'
condition: component2.enabled
Configuration of the components varies somewhat from component to component but
generally follows the pattern of one or more `configmap.yaml` files which can
directly provide configuration to the containers in addition to processing
configuration files stored in the `config` directory. It is the responsibility
of each ONAP component team to update these configuration files when changes
are made to the project containers that impact configuration.
The following section describes how the hierarchical ONAP configuration system
is key to management of such a large system.
.. MISC
.. ====
.. Note that although OOM uses Kubernetes facilities to minimize the effort
.. required of the ONAP component owners to implement a successful rolling
.. upgrade strategy there are other considerations that must be taken into
.. consideration.
.. For example, external APIs - both internal and external to ONAP - should be
.. designed to gracefully accept transactions from a peer at a different
.. software version to avoid deadlock situations. Embedded version codes in
.. messages may facilitate such capabilities.
..
.. Within each of the projects a new configuration repository contains all of
.. the project specific configuration artifacts. As changes are made within
.. the project, it's the responsibility of the project team to make appropriate
.. changes to the configuration data.
|
