Як встановити змінні оточення 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 Інженер 👨🏼‍💻

Як працюють Docker Volumes?❓

Нещодавно ми розглянули принципову різницю між Stateless (web-server) і Stateful (database) аплікаціями.

Із вищезгаданого посту зрозуміло - ми не можемо покладатись на файлову систему контенеру у сценаріях довгострокового збереження інформації. Файловою системою, якій ми дійсно довіряємо є ФС нашого пристрою.

Docker Volumes 🖼️ - це елегантний інтерфейс інтеграції ФС хосту всередину ФС контейнера. Тобто, тепер ми зберігаємо і контролюємо важливу інформацію в надійному місці і за потреби маунтимо її всередину доволі непостійного за своєю натурою контейнеру. 😉

Вийшла суха, але доволі важлива теорія. Надалі розглянемо це на практиці.

#docker

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

Твій перший повноцінний CI пайплайн❗️

Навчившись білдити Docker імейджі у GitHub Actions, нам залишається запушити збілджені імейджі у віддалений репозиторій.
📎 Що таке віддалений репозиторій?

Нагадаю, ось невеличка репка із вже готовим докерфайлом, залишається зробити fork і додати свій пайплайн.
📎 Як форкнути репку і додати свій пайплайн?

Тепер додаємо секрети DOCKERHUB_USERNAME та DOCKERHUB_PASSWORD із даними вашого акаунту.
📎 Як додати секрети у GitHub Actions?

Створюємо GitHub Actions із наступною конфігурацією:

name: Docker Image CI
on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Docker Login
      uses: docker/login-action@v3.3.0
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_PASSWORD }}
    - name: Build and push Docker images
      uses: docker/build-push-action@v6.7.0
      with:
        push: true
        tags: ${{ secrets.DOCKERHUB_USERNAME }}/my-very-first-ci:latest

Попередньо створіть репозиторій my-very-first-ci у своєму DockerHub акаунті.
📎 Як створити DockerHub репозиторій?

Готово! Кожна зміна коду призведе до автоматичного апдейту імейджа. Перевірити це можна на самому DockerHub по даті останнього пушу імейджа.

#docker

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

Що таке Terraform State File? ❓

Вивчаючи Terraform🖼️, важливо розібратись як відбувається "трекінг" існуючих ресурсів.
📎Що таке Terraform?

Terraform State File — це JSON-файл, що зберігає список ресурсів, сторених використовуючи Terraform, та взаємозвʼязки між ними.

Зберігати файл можно локально (не варто), або в бакеті на хмарі.
📎Що таке Amazon S3?

Завдяки State файлу можливе планування змін (terraform plan) та відстеження відхилення "реальної" інфраструктури від написаного коду.

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

Привіт, новий розіграш трьох Telegram Premium (на 3 місяці)💲. Для участі треба підписатись на цей канал.
Дякую всім хто слідкує, сподіваюсь цей контент приносить користь у роботі або розумінні сфери в цілому. Реакції 👍, коменти 💬 та активні дискусії 💬 - краща мотивація для написання постів.

Всім гарних вихідних) 😉

Змінні у Terraform, як і коли використовувати? ❓

Не дивно, що змінні - це іменовані комірки для даних.
Коли їх використовувати?🤔 Уяви, що твій Terraform-код має підлаштовуватись під декілька інфраструктур різного розміру та призначення. У випадку EC2 машини, в змінні краще винести розмір, а, наприклад, AMI зачасту може бути статичним.

👨‍💻 Приклад:

variable "instance_type" {
  type    = string
  default = "t2.micro"
}

resource "aws_instance" "web" {
  ami           = "ami-a1b2c3d4"
  instance_type = var.instance_type
}

Відноситись до змінних варто, як до аргументів функції у програмуванні. Це все тому, що ми пізніше навичимось ділити наш код на модулі, де змінні і виступатимуть такими "аргументами".

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

📞 Гарно почати ранок - це виставити правильний мікрофон перед дейліком.
DevOps Інженер 👨🏼‍💻

Так, трохи підзабив 🏖️, тож реабілітуюсь 🏋️‍♀️ розбираємось у відмінностях declarative та imperative підходів.

Declarative та Imperative - два підходи до написання коду (конфігурацій). Щоб зрозуміти із яким типом ви працюєте зараз, задайте собі питання:

Я зараз описую що саме повинна зробити программа (її output, declarative), чи яким чином діяти програмі (увесь process, imperative), щоб задовільнити мою потребу?

Наприклад: bash-скрипт - то imperative, бо ми кажемо нашому скрипту:

Спочатку сходи туди, перевір те і запусти інше

А от Terraform - це чистий declarative. Ми йому кажем:

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

В цьому випадку весь Imperative реалізували розробники Terraform та його провайдерів 😉

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

Vertical та Horizontal scaling 🗣️

Навіщо інтернет магазину тримати одну кількість активних серверів вночі та на чорну п'ятницю? Саме для цього важливо притримуватись принципу масштабованості.

Вертикальне масштабування (Scaling Up) - це збільшення розміру вже існуючого сервера. Тобто додавання RAM або CPU та інше.
Горизонтальне масштабування (Scaling Out) - це додавання нових серверів до системи для розподілу навантаження між ними.
Я асоціюю ці поняття із містом та селищем - в місті будують місткі хмарочоси🏙 (вертикальне), а в селищі маленькі хатки🏡 (горизонтальне).

Надалі розглянемо як пов'язана тема масштабування із типом аплікейшену (Stateful або Stateless [пост про різницю цих понять])

#cloud #aws
DevOps Інженер 👨🏼‍💻

Давно не бачились 😊
Поки я собі придумую подальші пости, ось мій досвід переїзду на k9s, тулу що візуалізує k8s кластер.
Навіщо це треба? Підвищити продуктивність під час роботи із куб-кластерами.
В цілому прога 8/10. Все працює швидко, класні хоткеї, переключення між кластерами, фільтри - все супер. Але мені не сподобалась документація проєкту і робота з логами контейнерів. Логи, як на мене, виглядають дуже нестабільно.
Але 100% раджу спробувати, тим паче якщо використовуєте аналоги. Тут взаємодія із кластером без мишки, кастомні dotfiles, TUI та інше.

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

Дійшли руки до власної homelab. 🧑‍🎓

Під homelab я маю на увазі створений в домашніх умовах k8s кластер із 1+ нодою. В моєму випадку нодою виступає старий, але дуже вірний, ThinkPad X250. Він, та трохи мережевого обладнання, використовують маленький EcoFlow як ДБЖ. Так - оверкіл, але чому ні, k8s тут теж оверкіл. 🤓
Для мене це щось нове - біганина від столу до шафи 10 разів на годину, бо чомусь не працює SSH або не резолвиться DNS сервера.

P.s. Пости у більш звичному цьому каналу форматі будуть продовжуватись в тому ж темпі. Жартую, реально будуть. 😄
P.P.s. Ось як це компактно розмітилось у шафі.

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