SemVer

Семантическое версирование программного обеспечения.
MAJOR.MINOR.PATCH-label

MAJOR - изменился программный интерфейс(API) от предыдущей версии.
MINOR - обратная совместимость сохранена с предыдущей версией, добавлен функционал.
PATCH - исправление ошибок без изменение какого-либо функционала.

label - пометочки аля пререлиз, или метаданные билд системы о том, что за комит был собран.

1.0.0 < 2.0.0 < 2.1.0 < 2.1.1
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

Быстрая поставка среды для разработки

В особо сложных проектах новому человеку может понадобиться недели, чтобы запустить среду для разработки проекта.
Цель сделать автоматическую, надежную, распространяемую, повторяемую, легкую в использовании и находящуюся под системой контроля версий.
Для этого существует Vargrant. Но сейчас его актуальность явно понизилась с появлением docker toolbox для всех основных платформ ОС - потому что все тоже самое можно уже сделать docker-compose-ами.

Он управляет виртуальными машинами и создает в них необходимые образы для запуска - одной-несколько VMs.

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

Кухонная раковина

- хозяйская ОС запускает только виртуалку/ки

- в виртуалке находится код

- вирутуалка с графикой

- IDE/редактор запускается в вирутуалке

- в виртуалке настроен процесс заливки

- в виртуалке настроены необходимые сети

Легкий сервер

- IDE/редактор запускается в хозяйской ОС

- хозяйка запускает VM, но без графики

- используются разделяемые папки, так изменяя код в хозяйке изменения попадают в виртуалку

- виртуалка только для локальной заливки

Концепции Vargrant

Boxes - контейнер для операционной системы, они имеют версии, и хранятся в у юзера на хозяйской ОС ~/.vagrant.d/boxes/, каждый бокс обеспечен одним провайдером.

Providers - поставщики виртуальных машин, на которые можно установить ОС: VirtualBox(deafult), VMWare; Parallels; Cloud: AWS, Azure; Docker...

Provisioning - поставка того, что нужно еще, кроме самого чистого образа с операционкой, под проект, который мы обеспечиваем быстрой средой разработки. Это обновление ОС, установка расширенных пакетов, приложений, внесение файлов конфигурации и другое. Они могут поставляться:
- файлы;
- shell;
- Chef (Solo / Client)
- Puppet (Apply / Agent)
- Docker

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


Если мы запускаем vagrant up и в текущей директории нет Vagrantfile, то утилита просмотрит до самого корня файловой системы в поиске этого файла.

Vagrantfile вообще-то не один он соединяется с перезагрузкой из нескольких:
1) из бокса
2) ~/.vagrant.d/Vagrantfile
3) главный/проектный файл
4) Multi-VM overrides
5) Provider overrides

Helm & Charts

Helm - это пакетный менеджер для Kubernetes. Пакетный формат, который он использует называется Kubernetes charts. Такой chart описывает какой-нибудь полный набор Kubernetes ресурсов для поставки готового собранного продукта.

Tiller это сервер, в то время как Helm является клиентом. Сервер запущен внутри Kubernetes кластера и управляет релизами(установками) чартов.

Helm запускается с локального хоста или с CI/CD.

Минимальное содержимое chart это Chart.yaml (описание пакета) и папка с шаблонами (./templates), которая содержит манифест-файлы ресурсов Kubernetes.

AWS Autoscaling

Услуга от AWS, которая предлагает 2 основные полезные возможности.

Fleet Management

Позволяет следить за "флотом" нод EC2, находя нестабильно работающие и заменять их без вмешательства человека самостоятельно на другие.
Ноды добавляются в AutoscalingGroup и так происходит контроль. Еще на сколько я понял то, есть ярлыки, которыми можно помечать ноды и тогда Autoscaling сервис будет с ними вести себя специально. Например, Stateful - такую ноду Autoscaling сервис ложить не будет, а Victim - будет положен, как только наткнется на такой маркер.

Dynamic Scaling

Этот уже сервис помогает определить правила (загрузка ЦПУ, время суток, даты и т.д.),  по которым начинают подыматься/ложиться дополнительные экземпляры  EC2.
Reactive Scaling Policies - это именно события которые можно рассчитывать, как необходимость поменять состав кластера.
Следующие сервисы по динамическому масштабированию:

aws cli не может залогиниться если время сбито

Если время не совпадает с действительный амазон не позволит залогиниться.
На убунте чтобы его синхронизировать с реальным временем:

$ sudo ntpdate pool.ntp.org 

Kubernetes

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

Чтобы попробовать локально Kubernates в деле, можно воспользоваться Minikube, который является элементарной реализацией Kubernates, создает одну VM (VirtualBox, кстати он должен быть установлен, чтобы минька заработала), которая будет единственным узлом (на продакшине нужно иметь минимум 3 узла, один из которых хозяйский).

minikube start - запуск
minikube dashboard - открыть браузер с Web UI урлом
minikube dashboard --url - вывести в консоль урл, а не открывать вкладку в браузере

Разарботка на локальной машине и доменные имена

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

$ curl 192.168.99.100 -H 'Host: helloworld-v1.example.com'

DNS клиенты

Ними можно подключиться к DNS серверу:

• nslookup (пакет bind)
• host
• dig (пакет bind)

Стратегии выпуска программного обеспечения

Сине-зеленое развертывание( blue/green deployment ) - существует две параллельные инфраструктуры (в которых находятся и базы данных и кластеры сервисов, и вообще все тоже самое), когда происходит развертывание новой версии продукта, то это делается на не подключенной инфраструктуре, проводятся тесты и потом просто переключается уравновешиватель нагрузки. Если  что пойдет не так, уравновешиватель просто переключает продукт на старую инфраструктуру, то есть предыдущую версию. Перед заливкой на продакшин, отключенная инфраструктура превращается в стейджинг среду и там происходит вся магия.
Проблемы такого подхода:
- синхронизация баз данных/сервисов в которых сохраняется состояние;
- вырастает в два раза цена инфраструктуры прода - ее нужно продублировать.

Выкатывающиеся развертывание( rolling deployment ) - в этом случае у продакшина одна инфраструктура, выкатывание происходит на минимальное количество учасников кластеров (продукт состоит из нескольких/многих сервисов, каждый из которых для отказоустойчивости - это кластер контейнеров/серверов(обычно 3)). Постепенное выкатывание обеспечивает отсутсвие даунтайма, тестирование происходит на обновленных нодах, при этом можно тестировать и живыми пользователями. Когда что-то идет не так, то обновленные ноды просто ложат, и инфраструктура работает на старых версиях сервисов.
Проблемы такого подхода:
- нужно обеспечить, чтобы обновленные схемы баз данных были подходящими и для старых и для новых версий сервисов - такое развертывание нужно сначала тестировать на стейджинге;
- сессии у сервисов с состояниями будут разрываться при переброске балансером между новой и старой версией, или их данные будут различаться, и даже у сервисов без состояний поведение будет "странненьким" -- это в случае, если мы развертываем приложение без отключения обновленных контейнеров от внешнего мира, если же отключаем и только наши тестировщики их пользуют, то есть риски влиять через базы на работу других сервисов со старой версией.

Факторы современных облачных приложений

https://12factor.net/