(4/6) Простой CI CD для пет проекта
Настройка сервера

Теперь давайте разберемся с настройкой сервера. Для развертывания приложения нам понадобится VPS сервер. Я рекомендую использовать сервер на базе Ubuntu 20.04, но сам использую debian 13. На сервере нам понадобится установить Docker и Docker Compose. (Тут я не буду останавливаться на установке Docker и Docker Compose, так как это можно найти в интернете.)

Клонируем репозиторий на сервере и переходим в папку проекта. Теперь нам нужно создать файл .env в корне проекта, в котором будут храниться переменные окружения для проекта. (если вы не знаете что это такое, то рекомендую ознакомиться с этой темой, так как это очень важно для разработчика.)

И под конец, нам нужно создать ssh ключи на сервере и добавить их в настройки репозитория на GitHub. Это нужно для того, чтобы GitHub Actions могли подключиться к серверу и выполнить команды для развертывания приложения.

Генерация ssh ключей и добавление их в авторизованные:

ssh-keygen -t rsa -b 4096
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Копируем содержимое файла ~/.ssh/id_rsa и добавляем его в настройки репозитория на GitHub. Это нужно для того, чтобы GitHub Actions могли подключиться к серверу и выполнить команды для развертывания приложения.

(5/6) Простой CI CD для пет проекта
GitHub Actions

Теперь давайте разберемся с GitHub Actions. GitHub Actions - это сервис, который позволяет автоматизировать процесс сборки, тестирования и развертывания приложения. Для этого нужно создать файлы с описанием шагов, которые нужно выполнить при различных событиях. Например, при пуше в репозиторий, при создании пулл-реквеста и т.д.

Давайте откроем файл .github/workflows/main.yml в корне проекта и увидем в нем следующий код:

name: "Deploy dev"

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  # Setting an environment variable with the value of a configuration variable
  env_var: ${{ vars.ENV_CONTEXT_VAR }}

jobs:

---
run_pull:
    name: run pull
    runs-on: ubuntu-latest
    needs:
---
    steps:
    - name: install ssh keys
        # check this thread to understand why its needed:
        # https://stackoverflow.com/a/70447517
        run: |
        install -m 600 -D /dev/null ~/.ssh/id_rsa
        echo "${{ secrets.DEV_SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
        ssh-keyscan -H ${{ vars.DEV_SSH_HOST }} > ~/.ssh/known_hosts
    - name: connect and pull
        run: ssh ${{ vars.DEV_SSH_USER }}@${{ vars.DEV_SSH_HOST }} "cd ${{ vars.DEV_DIR }} && git stash && git checkout ${{ vars.DEV_BRANCH }} && git pull"

    - name: stop containers -- 0 pack
        if: needs.landing_filter.outputs.output1 == 'true'
        run: ssh ${{ vars.DEV_SSH_USER }}@${{ vars.DEV_SSH_HOST }} "cd ${{ vars.DEV_DIR }} && docker-compose down landing_roll_over"
    - name: build and run containers -- 0 pack
        if: needs.landing_filter.outputs.output1 == 'true'
        run: ssh ${{ vars.DEV_SSH_USER }}@${{ vars.DEV_SSH_HOST }} "cd ${{ vars.DEV_DIR }} && docker-compose up -d --build landing_roll_over"
    ..

Уф, сложного навалилось. Давайте разберемся с этим файлом по частям.
Про vars и secrets я писать не буду, только вкратце скажу, что это переменные, которые мы можем задать в настройках репозитория. В secrets мы можем хранить секретные данные, которые не должны быть доступны в публичном репозитории, а в vars мы можем хранить обычные переменные, которые могут быть доступны в публичном репозитории.

Ну, а теперь к steps. Это шаги, которые нужно выполнить при различных событиях. В данном случае мы указываем, что нужно выполнить шаги при пуше в ветку main и при ручном запуске workflow_dispatch.
Весь пайплайн будет проходить на linux версии ubuntu_latest


Шаг номер один и два - это установка ssh ключей и выполнение команды git pull на сервере. Это нужно для того, чтобы получить последние изменения из репозитория на сервере.

Шаг номер 3 и 4 - это остановка и запуск контейнера landing_roll_over. Это нужно для того, чтобы обновить контейнер до последней версии.

(6/6) Простой CI CD для пет проекта
Заключение
Этот метод легок и расширяем, но имеет ряд недостатков:
- Нет возможности быстро откатиться к предыдущей версии приложения в случае ошибки, только если ручками переключать ветку на сервере.
- Весь код на сервере хранится в репозитории, что может быть не безопасно.
- Старые контейнеры докера потихоньку отжирают место на сервере, их нужно удалять ручками.

Но в целом, этот метод подойдет для небольших проектов, где нет большого количества пользователей и где нет большого количества изменений в коде. Если же проект большой и в нем много пользователей, то лучше использовать другие методы развертывания приложения.

----------------
Ставьте реакции, это поможет мне понять, что вам интересно и что нужно улучшить.

Если вам понравилась статья, то поделитесь ей с друзьями, это поможет мне развиваться и писать еще больше интересных статей.
Ссылка для того чтобы поделиться статьей: https://t.me/+bhtDL1JNSGM2YTMy

Вышло слишком длинно для tg, поэтому приложу еще и ссылочку на сайт, на котором таже статья, но в более удобном формате
https://dev.orby-tech.space/prostoi-ci-cd-dlia-piet-proiekta/

Вышла новая история одного разработчика!

https://t.me/story_of_one_developer

Принёс вам очень недооценный доклад про AWS для фронта

Пожалуй это лучшее выступление, для того чтобы начать разбираться с авсом именно с фронтовой стороны

https://youtu.be/9GQmPlcf8Fc?si=lvm3OvKv5ZGkpXxY

P.S. Статья будет, но чуть позже=)

(1/4) Простейшая дубликация при деплое пет-проекта
Что такое дубликация и зачем она нужна при деплое пет-проекта?

Дубликация - это копирование или повторное воспроизведение какого-либо объекта, текста или данных с целью создания его точной копии. Когда речь идет о деплое пет-проекта, дубликация может использоваться для создания резервной копии проекта или для передачи его другим участникам команды.

Когда я говорю про дубликацию, я имею в виду создание точной копии проекта или ноды, которая может быть использована для развертывания точной копии или ноды для тестирования, разработки или восстановления в случае сбоев.

Часто, дубликация вспоминается в контексте высоконагруженных систем, где дублирование ноды может быть использовано для балансировки нагрузки, увеличения надежности системы и возможности быстрого восстановления в случае сбоев.

Но является ли эта проблема актуальной для пет-проекта? Ведь пет-проекты обычно не используются в коммерческих целях и не несут в себе большой ответственности и чаще всего нагрузки смешные. Однако, в случае пет-проекта, я хотел бы иметь бесшовное обновление сервиса.

Тут каждому нужно определиться с тем, важна ли ему эта бесшовность или нет.
Ну, а я хочу, чтобы мой пет-проект был доступен 24/7, и чтобы я мог обновлять его без простоя.

(2/4) Простейшая дубликация при деплое пет-проекта
Классификация нод

В зависимости от того, какие задачи они выполняют, ноды могут быть разделены на несколько типов:

- Имеющие свой стейт (например, базы данных, кэши, очереди, не приятно собранные микросервисы)
- Не имеющие свой стейт (например, веб-серверы, прокси, балансировщики нагрузки, микросервисы, которые не хранят данные)

В случае простейшей дубликации, мы можем развернуть несколько нод, которые не имеют своего стейта, и использовать балансировщик нагрузки для распределения трафика между ними.
Ну, а если нода имеет свой стейт, то нам нужно будет использовать другие методы дубликации, такие как репликация, шардинг, кластеризация и т.д. (но это уже другая история).

(3/4) Простейшая дубликация при деплое пет-проекта
Как реализовать простейшую дубликацию при деплое пет-проекта?

Тут я буду использвать все тот же репозиторий с моим пет-проектом, который я использовал в предыдущей статье.
https://github.com/roll-over/landing

Сразу долго не думая залетаем в репозиторий и смотрим файлик docker-compose.yml. Вот интересная нам часть:

services:
  cosmo_roll_over:
    build: ./cosmo
    container_name: cosmo_roll_over
    working_dir: /frontend
    command: node build
    restart: unless-stopped
    ports:
      - "3001:3000"
    env_file:
      - .env
    depends_on:
      - landing_mongo
    environment:
      - DEV_MODE=false
  cosmo_roll_over_1:
    build: ./cosmo
    container_name: cosmo_roll_over_1
    working_dir: /frontend
    command: node build
    restart: unless-stopped
    ports:
      - "3002:3000"
    env_file:
      - .env
    depends_on:
      - landing_mongo
    environment:
      - DEV_MODE=false

Вот, мы видим, что у нас есть две ноды, которые не имеют своего стейта, и мы можем использовать балансировщик нагрузки для распределения трафика между ними.

Эти ноды опираются на одну и тоже часть кода в репозитории. Да и вообще, они одинаковые. Единственное, что их отличает - это порт, на котором они слушают.

(4/4) Простейшая дубликация при деплое пет-проекта
Как реализовать балансировку нагрузки между нодами?

Для балансировки нагрузки между нодами, я буду использовать nginx. Вот часть конфигурации, которую я буду использовать:

Тут я создаю upstream, в котором я перечисляю все ноды, которые я хочу балансировать. В данном случае, у меня есть две ноды, которые слушают на портах 3001 и 3002.

upstream cosmo {
    ip_hash;
    server 104.248.21.81:3001;
    server 104.248.21.81:3002;
}

Далее, я создаю location, в котором я указываю, что все запросы, которые приходят на порт 80, должны быть перенаправлены на upstream cosmo.

server {
    listen 80;
    server_name cosmo.roll-over.dev;
    location / {
        proxy_pass http://cosmo;
    }
}

Естественно, это только часть конфигурации, и в реальной жизни, тут могут быть другие настройки, такие как ssl, gzip, rate limiting, http2, и т.д.

---

В этой статье были затронуты только ноды без стейта, и балансировка нагрузки между ними. В следующих статьях, я хотел бы рассказать о других методах дубликации, таких как репликация, шардинг, кластеризация и т.д., но не уверен, что это будет интересно для пет-проекта. Ну, а если интересно, то дайте знать в комментариях.


----------------
Ставьте реакции, это поможет мне понять, что вам интересно и что нужно улучшить.

Если вам понравилась статья, то поделитесь ей с друзьями, это поможет мне развиваться и писать еще больше интересных статей.
Ссылка для того чтобы поделиться статьей: https://t.me/+bhtDL1JNSGM2YTMy

В этот раз без голосовашки, потому что мне последнее время ствли очень интересны облака и я хотел бы сделать достаточно большой цикл статей на этот счет☁️

Если есть какие то интересные штуки, про которые хотелось бы прочитать, подскажите в комментариях;)

#интеграция

Мой товарищ ищет работу питонистом

Имел удовольствие с ним поработать, мега кайф чувак

Помогите пожалуйста репостом / рекомендацией

https://www.linkedin.com/posts/kompoth_my-python-developer-cv-activity-7166041245511794689-4lhE?utm_source=share&utm_medium=member_desktop

(1/4) Введение в облака
Что такое облака?

Это обзорная статья, как начало серии статей о том, как использовать облачные технологии для петпроектов.

Облака в информационных технологиях - это распределенные вычислительные ресурсы, предоставляемые через интернет для хранения данных, обработки информации и запуска приложений.

Секундочку, а в чем разница между облаком и обычным сервером?
В облаке ресурсы предоставляются по требованию, а в случае с сервером, их нужно покупать и настраивать самостоятельно.

Вот представьте, что вы хотите запустить свой сайт, но нагрузка на него будет не постоянной, а временами. В этом случае вам придется покупать сервер, который будет простаивать большую часть времени. В облаке же вы можете арендовать ресурсы на время, когда они вам нужны. И при этом дополнительные ресурсы могут быть предоставлены автоматичемски, если нагрузка на сайт возрастет.

Чисто тетехнически, облако - это множество серверов, объединенных в единую сеть, которые предоставляют вычислительные ресурсы по требованию.

(2/4) Введение в облака
Какие основные провайдеры облачных сервисов существуют?

Существует множество провайдеров облачных сервисов, но основные из них:

1. Amazon Web Services (AWS)
2. Microsoft Azure
3. Google Cloud Platform (GCP)
4. IBM Cloud
5. Oracle Cloud

Для себя я выбрал AWS, так как это самый популярный провайдер облачных сервисов. И, как следствие, большинство документации и обучающих материалов написаны именно для него.
Стоит отметить, что у AWS есть спектор условно бесплатных услуг, которые можно использовать для петпроектов.

Я убежден, что нет большой разницы с чего начать, так как все облачные сервисы предоставляют схожие услуги и будут отличаться только названия. Поэтому, если вы хотите начать изучать облачные технологии, то выберите тот сервис, который вам больше нравится.

(3/4) Введение в облака
Каковы основные особенности использования облачных технологий?

Преимущества использования облачных технологий:

1. Гибкость и масштабируемость. (Вы можете арендовать ресурсы на время, когда они вам нужны, и при этом дополнительные ресурсы могут быть предоставлены автоматичемски, если нагрузка на сайт возрастет)
2. Автоматическое обновление программного обеспечения. (Вам не нужно заботиться о том, чтобы обновить программное обеспечение, так как это делает провайдер)

А в случае петпроекта, например, можно использовать бесплатные облачные сервисы, такие как GitHub Pages, Netlify, Vercel или тот же AWS

Не стоит забывать и о недостатках:

1. Зависимость от провайдера облачных сервисов. (Vendor lock-in, единыжды написанный код может быть сложно перенести на другой сервис)
2. Безопасность данных. (Вам придется особенно заботиться о безопасности данных, так как они будут храниться не у вас, а у провайдера)

(4/4) Введение в облака
Какие основные сервисы предоставляют облачные провайдеры?

Основные сервисы, которые предоставляют облачные провайдеры:

1. Вычислительные мощности (виртуальные машины, контейнеры, серверы)
2. Хранение данных (базы данных, файловое хранилище)
3. Сетевые сервисы (балансировка нагрузки, DNS, CDN)
4. Инструменты разработки (CI/CD, мониторинг, логирование)

По сути, облачные провайдеры предоставляют все, что вам нужно для разработки и поддержки приложений.

В следующих статьях я расскажу о том, как можно начать использовать облака для петпроектов и какие сервисы для этого можно использовать.


----------------
Ставьте реакции, это поможет мне понять, что вам интересно и что нужно улучшить.

Если вам понравилась статья, то поделитесь ей с друзьями, это поможет мне развиваться и писать еще больше интересных статей.
Ссылка для того чтобы поделиться статьей: https://t.me/+bhtDL1JNSGM2YTMy

* Введение в облака

Решил немного добавить про облака и почему они для петпроекта очень хорошее решение, особенно если нет опыта с серверами

1) Вам не нужно париться за настройки — у нормальных облачных систем хороший графический интерфейс
2) Ваша статическая страница будет грузиться гораздо быстрее чем с сервера за счёт того что сервера подбираются ближе к пользователю
3) Вы естественно познакомитесь с технологиями, которыми можно флексить в резюме



И важная отметка была в твиттере о безопасности вашего кошелька из-за автоскейлинга и ддос атаки
С этим я разберусь в следующих статьях, но если в кратце - лимиты наше всё, выставляя их вы защитите себе от экстра трат + у облаков есть системы защит от ddos и прочего, которые включаются одной кнопкой

(1/5) S3 для самых маленьких
Введение

Это вторая статья в цикле об облаках и на мой взгляд самая простая для знакомства с облачными технологиями. В ней я расскажу о том, как создать бакет в облаке и загрузить в него файлы, на примере тестового задания или простенького превью.

(2/5) S3 для самых маленьких
Что такое бакет?

Бакет — это просто папка в облаке. В ней можно хранить файлы, делиться ими с другими пользователями, настраивать доступ к ним и многое другое. В облаке бакеты используются для хранения данных, а также для размещения статических сайтов.

S3 — это сервис хранения данных в облаке от Amazon. В некотором смысле, это первопроходец в области облачных хранилищ, но похожие сервисы есть и у других облачных провайдеров. В этой статье я буду использовать именно S3, но если у вас есть аккаунт в другом облаке, то принципы работы с бакетами будут похожи.

Кстати, есть и не облачные аналоги S3, например, Minio. Это открытая реализация S3, которую можно установить на своем сервере или в своей локальной сети.

Мне кажется самая удобная аналогия для понимания S3 - это Google Drive. Только вместо папок и файлов у вас будут бакеты и объекты.