Хмарний вітрильник

Нещодавно студенту прийшла отака пропозиція, як вважаєте, хороші це умови чи ні? ☁️Хмарний вітрильник☁️

Хай гайз, з питаннячко було задане для наших менті, але цікаво що ви відповісте:

Як знаходячись на сервері (ssh) дізнатись його публічний IP?

Пишіть у коментарі відповіді) ☁️Хмарний вітрильник☁️

Шість стовпів архітектури на амазоні або як правильно білдити інфру з самого початку Всім хай! Хотіли давно ще обговорити тему архітектури інфраструктури, але все ніяк до цього руки не доходили))) Дуже часто маленькі проекти у разі успіху ростуть і з цього випливають багато проблем: "швидкі" та "прості" рішення стають костильними і не вивозять нових бізнесових викликів, тому рано чи пізно приходить етап редизайну архітектури (хоча варто було б це робити з самого початку х))) ) Тому, якщо ви білдите свій продукт на AWS, ми б радили почати досить детальне та свідоме планування за принципами AWS Well-Architected Framework. Цей фреймворк допомагає створювати надійні, безпечні та ефективні архітектури на AWS. На самому сайті амазону є багато документації на цю тему, але ми зупинимося коротко на шістьох стовпів хорошої архітектури в амазоні: 🦾 1. Операційна досконалість (Operational Excellence) Перше що треба робити — це максимально зробити прозорою інфраструктуру. Моніторинг та автоматизація рутинних процесів — маст хев. В супротивному випадку у разі збоїв відтрейсити причину фейлу буде важко, якщо не неможливо. 🛡 2. Безпека (Security) Дуже часто безпекою нехтують, наприклад, видають юзерам всі ІАМ дозволи, або якимось сервісам дають всі права. Поки ваш продукт непопулярний це може бути і не критичним, але згодом з ростом і впізнаванністю продукту це може стати великою проблемою (всі пам'ятаємо Київстар, ага?). Тому треба забезпечити максимальну ізоляцію всіх наявних ресурсів, надавати мінімальні дозволи як девелоперам так і серівсам, впроваджувати безпековий моніторинг тощо. 🔗 3. Надійність (Reliability) Забезпечення безперервної роботи систем, навіть у разі відмови компонентів. Умовно кажучи, у вас завжди має бути план Б на випадок якщо щось з інфрою пішло не так. Розраховувати, наприклад, на те, що RDS, наприклад, ніколи не зламається досить наївно, тому цей стовп закликає до стретегії резервного копіювання даних, розробку disaster recovery plan (перед тим як disaster стався) і безпосередньо розробка політики масштабування. 💻 4. Продуктивність (Performance Efficiency) Тут все просто: треба розуміти реальний лоад продукту і визначити, які ес2 інстанси (або взагалі лямбди) вам підійдуть, відносно чого їх скейлити, як скейлити і як моніторити. 💵 5. Оптимізація витрат (Cost Optimization) Далі необхідно думати над костом інфраструктури, чим більша інфра стає тим детальніше треба слідкувати за костом, адже кост може вирости у найнеочікуваніших місцях. Тому тут треба робити моніторинг костів і завчасно думати над тим, щоб юзати фічі амазону для збільшення кост ефішенсі (наприклад. спотові інстанси або резервди). 🌿 6. Сталий розвиток (Sustainability) Можливо для українського сегменту ІТ це буде трохи незрозумілим пунктом, але для бізнесу важливо мати високу соціальну репутацію, тут амазон має на увазі врахування екологічних аспектів при проектуванні та експлуатації систем, а також включає зниження вуглецевого сліду та ефективне використання ресурсів. 🔧Наостанок можете чисто забави ради заюзати таку тулу як AWS Well architected tool яка вам вивалить стіну рекомендацій що вам треба робити щоб досягти успіху у дизайні архітектури Якщо вам сподобався пост — пишіть у коментарях які з стовпів ви б хотіли щоб ми розглянули детальніше (ну і з вас лайкосік для мотивації☺️) ☁️Хмарний вітрильник☁️

🖼️Що таке AWS API Gateway? 🥴Уявіть собі, що ви створюєте популярний мобільний додаток для бронювання готелів (аля booking.com). Ваш додаток повинен дозволяти користувачам шукати доступні номери, переглядати деталі готелів, бронювати номери та оплачувати їх. Вам потрібна одна точка входу для аутентифікації та зв'язку між фронтендом та бекенд сервісами. Звичайно, можна все налаштувати самому у кубері або AWS ECS, але якщо ви не хочете над цим запарюватись, то на допомогу прийде AWS API Gateway! 🔸Що це таке? AWS API Gateway – це повністю керований сервіс, який дозволяє легко створювати, публікувати та масштабувати API для будь-якого розміру програми. Як сказано вище, він є мостом між вашими клієнтами (веб-додатками, мобільними додатками, IoT пристроями тощо) та вашими бекенд-сервісами. 🔹Що він може? Перше, це тісна інтеграція з іншими продуктами AWS: Lambda, DynamoDB, S3 та іншими, що дозволяє створювати складні бекенд-системи, і це не вимагатиме аж значних зусиль. По-друге, гейтвей має хорошу інтеграцію з аутентифікаційними сервісами, наприклад, підтримка AWS IAM ролей, AWS Cognito, OAuth2.0, а також можливість використання ключів API для контролю доступу. По-третє, це логування через Cloudwatch, що вже знімає з вас відповідальність за розробку моніторингової системи з нуля І останнє, це масштабування: на відміну від подів в кубері вам не треба думати над тим, чи витримає ваш гейтвей навантаження — це за вас робить амазон. 🔸Коли його варто і не варто юзати 😃На наш погляд, API Gateway вписується в архітектуру проекту де часто використовуються лямбди або не хочеться налаштовувати традиційний нетворкінг в кубері (є ціла стаття як замість інгресу юзати АРІ гейтвей). В решті, АРІ гейтвей зручний там де не хочеться надто багато морочитись над обслуговуванням інфри під проект. ☹️З мінусів: місцями неочевидний кост (може прилетіти кост не стіки за АРІ скіки за логи в клаудвотч) і в решті зворотня сторона повного обслуговування амазоном: чим більше все роблять за тебе, тим менше ти можеш кастомізувати солюшн і тим менш ти гнучкий у можливій міграції сервісів на інші клауди або у власний дата центр. Тому якщо ви не впевнені у тому чи буде ваш продукт на амазоні завжди або чи не буде там специфічних солюшнів — то краще обрати більш гнучкі, але водночас і складніші у обслуговуванні рішення. Сподобався пост? Став вподобайку!😎 ☁️Хмарний вітрильник☁️

Можливо, ви вже помітили, що Vodafone не працює. Оце так задеплоїли в прод.

📦Що таке Кафка? ЇЇ сила та наша біль 🫣Минулий раз ми поговорили що таке взагалі меседж брокери і от його один з найяскравіших прикладів — кафка. 🤓Кафка, як було раніше сказано, є найбільш надійною і масштабованою, тому часто її використовують для хайлоадів, але за рахунок чого це досягається? 😁Оскільки кафка це розподілена система, це значить що вона може розгортати в паралель багато брокерів. Це означає і більшу пропускну здатність і більшу витривалість системи за рахунок великої кількості точок відмов. 🥴З іншої сторони, є такі поняття як партиції та топіки. Топіки — це по суті логічні канали через які передають конкретні повідомлення від продюсера до консюмера, а партиції — це розбиття на кілька частин одного топіку і розподілення його між брокерами. 🙏В свою чергу партиції можуть мати кілька реплік, щоб забезпечити високу надійність у разі відмови одного з брокерів. 🫡Окрім того, якщо сервісам треба повернутись до колишніх повідомлень, то вони це роблять легко завдяки тому що кафка має логоподібну систему зберігання меседжів (у вигляді логів якщо простіше) 😎Ну і плюс, кафка найбільш ефективно юзає диски (до 600 мб/с по бенчмаркінгу), що прям дуже топово для хайлоадів 👎А що ж по мінусам? 🫣Звичайно було б дивно якби не було б тут недоліків і найголовніший з них — адміністрування. Навіть Strimzi в кубері чи AWS MSK не дають вам гарантії, що не доведеться сидіти і читати ретельно документацію як працюють партиції, як дати зовнішній доступ до кафки або як правильно спланувати навантаження (і це не кажучи про моніторинг такої бандури) 🫣Окрім того, для того щоб було самовідновлення кафки та його масштабованість юзають ZooKeeper — тула яка буквально слідкує за цим всім зоопарком топіків, партицій ітд ітп. Проблема тут в тому, що сам по собі ZooKeeper є вузьким місцем для масштабування і на великих проектах саме він є причиною сповільнення швидкодії кафки кластера в цілому. 😬Короче кажучи, перед обранням потрібної технології подумайте кілька разів, бо може так статись що вам вистачить простенької AWS SQS замість величезної кафки ☁️Хмарний вітрильник☁️

Зростає попит на DevOps. Аналітика Djinni радує на цьому тижні 🚀

📨Що таке меседж брокери і навіщо вони потрібні? 🤪Уявіть, що у вас є онлайн-магазин. Коли клієнт робить замовлення, його дані повинні бути передані кільком різним сервісам: для обробки платежу, оновлення складу, повідомлення клієнту та логістики тощо. 🏃‍♂️При цьому сервіси мають обробляти запити асинхронно і не залежати один від одного. Якщо умовно якийсь центральний мікросервіс (оркестратор) буде по черзі відсилати одне і те ж повідомлення по черзі кожному то швидкодія додатку буде кепська. Що робити? 🙄Саме тому придумали таку річ як меседж брокери — це програмний компонент, який приймає повідомлення від одного додатку і передає його іншому. Що меседж брокер може робити: 🔸Прийом повідомлень: брокер отримує повідомлення від різних джерел. 🔹Зберігання повідомлень: повідомлення можуть бути тимчасово збережені, якщо отримувач не готовий їх прийняти. 🔸Маршрутизація повідомлень: брокер визначає, куди слід направити повідомлення на основі конфігурацій та правил. 🔹Доставка повідомлень: брокер доставляє повідомлення до відповідних отримувачів. 😱Саме завдяки меседж брокеру можна розробляти складні event-driven архітектури додатків, які можуть витримувати шалені навантаження і працювати безперебійно. 😎Серед яскравих представників меседж брокерів є Apache Kafka, Rabbit MQ, Active MQ. Насправді кожен з цих інструментів має свої переваги, наприклад, Кафка визнана найбільш надійною та масштабованою, у той час як Ребіт більш гнучкий у налаштуваннях. Окрім того, є різні варіації таких інструментів у клаудах, наприклад, у амазону це SQS та MSK Став лайк, якщо хотів би у наступному пості розбір Кафки☺️ ☁️Хмарний вітрильник☁️

👩‍💻 Що таке CNI у Kubernetes та навіщо це потрібно? 😱 Думаю, якщо ви трохи працювали з мережами або принаймні в курсі як вони працюють: наприклад, ми розуміємо що таке IP адреса ЕС2 інстансу, тобто адреса через яку можна достучатись до самого серверу. А як щодо подів? У кожного пода є своя якась IP адреса, між подами відбувається певний обмін запитами і... Як це в біса працює? 🤢 Відповідь коротка: від нетворкінгу в кубері можна здуріти, є наприклад хороший відос який пояснює як працює мережа в кубері 🫠 В цьому пості ми обговоримо один з компонентів мережі кубера — CNI CNI (Container Network Interface) - це стандарт для налаштування мережевих підключень контейнерів. Він був розроблений для того, щоб полегшити конфігурацію мережевих інтерфейсів контейнерів у різних контейнеризованих середовищах, таких як Kubernetes 🤯 Коли в Kubernetes створюється новий под (pod), CNI відповідає за налаштування його мережевого інтерфейсу. Це робиться за допомогою спеціальних плагінів, які налаштовують IP-адреси, маршрутизацію та інші параметри мережі. 🤪 Усі ці приколи з маршрутизацією та ІР алокацією можуть бути гнучко налаштовані через плагіни CNI, наприклад, Flannel, Cilium, Calico або Weave. Якісь з них мають заточку на балансинг, а якісь на безпеку, детальніше про плагіни можна буде поговорити в окремих постах. 🤔 Для початківця у девопс це може бути не зовсім проста і навіть актуальна тема, але коли діло доходить до хайлоад продуктів або таких, що вимагають високої безпеки (той самий фінтех), можливостями CNI і його плагінів нехтувати не варто Якщо хочете пост про плагіни CNI — ставте лайк, і на наступному тижні він буде 😎 ☁️Хмарний вітрильник☁️

Як оформити гарне резюме? Швидкий чекліст! Мабуть, цей час настав: потроху будемо розповідати і про софт скіли🤩 Скласти резюме це водночас легка і складна задача, але від неї залежить чи взагалі ти зможеш добратись співбесіди, адже часто ще на етапі твого "паспорту" вас легко можуть відсіяти Тож... Пропонуємо вам простий чекліст того, що варто мати у себе в резюме: ✅Зайдіть на джин та подивіться 10 вакансій, зрозумійте чого хоче роботодавець від вас🤔 ✅Замість того щоб мучатись на резюме у ворді, краще створіть його у canva🙂 ✅Ваше резюме не має бути довшим ніж 1 сторінка🙄 ✅Додайте свої контакти: лінкедин, телеграм, пошта, гітхаб. 😐 ✅Гітхаб було б круто оформити — отут приклад🤔 ✅Визначте конкретну роль на яку ви претендуєте: не пишіть одразу DevOps/NOC/SRE🗒 ✅Для категорії софт скілів не треба писати шаблоні прикметники, напишіть краще про якості які корисні в бізнесі, наприклад "Маю досвід у спілкуванні з замовниками", "Можу правильно розставити пріоритети", "Люблю проявляти ініціативність" тощо.🗑 ✅У досвіді роботи наведіть найбільш цікаві та корисні з точки зору бізнесу кейси виконаних задач😎 ✅Підпишіть своє резюме власним прізвище а не CV_aboba.pdf😎 Збережіть ці поради до себе: думаю вони точно вам стануть в нагоді👍

👦А що окрім мінікубіка?👩‍💻 Часто новачки починають знайомитись з кубером через мінікуб — запускають віртуалку на локалці і розгортають там вже кластер, з яким можна працювати. Проблема часто в тому, що сам по собі мінікуб дуже порізаний за своїм функціоналом, а іноді хочеться попрацювати в клауді, наприклад, AWS, а мінікуб там ставити трохи накладно, а от EKS — занадто дорого. Не кажучи про те, що у когось на машині окремо може не стати віртуалка.. Тому хочемо показати вам добірку цікавих дистрибутівів кубера які так само можуть підійти для вашого навчання з цією платформою: 🔸k3s — дистрибутив що важить ледь 100 мб і розгортається за 5 секунд. Не вимагає багато ресурсів (особисто адмін ставив на ноду t3.small і як-не-як, але працювало) + саме встановлення можна задати через баш скрипт, а потім вкласти у тераформ. 🔸k3d — теж досить легковажна версія кубера (по суті той же k3s), але її головна відмінність полягає в тому, що він працює на основі контейнерів, де власне контейнер виступає як "віртуальна нода", це досить зручно, коли не хочеться на клауді плодити багато інстансів і хочеться попрацювати з мультинодовістю (наприклад. правильно асайнити поди на ноди). Тим не менш. сама по собі механіка роботи на докері може викликати деякі нюанси в роботі, тому тут дивіть уважно. 🔸k0s — також мінімальний дистрибутив кубера, однак окрім всього іншого може підтримувати роботу на ARM процесорах. Тому якщо комусь захотілося наприклад погратись з AWS EC2 Graviton інстансами (про них ми ще поговоримо), це також дуже хороший варіант. 🤔Фан факт: k3s використовується і в комерції, не тільки в тренувальних цілях. Як правило такі легкі дистрибутиви добре залітають для IoT та Edge Computing. ☁️Хмарний вітрильник☁️

🔧 Що таке PV та PVC у Kubernetes і навіщо вони потрібні? Уявіть, що ви розробляєте додаток для обробки зображень, який зберігає усі завантажені користувачами файли. Якщо ваш додаток працює в Kubernetes, потрібно забезпечити надійне зберігання даних, щоб вони не зникли при перезавантаженні подів. Саме тут стають у нагоді Persistent Volumes (PV) та Persistent Volume Claims (PVC). 🔹 Persistent Volume (PV): Це сховище даних, яке адміністратори налаштовують у кластері Kubernetes. Воно може бути фізичним диском на сервері або мережевим сховищем (у амазону це наприклад EBS). PV дозволяє зберігати дані незалежно від життєвого циклу подів. 🔹 Persistent Volume Claim (PVC): Це запит від поду на використання певного об'єму зберігання з певними характеристиками, наприклад, розміром або типом зберігання. PVC діє як посередник між подами та PV, дозволяючи подам використовувати ресурси зберігання без прямого доступу до них. 📌 Навіщо це потрібно? PV та PVC забезпечують, щоб ваші дані були надійно збережені та доступні незалежно від того, що трапляється з подами. Це важливо для додатків, які потребують зберігання великих об'ємів даних, таких як бази даних або файлові сховища. Наприклад, ваш додаток для обробки зображень може легко зберігати і отримувати файли завдяки PVC, навіть якщо сам додаток перезапускається або переміщується між нодами. Таким чином, використовуючи PV та PVC, ви забезпечуєте надійне зберігання даних, що робить ваші додатки більш стійкими та гнучкими! 🚀 👉Детальніше як налаштовується PV та PVC👈 ☁️Хмарний вітрильник☁️