В пості GitHub Actions: деплой Dev/Prod оточень з Terraform я вже трохи торкався теми Reusable Workflows та Composite Actions – прийшов час трохи більше з нею ознайомитись. Що треба зробити: зараз на проекті ми в кожному репозиторії пишемо Workflow-файли окремо. Втім, оскільки поступово всі процеси уніфікуються – управління інфраструктурою через Terraform, та запуск сервісів в… Читати далі »
У пості GitHub Actions: деплой Dev/Prod оточень з Terraform я вже описував те, як можна реалізувати CI/CD для Terraform з GitHub Actions, але в тому рішенні є один суттєвий недолік: немає можливості зробити review змін перед тим, як їх застосувати з terraform apply. GitHub Actions має можливість використання Reviewing deployments для approve/reject, проте ця можливість… Читати далі »
Отже, маємо розгорнутий кластер Kubernetes – див. серію Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints. Маємо GitHub Actions workflow для його деплою – див. GitHub Actions: деплой Dev/Prod оточень з Terraform. Прийшов час почати деплоїти наш бекенд в Kubernetes. Тут знов використаємо GitHub Actions – будемо білдити Docker-образ з API-сервісом бекенду, зберігати… Читати далі »
Тепер, як маємо готовий код для розгортання кластеру AWS Elastic Kubernetes Service (див. Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints і наступні частини), прийшов час подумати про автоматизацію, тобто – про створення пайплайнів в CI/CD, які би виконували створення нових енвів для тестування фіч, або деплоїли апдейти на Dev/Prod оточення Kubernetes. І… Читати далі »
Прийшла досить цікава задачка – побудувати в Grafana дашборду, в якій би відображався статус процессу розробки, а саме – перформанс, тобто ефективність наших DevOps-процесів. Потрібно це тому, что ми намагаємось побудувати “true continuous deployment”, щоб код автоматично потрапляв у Production, і нам важливо бачити як саме проходить процес розробки. Загалом для оцінки ефективності процессу розробки… Читати далі »
Запустились ми в production, і вилізла дуже неприємна бага – при git операціях clone/pull/push запит іноді зависав на 1-2 хвилини. Виглядало це як якась “плавуюча” бага, тобто 5 раз могло склонити нормально, а потім раз зависає. Проблеми gitlab-shell timeouts Наприклад – раз нормально: [simterm] $ time git clone [email protected]:example/platform/tables-api.git Cloning into ‘tables-api’… … real 0m1.380s… Читати далі »
Отже, продовжуємо нашу подорож з міграцією GitLab до себе в Kubernetes. Див. попередні частини: GitLab: компоненти, архітектура, інфраструктура та запуск з Helm-чарту в Minikube GitLab: Helm-чарт values, залежності та деплой у Kubernetes з AWS S3 GitLab: міграція даних з GitLab cloud та процес backup-restore у self-hosted версії в Kubernetes В цілому – все працює, і… Читати далі »
Продовжуємо рухатись до запуску нашого self-hosted GitLab в production. Див. попередні частини – GitLab: компоненти, архітектура, інфраструктура та запуск з Helm-чарту в Minikube та GitLab: Helm-чарт values, залежності та деплой у Kubernetes з AWS S3. Міграція даних Ще дуже хотілося написати пост про міграцію даних з GitLab Cloud до self-hosted, але немає часу, та й… Читати далі »
Продовжуємо зайомство з GitLab та його деплоєм у Kubernetes. Перша частина – GitLab: компоненти, архітектура, інфраструктура та запуск із Helm-чарту в Minikube, тепер давайте готуватися деплоїти в AWS Elastic Kubernetes Service. Що робитимемо і де: деплоїмо в AWS з Helm-чарту, для початку якийсь “test env” Kubernetes – AWS EKS object store – AWS S3 PostgreSQL… Читати далі »
Оскільки GitLab нещодавно змінив політику надання Free-доступу, і тепер по Free підписці буде доступно лише 5 користувачів, то вирішили ми переїжджати на self-hosted версію. Взагалі з ліцензією у них цікаво: ціна залежить від кількості користувачів, купити можна щонайменше на рік, і після покупки зменшити кількість користувачів у ліцензії не можна (але можна збільшити). GitLab… Читати далі »