Евгений Штольц - Облачная экосистема

essh@kubernetes-master:~/mongo-rs$ docker ps -q | docker stats

CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS

c8222b91737e mongo-rs_slave_1 19.83% 44.12MiB / 15.55GiB 0.28% 54.5kB / 78.8kB 12.7MB / 5.42MB 31

aa12810d16f5 mongo-rs_backup_1 0.81% 44.64MiB / 15.55GiB 0.28% 12.7kB / 0B 24.6kB / 4.83MB 26

7537c906a7ef mongo-rs_master_1 20.09% 47.67MiB / 15.55GiB 0.30% 140kB / 70.7kB 19.2MB / 7.5MB 57

f3916da35b6b redis 0.15% 3.043MiB / 15.55GiB 0.02% 13.2kB / 0B 2.97MB / 0B 4

f97e0697db61 node_api 0.00% 65.52MiB / 15.55GiB 0.41% 862kB / 8.23kB 137MB / 24.6kB 20

8c0d1adc9b9c portainer 0.00% 8.859MiB / 15.55GiB 0.06% 102kB / 3.87MB 57.8MB / 122MB 20

6018b7e3d9cd node_payin 0.00% 9.297MiB / 15.55GiB 0.06% 222kB / 3.04kB 82.4MB / 24.6kB 11

^C

При создании образов нужно учитывать:

** изменение большого слоя он будет пересоздан, поэтому его, часто лучше разделить, например, создать один слой с 'NPM i' и уже на втором скопировать код ;

* если файл в образе большой и контейнер иго изменят, то из слоя образа доступного только для чтения файл будет целиком скопирован в слой для редактирования, поэтому, контейнера предполагаются быть легковесными, а контент принято располагать в специальном хранилище. code-as-a-service: 12 факторов (12factor.net)

* Codebase – один сервис – они репозиторий;

* Dependeces – все зависимые сервисы в конфиге;

* Config – конфиги доступны через среду;

* BackEnd – обмениваются данными с другими сервисами через сеть на основе API;

* Processes – один сервис – одни процесс, что позволяет в случае падения однозначно отслеживать (завершается сам контейнер) и перезапускать его;

* Независимость о окружения и не влияние на него.

* СI/CD – code control (git) – build (jenkins, GitLab) – relies (Docker, jenkins) – deploy (helm, Kubernetes). Поддержание легковесности сервиса важно, но есть программы, не предназначенные для запуска в контейнерах, таки как базы данных. Из-за своей особенности к их запуску предъявляются определённые требования, а профит ограничен. Так, из-за больших данных они не просто медленно масштабируется, а ролинг-абдейт маловероятен, при этом перезапуск необходимо производить на тех же нодах, что и их данные из соображений производительности доступа к ним.

* Config – взаимоотношения сервисов определённо в конфигурации, например, docker-compose.yml;

* Port bindign – общение сервисов происходит через порты, при этом порт может выбираться автоматически, например, если в Dockerfile указан EXPOSE PORT, то при вызове контейнера с флагом -P он будет прикончен к свободному автоматически.

* Env – настройки среды предаются через переменные окружения, а не через конфиги, что позволяет их вносить в конфигурацию конфига сервисов, например, docker-compose.yml

* Logs – логи передаются потоком по сети, например, ELK, или выводится в вывод, который уже Docker передаёт потоком.

Внутренности Dockerd:

essh@kubernetes-master:~/mongo-rs$ ps aux | grep dockerd

root 6345 1.1 0.7 3257968 123640 ? Ssl июл05 76:11 /usr/bin/dockerd -H fd:// –containerd=/run/containerd/containerd.sock

essh 16650 0.0 0.0 21536 1036 pts/6 S+ 23:37 0:00 grep –color=auto dockerd

essh@kubernetes-master:~/mongo-rs$ pgrep dockerd

6345

essh@kubernetes-master:~/mongo-rs$ pstree -c -p -A $(pgrep dockerd)

dockerd(6345)-+-docker-proxy(720)-+-{docker-proxy}(721)

| |-{docker-proxy}(722)

| |-{docker-proxy}(723)

| |-{docker-proxy}(724)

| |-{docker-proxy}(725)

| |-{docker-proxy}(726)

| |-{docker-proxy}(727)

| `-{docker-proxy}(728)

|-docker-proxy(7794)-+-{docker-proxy}(7808)

Docker-File:

* чистка кэши от пакетных менеджеров: apt-get, pip и других, этот кэш не нужен на продакшне, лишь

занимает место и нагружает сеть, но ныне не зачастую не актуально, так как есть многоэтапные

сборки, но об этом ниже.

* группируйте команды одних сущностей, например, получение кэша APT, установку программ и удаление

кэша: в одной инструкции – код только программ, при разнесённом варианте – код программ и кэш,

так как если не удалить кэш в одной инструкции, то он будет сохранён в слое, не зависимо от

последующих действий.

* разделяйте инструкции по частоте изменения, так, например, если не разделить установку

программного обеспечения и код, то при изменении чего-либо в коде, то вместо использования готового

слоя с программами они будут переустановлены заново, что повлечёт существенное время на подготовку

образа, которое критично для разработчиков:

ADD ./app/package.json /app

RUN npm install

ADD ./app /app

Альтернативы 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.