📥 Деплой ботів та SSH ключі #цікаве👉 Деплой - процес розгортання веб-сервісу (в нашому випадку бота) в робочому оточенні (хостинг чи власна інфраструктура)1️⃣ Різні методи та інструменти

На даний момент є дуже багато різних технологій для деплою і підтримки (CI/CD) програмного забезпечення. Виділяється з них Docker - дуже зручний інструмент для контейнеризації, він дозволяє один раз зібрати образ (image) і на його основі створювати контейнери - ізольовані (на рівні OC, а не hardware) середовища для роботи сервісів. Є параметри, щоб Docker сам запускав контейнери, якщо сервер перезавантажити, перевіряв їх на працездатність і не тільки. Звичайною практикою буде побачити базу даних в одному контейнері, а основний сервіс в іншому + ще якісь додаткові контейнери - кожен відповідатиме за свою задачу. Базові образи, наприклад Python, PostgreSQL є на DockerHub, тому якщо треба, докер сам їх завантажить для побудови image. Всі технології прив'язані до якоїсь OC, тому їх багато варіантів + різні версії + lite збірки - можна заплутатися. Але якщо треба - розберешся2️⃣ Використання • Встанови докер та запусти його як сервіс• Напиши Dockerfile - в ньому будуть інструкції для побудови образу• Якщо в боті є додаткові сервіси (такі як бд, редіс і т.д) створи docker-compose.yaml щоб оркеструвати одразу декількома контейнерами (перед цим прочитай про мережі)• Дивись на приклади. Попрактикуйся з написанням образів та конфігів для компоузу, але головне розумій що робить та чи інша команда і коли що слід використовувати • Поцікався багатоетапними збірками (коли образ використовує збудований в цьому ж Dockerfile образ)• Дізнайся як відкривати порти. Це корисно, якщо треба взаємодіяти з сервісами не заходячи в сам контейнер. Наприклад за допомогою SSH тунелю можна локально в редакторі підключатись до БД в контейнері на сервері• Подивись що таке профілі, корисна штука за допомогою якої можна вибірково вказати, які сервіси компоузом не треба запускати, якщо ти цього явно не вкажеш📌 Збирати образи на сервері є поганою ідеєю, подивитись в сторону Docker Registry 😀 SSH ключі - шлях до безпечної праці з серверами💭 Базова концепція - є клієнт і сервер. Ціль - безпечно обмінюватись даними. Клієнт генерує пару ключів - приватний і публічний. За допомогою базової аутентифікації паролем клієнт поміщає на сервер публічний ключ. Далі можна спробувати з'єднатися за допомогою утиліти ssh. Також на приватний ключ можна додатково накладати пароль. Приватний ключ ніколи, нікому не даємо.1️⃣ Створення пари ключів

Для цього є різні утиліти. У мене наприклад є ssh-keygen. Команда генерації може виглядати так:ssh-keygen -t rsa -b 2048 -f ~/.ssh/key_name
-t алгоритм генерації ключа-b довжина ключів в байтах-f шлях, куди помістити ключі📌 Чому назва одна, ключів же 2? Справа в тому, що публічний ключ буде мати назву key_name.pub, а от приватний просто key_name2️⃣ Організація ключів💭 А якщо у нас буде багато серверів, при тому декілька різних ключів для кожного користувача на сервері, все пхати в .ssh? Для цього в директорії .ssh можна створити файл config. Він допомагає встановити відповідність між ключами та серверами. Наприклад:Host 123.45.67.89HostName mybot.ioUser admin1IdentityFile ~/.ssh/server1/key.pubIdentitiesOnly yesHost myserverHostName 132.89.46.72User admin2IdentityFile ~/.ssh/server2/key.pubIdentitiesOnly yes...
І так далі. Кожен блок відповідає за одну пару ключів.• Host - IP серверу чи кастомне ім'я• HostName - домен чи IP серверу• User - аккаунт на сервері• IdentityFile - шлях до публічного ключа• IdentitiesOnly - не пробувати інші ключі3️⃣ Перенесення ключів💭 Створили, організували, як перенести їх на сервер? Наприклад за допомогою scp чи ssh-copy-id. Приклад:ssh-copy-id -i ~/.ssh/.../key.pub user@ip_address
📌 Ключі буде перенесено в домашню директорію user! Вводимо пароль і ключі вже на сервері у потрібному місці!

📌 Після встановлення SSH ключів часто прибирають аутентифікацію паролем👩‍💻 Docker Guide🔑 SSH keys