Колись вже трохи писав про Pritunl – Pritunl: запуск VPN в Kubernetes. Повернемось до цієї теми ще раз, але цього разу на EC2 в AWS, без Kubernetes. Отже, що треба – це запустити якийсь VPN-сервіс для проекту, або мати доступ до всяких Kubernetes API/Kubernetes WorkerNodes/AWS RDS у приватних мережах. Вибір тут, в принципі, є –… Читати далі »
З часом, коли проект росте, то рано чи пізно постане питання про апгрейд версій пакетів, модулів, чартів. Робити це вручну, звісно, можна – але тільки до якоїсь межі, бо врешті-решт ви просто фізично не зможете моніторити та оновлювати все. Для автоматизації таких процесів існує багато рішень, але найчастіше зустрічаються два – Renovate та Dependabot. За… Читати далі »
У пості GitHub Actions: деплой Dev/Prod оточень з Terraform я вже описував те, як можна реалізувати CI/CD для Terraform з GitHub Actions, але в тому рішенні є один суттєвий недолік: немає можливості зробити review змін перед тим, як їх застосувати з terraform apply. GitHub Actions має можливість використання Reviewing deployments для approve/reject, проте ця можливість… Читати далі »
Приклад створення модулю Terraform для автоматизації збору логів з AWS Load Balancers у Grafana Loki. Як працює сама схема див. у Grafana Loki: збираємо логи AWS LoadBalancer з S3 за допомогою Promtail Lambda – ALB пише логи в S3-бакет, звідки їх забирає Lambda-функція з Promtail і пересилає у Grafana Loki. В чому ідея з модулем… Читати далі »
Отже, Karpenter зробив ще один великий шаг до релізу, і у версії 0.32 вийшов з етапу Alpha до Beta. Давайте кратко подивимось на зміни – а вони досить суттєві, а потім виконаємо апгрейд на EKS з Karpneter Terraform module та Karpenter Helm chart. Сам процес установки Karpenter описував у пості Terraform: створення EKS, частина 3… Читати далі »
Отже, маємо розгорнутий кластер Kubernetes – див. серію Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints. Маємо GitHub Actions workflow для його деплою – див. GitHub Actions: деплой Dev/Prod оточень з Terraform. Прийшов час почати деплоїти наш бекенд в Kubernetes. Тут знов використаємо GitHub Actions – будемо білдити Docker-образ з API-сервісом бекенду, зберігати… Читати далі »
В пості Loki: збір логів з CloudWatch Logs з використанням Lambda Promtail описано як можна збирати логи з CloudWatch Logs за допомогою Lambda-функції з Promtail, який пересилає логи в Grafana Loki. Що треба зробити зараз – це описати створення чотирьох таких функцій, по одній на кожен компонент проекту. Функції мають бути розміщені в приватних мережах… Читати далі »
За допомогою data “terraform_remote_state” ми можемо отримати outputs одного проекту, щоб використати в іншому. Наприклад, у нас AWS VPC створюється окремо від AWS EKS (хоча в серії Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints VPC створювалась як частина кластеру, але потім я їх розділив). Для створення EKS – йому треба передати VPC… Читати далі »
Тепер, як маємо готовий код для розгортання кластеру AWS Elastic Kubernetes Service (див. Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints і наступні частини), прийшов час подумати про автоматизацію, тобто – про створення пайплайнів в CI/CD, які би виконували створення нових енвів для тестування фіч, або деплоїли апдейти на Dev/Prod оточення Kubernetes. І… Читати далі »
Вже писав про питання управління бекендами у постах Terraform: початок роботи та планування нового проекту – Dev/Prod та bootsrap та Terraform: динамічний remote state з AWS S3 та multiple environments по директоріям, повернемось до цієї теми знов. Отже, вибрав все ж варіант з менеджментом бекендів через окремий проект Terraform, де в змінних маємо список проектів,… Читати далі »