Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
CEO and Co-founder в AppRecode
  • Консультація від досвідченого DevOps-інженера за донат (UPD: призупинено через велику кількість охочих)

    Доброго вечора. Отримав дуже багато запитів на консультацію і вже майже не було вільних слотів. От і деактивував лінку на календлі.
    Напишіть мені в лінкедіні, будь ласка.

  • Хто такий DevOps

    Та хоч енікейшик. Головне щоб проект і компенсація влаштовувала.

  • Хто такий DevOps

    Не обов’язковов щоб був чистий девопс. Такі проекти дійсно не часто трапляюся. Але є основи і методи за якими працюють девопс інженери і це сильно відрізняє їх від сисадмінів.

  • Підхід GitOps як сучасна практика для CD з Kubernetes

    Це у випадку, якщо ваша CI система, або ранери хоститься у вашому AWS акаунті. А якщо у вас все онсайт, то IAM роль не буде куди добавити.

  • Підхід GitOps як сучасна практика для CD з Kubernetes

    GitOps звісно не всім потрібен. Якщо ви не бачите в ньому потребу, то й не потрібно його інтегровувати. І я радий що є інші точки зору. Не може все бути ідеальним :)

    А стосовно

    AAD Pod Identity,

    це трошки інший випадок. Це доступ до ресурсів клауда. Для цього секрети не потрібні.
    В загальному, секрети це як додаткова частина GitOps та просто їх організація. Тулзів є багато і відповідно варто користуватися тією яка для вас зручна.

    Також хочу добавити що є різні моделі відповідальності на проекті між розробниками та системними інженерами (чи просто девопсами).
    В прикладі який я приводив на демо, це коли розробники мають свій репозиторій з хелм чартом або просто yaml файлом і воно його ж самі розробляють і несуть відповідальність на секрети (third-pary провайдери, api токени, та інше) так і за та що попаде на продакшин.

    Тому тут вже вам вирішувати наскільки ви хочете контролювати зміни девелоперів, або якщо ви дев, скільки відповідальності ви хотіли б мати на проекті.

  • Підхід GitOps як сучасна практика для CD з Kubernetes

    Поріг входу можливо буде вищий для DevOps/Infrastructure інженерів, так як прийдеться розбиратися з новою системою. Тестування можна виконувати на дев середовищі, до якого в іженера може бути повний доступ, щоб не робити 100 комітів, щоб відтестувати ту чи іншу фічу і вже на вищий стейджах доставляти тільки кодом.

    Мануальний тригер також присутнійю Ось на демо я демонтрую як можна швидко запустити процес оновлення з git-а:
    youtu.be/Qhy1lxKbLHM?t=1019

    Для розробників GitOps навпаки зменшує поріг входу, тому, що їм не потрібно розбиратися з кластером. Їх робота буде тільки в оновленні yaml файлів в репозиторії на основі інших прикладів.
    Проблема може бути тільки в розумінні «як це працює», але це вже індивідуально.

    Підтримав: Andrii Kyianov
  • Підхід GitOps як сучасна практика для CD з Kubernetes

    Привіт, дякую за питання.
    Ключ шифрування можна забекапити для майбутнього відновлення у випадку втрати кластера.
    Більше мона дізнатися тут:
    github.com/...​offline-with-a-backup-key

    Підтримав: Max Shnurenok