Як підняти аплікейшн у контейнері? 🖼️

Під час роботи ми часто потребуємо програму "на пару раз". От нам раз на два місяці захотілось підключатись до бази через UI інтерфейс або для локальних тестів підняти MySQL базу. В мене таких прикладів регулярно до пʼяти на місяць.
Оскільки такі речі є разовими, я не люблю встановлювати і зберігати ці програми у себе на компʼютері, вважаю що можна зробити простіше та зручніше - підіймати ці програми у контейнерах. Для цього достатньо встановити одну утиліту - Docker.

Розглянемо на прикладі: потрібно підняти локально MySQL, щоб підключитись до неї і протестувати програму. Можна почати гуглити install mysql linux... АБО написати наступне у своєму терміналі

docker run --name='mysqlcontainer' -d -p 127.0.0.1:3306:3306 mysql/mysql-server

Тепер сервер доступний за адресою localhost:3306

Я вважаю цей метод більш зручним бо:
1) Легко вказати версію апки за допогою імейдж-тагу mysql/mysql-server:8.0
2) Не треба паритись: як встановити, включити і, за потреби, видалити програму. Достатньо видалити контейнер.
3) Універсальність рішення на більшості систем.

#docker

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

Яка різниця між Terraform resource та data source?
Питання по Тераформу 🖼️ зі співбесіди. ❓

Створюючи Terraform конфігурацію, ми підключаємо до неї усі необхідні провайдери, наприклад "aws", "google" або "kubernetes". Кожен такий провайдер описує ряд ресурсів і дата сурсів для використання у конфігурації.

Найбільш поширеним є блок resource. Це обʼєкт у конфігурації, що дозволяє стоврювати, змінювати, відстежувати та видаляти віддаленний ресурс (GET, PUT, DELETE...) - в залежності від провайдеру це може бути екземпляр бази даних, kubernetes pod або юзер. В шапці блоку зазначається назва ресурсу, а в його тілі описуються відповідні характеристики наступним чином:

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

Data source відрізняється від resource тим, що для такого обʼєкту Terraform може застосовувати виключно операцію читання (GET). Це корисно у випадках, коли нам не підвласно створення ресурсу, але необхідно посилатись на нього у конфігурації. Наприклад, це може бути загальнодоступний знімок ОС або ресурс, створений іншим ресурсом.

data "aws_ami" "web" {
  filter {
    name   = "tag:Component"
    values = ["web"]
  }
  most_recent = true
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.web.id
  instance_type = "t2.micro"
}

#terraform

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

Що таке AWS 🖼️ і як підняти свій перший EC2 інстанс?

AWS - це набір хмарних сервісів, що надають розробникам інструменти для розгортання і масштабування власних додатків. Одним із базових AWS сервісів є EC2 🖼️.

Цей сервіс дозволяє створювати віртуальні машини різного розміру із по-хвилинною оплатою.

Ось приклад створення маленького тестового інстансу, робиться це всього у декілька кроків. Цей інстанс буде розміщено у публічній мережі із можливістю підключитись по SSH через інтерфейс AWS. (це не кращий метод, але для тесту підійде)

Після тестування не забудьте видалити інстанс у вкладці Instances і за наявності диск у вкладці Volumes.

#aws

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

GitHub 📱 приліг, хай поправляється.
https://www.githubstatus.com
UPD. Кажуть, що починились.

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

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

Як створити користувача в AWS 🖼️?

Root-юзер - супер-адмін аккаунту, у якому ви знаходитесь після реєстрації в AWS. Моя рекомендація - не використовувати його повсякденно, а краще взагалі. Підключити MFA, зробити дії описані нижче і забути про нього.
Паролі не забувати, а покласти в "тумбочку", щоб після реєстрації на AWS, там хоч шось було. 😄

Які альтернативи?
На власному акаунті - створити IAM 🖼️ юзера. IAM - це один із сервісів AWS, що дозволяє менеджити доступ у хмарі.
Оскільки аккаунт наш - то можна видати полісі AdministratorAccess. Використання такого юзера - набагато безпечніше. До нього також треба піключити MFA.

На акаунті "не власному", я б із самого початку радив дивитись у бік AWS Identity Center, це тутешнє SSO і "бест практіс" Амазону. Його ми розглянемо пізніше.

#aws

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

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

Що таке 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. Починились, була якась проблема із мережею.