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

#memes Без коментарів)

#memes ☁️Хмарний вітрильник☁️

#memes

#terraform 🌐 Використання S3 як Віддаленого Backend у Terraform Сьогодні обговоримо ключову концепцію у керуванні інфраструктурою як кодом (IaC) за допомогою Terraform: використання Amazon S3 як віддаленого backend. 🔧 Що таке Terraform Backend? Backend у Terraform визначає, де та як зберігати стан інфраструктури (state). За замовчуванням, Terraform зберігає стан локально у файлі terraform.tfstate, але для командної роботи та забезпечення безпеки краще використовувати віддалені backends. 💡 Чому вибирають S3 як Backend? AWS S3 (Simple Storage Service) - це надійне, масштабоване, та безпечне рішення для зберігання файлів. Використання S3 як backend для Terraform пропонує: 1. Централізоване зберігання стану: забезпечує одне місце для всієї команди для доступу та управління станом. 2. Безпеку: використовуючи ролі та політики AWS, можна контролювати доступ до стану. 3. Версіонування: S3 підтримує версіонування файлів, що дозволяє відновлювати попередні стани. Шифрування: Можливість шифрувати стан у сховищі. 🛠 Як Налаштувати S3 як Backend? 1. Створіть Bucket у S3: Переконайтеся, що bucket має унікальну назву та включене версіонування. 2. Налаштування Backend у Terraform конфігурації:

terraform {
  backend "s3" {
    bucket = "my-terraform-state-bucket"
    key    = "path/to/my/key"
    region = "us-east-1"
  }
}

3. Ініціалізуйте Terraform: Запустіть terraform init для ініціалізації з новими налаштуваннями backend. 📚 Кращі Практики: Захистіть ваш S3 Bucket: використовуйте політики доступу та шифрування для забезпечення безпеки. Використовуйте DynamoDB для блокування стану: це запобігає одночасному застосуванню змін різними користувачами. 🌟 І наостанок, використання Amazon S3 як backend для Terraform є відмінним рішенням для керування станом інфраструктури в масштабах команди. Це не тільки забезпечує безпеку та централізацію, але й додає гнучкість у керуванні версіями стану. ☁️Хмарний вітрильник☁️

#memes ☁️Хмарний вітрильник☁️

Хлопці та дівчата, всім привіт! У нас в планах є ідея зробити для вас аля тестового завдання на роботу для джун/мідл позиції девопса, яке ви потім можете використовувати як портфоліо Нам важлива ваша думка: скажіть будь ласка, чи цікава вам така активність?

#AWS 🪣Про класи S3 бакетів Раніше ми з вами обговориле що таке взагалі S3 бакети. Не буде зайвим також вам розповісти які класи бакетів взагалі існують: S3 standard: цей клас найкраще підходить для даних, які вимагають високої доступності та часто використовуються. Він забезпечує найвищий рівень продуктивності та надійності, зберігаючи копії даних у різних зонах доступності. S3 intelligent-tiering: це варіант для даних з непередбачуваною частотою доступу. Цей клас автоматично переміщує дані між рівнями доступу, оптимізуючи вартість, коли дані рідко використовуються. S3 standard-infrequent access (S3 standard-ia): цей клас підходить для даних, які не часто використовуються, але коли до них звертаються, потрібен швидкий доступ. Він пропонує нижчу вартість зберігання в порівнянні з S3 Standard, з додатковими зборами за вилучення даних. S3 one zone-infrequent access (s3 one zone-ia): схожий на Standard-IA, але дані зберігаються в одній зоні доступності. Це робить його більш економічним, але збільшує ризики, пов'язані з втратою даних у разі проблем з цією зоною. S3 glacier: призначений для архівування даних, до яких рідко потрібен доступ. Цей клас пропонує дуже низьку вартість зберігання, але час вилучення даних може становити від декількох хвилин до кількох годин. S3 glacier deep archive: це найбільш економічний клас для довгострокового зберігання даних. Він ідеально підходить для даних, до яких дуже рідко потрібно звертатися, але важливо зберігати на тривалий термін. Вилучення даних може займати до 12 годин. 📝Висновок На початку свого шляху у девопсі ви скоріш за все будете використовувати стандартний S3 бакет. Однак чим більш специфічні задачі перед вами постають, особливо у питанні "як часто ми будемо використовувати ці данні?" та "скільки коштуватиме нам те чи інше зберігання дати?" — тим більше вам доведеться працювати з різними видами бакетів. ☁️Хмарний вітрильник☁️

#fun_fact #terraform 👩‍💻🤯А чи знали ви що є така команда у тераформі як terraform fmt? Вона допомагає відформатувати ваш код згідно зі стандартами тераформу, прям як на скріні. Дуже зручно, коли влом прописувати всюди таби вручну☺️ ☁️Хмарний вітрильник☁️

#docker 🐳Based Docker image При роботі в клаудах розмір імеджу не є надто критичним (хіба що якщо сам імедж не складає по 10-20 гігів, в залежності від призначення імеджу. Водночас розробникам, себто вашим колегам, хотілося б аби час виконання CI/CD пайплайну виходив трошки швидше. Наприклад, навіщо заради одного нещасного фікса чекати деплою по 10-15 хвилин? Саме для цього і існує метод базового імеджу — коли ви всі необхідні залежності, бібліотеки, модулі, драйвери тощо уміщаєте в один єдиний образ, поверх якого ви просто додаєте власний код. 👷Приклад Дуже добре цей метод працює саме з пайтоном, ось як виглядає докерфайл до оптимізації:

FROM python:3.9

WORKDIR /usr/src/app

COPY requirements.txt ./

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "./your-app.py"]

Тепер робимо два докерфайли — один для базового імеджу, інший для сервісу:

FROM python:3.9-slim

COPY requirements.txt /tmp/

RUN pip install --no-cache-dir -r /tmp/requirements.txt

RUN rm /tmp/requirements.txt

WORKDIR /usr/src/app

FROM your-custom-python-image:latest

COPY . /usr/src/app

CMD ["python", "./your-app.py"]

Вуаля! Маємо базовий докер імедж, який можна буде використовувати для кількох різних застосунків, а через те, що вам не треба кожен раз при білді встановлювати одні і ті ж модулі ви значно економите час білду. 📕 Домашнє завдання для новачків Як ви думаєте, для яких мов програмування у сервісах мультистейдж та базовий імедж працюють краще? ☁️Хмарний вітрильник☁️

#memes Мем старий як кубернетес, але іноді це жиза ☁️Хмарний вітрильник☁️

#memes Коли вперше зустрівся з докером ☁️Хмарний вітрильник☁️

#containerization #k8s 👩‍💻Поди у кубернетесі Почнімо потроху вам розповідати про елементи кубернетесу і почнімо з найпростішого і найзрозумілішого — поди. ‼️Важливо: перш ніж сідати вивчати кубер, наполегливо радимо спочатку розібратися в докері 🌟Отже, що ж таке Pod в Kubernetes? Pod - це найменша та найпростіша одиниця в моделі Kubernetes. Дуже часто коли кажуть под мається на увазі той самий знайомий нам контейнер у докері, але насправді це не зовсім так. По-суті, це обгортка для одного або навіть декількох контейнерів, які запускаються разом на одному вузлі. Як правило, у поді використовується один контейнер + допоміжний контейнер (sidecar), однак про нього поговоримо у наступних постах. 🔍 Основні характеристики: Спільні ресурси: поди ділять однакову IP-адресу, порти, об'єм пам'яті, що дозволяє контейнерам ефективно спілкуватися. Залежності та зберігання: вони можуть спільно використовувати файлові системи, обмінюватися даними через локальну мережу. Життєвий цикл: pod має короткий життєвий цикл. Якщо він зупиняється або знищується, контейнери всередині нього також припиняють роботу. Приклад поду:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

У данному прикладі ми в чисту написали маніфест файл для нжінксу, чи не виглядає дуже схоже з докер-компоуз файлами?) ✨ Подсумок: Pods у Kubernetes - це більше, ніж просто контейнер; це фундаментальна одиниця, що дозволяє Kubernetes бути гнучким, але потужним інструментом в руках DevOps-інженерів. На основі маленьких подів будуються багато інших конструктів, наприклад, деплойментів, про які буде наступний пост 📕Домашнє завдання для початківців: 1. Спробуйте розібрати повністю з чого складається YAML файл, наведений у пості 2. Спробуйте взяти будь-який докер-компоуз файл з інтернету (наприклад, гітхаб) і переписати його як под ☁️Хмарний вітрильник☁️

#containerization #k8s 💀Kubernetes: що то за звір та як його приборкати? Здається, на джині, доу чи лінкедині зараз не існує вакансії на девопса, де не було б вимоги знати кубернетес. І насправді багатьох світчерів чи просто початківців у девопс ця технологія лякає. Як мінімум, це виникає тому що у мережі кубер має ореол чогось надскладного, аля чорної магії чи вищої математики для гуманітарія. Але нашій команді здається, що будь що може бути простим, якщо з цим працювати практично, тому почнімо з основи ❓Що таке Kubernetes? Kubernetes - це відкритий інструмент для автоматизації розгортання, масштабування та управління контейнеризованими додатками. Уявіть собі, що ви будуєте модель міста, де кожна будівля - це контейнер з вашим додатком (наприклад, один контейнер = один мікросервіс). Кубернетес тут - це міська адміністрація, яка допомагає управляти будівлями: вирішує, де їх розташувати, як їх масштабувати, забезпечує їх електрикою (ресурсами) і т.д. 👨‍💻Як почати працювати з кубером? Думаю ми вам Америку не відкриємо, але насправді існує сотні курсів про кубернетес на тому ж юдемі. Також є документація в кубернетесі, але скоріш за все вона вас ще більше налякає, тому пропонуємо наступні кроки: 1. Встановіть на свою локальну машину Minikube та kubectl 2. Створіть под (контейнер) з нжінксом імеджем 3. Після того як створите под спробуйте зробити expose вашого поду (так і гугліть how to expose pod in kubernetes) Якщо ви все правильно зробили — вам відкриється з локалхосту стартова сторінка нжінкс і власне ви створили першу інфраструктуру в кубернетесі😁 🥳 🤔Звичайно, є багато нюансів як і в самому кубері, так і в додаткових інструментах накшталт хелму та арго, але про них трохи пізніше) 🤷‍♂️Що робити потім? Далі у вас є кілька шляхів: 1. 🤔 Спробувати самостійно на основі якогось пет проекту розбудувати на локальній машині кубернетес кластер АБО 2. 👍Спробувати пройти нашу менторську програму, де кубернетес розглядається в системі з клаудами та CI/CD ☁️Хмарний вітрильник☁️

#AWS 💾Amazon EFS: що то таке? Amazon Elastic File System (EFS) – це повністю кероване хмарне сховище, що забезпечує легкість та гнучкість NFS (Network File System) з перевагами хмарної інфраструктури AWS. Це дозволяє системам та додаткам легко спілкуватися з даними, збереженими в хмарі, як ніби вони знаходяться на локальному диску. 👨‍🔧А як це працює? EFS працює на основі NFS, що дозволяє додаткам, запущеним у хмарі або на локальних серверах, достукатися до файлів через стандартний протокол мережевого файлового сховища. Основна відмінність від традиційних файлових систем полягає у тому, що EFS автоматично масштабується, забезпечуючи потрібну ємність та пропускну здатність без необхідності заздалегідь визначати параметри сховища. ❔А в чому різниця з S3? EFS найкраще підходить для випадків, коли потрібна спільна файлова система для декількох EC2 інстансів, що підтримує файлові операції в режимі реального часу із низькою затримкою, наприклад, для застосунків, що використовують спільні файли або потребують POSIX-сумісності. У той час як S3 краще використовувати для великомасштабного зберігання даних, веб-хостингу статичного контенту, архівування, резервного копіювання та як сховище для даних, що аналізуються різноманітними сервісами AWS. 📕Домашнє завдання для новачків: спробуйте розписати EFS як ресурс у тераформі, визначивши зону доступності (AZ), performance_mode, lifecycle_policy, а також радимо розібратись з цими параметрами та за що вони відповідають. ☁️Хмарний вітрильник☁️

#memes Коротко про те як працює кубернетес, поди та контейнери, але про це детальніше у наступних постах🤭🙃 ☁️Хмарний вітрильник☁️

#docker 🐳Docker multistage Часто на роботі виникають кілька проблем при побудові докер імеджів:

Імедж занадто важкий, і у випадках з он-прем серверами це створює досить значні проблеми

Є багато способів вирішити ці проблеми, але зосередимось на одній з можливих: мультистейдж білд. 🤨В чому суть? Мультистейдж білд — це метод оптимізації збірки імеджів, який дозволяє використовувати декілька "стадій" у одному Dockerfile. Це щось дуже схоже на святковий торт з кількома сходинками, де на кожна наступна сходинка все меньше і меньше, а в данному випадку нас цікавить найвища (тобто найменша) сходинка. Кожна стадія починається з команди FROM. Для прикладу візьмемо якусь простенький сервіс на Node.JS:

# Використання одного базового образу
FROM node:14

# Встановлення робочого каталогу в контейнері
WORKDIR /app

# Копіювання файлів package.json та package-lock.json
COPY package*.json ./

# Встановлення залежностей
RUN npm install

# Копіювання всіх файлів джерела
COPY . .

# Вказівка порту, на якому буде працювати застосунок
EXPOSE 3000

# Запуск застосунку
CMD ["npm", "start"]

Оптимізований докерфайл матиме наступний вигляд:

# Стадія збірки
FROM node:14 as builder

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

RUN npm run build

# Стадія виробництва
FROM node:14-slim

WORKDIR /app

# Копіювання вузлових модулів та зібраних файлів з попередньої стадії
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/build ./build

EXPOSE 3000

CMD ["node", "build/app.js"]

👍Таким чином, на першому етапі ми компілюємо необхідні залежності, а далі вже на наступні етапи перетягуємо лише ті файли, які необхідні, за рахунок чого ми зменшуємо розмір кінцевого докер імеджу ☁️Хмарний вітрильник☁️