Лучшая практика развертывания kubernetes в различных средах и обработки номеров сборки в конфигурации - PullRequest
Новая
       46

Лучшая практика развертывания kubernetes в различных средах и обработки номеров сборки в конфигурации

0 голосов
/ 27 июня 2019

У меня есть конфигурация развертывания, лежащая с каждым микросервисом.Это выглядит примерно так: 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    io.kompose.service: service_x
  name: service_x
spec:
  replicas: 2
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        io.kompose.service: service_x
    spec:
      containers:
      - env:
        - name: FLASK_ENV
          value: "production"
        image: somewhere/service_x:master_179
        name: service_x
        ports:
        - containerPort: 80
        resources: {}
        volumeMounts:
          - mountPath: /app/service_x/config/deployed
            name: volume-service_xproduction
      restartPolicy: Always
      volumes:
        - name: volume-service_xproduction
          configMap:
            name: service_xproduction
            items:
              - key: production.py
                path: production.py

У нас есть следующие среды разработки, стадии, производства.Как видите, параметр image содержит сервис, ветку и номер сборки.У меня есть несколько идей, чтобы сделать это динамичным и иметь возможность развернуть, например, service_x: development_190 в среде разработчика и другую сборку на сцене.Но прежде чем я начну - может быть - изобретать колесо новым, мне интересно, как другие люди решают эту проблему ... Кстати.Мы используем CircleCI для создания образов докера.

Мой вопрос здесь сейчас;Каков наилучший способ развертывания сборок в разных средах?

  • сборка deploy.yml для каждой сборки?
  • с использованием переменных / шаблонов?
  • Любые другие решения iне знаете?
  • может быть, не самая лучшая идея хранить файлы kubernetes в микросервисе?

1 Ответ

2 голосов
/ 27 июня 2019

Есть много способов сделать то, что вы хотите сделать, как рулевые диаграммы, обновление шаблонов и т. Д.

Что я делаю, так это структурирую код: 

├── .git
├── .gitignore
├── .gitlab-ci.yml
├── LICENSE
├── Makefile
├── README.md
├── src
│   ├── Dockerfile
│   ├── index.html
└── templates
    ├── autoscaler.yml
    ├── deployment.yml
    ├── ingress.yml
    ├── sa.yml
    ├── sm.yml
    └── svc.yml

Файлы шаблонов Kubernetes будут иметь что-то вроде: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deployment
  namespace: __NAMESPACE__
  labels:
    app: app
    environment: __CI_COMMIT_REF_NAME__
    commit: __CI_COMMIT_SHORT_SHA__
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
        environment: __CI_COMMIT_REF_NAME__
        commit: __CI_COMMIT_SHORT_SHA__
      annotations:
        "cluster-autoscaler.kubernetes.io/safe-to-evict": "true"
    spec:
      containers:
        - name: app
          image: <registry>/app:__CI_COMMIT_SHORT_SHA__
          ports:
            - containerPort: 80

Так что этот шаблон не изменится, если вы измените src.

Затем в конфигурации CircleCI вы можете выполнить шаги по обновлению шаблона перед применением: 

- sed -i "s/__NAMESPACE__/${CI_COMMIT_REF_NAME}/" deployment.yml service.yml
- sed -i "s/__CI_COMMIT_SHORT_SHA__/${CI_COMMIT_SHORT_SHA}/" deployment.yml service.yml
- sed -i "s/__CI_COMMIT_REF_NAME__/${CI_COMMIT_REF_NAME}/" deployment.yml service.yml
- kubectl apply -f deployment.yml
- kubectl apply -f service.yml

Переменные будут вам доступны или установлены в CircleCI.

...