Я пытаюсь развернуть Airbyte на Amazon EKS по его контрольной диаграмме. Я использую Airbyte v0.63.1 и Helm Chart v0.199.0.
На основе этого руководства я заранее создал секрет Kubernetes production-hm-airbyte-secret со значениями.
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYLOG_S3_BUCKET_NAMELOG_S3_BUCKET_REGIONPOSTGRES_USER_NAMEPOSTGRES_PASSWORDНа основе оригинального файла values.yaml , вот мой-values.yaml:
global:
state:
storage:
type: S3
database:
type: external
host: production-hm-airbyte-postgres.xxx.us-west-2.rds.amazonaws.com
port: 5432
database: airbyte_db
user: airbyte_user
secretName: production-hm-airbyte-secret
passwordSecretKey: POSTGRES_PASSWORD
logs:
accessKey:
existingSecret: production-hm-airbyte-secret
existingSecretKey: AWS_ACCESS_KEY_ID
secretKey:
existingSecret: production-hm-airbyte-secret
existingSecretKey: AWS_SECRET_ACCESS_KEY
storage:
type: S3
minio:
enabled: false
server:
extraEnv:
- name: AWS_ACCESS_KEY_ID
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_ACCESS_KEY_ID
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_SECRET_ACCESS_KEY
- name: STATE_STORAGE_S3_ACCESS_KEY
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_ACCESS_KEY_ID
- name: STATE_STORAGE_S3_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_SECRET_ACCESS_KEY
- name: STATE_STORAGE_S3_BUCKET_NAME
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: LOG_S3_BUCKET_NAME
- name: STATE_STORAGE_S3_REGION
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: LOG_S3_BUCKET_REGION
worker:
extraEnv:
- name: AWS_ACCESS_KEY_ID
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_ACCESS_KEY_ID
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_SECRET_ACCESS_KEY
- name: STATE_STORAGE_S3_ACCESS_KEY
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_ACCESS_KEY_ID
- name: STATE_STORAGE_S3_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: AWS_SECRET_ACCESS_KEY
- name: STATE_STORAGE_S3_BUCKET_NAME
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: LOG_S3_BUCKET_NAME
- name: STATE_STORAGE_S3_REGION
valueFrom:
secretKeyRef:
name: production-hm-airbyte-secret
key: LOG_S3_BUCKET_REGION
postgresql:
enabled: false
externalDatabase:
host: production-hm-airbyte-postgres.xxx.us-west-2.rds.amazonaws.com
port: 5432
database: airbyte_db
user: airbyte_user
existingSecret: production-hm-airbyte-secret
existingSecretPasswordKey: POSTGRES_PASSWORD
Однако после развертывания диаграммы Airbyte Helm v0.199.0 внутри модуля «airbyte-airbyte-bootloader» появилась ошибка:
Ошибка: не удалось найти ключ DATABASE_USER в секретном производстве-hm-airbyte/airbyte-airbyte-secrets.
Кроме того, я заметил, что Airbyte создал секрет airbyte-airbyte-secrets во время развертывания со значениями.
DEFAULT_MINIO_ACCESS_KEYDEFAULT_MINIO_SECRET_KEYWORKLOAD_API_BEARER_TOKENИ не хватает DATABASE_USER внутри.
Я пытаюсь добавить раздел airbyte-bootloader в my-values.yaml. Оба
airbyte-bootloader:
extraEnv:
- name: DATABASE_USER
value: airbyte_user
и
airbyte-bootloader:
secrets:
DATABASE_USER: airbyte_user
выдаст ошибку
не удалось создать типизированный объект исправления (production-hm-airbyte/airbyte-airbyte-bootloader; /v1, Kind=Pod): .spec.containers[name="airbyte-bootloader-container"].env: повторяющиеся записи для ключа [ name="DATABASE_USER"]
Я искал в Интернете и нашел
Но ни один из них не дает решения.
Любой гид будет признателен, спасибо!





Я нашел чистое решение! После того, как я перейду с
global
database:
# ...
secretName: production-hm-airbyte-secret
user: airbyte_user
passwordSecretKey: POSTGRES_PASSWORD
# ...
к
global
database:
# ...
secretName: production-hm-airbyte-secret
userSecretKey: POSTGRES_USER_NAME
passwordSecretKey: POSTGRES_PASSWORD
# ...
Он больше не ожидает DATABASE_USER и может плавно развернуться!
P.S. Я открыл билет на https://github.com/airbytehq/airbyte/issues/39604, надеюсь, user: airbyte_user способ будет работать гладко и в будущем.
Я нашел обходное решение: исправляет секрет Kubernetes airbyte-airbyte-secrets, чтобы добавить недостающие DATABASE_USER сразу после развертывания.
kubectl patch secret airbyte-airbyte-secrets \
--namespace=production-hm-airbyte \
--patch = "{\"stringData\":{\"DATABASE_USER\":\"airbyte_user\"}}"
Затем модуль airbyte-airbyte-bootloader сможет получить это DATABASE_USER из секретного airbyte-airbyte-secrets значения Kubernetes.