Вітаю, останнім часом роздумую про контент на цьому каналі. Як його зробити найбільш корисним і цікавим вам і мені. Щоб більше розуміти картину, попрошу відповісти на опитування нижче. 🙂

Що таке Infrastructure as Code (IaC)? ❓

Реалізація проекту потребує розгортання багатьох компонентів - мережа, сервери, бази даних... і купа іншого. І непогано було б це все якось "трекати", вести облік бажаних ресурсів.

IaC — це спосіб управління хмарною інфраструктурою використвуючи код.
Навіщо мені це?
1) Автоматичне розгортання ресурсів, описаних у коді
2) Можливість швидкого розгортання інфраструктури у різних середовищах одного типу (різні AWS аккаунти/регіони, k8s кластери)
3) Єдина точка правди. Ми маємо репозиторій 💻, де описується вся інфраструктура проєкту, будь які відхилення від коду, мають бути виправлені.
4) Версіонування 💻 інфраструктури, можливість відкатитися на "вчорашню" конфігурацію.

Реалізуючи проєкт "вручну", легко забути про якусь машину або видані доступа. Написавши їх через код, ми завжди будемо трекати їх статус і, за необхідності, видалимо при міграції.

Надалі ми розглянемо декілька різних за своїм принципом рішень, знайомлячись із CI/CD та GitOps, тож слідкуйте.

#terraform

DevOps Інженер 👨🏼‍💻

Як написати свій Dockerfile? ❓

В попередньому пості про Docker 🖼️ ми розгорнули стандартний імейдж із публічного репозиторію. Таких імейджів дуже багато. А головне, що на їх основі можна розробляти власні.
Створимо наступний файл:

FROM httpd:latest

RUN echo "Hola!" > /usr/local/apache2/htdocs/index.html
# COPY index.html /usr/local/apache2/htdocs/index.html

FROM - визначає базовий образ, на якому буде створений контейнер. (httpd - це Apache HTTP server, latest - остання його версія)
RUN - запускає команду всередині контейнера.
COPY - використовується для копіювання файлів із локальної файлової системи у контейнер.

Залишилось збілдити та запустити імейдж:

docker build -t custom-web:1 .
docker run -p 127.0.0.1:8080:80 -it custom-web:1

Тепер наша сторінка доступна за адресою http://localhost:8080

Ці знання знадобляться нам під час розгортання CI/CD пайплайну.

#docker

DevOps Інженер 👨🏼‍💻

Як створити перший CI пайплайн? ❓

Білд Docker-імейджу 🖼️ є частиною процесу Continuous Integration (CI) в CI/CD. Оскільки білдити імейджі ми вже вміємо, тепер необхідно навчитись робити це автоматично під час кожної зміни коду.

Заливши код на GitHub, необхідно сформувати свій Dockerfile і створити GitHub Actions як показано у відео. Dockerfile є відносно унікальним для кожного проекту, але зачасту відображає послідовність дій локального розгортання застосунку.

Додаю посилання на репу, із уже сформованим Dockerfile. Достатньо просто зробити з неї fork.

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

#docker

DevOps Інженер 👨🏼‍💻

Як створити ресурс використовуючи Terraform? ❓

Ми вже обсудили важливість наявності Terraform 🖼️ на проєкті і розглянули його базовий синтаксис, тож давайте піднімемо першу GCP 👩‍💻 машинку за допомогою цієї тули.

По перше, створимо папку, а в ній файлик:

provider "google" {
  project = "<gcp-project-name>"
  region = "us-central1"
  zone = "us-central1-a"
  credentials = "./access.json"
}

resource "google_compute_instance" "vm" {
  name         = "my-first-instance-tf"
  machine_type = "e2-medium"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }
  network_interface {
    network = "default"
  }
}

Для створення ресурсу із власного ПК, необхідний доступ до клауду. Процес створення GCP Service Account навів у відосі. Завантажуємо файл ключів і скидуємо у папку проєкту.

Тепер запускаємо:

terraform init
terraform apply

Готово! Ми стоврили наш перший інстанс.

Після тестувань не забудьте почистити ресурси.
1. Видалимо машинку:

terraform destroy

2. Вручну видалимо GCP Service Account

#terraform

DevOps Інженер 👨🏼‍💻

AWS 🖼️ наче трохи прихворів, на реддіті скражаться, що Route53 і STS попадали глобально. Сам AWS нічого не звітує поки, але хай одужує(

BTW. перевіряти такі проблеми через спільноти на реддіті - один із найшвидших по часу реакції метод.

UPD. Дійсно проблеми із STS, AWS каже, що вже дивляться.
UPD. Починились, була якась проблема із мережею.

Яка різниця між Stateless та Stateful аплікаціями?
Питання по Docker із співбесіди ❓

Stateless аплікації, як приклад веб-сервери, не зберігають дані про попередні дії користувача. Кожен запит обробляється незалежно від попередніх, що спрощує масштабування таких систем, бо контейнери є ідентичними, і немає різниці їх 2 або 10.

Stateful аплікації, як-от бази даних, запам'ятовують інформацію про попередні взаємодії. Вони зберігають дані, необхідні для подальшого використання, що ускладнює їх розгортання в Docker 🖼️. Таким системам необхідно забезпечити збереження даних навіть після перестворення контейнерів.

[detailed: 1, 2]

#docker

DevOps Інженер 👨🏼‍💻

Як і де зберігати готові Docker 🖼️ images? ❓

Ми вже вміємо запускати власний CI/CD пайплайн, який білдить Docker імейджі. Але, оскільки метою пайплайну є подальше розгортання нової версії коду, потрібно ці імейджі десь зберігати.
Опцій багато: Docker Hub, Amazon ECR, GCR, etc. Але суть схожа - підтримання репозиторію для версіонованого зберігання Docker імейджів (і не тільки).

Як залити імейдж у Docker Hub:

# Залогінитись в репозиторій
docker login
# Тегнути збілджений імейдж у форматі віддаленого репозиторію
docker tag <image-name>:<tag> <username>/<repo-name>:<tag>
# Запушити імейдж
docker push <username>/<repo-name>:<tag>

Тобто, на умовний GitHub ви вигружаєте версії свого коду, та і на той самий GitHub Container Registry можете публічно/приватно виливати версії цього коду, але вже в контейнері)

При реалізації на проєктах, уважно перевірте, чи не пропонує ваш клауд власний сервіс registry. Якщо так - це може зберегти час та нерви.

#docker

DevOps Інженер 👨🏼‍💻

Всіх вітаю, запускаю новий розіграш трьох Telegram Premium, для участі підпишись на канал і приймайте участь вище. 🖥

Дякую всім хто слідкує за постами, реагує, пропонує теми та примає участь у дискусіях, це найкраща мотивація створювати контент.

Також, протягом останніх тижнів ми розглянули цікаві теми по Docker 🖼️, і якщо ви їх пропустили, ось посилання на пости:

📌Як підняти аплікейшн у контейнері? Розгортання програм у контейнерах для одноразових потреб.
📎Як написати Dockerfile? Створення власного імейджа за допомогою команд FROM, RUN, COPY.
📌Як створити перший CI пайплайн? Автоматизація білду Docker-імейджів через GitHub Actions.
📎Як зберігати Docker images? Інструкція по зберіганню імейджів у Docker Hub та інших сервісах.

DevOps Інженер 👨🏼‍💻

Зараз на канал заходить багато нових людей, тому пост типу Day in the Life of a DevOps Engineer✨ буде цілком в тему.

🌻 Ранок:
Перевірка пошти та каналів комунікації, стенд-ап.
Дивимось важливі нотіфікейшени. Політ нормальний)

💻 День:
Налаштування CI/CD, їх швидкість, безпека.
Модифікація ресурсів через Terraform (бази даних, віртуальні машини).
Підтримка оточень розробки та раніше створених рішень із автоматизації.

⭐️ Друга половина дня:
Автоматизація вищеописаних процесів: чи не круто коли ресурси, що використовуються для автоматизації процесів, створюються також автоматично.

🌒 Вечір:
Заливання нової версії в продакшн. Дивимось метрики, що все іде по плану.

(Це все не обовʼязково в один день 😄)

DevOps Інженер 👨🏼‍💻

Як встановити змінні оточення GitHub Actions🏛?

У попередньому пості ми розібрали, як пушити Docker-імейджі 🖼️ в Docker Hub. Важливий крок — це авторизація через docker login.
Локально все просто: ввели пароль в консолі й готово. Але треба памʼятати - ні в якому разі не можна комітити секретні дані у віддалений репозиторій. Як тоді передати ці дані в CI?

Для цього GitHub Actions має можливість використовувати змінні оточення. Достатньо в налаштуваннях репозиторію додати свої секрети, в нашому випаду це DOCKERHUB_USERNAME та DOCKERHUB_PASSWORD, і вони стануть доступними під час виконання.

Надалі ми розглянемо, як використати ці змінні у процесі CI.

#docker

DevOps Інженер 👨🏼‍💻

Що таке Amazon S3 🖼️?

Якщо ви користувались Google Drive або Dropbox, то вже дотично знайомі із зберіганням файлів у хмарі. S3 — це подібний сервіс від Amazon, але з розширеними можливостями для розробників та бізнесу.

Ось приклад таких можливостей:
🗂Versioning: Зберігає попередні версії файлів, дозволяючи відкотитись у разі потреби.
🌐Static Hosting: Дозволяє розмістити статичний веб-сайт безпосередньо на S3.
⏳Lifecycle Rules: Автоматизує видалення (і не тільки) файлів за встановленими правилами.

Як створити свій перший S3 бакет? Terraform edition
Чих:

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "favourite_one" {
  bucket_prefix = "my-first-s3-bucket-"
}

Пих:

terraform init
terraform apply

І готово)

#aws

DevOps Інженер 👨🏼‍💻