Kulebiac Save

Фреймворк на основе CDKTF для развертывания облачной инфраструктуры любой сложности

Project README

KulebiaC

logo

Telegram Url HitCount

Развертывание необходимой облачной инфраструктуры из одного простого yaml-файла. Данный инструмент разрабатывается и поддерживается компанией ITSumma, мы с радостью ответим на ваши вопросы в телеграм чате …

Поддерживаемые провайдеры:

  • YandexCloud
  • SberCloud

Как воспользоваться?

Установка зависимостей

 yarn install
 cdktf get

Для YandexCloud

  • Создать каталог (1 каталог == 1 окружение)
  • Получить API-token для взаимодействия с YandexCloud
  • В каталоге создать s3-бакет для хранения state
  • В каталоге создать сервис-аккаунт, назначить ему роль admin и создать статический ключ доступа (для взаимодействия с S3-Storage)

Для SberCloud

  • Создать IAM-пользователя с admin-правами в облаке; получить AccessKey, SecretKey Подробнее...
  • В сервисе OBS создать s3-бакет для хранения state

Опционально (для установки различных компонентов в k8s-кластера)

helm repo add jetstack https://charts.jetstack.io
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
helm repo update

Подготовка конфигурации

Запуск плана/деплоя

cdktf diff <stack_name>
cdktf deploy <stack_name>
cdktf output <stack_name> --outputs-file <path_to_output_file>  --outputs-file-include-sensitive-outputs true

Запуск из настроенного окружения в docker

docker run --rm --name kulebiac -v ${PWD}/config.yaml:/app/config.yaml --env-file ${PWD}/.env -ti ghcr.io/itsumma/kulebiac/kulebiac:v1.6.0 bash
# далее внутри докера выполняем
cdktf diff production
cdktf deploy production

Запуск из gitlab ci (Для YandexCloud)

Для запуса нужен предварительно настроенный раннер, который может запускать докер образы

В код репозитория кладём config.yaml

в Settings гитлаба в секцию CI/CD прописываем нужные нам Variables: KULEBIAC_VERSION, KULEBIAC_YC_TOKEN, KULEBIAC_CLOUD_ID, KULEBIAC_FOLDER_ID, KULEBIAC_STATE_BUCKET_NAME, KULEBIAC_ACCESS_KEY, KULEBIAC_SECRET_KEY, KULEBIAC_STACK

Прописываем в .gitlab-ci.yml примерно следующее

stages:
  - deploy

deploy:
  stage: deploy
  image: ghcr.io/itsumma/kulebiac/kulebiac:${KULEBIAC_VERSION}
  variables:
    YC_TOKEN: ${KULEBIAC_YC_TOKEN}
    CLOUD_ID: ${KULEBIAC_CLOUD_ID}
    FOLDER_ID: ${KULEBIAC_FOLDER_ID}
    STATE_BUCKET_NAME: ${KULEBIAC_STATE_BUCKET_NAME}
    ACCESS_KEY: ${KULEBIAC_ACCESS_KEY}
    SECRET_KEY: ${KULEBIAC_SECRET_KEY}
  script:
    - cp config.yaml /app && cd /app
    - cdktf diff ${KULEBIAC_STACK} || cdktf diff ${KULEBIAC_STACK} #если раннер в России, первая команда упадёт с ошибкой изза блокировок со стороны hashicorp. Нужно просто повторить её
    - cdktf deploy ${KULEBIAC_STACK} --auto-approve
  tags:
    - docker

(tags прописываем соответственно настроенному раннеру)

Возможности KulebiaС

Описание облачной инфраструктуры в виде terraform сценариев может занимать очень много времени, модули, как правило, получаются довольно специфичными и тяжелыми в реиспользовании и не обеспечивают необходимого PaaS подхода к описанию инфраструктуры – каждый контур, как правило, описывается отдельно и имеет свой порядок и план выполнения. Мы разработали данный инструмент для возможности предоставления именно платформенного подхода к использованию облачных ресурсов в рамках методологий IaC и DevOps:

  1. Инфраструктура описана в доступном формате (yaml)
  2. Возможность довольно легко и быстро разворачивать новые окружения без дополнительного изменения декларативного описания инфраструктуры
  3. Вся инфраструктура разворачивается за один проход инструмента

Принцип работы

Kulebiac реализован на базе инструмента Cdktf, в который мы портировали наши Terraform-модули (в частности - для YandexCloud) в TypeScript-формат (не через генерацию биндингов), что позволило нам:

  • гораздо гибче работать с вложенными итерациями по массивам
  • динамически кодом создавать дополнительные вспомогательные провайдеры - например, после создания двух кластеров k8s, через вспомогательные провайдеры можно установить в эти кластеры различные компоненты (ingress-контроллер, cert-manager)
  • использовать строгую типизацию для входных параметров модуля с возможностью использования опциональных переменных с дефолтными значениями (исходно в hcl так нельзя)

В итоге работы инструмента вы получаете сгенерированный в json формате файл конфигурации terraform, который применит все в конкретном каталоге. Также, основываясь на сущности STACK предоставляемой cdktf, с помощью единого конфигурационного файла можно описать несколько изолированных друг от друга окружений (в данный момент - на основе YandexCloud - окружения можно сетапить в разные Folder/Cloud - в дальнейшем, использовать абсолютно различные провайдеры) - аналогичный пример - https://terragrunt.gruntwork.io/

Примеры использования

  • Нужна скорая инфраструктура для стартапа – Kubernetes + стандартные аддоны + Postgres - пример №1
    • результат – VPC, Nat-Instance, Kubernetes (+ autoscaling) + Postgres, S3-PVC
  • Нужно dev и prod окружение, Kubernetes, Postgres, RabbitMQ, Gitlab - пример №2
    • результат – раздельные контуры на уровне сети, безопасность, instance с cloud-init, S3-PVC, прерываемые ASG на dev Kubernetes
  • Необходимо создать S3-бакеты для хостинга статичных сайтов и хранения загружаемого контента, интегрировать K8S с Lockbox для синхронизации секретов (на основе) - пример №3
    • результат - VPC, Nat-Instance, Kuberenetes с синхронизацией Lockbox пример секрета для приложения, секреты в Lockbox можно задавать как в открытом виде, так и через переменные окружения
  • Создание ComputeInstanceGroups + NLB (внешний и внутренний балансировщик) + хелс-чеки + конфигурация autoscale пример №4
  • Создание MySQL, Postgres, Redis, MongoDB, ClickHouse с автоматической интеграцией паролей от пользователей БД в секреты LockBox пример №4
  • Необходима базовая инфраструктура для WEB-проекта: Managed K8S, RDS (Postgres), S3 (static-website-hosting) в SberCLoud - пример №6

Version History

  • 1.8.0 (sbercloud integration, docker/docker-compose with instance groups)
  • 1.7.1 (preemptible ComputeInstance/InstanceGroups)
  • 1.7.0 (InstanceGroups, NLB, Lockbox integration with DB)
  • 1.6.0 (KMS, LockBox, S3-CORS, S3-Website-hosting, Docker + CI/CD examples)
  • 1.5.0 (MySQL, MongoDB, Redis, ClickHouse, минорные оптимизации и рефакторинг)
  • 1.4.0 (рефакторинг PG-модуля, доступы к PG для DataLens, DataTransfer...)
  • 1.3.0 (дополнительные статические маршруты, зависимость между SA и K8S)
  • 1.2.0 (оутпуты для модуля Instances)
  • 1.1.0 (все корневые массивы для ресурсов в стэке с обязательных переключены на опциональные)
  • 1.0.0

License

Apache License 2.0, see LICENSE.

Acknowledgments

Ссылки:

Группа Telegram

Разрабатывается и поддерживается itsumma.ru

Open Source Agenda is not affiliated with "Kulebiac" Project. README Source: itsumma/kulebiac
Stars
90
Open Issues
0
Last Commit
6 months ago
Repository
License

Open Source Agenda Badge

Open Source Agenda Rating