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

Что есть что?

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

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



В чем же разница?

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

2. Гранулярность: Виртуализация позволяет виртуализировать все аппаратные ресурсы физического сервера, включая процессор, память и хранение. Каждая виртуальная машина имеет свои выделенные ресурсы. С другой стороны, контейнеры используют общие ресурсы операционной системы, такие как ядро, файловая система и сеть. Контейнеры могут быть созданы и уничтожены более быстро и требуют меньше ресурсов сервера, чем виртуальные машины.

3. Планирование и управление: Виртуальные машины требуют гипервизор для управления и разделения ресурсов. Каждая ВМ имеет собственную загрузочную конфигурацию и операционную систему, что может варьироваться. В отличие от этого, контейнеры управляются с помощью контейнерных оркестраторов, таких как Kubernetes или Docker. Оркестраторы контейнеров управляют размещением и масштабированием контейнеров на физических или виртуальных серверах. Они облегчают автоматизацию развертывания, мониторинга и управления контейнерными приложениями.

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



С чего начать изучение?

Если вы хотите начать изучение контейнеризации и виртуализации, вот несколько рекомендаций о том, с чего можно начать:

1. Понимание основных концепций: Начните с освоения основных концепций контейнеризации и виртуализации. Изучите разницу между контейнеризацией и виртуализацией, понимание изоляции и разделения ресурсов, а также роли гипервизоров и контейнерных оркестраторов.

2. Исследование инструментов: Ознакомьтесь с популярными инструментами контейнеризации и виртуализации, такими как Docker, Kubernetes, VMware, Hyper-V и другими. Изучите их функциональность, возможности, синтаксис и способы работы с ними.

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


Какие инструменты подходят для старта?

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

version: '3.3'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
  redis:
    image: redis:alpine
    ports:
      - "6379:6379"

Тут мы запускаем два контейнера: nginx и redis. Первый будет доступен на порту 80, а второй - на порту 6379. Все это можно запустить командой docker-compose up. После этого можно будет зайти на localhost и увидеть страницу nginx. Также можно будет подключиться к redis через localhost:6379.


В случае виртуализации можно начать с VirtualBox. Это простой инструмент, который позволяет запускать виртуальные машины. У него есть графический интерфейс, который позволяет создавать и управлять виртуальными машинами.
Картинок прикладывать не буду ввиду того что для начала это не нужно, а для углубления в тему VirtualBox уже не подходит и нужно использовать что-то более продвинутое, например Vagrant или libvirt.

(1/5) Фреймворки и библиотеки
Что такое фреймворки и библиотеки?

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

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

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

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

(2/5) Фреймворки и библиотеки
Какие критерии следует учитывать при выборе конкретного фреймворка или библиотеки для разработки проекта?

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

1. Функциональность: Удостоверьтесь, что фреймворк или библиотека обладают необходимой функциональностью для решения конкретных задач вашего проекта.

2. Совместимость: Убедитесь, что фреймворк или библиотека совместимы с используемыми вами инструментами, языками программирования, операционной системой и другими компонентами вашего проекта.

3. Расширяемость и гибкость: Исследуйте, насколько легко фреймворк или библиотека могут быть расширены или настроены под ваши потребности.

4. Производительность: Использование фреймворка или библиотеки может влиять на производительность вашего проекта.

5. Обучение и поддержка: Исследуйте доступность и качество документации, обучающих ресурсов, сообщества разработчиков и поддержки со стороны разработчиков фреймворка или библиотеки. Обратите внимание, используется ли инструмент широко в индустрии и имеет ли он активное сообщество разработчиков для помощи и консультации.

6. Лицензия и стоимость: Убедитесь, что лицензия фреймворка или библиотеки соответствует требованиям вашего проекта и вашим бизнес-потребностям. Если инструмент является коммерческим, также уточните его стоимость и условия использования.

(3/5) Фреймворки и библиотеки
Какие популярные фреймворки или библиотеки существуют в разных областях разработки, таких как веб, мобильная разработка, машинное обучение и другие?

Существует множество популярных фреймворков и библиотек в разных областях разработки. Вот несколько примеров:

1. Веб-разработка:

- Django: фреймворк для разработки веб-приложений на языке Python.
- Ruby on Rails: фреймворк для разработки веб-приложений на языке Ruby.
- React: JavaScript-библиотека для создания пользовательских интерфейсов.
- Angular: фреймворк JavaScript для разработки одностраничных приложений.

2. Мобильная разработка:

- React Native: фреймворк для разработки мобильных приложений на базе React.
- Flutter: фреймворк для создания кросс-платформенных мобильных приложений на языке Dart.
- Xamarin: платформа для разработки кросс-платформенных мобильных приложений.

3. Машинное обучение и искусственный интеллект:

- TensorFlow: библиотека машинного обучения с открытым исходным кодом, разработанная Google.
- PyTorch: библиотека машинного обучения с открытым исходным кодом, разработанная Facebook.
- scikit-learn: библиотека машинного обучения для Python, предоставляющая инструменты для классификации, регрессии, кластеризации и др.

4. Разработка игр:
- Godot: популярный фреймворк для разработки 2D и 3D игр.
- Unreal Engine: мощный инструмент для разработки компьютерных игр и визуализации.

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

(4/5) Фреймворки и библиотеки
Как влияют фреймворки и библиотеки на производительность и эффективность разработки программного обеспечения?

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

1. Ускорение разработки: Фреймворки и библиотеки предоставляют готовые решения и функциональность, которые способствуют ускорению разработки. Они предоставляют набор инструментов, шаблонов и компонентов, которые помогают разработчикам создавать приложения быстрее, поскольку многие типовые задачи уже реализованы.

2. Снижение сложности разработки: Фреймворки и библиотеки предоставляют абстракцию и стандартные решения, которые помогают упростить и стандартизировать разработку. Они поставляют структуры и правила, которые позволяют разработчику избежать наиболее сложных и подверженных ошибкам аспектов разработки.

3. Улучшение качества кода: Фреймворки и библиотеки прошли тщательное тестирование и используют передовые методы разработки. Это помогает повысить качество кода, уменьшить количество ошибок и проблем, связанных с безопасностью и совместимостью.

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

5. Расширяемость и гибкость: Фреймворки и библиотеки могут предложить механизмы для расширения и настройки функциональности под конкретные потребности проекта. Благодаря этим возможностям, разработчики могут легко адаптировать инструменты под свои требования и дополнять их новыми функциями.

6. Производительность: Фреймворки и библиотеки могут повысить производительность разработки, что в конечном итоге приводит к сокращению времени разработки и снижению затрат на разработку. Они также могут повысить производительность приложения, поскольку многие из них оптимизированы для эффективного использования ресурсов. Но в некоторых случаях использование фреймворков и библиотек может привести к снижению производительности, поскольку они могут добавлять дополнительные слои абстракции и накладные расходы. Например, использование фреймворка Django для создания простого приложения может быть неоправданно, поскольку фреймворк может добавить дополнительные сложности и накладные расходы, которые могут снизить производительность.

(5/5) Фреймворки и библиотеки
Как определить, когда целесообразно использовать готовый фреймворк или библиотеку, а когда целесообразно создать индивидуальное решение?

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

1. Требования проекта: Оцените требования вашего проекта по функциональности, производительности, масштабируемости и другим критериям. Если проект требует специфических функций, которые затруднительно реализовать с использованием готового решения, возможно, создание индивидуального решения будет более подходящим.

2. Ограничения по времени: Если у вас есть ограниченные сроки для выполнения проекта, использование готового фреймворка или библиотеки может сэкономить время и ускорить разработку. Создание индивидуального решения может потребовать больше времени на проектирование, разработку и тестирование.

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

#интеграция

Сегодня я дам ссылочки на другие интересные статьи

1) Какие бывают юрлица - https://t.me/+Jin_etwu-I9mYzJi


2) Делегирование - https://t.me/+6y_vVyLl7jhjYjVi


3) Почему важны естественные спутники планет - https://t.me/+OAwzK0mOoJw4MDg6


4) Как устроено ядро планеты - https://t.me/+BaDups8kqCA5ZDg6

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

В разработку я пришел из науки. Я с отличием закончил физфак МГУ, занимался ядерными процессами в звездах, писал сложные численные модели, в основном на C++. Некоторые из моих симуляций крутились на компе неделями, в течение которых рассчитывались миллионы лет звездной эволюции. Потом наши с физикой дорожки разошлись: хоть я и был на хорошем счету, много публиковался и даже преподавал, особых перспектив видно не было. Ну и по гражданской позиции были трения с руководством. К концу маги я решил, что в IT у меня больше возможностей, а интересных задач там тоже завались. Так я решил полностью посвятить себя коммерческой разработке.

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

Как и многие молодые разрабы, я страдаю от синдрома самозванца. Тем не менее у меня объективно есть экспертиза, как в разработке, так и в связанных с нею софт-скиллах. Я могу помочь новичкам с Python, SQL (очень много работаю с БД в последние два года), моим любимым Linux, некоторыми инструментами разработчика вроде git и Docker. Готов подсказать с личными проектами -- как развернуть и админить свой сервис, какую БД выбрать, как настроить CI/CD.

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

Да, а еще отдыхайте. Найдите маленькую радость, которую вы можете подарить себе каждый день и которая будет стабильно давать вам немного ресурса, сил двигаться дальше. Это будет ваша безусловная награда самим себе, приз за ежедневный труд, который у вас никто не отнимет ни при каких условиях. Даже вы сами. Помните: загнанная лошадь далеко не увезет.

Со мной можно связаться в телеге: @kot_tolstij. Еще у меня есть кринж-канал. У него нет узкой специализации, там все мои интересы в кучу: разработка, НРИ, походы и много всего прочего. Сейчас я ищу работу на западном рынке и планирую писать в канал про мои успехи на этом поприще. Возможно, вам будет интересно.

——————

#python #проекты #web #боты #linux #наука #физфакМГУ #SQL #git #docker #рефлексия #отдых #карьера

(1/6) Простой CI CD для пет проекта
Введение

Давайте определимся с тем, что такое CI/CD и зачем он нужен. CI/CD - это практика разработки программного обеспечения, которая объединяет в себе непрерывную интеграцию (Continuous Integration) и непрерывное развертывание (Continuous Deployment). Это позволяет автоматизировать процесс сборки, тестирования и развертывания приложения. CI/CD позволяет ускорить процесс разработки, уменьшить количество ошибок и упростить процесс развертывания приложения. В этой статье мы рассмотрим, как настроить простой CI/CD для пет проекта с использованием GitHub Actions.

И так, что нам понадобится для настройки CI/CD:

- GitHub репозиторий с проектом
- Docker
- GitHub Actions
- VPS сервер для развертывания приложения (2 ГБ оперативной памяти будет достаточно)

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

Можно обратить внимание на то, что в репозитории уже есть файлы Dockerfile и docker-compose.yml, что упростит настройку CI/CD.
Также, не смотря на простое название, там уже несколько сервисов, которые нужно развернуть, что позволит нам познакомиться с различными ситуациями и даст возможность попрактиковаться в разборе говнокода.

(2/6) Простой CI CD для пет проекта
docker-compose.yml

Не будем тратить время на разбор проекта, а сразу перейдем к файлу docker-compose.yml, который описывает сервисы, которые нужно развернуть. В данном случае это landing_roll_over, minio и другие, на которые мы пока не будем обращать внимания.

---
landing_mongo:
  image: mongo
  container_name: landing_mongo
  restart: unless-stopped
  env_file:
    - .env
  volumes:
    - "./data:/data/db"
---
landing_roll_over:
  build: ./landing
  container_name: landing_roll_over
  working_dir: /frontend
  command: node build
  restart: unless-stopped
  ports:
    - "3011:3000"
  env_file:
    - .env
  depends_on:
    - landing_mongo
  environment:
    - DEV_MODE=false
---
minio:
  image: quay.io/minio/minio
  container_name: minio
  command: server /data --console-address ":9900"
  restart: unless-stopped
  ports:
    - "127.0.0.1:9900:9900"
    - "127.0.0.1:9001:9001"
  volumes:
    - "./minio_data:/data"
  environment:
    - MINIO_ROOT_USER=your_username
    - MINIO_ROOT_PASSWORD=your_pasword
    - MINIO_DEFAULT_BUCKETS=femida,landing,denta

Давайте немного разберемся с этим файлом. (Я рассчитываю на то что вы уже знакомы с Docker и Docker Compose, если нет, то рекомендую ознакомиться с этими технологиями, так как они очень удобны и позволяют упростить развертывание приложений.)

В данном файле описаны 3 сервиса: landing_mongo, landing_roll_over и minio.

Там и там мы указываем имя контейнера, который будет создан при развертывании сервиса. Также мы указываем порты, которые будут проброшены из контейнера на хост. В случае с landing_roll_over это порт 3011, в случае с minio это порты 9900 и 9001, а для монги мы вообще не указываем порт (что говорит о том что контейнер будет доступен только внутри виртуальной сети docker-compose). Также мы указываем, что сервисы должны перезапускаться в случае ошибки.
Есть еще ряд переменных, которые мы указываем для сервиса minio.

Обратите внимание на то, что в сервисе landing_roll_over мы указываем, что он зависит от сервиса landing_mongo. Это означает, что перед тем как запустить сервис landing_roll_over, нужно дождаться пока сервис landing_mongo будет запущен и готов к работе.

Так же стоит отметить, что в сервисе minio мы указываем, что контейнер будет доступен только на localhost, что означает, что он будет доступен только на сервере, на котором мы его развернем.

(3/6) Простой CI CD для пет проекта
Dockerfile

Теперь давайте разберемся с файлом Dockerfile, который описывает, как собрать образ для сервиса landing_roll_over.
Он лежит в папке landing, которая находится в корне проекта.

FROM node:20.5-slim AS base

COPY ./ /frontend
WORKDIR /frontend

RUN corepack enable
RUN pnpm install
ARG DEV_MODE=false
ARG ME_CONFIG_MONGODB_URL='mongodb://mongo:27017'
ARG OPENAI_API_KEY=''
ARG GOOGLE_ID=''
ARG GOOGLE_SECRET=''
RUN pnpm run build

В данном файле мы указываем, что образ будет создан на основе образа node:20.5-slim. Далее мы копируем все файлы из корня проекта в папку /frontend внутри образа. Далее мы указываем рабочую директорию /frontend и запускаем команды для установки зависимостей и сборки проекта.

Также мы указываем несколько переменных, которые будут доступны внутри образа. Это переменные DEV_MODE, ME_CONFIG_MONGODB_URL, OPENAI_API_KEY, GOOGLE_ID, GOOGLE_SECRET. Они будут доступны внутри образа и будут использованы при сборке проекта.

(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