Развертывание PLAN-R Helm Chart
Подготовка к развертыванию
Для развертывания системы необходимо:
- Настроенный кластер Kubernetes или Deckhouse
- Утилиты для работы с кластером: kubectl и менеджер пакетов helm
- Для внешнего доступа необходим настроенный ingress (например nginx или traefik).
Важно! Ingress должен поддерживать протокол WebSocket.
- В качестве постоянного хранилища может использоватся s3 совместимые хранилища (Minio, Закрома.Хранение).
При использовании другого типа необходимо убедится что сsi контроллер поддерживает тип доступа ReadWriteMany (т.к. всем подам PLAN-R будет необходим доступ к файлам)
- Необходим доступ к реестру образов: registry.dppm.pro (открытый).
При использовании частного реестра образов, будет необходимо настроить проксирование образов из публичного репозитория registry.dppm.pro/releases в частный. Также возможна ручная загрузка образов из скомплекта поставки в частный репозиторий.
Рекомендации:
- Производить установку базы данны Postgresql на выделенный сервер или кластер серверов, для обеспечения большей стабильности, простоты управления и отказоустойчивости.
При развертывании базы данных через helm chart убедится что используется нужный csi драйвер, с ReclaimPolicy: Retain (для избежания потери данных)
- Для внешнего доступа по HTTS необходимо сгенерировать самоподписаный сертификат, либо использовать cert-manager для автоматизации запроа и выдачи SSL сертификатов;
- Постоянное хранилище для redis не является необходимым, все данные хранятся в оперативной памяти, потеря данных не критична;
- При установки helm chart создать отдельный файл для значений, в нем хранить только те значения которые отличаются от оригинального values.yaml, это упростит поддержку и последующее обновления системы.
Получение PLAN-R Helm Chart
PLAN-R Helm Chart можно получить следующими способами:
- Из комплекта поставки. При это версия Helm Chart будет соответствовать версии образов
- Из публичного OCI репозитория registry.dppm.pro/charts
При получении из OCI репозитория PLAN-R Helm Chart можно также скачать напрямую (по умолчанию - последняя версия, при необходимости версию можно указать с помощью аргумента --version)
helm pull oci://registry.dppm.pro/charts/planr --version 1.0.0
Получение PLAN-R Helm Chart
Получение образов системы
- Из комплекта поставки.
При использовании этого способа будет необходимо вручную загрузить полученые образа в частный репозиторий, для дальнейшего их использования в k8s
Также необходимо будет переопределить все ссылки на docker обрызы в values.yaml
Для этого используем скрипт load.sh из комплекта поставки для газрузки полученых образов в частный репозиторий. Перед публикацией образов необходимо дополнительно выполнить аутентификацию в этом репозитории
docker login <registry>
./load.sh --help
./load.sh <path-to-image> <registry> --push
Загрузка образов системы в частный репозиторий
- Из публичного OCI репозитория registry.dppm.pro/releases
При использовании этого способа также доступны docker образы на базе РЕД ОС 7.3, для их использования необходимо добавить redos в конце каждого тэга. Для постоянного их использования переопределить параметр planrGlobal.image.redos=true
Также можно настроить проксирование образов из registry.dppm.pro/releases в приватный репозиторий для их использования в закрытом контуре.
Создание необходимых секретов
Конфигурация секретов хранится в секции planrGlobal.secrets. Для удобства они унифицированы, при разворачивании создасётся секрет со всеми необходимыми ключами.
Также секреты можно переопределить вручную изменив необходимые значения в файле values.yaml. Создать можно как один унифицированный секрет с множеством ключей, так и несколько секретов с одним ключом.
Задание необходимых секретов происходит в секции planrConfig.secrets:
planrConfig:
secrets:
postgresqlUrl:
value: "postgresql://planr:planr@{{ .Release.Name }}-postgresql-hl:5432/planr"
createSecretForPostgres: false
existingSecret: ""
existingSecretKey: ""
где :
- planrConfig - секция отвечающая за общую конфигурацию PLAN-R;
- secrets - секция отвечающая за работу с секретами;
- postgresqlUrl - пример секрета содержащего строку подключения к postgresql;
- value - значения секрета по умолчанию (если не создается вручную). Также в это поле можно вписать желаемое значение которое поместится в созданный секрет (хранение значений в values.yml - не безопасно);
- createSecretForPostgres - переключатель автоматического создания секрета для postgresql (при установки postgresql как sub chart);
- existingSecret- имя секрета созданного вручную (при заполнении этого поля value и createSecretForPostgres не учитываются);
- existingSecretKey- ключ секрета созданного вручную.
Необходимые секреты для работы (при создании вручную):
- Строка подключения к Postgresql;
- Строка подключения к RabbitMq;
- Строка подключения к Redis.
Для создания секретов выполним следующую команду (При необходимости их можно будет изменить), учтем что значения секретов хранятся в base64.
Важно: название созданного секрета должно отличаться от созданных секретов в planr (название
{{ .Release.Name }}-unified.
Для создания из командной строки:
kubectl create secret generic --namespace planr planr-connection \
--from-literal=postgresql-url='postgresql://planr:planr@planr-postgresql-hl:5432/planr' \
--from-literal=rabbitmq-url='amqp://planr:planr@planr-rabbitmq-headless:5672/planr' \
--from-literal=redsi-url='amqp://planr:planr@planr-rabbitmq-headless:5672/planr'
Для явного создания из yaml файла можно воспользоваться конструкцией:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: planr-connection
namespace: planr
type: Opaque
stringData:
postgresql-url: postgresql://planr:planr@planr-postgresql-hl:5432/planr
rabbitmq-url: amqp://planr:planr@planr-rabbitmq-headless:5672/planr
redsi-url: amqp://planr:planr@planr-rabbitmq-headless:5672/planr
EOF
Если необходимом поменять секрет после развертывания можно выполнить следующую команду:
kubectl edit -n planr secret planr-connection
Вносим значения созданных секретов в values-planr.yaml
planrConfig:
secrets:
postgresqlUrl:
existingSecret: planr-connection
existingSecretKey: postgresql-url
rabbitmqUrl:
existingSecret: planr-connection
existingSecretKey: rabbitmq-url
redisUrl:
existingSecret: planr-connection
existingSecretKey: redsi-url
Важно:: Для вступления изменений в силу необходимо перезагрузить все поды использующие этот секрет.
Настройка хранилищ
Для настройки хранилища используется секция persistence
При использовании S3 - совместимого хранилища (настраивается в консоли администрирования), оставить persistence.enabled=false
Базовая настройка хранилища выглядит следующим образом:
persistence:
enabled: true
storageClass: "Longhorn" # Используемый Storage Class
size: 100Gi # желаемый размер хранилища
Если том уже создан, можно указать его с помощью persistence.existingClaim=existing-pvc
Настройка внешнего доступа
Внешний доступ настраивается в секции ingress
Есть 2 варианта создания:
- Создать 1 ingress для доступа к пользовательскому интерфейсу и консоли администрирования (/admin), на одном домене
При этом конфигурация примет следующий вид:
ingress:
main:
enabled: true
hostname: planr.local
ingressClassName: "nginx"
В этом случаи пользовательский интерфейс будет доступен на домене planr.local, а консоль администратора на planr.local/admin
Если явно не указать ingressClassName, при создании ingress объекта будет использован ingress класс по умолчанию
- Создание двух отдельных ingress ресурсов для пользовательского интерфейса и консоли администратора.
При этом конфигурация примет следующий вид:
ingress:
main:
enabled: true
hostname: planr.local
ingressClassName: "nginx"
admin:
enabled: true
hostname: planr-admin.local
ingressClassName: "nginx"
В этом случаи пользовательский интерфейс будет доступен на домене planr.local, а консоль администратора на planr-admin.local/admin
- Настройка внешнего доступа через сервис типа NodePort: Согласно схеме архитектуры необходимо будет настроить 3 сервиса (planrMain.service, planrAdmin.service, planrApi.service) с типом NodePort, для этого нужно переопределить значения для этих сервисов в values.yml
planrMain:
service:
type: NodePort
nodePorts:
http: "30800" (фиксация порта из промежутка 30000-32767)
planrAdmin:
service:
type: NodePort
nodePorts:
http: "30801" (фиксация порта из промежутка 30000-32767)
planrApi:
service:
type: NodePort
nodePorts:
http: "30802" (фиксация порта из промежутка 30000-32767)
В этом случае сервисы откроются с типом NodePort и будут доступны на выбранных портах нод кластера.
Настройка TLS/SSL для внешнего доступа
- Использование самоподписанных сертификатов предварительно созданных в качестве секрета.
kubectl create secret planr.local-tls \
--cert=tls.crt \
--key=tls.key \
--namespace=planr
tls.crt должен содержать всю цепочку сертификатов
Пример использования в values.yml
ingress:
main:
enabled: true
hostname: planr.local
ingressClassName: nginx
tls: true
extraTls:
- hosts:
- planr.local
secretName: planr.local-tls
- Выдача сертификатов через cert-manager с помощью Issuer или ClusterIssuer.
Пример выдачи сертификатов для ingress ресурса через cluster issuer.
ingress:
main:
enabled: true
hostname: plan-r.tech
ingressClassName: traefik
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod" # использование ClusterIssuer для выдачи сертификата от letsencrypt
tls: true
Настройка SSL/TLS подключения к сервисам
Для настройки SSL/TLS шифрования между сервисами (Postgres, Redis, RabbitMQ) необходимо подготовить следующие компоненты:
- Сгенерировать серверные сертификаты для сервисов, к которым будет происходить подключение
- Создать секрет, который будет содержать все корневые сертификаты и соответствующие закрытые ключи
- Добавить корневые сертификаты или цепочку корневых сертификатов в хранилище доверенных сертификатов контейнеров
- Настроить Postgres, Redis, RabbitMQ для работы с сертификатами
- Изменить строки подключения для работы пол ssl
Подготовка серверных сертификатов
- Сформировать файл конфигурации, указав в нем необходимые расширения (req_ext) и параметры (alt_names)
- req_ext необходима для указания типа сертификата (extendedKeyUsage = serverAuth) и использования SAN (subjectAltName = @alt_names)
- alt_names необходимы для указания валидных FQDN для серверного сертификата, включая localhost (для корректной работы healthcheck) и имен Kubernetes сервисов
- Сформировать .csr запрос на подпись и закрытый ключ
- Подписать сертификаты корпоративным центром сертификации
Далее приведены следующие примеры для всех внешних сервисов:
Postgres:
# формирование конигурации для сертификата postgres
cat > postgres.conf << EOF
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
C = RU
ST = Moscow
L = Moscow
O = Planr
CN = planr-postgres.planr.svc.cluster.local
[req_ext]
subjectAltName = @alt_names
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[alt_names]
DNS.1 = postgres
DNS.2 = planr-postgres
DNS.3 = planr-postgres-headless
DNS.4 = planr-postgres.planr.svc.cluster.local
DNS.5 = planr-postgres-headless.planr.svc.cluster.local
DNS.6 = localhost
IP.1 = 127.0.0.1
EOF
## формируем .csr запрос на подпись сразу с закрытом ключем
openssl req -newkey rsa:2048 -nodes -keyout postgres.key -out postgres.csr -config postgres.conf
Redis:
# формирование конфигурации для сертификата
cat > redis.conf << EOF
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
C = RU
ST = Moscow
L = Moscow
O = Planr
CN = planr-redis.planr.svc.cluster.local
[req_ext]
subjectAltName = @alt_names
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[alt_names]
DNS.1 = redis
DNS.2 = planr-redis
DNS.3 = planr-redis-headless
DNS.4 = planr-redis.planr.svc.cluster.local
DNS.5 = planr-redis-headless.planr.svc.cluster.local
DNS.6 = localhost
IP.1 = 127.0.0.1
EOF
## формируем .csr запрос cразу с закрытым ключем на подпись
openssl req -newkey rsa:2048 -nodes -keyout redis.key -out redis.csr -config redis.conf
Rabbitmq:
# формирование конфигурации для сертификата
cat > rabbitmq.conf << EOF
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[req_distinguished_name]
C = RU
ST = Moscow
L = Moscow
O = Planr
CN = planr-rabbitmq.planr.svc.cluster.local
[req_ext]
subjectAltName = @alt_names
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[alt_names]
DNS.1 = rabbitmq
DNS.2 = planr-rabbitmq
DNS.3 = planr-rabbitmq-headless
DNS.4 = planr-rabbitmq.planr.svc.cluster.local
DNS.5 = planr-rabbitmq-headless.planr.svc.cluster.local
DNS.6 = localhost
IP.1 = 127.0.0.1
EOF
## формируем .csr запрос cразу с закрытым ключем на подпись
openssl req -newkey rsa:2048 -nodes -keyout rabbitmq.key -out rabbitmq.csr -config rabbitmq.conf
Для подписи сертификатов корневым сертификатом (при наличии закрытого ключа) можно использовать следующие команды:
openssl x509 -req -in postgres.csr -CA <ca>.crt -CAkey <ca>.key -CAcreateserial -out postgres.crt -days 365 -sha256 -extfile postgres.conf -extensions req_ext
openssl x509 -req -in redis.csr -CA <ca>.crt -CAkey <ca>.key -CAcreateserial -out redis.crt -days 365 -sha256 -extfile redis.conf -extensions req_ext
openssl x509 -req -in rabbitmq.csr -CA <ca>.crt -CAkey <ca>.key -CAcreateserial -out rabbitmq.crt -days 365 -sha256 -extfile rabbitmq.conf -extensions req_ext
Создание секрета с сертификатами
Для удобства создадим один секрет, включающий корневые сертификаты, серверные сертификаты и закрытые ключи к серверным сертификатам. Для этого выполним следующую команду:
Так как мы используем stringData, значения ключей можно передать без base64 кодирования — оно применится автоматически
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
name: tls-unified
# указать правильный namespace
namespace: planr
type: Opaque
stringData:
ca.pem: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
postgres.key: |
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
postgres.pem: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
rabbitmq.key: |
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
rabbitmq.pem: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
redis.key: |
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
redis.pem: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
EOF
Добавление доверенных центров сертификации
Для добавления корневого сертификата или цепочки корневых сертификатов в хранилище доверенных сертификатов контейнера необходимо в values указать следующие настройки:
Используем корневые сертификаты (ca.pem) из секрета, созданного на предыдущем шаге
planrConfig:
ssl:
## @param planrConfig.ssl.ignoreUntrusted Игнорирование доверия к самоподписаным сертификатом (добавляет NODE_TLS_REJECT_UNAUTHORIZED=0). Не рекомендуется
##
ignoreUntrusted: false
trusted:
## @param planrConfig.ssl.trusted.existingConfigMap configMap который содержит самоподписанные корневые сертификаты.
## @param planrConfig.ssl.trusted.existingConfigMapKey ключ configMap который содержит самоподписанные корневые сертификаты.
## @param planrConfig.ssl.trusted.existingSecret секрет который содержит самоподписанные корневые сертификаты.
## @param planrConfig.ssl.trusted.existingSecretKey ключ секрета который содержит самодписанные сертификаты.
## @param planrConfig.ssl.trusted.ca string строка содержащая корневые сертификаты в открытом виде.
##
existingConfigMap: ""
existingConfigMapKey: ca.pem
existingSecret: "tls-unified"
existingSecretKey: ca.pem
ca: ""
Конфигурациия внешних сервисов для SSL/TLS
Для обеспечения шифрования необходимо сконфигурировать внешние сервисы (Postgres, Redis, RabbitMQ) следующим образом:
В каждый сервис монтируем только необходимые ему серверный сертификат и закрытый ключ
Postgres:
postgres:
enabled: true
config:
## добавляем обязательную строку с парольной авторизацие и шифрованием
## hostssl all all 0.0.0.0/0 scram-sha-256
pgHbaConfig: |
# Default pg_hba.conf configuration
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
# Allow connections from any host with password authentication
hostssl all all 0.0.0.0/0 scram-sha-256
## редактируем параметры ssl
## Важно
## перед применением необходимо сгенерированые серверные сертификаты для postgre, и примонтировать их в pod
extraConfig:
- ssl = on
- ssl_ca_file = '/var/lib/postgresql/tls/ca.pem'
- ssl_cert_file = '/var/lib/postgresql/tls/postgres.pem'
- ssl_key_file = '/var/lib/postgresql/tls/postgres.key'
## монтируем секрет с сертифаитами
## ca.pem - корневой сертификат или цепочка корневых сертификатов
## postgres.pem - серверный сертификат сля postgres
## postgres.key - приватный ключ серверного сертификата
extraVolumes:
- name: tls-secret-temp
secret:
secretName: tls-unified
items:
- key: ca.pem
path: ca.pem
- key: postgres.pem
path: postgres.pem
- key: postgres.key
path: postgres.key
# postgres требует правильные права 644 для сертификатов, поэтому необходимо их исправить с помощтю init-container
initContainers:
- name: setup-tls
image: alpine:latest
securityContext:
runAsUser: 0
command:
- /bin/sh
- -c
- |
set -ex
mkdir -p /var/lib/postgresql/data/tls
# копируем из init контейнера
cp /tmp-tls/ca.pem /var/lib/postgresql/data/tls/
cp /tmp-tls/postgres.pem /var/lib/postgresql/data/tls/
cp /tmp-tls/postgres.key /var/lib/postgresql/data/tls/
# назначяем права которые требует postgres
chmod 644 /var/lib/postgresql/data/tls/ca.pem
chmod 644 /var/lib/postgresql/data/tls/postgres.pem
chmod 600 /var/lib/postgresql/data/tls/postgres.key
# меняем владельца директории на postgres
chown -R 999:999 /var/lib/postgresql/data/tls
# монтируем сертификаты из секрета
volumeMounts:
- name: data
mountPath: /var/lib/postgresql/data
- name: tls-secret-temp
mountPath: /tmp-tls
readOnly: true
Redis:
redis:
enabled: true
## настройка redis с шифрованием канала
## ca.pem - корневой сертификат или цепочка корневых сертификатов
## redis.pem - серверный сертификат для redis
## redis.key - приватный ключ для redis серификата
tls:
enabled: true
authClients: false
port: 6379
existingSecret: tls-unified
certFilename: redis.pem
certKeyFilename: redis.key
certCAFilename: ca.pem
config:
content: |-
appendonly no
Rabbitmq:
rabbitmq:
enabled: true
config:
extraConfiguration: |
# disable anonymous auth
loopback_users = none
anonymous_login_user = none
# auth setup
# auth_mechanisms.1 = EXTERNAL
auth_backends.1 = internal
# ssl_cert_login_from = common_name
# ssl setup
listeners.tcp = none
listeners.ssl.default = 5672
ssl_options.cacertfile = /tls/ca.pem
ssl_options.certfile = /tls/rabbitmq.pem
ssl_options.keyfile = /tls/rabbitmq.key
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = false
ssl_options.versions.1 = tlsv1.3
ssl_options.versions.2 = tlsv1.2
## монтируем необходимые сертификаты из секрета
extraVolumes:
- name: rabbitmq-tls
secret:
secretName: tls-unified
items:
- key: ca.pem
path: ca.pem
- key: rabbitmq.pem
path: rabbitmq.pem
- key: rabbitmq.key
path: rabbitmq.key
extraVolumeMounts:
- name: rabbitmq-tls
mountPath: /tls
readOnly: true
Настройка строк подключения для работы через SSL/TLS
Для взаимодействия с сервисами postgres, rabbitmq, redis через защищенной SSL/TLS соединие, необходимо привести сроки подключения к сервисам к следующему виду:
Postgres:
Для Postgres строка подключения будет выглядеть следующим образом:
Добавляем параметр ?ssl=true, в хосте указываем валидный DNS из alt_names сертификата
postgresql://planr:planr@planr-postgres-headless.planr.svc.cluster.local:5432/planr?ssl=true
Redis:
заменям протокол с redis на rediss, в хосте указываем валидный DNS из alt_names сертификата
rediss://:planr@planr-redis.planr.svc.cluster.local:6379
Rabbitmq:
Заменяем amqp на amqps, в хосте указываем валидный DNS из alt_names сертификата
amqps://planr:planr@planr-rabbitmq.planr.svc.cluster.local:5672/planr
Настройка потребления ресурсов
Потребление ресурсов для всех контейнеров настраивается в секции planrGlobal.resources, а также специфичные настройки для следующих контейнеров planrMain.resources, planrApi.resources, planrAdmin.resources, planrWorkers.backup.resources, planrWorkers.planr.resources, planrWorkers.impex.resources, planrWorkers.schedule.resources, planrWorkers.notice.resources, planrWorkers.storage.resources, planrWorkers.csharp.resources, planrWorkers.costr.resources
Пример настройки и потребления ресурсов согласно документации
# Переопределяем limits у специфичных контейнеров согласно аппаратным требованиям из документации:
planrMain:
resources:
limits:
cpu: 1.3
memory: 2048Mi
planrApi:
resources:
limits:
cpu: 1.3
memory: 2048Mi
planrAdmin:
resources:
limits:
cpu: 1.3
memory: 1024Mi
planrWorkers:
backup:
resources:
limits:
cpu: 1.3
memory: 12288Mi
planr:
resources:
limits:
cpu: 1.3
memory: 4096Mi
impex:
resources:
limits:
cpu: 1.3
memory: 8192Mi
schedule:
resources:
limits:
cpu: 1.3
memory: 1024Mi
notice:
resources:
limits:
cpu: 1.3
memory: 2048Mi
storage:
resources:
limits:
cpu: 1.3
memory: 2048Mi
csharp:
resources:
limits:
cpu: 6
memory: 12288Mi
costr:
resources:
limits:
cpu: 1.3
memory: 4096Mi
Установка PLAN-R helm chart
- Проверем подключение и наличие необходимых утилит kubectl, helm
kubectl version
kubectl cluster-info
helm version
Проверка подключения к кластеру
- Создаем файл planr-values.yaml (готовые примеры можно посмотреть тута, где будем изменять и хранить только необходимые значения.
vi planr-values.yaml
Просмотреть исходный файл с параметрами можно следующими командами:
Можно записать значение вывода в файл, т.к исходный файл достаточно большой
helm show values plan-r-1.0.0.tgz >> base-values.yaml
helm show values oci://registry.dppm.pro/charts/planr >> base-values.yaml
- Выполняем установку
Создать пространство имен можно прямо во время установки, добавив аргумент --create-namespace в качестве аргумента
helm upgrade --install -namespace <namespce> --create-namespace --values=<path_to_custom_values> <RELEASE_NAME> <CHART_PATH>
Для локальной уставки:
helm upgrade --install --namespace planr --create-namespace --values=./planr-values.yaml planr plan-r-1.0.0.tgz
Для установки из OCI репозитория (без аргумента --version установится последняя доступная версия)
helm upgrade --install --namespace planr --create-namespace --values ./planr-values.yaml planr oci://registry.dppm.pro/charts/planr --version 1.0.0
Обновление PLAN-R helm chart
Для обновления выполним следующую команду:
Для обновления PLAN-R Helm chart из комплекта поставки:
helm upgrade --install --namespace planr --create-namespace --values ./planr-values.yaml planr oci://registry.dppm.pro/charts/planr --version 1.1.0
Для обновления PLAN-R Helm chart из репозитория поставки:
helm upgrade --install --namespace planr --create-namespace --values ./planr-values.yaml planr plan-r-1.0.0.tgz --version 1.1.0
Важно:: Если явно не указать параметр --version произойдет обновление до последней доступной версии
Примеры развертывания
Примеры values.yml доступны для просмотра и быстрого использования (в целях тестирования) в директории examples PLAN-R helm chart.
Для быстрого извлечения файлов с примерами можно использовать следующие команды:
Для OCI репозитория
mkdir -p examples && helm pull oci://registry.dppm.pro/charts/planr -d /tmp && tar -xzf /tmp/planr-*.tgz -C ./examples --strip-components=2 "planr/examples/"
Если helm chart уже скачан:
mkdir -p examples && tar -xzf ./planr-1.0.0.tgz -C ./examples --strip-components=2 "planr/examples/"
Файлы примеров будут находится в созданоой директори examples
Директория с примерами развертывания