Translate

понеділок, 11 травня 2020 р.

Pulumi. Part II: AWS Subnets and Fargate

Минулого разу  ми торкнулись причин появи нового IaС продукту Pulumi та спробували розібратись із базовими принципами його роботи на прикладі створення простого AWS S3 buсket-у. Наразі ж спробуємо описати на Python-інтерфейсі Pulumi власний VPC із підмережами та ECS Fargate кластер, тобто значно ближчий до реального життя випадок. Також побачимо як користуватись S3-бекендом для збереження стейтів (checkpoints в термінології Pulumi), та що робити із відсутністю lock-ів на паралельний запуск того ж коду. У кінці спробуємо поговорити про нинішній стан речей та перспективи Pulumi. Всі описані нижче приклади можна буде знайти у наступному github-проекті https://github.com/ipeacocks/pulumi-aws-example

Отже для подальших дій необхідні:

1. CUSTOM VPC/SUBNETS IN FEW AZs

Якою має бути мережа, котру буде не дуже соромно лишати для prod-цілей? Має бути як мінімум декілька публічний підмереж у різних зонах доступності регіону (AZ, availability zone), декілька приватних та стільки ж NAT-шлюзів для з'єднання приватних підмереж із зовнішнім світом. NAT-шлюзи зобов'язані мати постійні IP-адреси (EIP) і лежати в публічних підмережах аналогічних зон доступності. Трафік публічних підмереж має прямувати на Internet-gateway, а приватних - на відповідний NAT-гейтвей своєї ж зони доступності. Спробуємо це реалізувати.

Експортуємо значення Programmatic Access:

$ export AWS_ACCESS_KEY_ID=AKIA1234563J76A
$ export AWS_SECRET_ACCESS_KEY=/xLmpmdp1V3abcdefghklmnopabcdefg2nKRDKO
$ export AWS_REGION=us-east-1

Створимо S3-bucket для стейтів Pulumi:

$ aws s3api create-bucket \
      --bucket pulumi-states-zeezpha \
      --region us-east-1

$ aws s3api put-bucket-versioning \
      --bucket pulumi-states-zeezpha \
      --versioning-configuration Status=Enabled

Назва бакету має бути унікальною, тому необхідно обрати якусь власну назву.

Укажемо для Pulumi, що ми збираємось зберігати стейти в створеному вище бакеті S3:

$ pulumi login s3://pulumi-states-zeezpha

четвер, 7 травня 2020 р.

Pulumi. Part I: Overview

Загальні практики вказують на те, що зберігати налаштування як код корисно навіть для будь-яких відносно простих систем. Тобто усі параметри, їх зміни та авторів досить легко переглядати і відслідковувати в системі контролю версій, а за необхідності їх можна повертати до попередніх значень, якщо щось пішло не за планом. У разі якщо стан системи описаний як код, дуже легко та швидко підняти аналогічну копію такої системи. Це чудова тенденція і вона прослідковується у всіх популярних продуктах для різних команд: наприклад у Jenkins є Pipelines, для побудови інфраструктур в основному використовується Terraform, а система моніторингу Prometheus взагалі розроблялась без відповідних GUI інтерфейсів і всі налаштування відбуваються через код. Загалом будь-який новий продукт розробляється із розрахунку на те, його налаштування буде зберігатись як код.

Часто кожний продукт пропонує свою специфічну мову (DSL, Domain-specific language) для опису логіки роботи систем. Наприклад, у Puppet є свій DSL для опису стану, котрий хоче набути ресурс, а у Terraform-a свій власний HCL (HashiCorp Domain Language) для опису ресурсів. DSL загалом використовується для декларативного підходу - цікавить саме ресурс, котрий буде побудовано, а не те як він буде побудовано і з якими етапами. В силу своєї специфічності DSL мови мають багато недоліків і якісь відносно складні речі на DSL виглядають просто жахливо. Модулі Terraform, що описують хоча б дещо комплексну систему, аж занадто не елегантні і їх часто соромно переглядати чи показувати комусь: те що в мові загального користування виглядає лаконічно - в Terraform-і це ж саме перетворюється на рядок в 100 символів і більше, який ще до того не можна розірвати! Тому не раджу нікому дивитись в чужі модулі Terraform, це може вплинути на психічний стан. Вже згаданий Puppet також далеко прорвався вперед і страждає від тих самих проблем, коли читабельно виглядають лише нескладні стандартні ресурси.

Я, як активний користувач Terraform, часто приходив до висновку, що Terraform-у складно виконувати всі покладені на нього завдання конфігурації інфраструктури та виливки додатків. Із однієї сторони в нього є купа різних провайдерів і автори його позиціонують як "швейцарський ніж" сучасного інженера, а із іншої сторони в Teraform-і у якості if використовують count. Із Terraform наприклад не можна реалізувати щось на зразок перевірки існування змінної чи запустити декілька раз той самий модуль (count недоступний під час запуску модуля), чи обійти два списки водночас (адже count лише один) і тому подібне.

Знову ж, я не хочу сказати, що Terraform поганий і з ним неможливо жити. Але варто одразу розуміти, що це DSL, і з однієї сторони його код досить простий і декларативний, а з іншої, по причинам описаними вище, із ним варто звикати до постійного copy-paste. Але може не потрібно? Можливо існує щось інше? Так існує, це Pulumi.

Перший публічний реліз Pulumi з'явився в 2018 році, завдяки зусиллям однойменного стартапу, що базується в Сіетлі. За ідею проекту було взято написання системи, що полишить практики використання специфічних DSL мов та буде ближчим для розробників, таким чином скоротивши розрив між ними та devops/operation командами, котрі займаються їх підтримкою. Хоча це досить контроверсійні аргументи, але не будемо наразі на цьому зупинятись. Перейдемо до більш конкретних речей.

неділя, 28 липня 2019 р.

WireGuard VPN. Part II: Setup And Usage

Минулого разу ми говорили про ідеї, що підштовхнули до створення мережевого тунелю WireGuard, та алгоритми, що лежать в його основі. Цього ж разу спробуємо налаштувати WireGuard і пересвідчимось, що VPN is fun again.

1. SETUP


WireGuard ще не включено до кодової бази ядра Linux і наразі розповсюджується як DKMS-модуль. У якості сервера Wireguard працює лише на Linux, а у якості клієнта - під усіма популярними операційними системами, в т.ч. мобільними, в основному як userspace-імплементація на мові Go.

Для демонстрації можливостей WireGuard ми скористаємось Ubuntu 18.04. Для неї пакети розповсюджуються через ppa-репозиторій. На кожному вузлі, що буде з'єднуватись тунелем, необхідно встановити наступні пакети:

# add-apt-repository ppa:wireguard/wireguard
# apt update
# apt install wireguard

Можливо також потрібно буде встановити пакети-заголовки для ядра:

# apt install linux-headers-$(uname -r) linux-headers-generic

Кожен вузол повинен мати свою пару асиметричних ключів, тож згенеруємо їх на кожному хості:

# cd /etc/wireguard/
# umask 077
# wg genkey | tee privatekey | wg pubkey > publickey


неділя, 2 червня 2019 р.

WireGuard VPN. Part I: Intro

WireGuard  - сучасний мережевий тунель, що працює на 3 рівні моделі OSI, повністю реалізований в просторі ядра Linux (хоча клієнти можуть працювати і в просторі користувача) завдяки чому досягається вища швидкість передачі даних на відміну від OpenVPN. Останній має значно більшу кодову базу (~120 тисяч рядків коду проти 4000 WireGuard) і лише частково працює в просторі ядра.

WireGuard розповсюджується як відкрите програмне забезпечення під ліцензією GPLv2. Хоч продукт вже і достатньо зрілий, проте, як говорить основний розробник і автор проекту Джейсон А. Доненфельд, його поки не варто використовувати в production-цілях, адже код ще не пройшов належний рівень аудиту безпеки. В майбутньому його планують повністю включити в ядро, а наразі він розповсюджується як окремий DKMS-модуль. Про WireGuard вже позитивно висловлювались Лінус Торвальдс та Грег Кроа-Хартман, порівнюючи його із витвором мистецтва.


вівторок, 25 грудня 2018 р.

Graphite. Stack Based On ClickHouse

Graphite - це моніторингова система, що працює за push-моделлю, тобто отримує дані від вузлів, а не опитує їх. Вона чудово підходить для збирання та аналізу метрик і, завдяки вбудованому механізму ущільнення даних (storage aggregation/rollup/retention/downsampling), ці дані можуть зберігатись на протязі дійсно пристойного часу (декілька років).

Graphite був написаний Крісом Дейвісом (Chris Davis), співробітником компанії Orbitz в 2006 році. Мова програмування оригінального проекту - Python, але наразі майже всі компоненти Graphite можна замінити на сторонні, написані на мові Go. Більш того, навіть бібліотеку Whisper для роботи з базою Graphite можна замінити на альтернативні рішення зі збереженням даних в базі Cassandra, ClickHouse і т.п. Якраз про останній і піде мова цього разу.

Детальніше про оригінальний стек Graphite можна почитати в моїй попередній статті. До його недоліків можна віднести досить слабку продуктивність, неефективну роботу з дисковим простором, відсутність можливості масштабування бази даних і ін. Але це зовсім не значить, що він не підійде у випадках не надто високих навантажень.

Спершу пройдемось по кожному із компонентів та опишемо їх призначення.

  • Carbon-clickhouse - демон, що працює у якості заміни оригінального Carbon та може писати отримані метрики від третіх систем в базу даних ClickHouse.
  • ClickHouse - OLAP база даних від компанії Yandex. Пізніше розповім про неї детальніше.
  • Graphite-clickhouse - проміжне програмне забезпечення для роботи між API сервісом та базою ClickHouse.
  • Carbonapi - API-сервер Graphite, написаний на мові Go. Теоретично замість нього може бути використано Graphite-web (оригінальна імплементація API та веб-панель) чи Graphite-api (лише API на Flask фреймворку)
  • Grafana - веб-панель на Go/NodeJS для побудови та відображення метрик. Вміє опитувати Graphite "із коробки", підтримує всі його API-функції. Для Grafana-и увесь описаний вгорі стек буде виглядати як звичайна інсталяція Graphite-у.

елементи наведені пунктиром - опціональні

У свою чергу Carbon-clickhouse та Graphite-clickhouse - по деяких опосередкованих даних розробки компанії Mail.ru, а Carbonapi - Booking.com.

понеділок, 15 жовтня 2018 р.

Prometheus. From Metrics To Insight

Prometheus  - моніторингова система з відкритим вихідним кодом,  була створена та розроблялась в компанії Soundcloud з 2012, а в 2015 році представлена публічно і наразі розвивається незалежно.

Переважно написана на мові Go колишніми співробітниками компанії Google. Прототипом Prometheus виступала моніторингова система Borgmon. Ця моніторингова система має наступні переваги/недоліки/особливості:

  • багатовимірну модель даних, з часовими рядами, що ідентифікуються назвою метрики та парою ключ/значення;
  • гнучку мову запитів, що використовує цю модель;
  • pull-модель роботи серверу, збирання даних відбувається опитуванням вузлів, що моніторяться, по протоколу HTTP (хоча існує також Pushgateway, що працює по push-моделі і призначений для збирання метрик з недовговічних вузлів);
  • відсутність залежності від розподілених віддалених сховищ; кожен вузол Prometheus є автономним;
  • об'єкти моніторингу можуть додаватись вручну до основного конфігураційного файлу Prometheus чи автоматично через service discovery (Consul, API/теги AWS, GCP, Kubernetes, Openstack та інші).

Як вже було згадано, Prometheus - це моніторингова система, що працює за pull-моделлю. Тобто сервер опитує власноруч кожен вузол, що потребує моніторингу. На думку авторів проекту, така модель дещо краща за push-модель (коли метрики відправляються самостійно на сервер моніторингу без жодних запитів). Чудовим прикладом останньої є Sensu, про яку я вже писав декілька років тому.

понеділок, 16 липня 2018 р.

Terraform. Managing AWS Infrastructure

Terraform - це програма для побудови та безпечного обслуговування інфраструктури. Його основний розробник, компанія HashiCorp, представила перший реліз Terraform в 2012 році і наразі будь-хто може приєднатись до його розробки.

Ресурси в Terraform описуються як код на власній декларативній мові HCL (Hashicorp Common Language), тому він з легкістю може бути доданий до системи контролю версій на зразок Git (Infrastructure as Code). Ця особливість забезпечує зручне відслідковування змін коду, його рецензування, можливість налаштування якісного CI/CD та інше.

Terraform складається із двох основних частин: Core та Plugins. Terraform Core відповідальний за побудову графів залежності ресурсів, плану їх створення чи зміни та, за допомогою протоколу RPC, комунікує із плагінами. У свою чергу Terraform Plugins - це різноманітні реалізації API специфічних сервісів, на кшталт SDN (AWS, Azure, Google Cloud, OpenStack і інші), PaaS-платформ (Heroku), SaaS сервісів (наприклад, DNSimple, CloudFlare, Gitlab), self-hosted програмного забезпечення (Docker, MySQL, RabbitMQ) і неймовірної кількість іншого софту.

Далі буде розглянуто роботу Terraform з IaaS провайдером Amazon Web Services. Забігаючи наперед скажу, що Terraform не cloud-agnostic, тобто для побудови схожої інфраструктури, наприклад, у Google Cloud необхідно буде переписувати всі темплейти.


1. PREREQUIREMENTS


Terraform і його плагіни написані на мові Go зі статичним лінкуванням бібліотек і розповсюджується як готовий бінарний файли для всіх популярних і не дуже ОС. У якості клієнта я буду використовувати Ubuntu, тож завантажу відповідний архів:

$ wget https://releases.hashicorp.com/terraform/0.11.7/terraform_0.11.7_linux_amd64.zip
$ tar xvfz terraform_0.11.7_linux_amd64.zip
$ chmod +x terraform
$ sudo mv terraform /usr/local/bin/

$ terraform -v
Terraform v0.11.7

Надалі нам також знадобиться aws-cli, хоч він не обов'язковий і Terraform не потребує його присутності:

$ pip install awscli --upgrade --user

$ aws --version
aws-cli/1.15.37 Python/3.6.3 Linux/4.13.0-43-generic botocore/1.10.37