Евгений Штольц - Из разработчика в архитекторы. Практический путь

Pupel, Ansible, Salt, задаёт топологию системы. В топологии указывается какой контейнер в на каком месте

располагается.

* Оркестрация (планировщики) – полуавтоматическое распределение, поддержание состояния и реакция на изменение

системы. Например: Google Kubernetes, Apache Mesos, Hashicorp Nomad, Docker Swarm mode и YARN, который мы

рассмотрим. Также появляются новые: Flocker (https://github.com/ClusterHQ/Flocker/),

Helios (https://github.com/spotify/helios/)

Существует нативное решение docker-swarm. Из взрослых систем наибольшую популярность показали Kubernetes (Kubernetes) и Mesos, при этом первый представляет из себя универсальную и полностью готовую к работе систему, а второй – комплекс разнообразных проектов, объединённых в единый пакет и позволяющие заменить или изменять свои компоненты. Cуществует, также, огромное количество менее популярных решений, не продвигаемы такими гигантами, как Google, Twitter и другими: Nomad, Scheduling, Scalling, Upgrades, Service Descovery, но мы их рассматривать не будем. Здесь мы будем рассматривать наиболее готовое решение – Kuberntes, которое завоевало большую популярность за низкий порог вхождения, поддержки и достаточную гибкость в большинстве случае, вытеснив Mesos в нишу кастомизуруемых решений, когда кастомизация и разработка экономически оправдана.

У Kubernetes есть несколько готовых конфигураций:

* MiniKube – кластер из одной локальной машины, предназначен для преодоления порога вхождения и экспериментов

* kubeadm

* kops

* kubernetes-ansible

* microKubernetes

Мониторинг – Heapster

Наименьшая структурная единица называется Pod, которая соответствует yml-файлу в docker-compose. Процесс создания Pod, как и других сущностей производится декларативно: через написание или изменение конфигурационного yml-файла и применение его к кластеру. И так, создадим Pod:

# test_pod.yml

# kybectl create – f test_pod.yaml

containers:

– name: test

image: debian

Для запуска нескольких реплик:

# test_replica_controller.yml

# kybectl create – f test_replica_controller.yml

apiVersion: v1

kind: ReplicationController

metadata:

name: Nginx

spec:

replicas: 3

selector:

app: Nginx // метка, по которой реплика определяет наличие запущенных контейнеров

template:

containers:

– name: test

image: debian

Для балансировки используется разновидность service (логическая сущность) – LoadBalancer, кроме которого существует ещё ClasterIP и Node Port:

appVersion: v1

kind: Service

metadata:

name: test_service

apec:

type: LoadBalanser

ports:

– port: 80

– targetPort: 80

– protocol: TCP

– name: http

selector:

app: Web

Плагины overlay сети (создаётся и настраивается автоматически): Contiv, Flannel, GCE networking, Linux bridging, Callico, Kube-DNS, SkyDNS. #configmap apiVersion: v1 kind: ConfigMap metadata: name: config_name data:

Аналогично секретам в docker-swarm существует секрет и для Kubernetes, примером которых могут быть настройки Nginx:

#secrets

apiVersion: v1

kind: Secrets

metadata: name: test_secret

data:

password:….

А для добавления секрета в под, нужно его указать в конфиге пода:

….

valumes:

secret:

secretName: test_secret

…

У Kubernetes больше разновидностей Valumes:

* emptyDir

* hostPatch

* gcePersistentDisc – диск на Google Cloud

* awsElasticBlockStore – диск на Amazon AWS

volumeMounts:

– name: app

nountPath: ""

volumes:

– name: app

hostPatch:

….

Особенностью буде UI: Dashbord UI

Дополнительно имеется:

* Main metrics – сбор метрик

* Logs collect – сбор логов

* Scheduled jobs

* Autentification

* Federation – распределение по дата-центрам

* Helm – пакетный менеджер, аналог Docker Hub

https://www.youtube.com/watch?v=FvlwBWvI-Zg

Альтернативы Docker

* Rocket или rkt – контейнеры для операционной среды CoreOS от RedHut, специально созданной на использование

контейнеров.

* Hyper-V – среда для запуска Docker в операционной системе Windows, представляющая из себя обертку (легковесную

виртуальную машину) контейнера.

От Docker ответвились его базовые компоненты, которые используются им как примитивы, ставшие стандартными компонентами для реализации контейнеров, таких как RKT, объединенных в проект containerd:

* CRI-O – OpanSource проект, с самого начала нацеленный на полную поддержку стандартов CRI (Container Runtime

Interface), github.com/opencontainers/runtime-spec/">Runtime Specification и github.com/opencontainers/image-spec">Image Specification как общего интерфейса

взаимодействия системы оркестровки с контейнерами. Наряду c Docker, добавлена поддержка CRI-O 1.0 в Kubernetes

(речь пойдёт дальше) с версии 1.7 в 2007, а также в MiniKube и Kubic. Имеет реализацию CLI (Common Line

Interface) в проекте Pandom, практически полностью повторяющий команды Docker, но без оркестровки (Docker

Swarm), который по умолчанию является инструментом в Linux Fedora.

* CRI (kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/">Container

Runtime Interface) – среда для запуска контейнеров, универсально предоставляющие примитивы (Executor,

Supervisor, Metadata, Content, Snapshot, Events и Metrics) для работы с Linux контейнерами (пространствами

процессов, групп и т. д.).

* CNI (Container Networking Interface) – работа с сетью

Portainer

Простейшим вариантом мониторинга будет Portainer:

essh@kubernetes-master:~/microKubernetes$ cat << EOF > docker-compose.monitoring.yml

version: 2

>

services:

portainer:

image: portainer/portainer

command: – H unix:///var/run/docker.sock

restart: always

ports:

– 9000:9000

volumes:

– /var/run/docker.sock:/var/run/docker.sock

–./portainer_data:/data

>

EOF

essh@kubernetes-master:~/microKubernetes$ docker-compose – f docker-compose.monitoring.yml up – d

Облачные системы, как источник непрерывного масштабирования: Google Cloud и Amason AWS

Кроме хостинга и аренды сервера, в частности виртуального VPS, можно воспользоваться облачными решениями (SAS, Service As Software) решениями, то есть осуществлять работу нашего Web приложения (ий) только через панель управления используя готовую инфраструктуру. Этот подход имеет как плюсы, так и минусы, которые зависит от бизнеса заказчика. Если с технической стороны сам сервер удалён, но мы можем к нему подключиться, и как бонус получаем панель администрирования, то для разработчика различия более существенны. Разделим проекты на три группы по месту развёртывания: на хостинге, в своём дата центре или использующие VPS и в облаке. Компании использующие хостинг в силу существенных ограничений налагаемых на разработку – невозможность установить своё программное обеспечение и нестабильность и размер предоставляемой мощности – в основном специализируются на заказной (потоковой) разработке сайтов и магазинов, которая в силу малых требований к квалификации разработчиков и нетребовательности к знаниям инфраструктуры рынок готов оплачивать их труд по минимум. Ко второй группе относятся компании реализующие состоявшиеся проекты, но разработчики отстранены от работы с инфраструктурой наличием системных администраторов, build инженеров, DevOps и других специалистов по инфраструктуре. Компании, выбирающие облачные решения, в основном оправдывают переплату за готовую инфраструктуру и мощности их расширяемостью (актуально для стартапов, когда рост нагрузки не предсказуем). Для реализации подобных проектов в основном берут высококвалифицированных специалистов широкого круга для реализации нестандартных решений, где инфраструктура уже является просто инструментом, а специалисты по ней просто отсутствуют. На разработчиков возлагаются функции по проектированию проекта в целом, как единого целого, а не программы в отрыве от инфраструктуры. В основном это зарубежные компании, готовые хорошо оплачивать труд ценных сотрудников.