# Docker & k8s # Консоль и теория # Общая информация и установка

**Установка**

[Доп. ссылка](https://dockerhosting.ru/blog/ustanovka-docker-na-debian-12/)

Добавить пользователя, который впоследствии будет запускать контейнеры

```bash apt-get install sudo usermod -aG sudo sergey sudo apt-get update ```

**Добавить сертификат и новое хранилище**

(Вариант 1 - Debian)

```bash sudo apt-get install ca-certificates curl gnupg lsb-release sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null ``` (Вариант 2 - Ubuntu) ```bash sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null ``` **Установка docker и docker compose** (Вариант 1 Debian/Ubuntu) ```bash sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin ```

(Вариант 2 Alt Linux, сертификаты ставить не надо)

``` sudo apt-get install -y docker-engine sudo apt-get install -y docker-compose-v2 ```

**Дополнительные удобства**

Запуск docker при старте системы

``` sudo systemctl enable docker ``` Добавить пользователя в группу docker ``` sudo usermod -aG docker $USER ``` Информация о текущем статусе docker ``` docker info ``` Для Alt Linux ``` sudo gpasswd -a USER docker sudo systemctl enable --now docker sudo init 6 ```

**Теория**

Образы (Images): неизменяемые элементы, основанные как минимум на ядре и архитектуре. Контейнер: исполняемый образ. Назначение контейнера - запуск одного приложения. Аналогия: Образ=класс, контейнер=объект. Т.е. к образу в момент запуска добавляются параметры и он становится исполняемым контейнером, но изменения в контейнере не затрагивают образ. Контейнер в текущем состоянии можно превратить в образ, но после остановки (если не сохранить данные в файловой системе хоста или еще где-либо) все данные будут потеряны. Повторный запуск будет произведен как будто создался новый объект. В этом принципиальное отличие от виртуальной машины.

[![docker_sheme.jpg](http://bobrobotirk.ru/uploads/images/gallery/2024-06/scaled-1680-/docker-sheme.jpg)](http://bobrobotirk.ru/uploads/images/gallery/2024-06/docker-sheme.jpg)

Может быть: архитектура ПК-ядро-образ-образ-образ-контейнер

**Архитектура**

Docker client -> Docker engine (daemon) -> containerd -> runc-> shim

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

**Пример процессов:**

docker run --name ctr1 -it alpine:latest sh

- docker client преобразовывает в POST API запрос в Docker engine - Запрос отправляется в сокет /var/run/docker.sock - демон получает команду создания нового контейнера и передает вызов в containerd (CRUD-style API поверх gRPC) - containerd преобразовывает Docker image и направляет запрос в runc для создания нового контейнера - runc взаимодействует с ядром, создавая контейнер. Контейнер запускается как дочерний процесс runc. После запуска контейнера runc завершается.

Docker daemon может работать с сетью, non-TLS порт 2375, TLS port 2376

**Контейнеры:**

После запуска основным процессом становится приложение из параметров запуска

При отсутствии, используется приложение сконфигурированное в образе как точка запуска (Entrypoint)

**Взаимоотношение между способами работы с Docker.**

При работе с докером используются как минимум три способа (возможно больше) взаимодействий: прямое взаимодействие через консоль, dockerfile, docker compose. Терминология общая, но способы работы и результаты отличаются. Из-за того, что в целях упрощения консоли docker (групп команд docker ...) эти способы перемешаны, сначала возникает путаница. В статьях видимо по умолчанию считается, что читатель это отличие полностью осознал. Сравнение способов:

	Консоль	Dockerfile	docker compose
Мое понимание термина	Ввод команд настроек и запуска одного контейнера напрямую в консоли. Будет работать через bash скрипт, но удобнее так не делать.	Сохранение команд настроек одного контейнера в файл и запуск через консоль.	Настройка взаимодействия нескольких взаимосвязанных контейнеров при условии подготовленных образов. Запуск через консоль / планировщик
Применение	При тестовом запуске или для просмотра (корректировки) параметров работающего контейнера	Шаблон одного контейнера. Нужно при создании образа для последующего использования в compose.	Оркестрация образов.
Стадия использования	Тестовая, до MVP. Либо product для анализа проблем.	Тестирование, отладка одного образа. MVP - pre product.	Комплексный запуск сервиса. Pre product - product
Формат	Bash	ini	YAML
Точка использования	Преимущественно на ПК разработчика, при обучении технологии или для выявления проблем с работающим контейнером на всех стадиях.	ПК разработчика или тестовый сервер.	Тестовый / product сервер.
Необходимость серьезного изучения	Скорее администраторам.	Да, если для сервиса потребуется создание отдельных образов.	Да. Данный способ можно использовать для одного контейнера, для product все равно потребуется.\*

* При сборке из чистых образов (типа debian для запуска nginx+...) требуется доп. установка и настройка ПО, а данный вопрос проще решать через dockerfile. К тому же существует например ansible, позволяющий решить ряд вопросов. В книгах для примеров часто используют консоль (быстро, акцент на одном изучаемом аспекте). А через ansible возможно настроить и запустить контейнер (и оркестр) без dockerfile/docker compose. Но в случае ansible для compose используется терминология compose, а вид команд другой.

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

# Образы

Образ - контейнер только для чтения, содержащий все для запуска (минимальная ОС, приложение, зависимости, метаданные)

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

Образ - manifest файл, в котором список слоев и метаданных.

Слой - целостный объект.

Каждая команда в dockerfile, модифицирующая файловую систему контейнера, создает новый слой.

Нельзя удалить образ, пока последний контейнер не будет удален.

Образы обычно хранятся в /var/lib/docker/<storage-driver>

!Нужно достаточно места в /var!

У образа есть hash (digest), у каждого из слоев есть digest

Параметр distribution hash - hash сжатого образа или образа для размещения в hub

Для поддержки разных архитектур и платформ для одного названия (напр. golang:latest) используются manifest list и manifests

Для каждого контейнера создается новый слой чтения/записи

**Команды работы с образами**

Базовая команда	Доп. парам.	Описание
docker images		Список установленных образов
	-q	только отображение ID контейнеров
	--digests	добавляет столбец с хэшем образа
	dangling: true/false	Образы без тега. Происходит если при создании нового образа сохраняется тег старого. У старого обнуляется тэг, у нового остается.
	label: <label>	Фильтрует на основе наличия метки или ярлыка и значения. Команда docker images не отображает метки в своих выходных данных.
docker search	<слово>	поиск в dockerhub по слову <слово>
	--filter ""	Доп. фильтр ```bash docker search alpine --filter "is-official=true" ```
	--limit число	кол-во выдачи, максимум 100
docker image pull Синоним: docker pull	<repository>:<tag>	Загрузка образа из репозитория repository: - В случае официального образа на docker hub: одно слово - В случае неофициального образа на docker hub: слово/слово ```bash docker pull nigelpoulton/tu-demo:v2 ``` - В случае внешнего хранилища: адрес хранилища без http(s) ```bash docker pull gcr.io/google-containers/git-sync:v3.1.5 ```
	<digest>	Хэш образа
docker image push Синоним: docker push	<repository>:<tag>\|<digest>	Загрузка образа на репозиторий, доп. параметры аналогичны pull
docker image prune	<repository>:<tag>	удаление образа из локального хранилища
	-a	удаление всех неиспользуемых контейнерами образов
docker build docker image build	-t тег образа. обычно имя:версия <путь к dockerfile> - обязательный	Создание образа из dockerfile ``` docker build -t myapp:1.0 . docker build -t ${PROJECT_NAME}_db:${VERSION} ./database ```
docker save	-o имя\_файла.tar имя\_образа:тег	Сохранение существующего образа в файл ``` docker save -o имя_файла.tar имя_образа:тег ```
docker load	-i имя\_файла.tar	Загрузка образа из файла ``` docker load -i имя_файла.tar ```
docker image tag docker tag		Создать тэг TARGET\_IMAGE связанный с SOURCE\_IMAGE Это нужно только для публикации образа в dockerhub ``` docker tag ddd-book:ch8.1 nigelpoulton/ddd-book:ch8.1 ```
docker rmi		Удаляет заданный образ или несколько образов. Удаление всех образов: ```bash docker rmi $(docker images -q) -f ``` Эта команда удаляет старые теги без удаления образа, если есть еще образы, ссылающиеся на этот образ.
docker inspect <имя или ID образа>		информация по образу
docker info \| grep Storage		При использовании docker pull или docker-compose up -d образы размещаются в /var/lib/docker/overlay2

# Контейнеры **Основные команды**

Команда	Доп. пар.	Описание
docker ps		список работающих контейнеров
	-a	список остановленных но еще существующих контейнеров
docker logs <name>		список событий внутри контейнера name
docker start <name>		запуск остановленного контейнера
docker restart <name>		Перезапускает один или несколько контейнеров. Можно считать приблизительным аналогом выполнения для заданных контейнеров команды docker stop, за которой сразу следует команда docker start.
	-t	определяет интервал времени ожидания, необходимого для завершения работы контейнера, перед его остановом по сигналу SIGTERM.
docker stop <name>		Останавливает (но не удаляет) один или несколько контейнеров. После выполнения этой команды заданный контейнер переходит в состояние «остановлен».
	-t	Аналогично restart
docker kill <name>		Сигнал основному процессу (PID=1) в контейнере. По умолчанию SIGKILL (немедленное завершение работы). Возвращает идентификатор контейнера.
	-s	другой сигнал
docker rm <name или id>		удаление остановленного контейнера
	-f	позволяет удалять работающие контейнеры.
	-v	удалить тома, созданные удаляемым контейнером (если эти тома не смонтированы на каталоги и не используются другими контейнерами) ```bash docker rm -v $(docker ps -aq -f status=exited) ``` удаляет все остановленные контейнеры
docker top <name или id>		информация о процессах внутри контейнера
docker port <name или id>		номера портов, назначенные механизмом Docker
docker create <name или id>		Создает контейнер из образа, но не запускает его. Аргументы как у docker run.
docker run		создание и запуск контейнера из образа
	-it или -d	сеанс интерактивной работы или запуск в фоновом режиме
	--link <namecur:nameinnew>	соединение между новым контейнером и существующим контейнером myredis, в новом контейнере ссылка на существующий обозначена именем redis ```bash --link myredis:redis ```
	--name	имя для дальнейшего взаимодействия
	--hostname	имя для обращения
	--mount	монтирование
	--volumes-from CONTAINER	использование томов контейнера
	-p HostPort:ContPort	перенаправление с портов хоста на порт контейнера
	--rm	удаление остановленного контейнера и файловой системы после запуска и выполнения команды. Несовместим с ключом -d.
	--restart	Позволяет настроить образ действий при попытке Docker перезапустить остановленный контейнер. - no запрещает любые попытки перезапуска контейнера. - unless-stopped Будет перезагружаться до остановки. После перезагрузки демона Docker контейнер останется выключенным. - always попытки перезапуска выполняются в любом случае вне зависимости от состояния контейнера после выхода. После перезагрузки демона Docker контейнер опять запустится. - on-failure: перезапуск выполняются для контейнера, завершившего работу с ненулевым статусом. После перезагрузки демона Docker контейнер опять запустится. Может быть задан аргумент, определяющий максимальное количество попыток перезапуска (иначе попытки будут выполняться бесконечно). ```bash docker run --restart on-failure:10 postgres ```
	-t, --tty	Создает псевдоустройство TTY (терминал). Как правило, используется вместе с ключом -i для запуска контейнера в интерактивном режиме.
	-e, --env	Определяет переменные среды внутри контейнера.
	--entrypoint	Определяет точку входа для запускаемого контейнера в соответствии с заданным аргументом, заменяя содержимое любой инструкции ENTRYPOINT из Dockerfile.
	-u, --user	Определяет пользователя, от имени которого выполняются команды. Может быть задано как символьное имя пользователя или как числовой идентификатор UID. Заменяет содержимое инструкции USER из Dockerfile.
	-w, --workdir	Устанавливает рабочий каталог в контейнере в соответствии с заданным путевым именем. Заменяет любые значения, определенные в файле Dockerfile.
	--add-host=docker:10.180.0.1	ХЗ, узнать
docker pause/unpause		Временно приостанавливает/запускает все процессы внутри контейнера. Процессы не получают никаких сигналов приостановки(не могут быть остановлены и завершены или удалены).
docker commit <container name> <repo name>		образ контейнера. По умолчанию приостанавливаются, без приостановки --pause=false.
docker network ls		список сетей

**Взаимодействие реального времени** Ctrl-PQ (или Ctrl+P, Ctrl+Q) отключение от контейнера без остановки

Команда	Доп. пар.	Описание
docker attach <name или id>		наблюдать или взаимодействовать с основным процессом внутри контейнера.
docker cp		Позволяет копировать файлы между файловыми системами контейнера и хоста. ```bash docker cp /tmp/config.ini grafana:/usr/share/grafana/conf/ ```
docker exec		Запускает заданную команду внутри контейнера (может быть работающий сейчас). Может использоваться для выполнения задач сопровождения или в качестве замены ssh при входе (регистрации) в контейнер. ``` docker exec -it ubuntu:latest bash ```
docker events		Выводит в реальном времени события от демона демону. Выхода Ctrl-C.

**Примеры**

- Запуск контейнера образа ubuntu:latest в интерактивном режиме с bash ```bash docker run -it ubuntu:latest /bin/bash ``` - Подключение к работающему контейнеру и запуск в нем bash ```bash docker exec -it e37f24dc7e0a bash ```

# Тома (volumes) Тома (volumes) – файлы или каталоги, смонтированные на хосте и не являющиеся частью каскадно-объединенной файловой системы. Другие контейнеры могут совместно использовать их, и все изменения будут сразу же фиксироваться в файловой системе хоста. Устаревшее: В качестве точки монтирования можно определить любой другой каталог хоста в команде docker run (например, docker run -d -v /host/dir:/container/dir test/web-server). В Dockerfile bind mounts не работает - а это и не надо делать, т к это определяется при старте образа/через compose. Способы хранения данных: 1. Временное (удаляется при остановке контейнера) 1. по умолчанию изолировано на диске 2. tmpfs в оперативной памяти 2. Постоянное 1. обычные тома Docker 2. bind mounts - прямое монтирование папки в контейнер **Драйвера volumes**

Драйвер	Описание
local	Драйвер по умолчанию. Только точки монтирования, доступные на хосте.
	И еще штук 30 драйверов, [список драйверов](https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins)

**Управление томами при запуске контейнера из консоли:** Если тома нет - будет создан

Основная команда	Параметр	Описание
docker run ... --mount	type=	Тип тома: - volume - bind - tmpfs
	source(src)=	Имя тома или не указывается для анонимных
	destination(dst)=	точка монтирования в контейнере
	volume-driver=	local по умолчанию, локальный том
	volume-opt=	опция=значение ```bash volume-opt=type=nfs,volume-opt=device=: ```
	readonly	только для чтения
docker run ... \--volumes-from ContID		связывание с томами контейнера

Пример: ```bash --mount 'type=volume,src=data-volume,dst=/var/opt/project,volume-driver=local,readonly' ``` Без пробелов после запятых. **Создание и управление томами независимо от контейнеров**

Основная команда	Параметр	Описание
docker volume	create --name my\_volume create my\_volume	Создание тома. /var/lib/docker/volumes/имя тома/\_data - расположение файлов По умолчанию на хосте в каталоге установки Docker (обычно каталог /var/lib/docker/). /var/lib/docker/volumes/
	ls	местоположение определенных томов, по имени или ID тома.
	inspect my\_volume	информация о томе
	rm my\_volume	удаление тома
	prune	удаление всех томов, которыми не пользуются контейнерами. Но иногда после удаления контейнера данные не обновляются
docker system prune		очистка ресурсов docker. Потом - повторное удаление томов.

**Примеры:**

Автоматическое создание том с именем test-data в /var/lib/docker/volumes/test-data/_data

```bash docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine ```

**Монтирование в другую точку.**

Нужно создать директорию.

```bash mkdir /home/avimanyu/test-data docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine ```

**Архивировать том datavol в dbdata и восстановить его в том dbdata2 контейнера dbstore2** Создание тома datavol в контейнере dbdata

```bash docker run -it --mount 'type=volume,src=datavol,dst=/datavol' --name dbstore ubuntu /bin/bash ```

Создание временного контейнера, примонтирование тома из dbdata, создание тома backup и сохранение архива datavol в backup и удаление временного контейнера

```bash docker run --rm --volumes-from dbstore --mount 'type=volume,src=backup,dst=/backup' --name tmpubn ubuntu tar cvf /backup/backup.tar /datavol ```

Создание тома datavol2 в контейнере dbdata2

```bash docker run -it --mount 'type=volume,src=datavol2,dst=/datavol' --name dbstore2 ubuntu /bin/bash ```

Создание временного контейнера, примонтирование тома из dbstore2, создание тома backup и сохранение архива datavol в backup и удаление временного контейнера

```bash docker run --rm --volumes-from dbstore2 --mount 'type=volume,src=backup,dst=/backup' ubuntu bash -c "cd /datavol && tar xvf /backup/backup.tar --strip 1" ``` # Сеть (networking) Docker поставляется со следующими сетевыми драйверами в рамках библиотеки libnetwork: - single-host bridge networks (bridge) - multi-host overlays (overlay) - options for plugging into existing VLANs (macvlan) Для тестов нужно установить ``` apt-get install bridge-utils ``` Docker регистрирует DNS сервис в пределах бриджа. Но в сети по умолчанию (docker0) DNS сервиса нет.

Команда	Описание
brctl show	Список бриджей. ``` sudo brctl show bridge name bridge id STP enabled interfaces br-62694f46296d 8000.7ee73b5c2894 no br-8af5ede4ffdc 8000.aee56ab6b984 no br-96dd8dcd216d 8000.5a64a8825202 no docker0 8000.f220300c62b1 no ```

Также есть опция поиска сервисов и балансировка входной нагрузки.

Основная команда	Параметр	Описание
docker network	ls	Список сетей
docker inspect ИмяСети		Выводит информацию по указанной сети. bridge - сеть по умолчанию.
docker network create	-d драйвер	Создает сеть ``` docker network create -d bridge localnet ```
	название сети
docker port ContName		Выводит map портов внутрь контейнера
docker network prune		Удаляет неиспользуемые сети
docker network rm	Название сети	Удаляет конкретную сеть

**Single-host bridge networks** Создается интерфейс на хосте docker. [![docker_networks_0.JPG](http://bobrobotirk.ru/uploads/images/gallery/2025-03/scaled-1680-/docker-networks-0.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2025-03/docker-networks-0.JPG) Один порт может занимать только один контейнер. Взаимодействие контейнеров внутри хоста. **Multi-host overlay networks** Для взаимодействия контейнеров внутри виртуальной сети нескольких хостов. Могут быть расположены на разных нодах swarm. Сеть второго уровня, распределяющаяся по нужным нодам с dns сервисом и распределением нагрузки. **Plugging into existing VLANs** Для прямого подключения к сетевому интерфейсу соответственно с независимым адресом. Необходим promiscuous mode на интерфейсе хоста (неразборчивый режим). ipvlan с возможностью независимого адреса в пределах диапазона сетевой карты хоста заработал ``` services: condb: image: nginx networks: my_ipvlan: ipv4_address: 192.168.1.40 networks: my_ipvlan: driver: ipvlan driver_opts: parent: enp0s3 ipvlan_mode: l2 ipam: config: - subnet: 192.168.1.0/24 gateway: 192.168.1.1 ``` macvlan напрямую не заработал. Из интернетов: ``` sudo ip link add mymacvlan link enp0s3 type macvlan mode bridge sudo ip addr add 192.168.1.99/24 dev mymacvlan sudo ip link set mymacvlan up ``` **Docker и firewall** Тут у меня началась веселуха. Первая проблема в том, что в литературе по докеру сетевая подсистема описана слабо, и не говорится самого главного: один хрен ip/nf tables (для определенности далее будем использовать iptables, помня обо всех нюансах). Docker самостоятельно управляет записями в iptables, за счет них организуется сетевая подсистема. Поэтому 1. Все службы вне докера управляются цепочкой INPUT 2. Службы докера, транслируемые наружу (ports в compose файле) по умолчанию попадают в цепочку FORWARD, которая сначала отдает пакеты в цепочку DOCKER-USER, затем в DOCKER-FORWARD и далее блокируется Цепочка DOCKER-USER служит для пользовательского управления пакетами. Автоматически самим Docker не изменяется. Поэтому в ней можно блокировать например внешние запросы к внутренним сервисам, оставляя доступ для определенных адресов. # Yaml формат \# - комментарии Ключ-значение ``` first: second ``` Обязательный пробел после : Вложенные ресурсы в python виде, два пробела **Типы данных** Строка. Может быть без кавычек если хотя-бы один нечисловой символ Многостроковая переменная: ``` config: | server.port=8443 logfile=/var/log ``` Числа - как числа Логические true/false Список: ``` ports: - 8080 - 8443 ``` Список словарей. ``` env: - name: FIRSTVAR value: ONE - name: SECONDVAR value: TWO ``` # Архивация образов и Хранилище образов (hub) **Первый в /projects\_ogrinizer/compose-files второй в /projects\_ogrinizer/compose-files/Dockerhub** **Терминология** **реестр (registry или hub)** – сервис, отвечающий за хранение и распространение образов. **репозиторий (repository)** – набор взаимосвязанных образов, обычно различные версии приложения **тег (tag)** – алфавитно-цифровой идентификатор, присваиваемый образам внутри репозитория (например, 14.04 или stable). Тегов может быть много. **Пространства имен:** - начинающиеся с текстовой строки и слеша (/), такие как amouat/revealjs В репозитории Docker Hub это образы, выгруженные конкретным пользователем. - имена без префиксов и слешей, принадлежат пространству имен «root», управляемому компанией Docker Inc. - имена с префиксами в виде имени хоста или IP-адреса представляют образы, хранящиеся в сторонних реестрах (не в Docker Hub). Например, localhost:5000/wordpress Docker сохраняет аутентификационную информацию в файле .dockercfg, расположенном в вашем домашнем каталоге. **Создание архива образа из существующего образа** Создаем Dockerfile ``` FROM alpine:latest ARG NODE_ENV=production2 ENV NODE_ENV=${NODE_ENV} RUN mkdir /var/www RUN echo $NODE_ENV > /var/www/first.txt CMD ["cat", "/var/www/first.txt"] ``` Собираем образ ``` docker build -t bobrobot:1.0 . ``` Сохраняем образ, копируем и устанавливаем на нужной системе, и запускаем ``` docker save bobrobot:1.0 > bobrobot:1.0.tar docker load -i bobrobot\:1.0.tar docker run bobrobot:1.0 ``` **Команды**

Команда	Доп. пар.	Описание
docker login		Регистрация/вход на сервер реестра. По умолчанию Docker Hub. ``` docker login https://hub.bobrobotirk.ru ```
docker logout		Выход из реестра Docker. По умолчанию Docker Hub.
docker pull		Загружает заданный образ из реестра. Реестр определяется по имени образа, по умолчанию принимается Docker Hub.
docker push		Выгружает образ или репозиторий в заданный реестр. При отсутствии тега выгружаются все образы указанного репозитория в заданный реестр. ``` docker push hub.bobrobotirk.ru/testimage ```
docker search		Выводит список общедоступных репозиториев из реестра Docker Hub
docker build .
	-t	Определение имени репозитория и тега
docker tag <current> <in hub>		Устанавливается соответствие имени с образом, который ссылается на образ в репозитории Docker Hub. ``` docker tag testimage hub.bobrobotirk.ru/testimage ```

**Локальный hub (теория из разных источников, кое-что устаревшее)** [Пример](https://www.dmosk.ru/miniinstruktions.php?mini=docker-local-repo) На серверной стороне: ```bash mkdir dockertest_certs openssl req -newkey rsa:4096 -nodes -sha256 -subj "/CN=dockertest" -addext "subjectAltName = DNS:dockertest" -keyout dockertest_certs/domain.key -x509 -days 365 -out dockertest_certs/domain.crt docker run -d -p 5000:5000 -v $(pwd)/dockertest_certs:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key --restart=always --name registry registry docker run --entrypoint htpasswd httpd:2 -Bbn testuser testpassword >> auth/htpasswd #добавить пользователя ``` На клиентской стороне (из-под root): ```bash mkdir -p /etc/docker/certs.d/dockertest:5000 #добавить в /etc/hosts запись о сервере dockertest scp sergey@dockertest:/home/sergey/dockertest_certs/domain.crt /etc/docker/certs.d/dockertest:5000/ca.crt service docker restart ``` Перелинковать на клиенте образ на новый хаб и загрузить его ```bash docker tag amouat/identidock:0.1 dockertest:5000/identidock:0.1 docker push dockertest:5000/identidock:0.1 ``` Пример docker-compose.yml для запуска локального реестра ```yaml services: registry: restart: always image: registry ports: - "5000:5000" environment: REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt REGISTRY_HTTP_TLS_KEY: /certs/domain.key REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm volumes: - ./dockertest_certs:/certs - ./auth:/auth ``` **Практический запуск регистра** Поскольку это пока что тестовый хаб, решил сделать [сертификат LetsEncrypt](http://bobrobotirk.ru/books/linux/page/sertifikat-ot-letsencrypt "Сертификат от LetsEncrypt"). На dns сервере сделал запись сайта hub.bobrobotirk.ru. Прокинул порты 443 и 8090 до виртуальной машины. Создал папки ``` mkdir data mkdir auth mkdir certs ``` В папку certs скопировал сертификат и ключ. Для создания пользователей установил утилиту ``` sudo apt-get install apache2-utils ``` Создал пользователя testuser с паролем StrongPassword ``` htpasswd -Bbn testuser StrongPassword > auth/htpasswd ``` Для добавления пользователей: ``` htpasswd -Bb auth/htpasswd user2 password2 ``` Создал docker-compose.yaml ```yaml services: registry-server: image: registry:2.8.2 container_name: registry-server restart: always ports: - "443:5000" # Перенаправление HTTPS-трафика environment: REGISTRY_HTTP_HEADERS_Access-Control-Allow-Origin: '["https://hub.bobrobotirk.ru"]' REGISTRY_HTTP_HEADERS_Access-Control-Allow-Methods: '["HEAD", "GET", "OPTIONS", "DELETE"]' REGISTRY_HTTP_HEADERS_Access-Control-Allow-Credentials: '["true"]' REGISTRY_HTTP_HEADERS_Access-Control-Allow-Headers: '["Authorization", "Accept", "Cache-Control"]' REGISTRY_HTTP_HEADERS_Access-Control-Expose-Headers: '["Docker-Content-Digest"]' REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd REGISTRY_HTTP_TLS_CERTIFICATE: /certs/cert.crt REGISTRY_HTTP_TLS_KEY: /certs/key.key REGISTRY_STORAGE_DELETE_ENABLED: "true" volumes: - ./data:/var/lib/registry # Для сохранения данных реестра - ./auth:/auth # Для файла htpasswd - ./certs:/certs # Для SSL сертификатов registry-ui: image: joxit/docker-registry-ui:main container_name: registry-ui restart: always ports: - "8090:80" # Интерфейс доступен по порту 8090 environment: SINGLE_REGISTRY: "true" REGISTRY_TITLE: "BobRobotIRK Docker Registry" DELETE_IMAGES: "true" SHOW_CONTENT_DIGEST: "true" NGINX_PROXY_PASS_URL: "https://hub.bobrobotirk.ru" # URL реестра SHOW_CATALOG_NB_TAGS: "true" CATALOG_MIN_BRANCHES: "1" CATALOG_MAX_BRANCHES: "1" TAGLIST_PAGE_SIZE: "100" REGISTRY_SECURED: "true" # Реестр защищен авторизацией CATALOG_ELEMENTS_LIMIT: "1000" depends_on: - registry-server ``` И по адресу [http://hub.bobrobotirk.ru:8090/](http://hub.bobrobotirk.ru:8090/) появился web интерфейс с авторизацией. Авторизовался с другого сервера ``` docker login https://hub.bobrobotirk.ru ``` Создал Dockerfile ``` FROM alpine:latest ARG NODE_ENV=production2 ENV NODE_ENV=${NODE_ENV} RUN mkdir /var/www RUN echo $NODE_ENV > /var/www/first.txt CMD ["cat", "/var/www/first.txt"] ``` Собрал образ (пора переходить на buildx) ``` docker build -t testimage . ``` Точка обозначает расположение Dockerfile) Он появился в списке образов ``` docker images REPOSITORY TAG IMAGE ID CREATED SIZE testimage latest 1f3755f48bea 3 minutes ago 7.83MB ``` Добавил тег образу ``` docker tag testimage hub.bobrobotirk.ru/testimage ``` Загрузил образ на hub ``` docker push hub.bobrobotirk.ru/testimage ``` Да, образ отобразился в списке. Теперь на третьем сервере авторизовался на hub.bobrobotirk.ru и попробовал запустить контейнер из образа ``` services: testapp: image: hub.bobrobotirk.ru/testimage ``` Образ скачался и контейнер запустился. Повторить это все просто, а в первый раз потратил на это один день. P.s. Второй вариант, в случае наличия внешнего nginx reverse proxy + https termination ```yaml services: http-registry-server: image: registry:2.8.2 container_name: http-registry-server restart: no ports: - "${HUB_BACKEND_PORT}:5000" # Перенаправление HTTP-трафика environment: REGISTRY_AUTH: htpasswd REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd REGISTRY_STORAGE_DELETE_ENABLED: "true" REGISTRY_HTTP_ADDR: 0.0.0.0:5000 REGISTRY_HTTP_NET: "tcp" # Явно указываем протокол REGISTRY_HTTP_HEADERS_Access-Control-Allow-Origin: '["*"]' REGISTRY_HTTP_HEADERS_Access-Control-Allow-Methods: '["HEAD", "GET", "OPTIONS", "DELETE"]' REGISTRY_HTTP_HEADERS_Access-Control-Allow-Credentials: '["true"]' REGISTRY_HTTP_HEADERS_Access-Control-Allow-Headers: '["Authorization", "Accept", "Cache-Control"]' REGISTRY_HTTP_HEADERS_Access-Control-Expose-Headers: '["Docker-Content-Digest"]' volumes: - ./data:/var/lib/registry # Для сохранения данных реестра - ./auth:/auth # Для файла htpasswd http-registry-ui: image: joxit/docker-registry-ui:main container_name: http-registry-ui restart: no ports: - "${HUB_BACKEND_WEB_PORT}:80" environment: NGINX_PROXY_PASS_URL: "http://${HUB_BACKEND_IP}:${HUB_BACKEND_PORT}" SINGLE_REGISTRY: "true" REGISTRY_TITLE: "${WEB_TITLE}" DELETE_IMAGES: "true" SHOW_CONTENT_DIGEST: "true" SHOW_CATALOG_NB_TAGS: "true" CATALOG_MIN_BRANCHES: "1" CATALOG_MAX_BRANCHES: "1" TAGLIST_PAGE_SIZE: "100" REGISTRY_SECURED: "true" # Реестр защищен авторизацией CATALOG_ELEMENTS_LIMIT: "1000" depends_on: - http-registry-server ``` **Примеры** Загрузка образа с тегом latest в репозиторий amouat/revealjs из реестра Docker Hub. ```bash docker pull amouat/revealjs:latest ``` Загрузка образа из неофициального реестра. ```bash docker pull gcr.io/google-containers/git-sync:v3.1.5 ``` Определение имени репозитория identidock и тега 0.1 для образа, собранного из локального dockerfile. ```bash docker build -t "identidock:0.1" . ``` Устанавливается соответствие имени amouat/identidock с образом, который ссылается на имя пользователя amouat в репозитории Docker Hub. ```bash docker tag "identidock:0.1" "amouat/identidock:0.1" ``` **Ссылки** [Настройка локального hub](https://www.dmosk.ru/miniinstruktions.php?mini=docker-local-repo) # Dockerfile

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

Имя файла: Dockerfile (без расширения).

Контекст создания - набор локальных файлов/каталогов, к которым можно обращаться через copy/add.

/ не стоит использовать как контекст, полностью включается в архив

\# комментарии

При сборке образа попытки использования кэша идут до первого промаха. Затем кэш не проверяется.

.dockerignore - файл исключений из контекста

При сборке компилируемых приложений лучше использовать multi-stage build.

Основная команда	Параметры	Описание
docker build		создание образа Создание образа из docker файла . - контекст создания (текущая папка) ```bash docker build -t test/cowsay-dockerfile . ``` После этого образ появляется в списке образов
	-t	имя слоя
	-f	расположение слоя
	--squash	сжимает все слои в один
docker history	<image>	инструкции создания образа
docker buildx		для компиляции под разные платформы

**Формат exec и формат командной оболочки**

**Формат exec**

JSON-массив

первый элемент массива: имя выполняемого файла

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

**Формат командной оболочки**

строка произвольной формы, передаваемая для интерпретации в /bin/sh -c.

Используйте формат exec, чтобы избежать случайного искажения строк командной оболочки, или в тех случаях, когда образ не содержит /bin/sh.

Команды файла:

Основная команда	Параметры	Описание
FROM	<name>	название базового образа
MAINTAINER	<name>	имя поддерживающего пользователя
USER	<name>	!Всегда определять! Задает пользователя (по имени или по идентификатору UID) для использования во всех последующих инструкциях RUN, CMD, ENTRYPOINT.
WORKDIR		рабочий каталог для последующих RUN, CMD, ENTRYPOINT, ADD, COPY. можно использовать несколько раз можно относительные пути, итоговый путь относительно предыдущего WORKDIR.
RUN	<commands>	команды при инициализации образа, обычно установка пакетов каждая создает новый слой
CMD {''}		команда с аргументами, выполняемая после запуска контейнера. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD.
ENTRYPOINT	<program name>	Выполняемый файл, который будет вызываться для обработки аргументов, переданных в команду docker run ``` ENTRYPOINT ["/usr/games/cowsay", "-k"] ```
COPY	<> <>	копирование файла из ФС ОС в ФС образа COPY . /src копирует все из текущей папки в папку /src
VOLUME	<>	Том в ФС
ARG		Определяет переменные среды, доступные внутри образа при сборке. Неизменяемые.
ENV		Определяет переменные среды внутри образа, но могут изменяться. На эти переменные можно ссылаться в последующих инструкциях.* ```yaml ENV MY_VERSION 1.3 RUN apt-get install -y mypackage=$MY_VERSION ``` Переменные среды со значением по умолчанию Файл first.sh ``` echo $NODE_ENV ``` Dockerfile ```yaml FROM alpine:latest ARG NODE_ENV=production2 ENV NODE_ENV=${NODE_ENV} RUN mkdir /var/www COPY first.sh /var/www/first.sh CMD ["sh", "/var/www/first.sh"] ``` Собираем образ ``` docker build -t bobrobot:1.0 . ``` docker-compose.yml ``` services: bobrobot: image: bobrobot:1.0 environment: NODE_ENV: "first2" ``` В итоге при указании NODE\_ENV выводится first2, иначе production2
EXPOSE		Сообщает механизму Docker, что в контейнере будет процесс, прослушивающий порт(ы) не оказывает воздействия на сетевую среду нужно для аргумента -p в docker run
ONBUILD		инструкция, выполняемая когда образ будет использоваться как основной уровень для другого образа. Полезным при обработке данных, добавляемых в образ-потомок (например, инструкция копирования дополнительного кода из заданного каталога и запуска скрипта сборки, обрабатывающего скопированные данные).

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

При сборке команды исполняются однократно. Затем при запуске образа они не повторяют исполнение. Поэтому для

``` FROM alpine:latest ARG NODE_ENV=production2 ENV NODE_ENV=${NODE_ENV} RUN mkdir /var/www RUN echo $NODE_ENV > /var/www/first.txt CMD ["cat", "/var/www/first.txt"] ```

вывод всегда будет production2.

**Многошаговая сборка (Multi-stage building)**

**Создание одного образа с участием нескольких временных**

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

``` FROM golang:1.20-alpine AS base WORKDIR /src COPY go.mod go.sum . RUN go mod download COPY . . FROM base AS build-client RUN go build -o /bin/client ./cmd/client FROM base AS build-server RUN go build -o /bin/server ./cmd/server FROM scratch AS prod COPY --from=build-client /bin/client /bin/ COPY --from=build-server /bin/server /bin/ ENTRYPOINT [ "/bin/server" ] ```

Сборка образа: ``` docker build -t multi:stage . ``` **Создание нескольких образов** Также можно создать несколько образов при помощи одного Dockerfile. Отличие в последней стадии: ``` ... FROM scratch AS prod-client COPY --from=build-client /bin/client /bin/ ENTRYPOINT [ "/bin/client" ] FROM scratch AS prod-server COPY --from=build-server /bin/server /bin/ ENTRYPOINT [ "/bin/server" ] ``` Сборка образов: ``` docker build -t multi:client --target prod-client -f Dockerfile-final . docker build -t multi:server --target prod-server -f Dockerfile-final . ``` **Мультиплатформенная сборка** Возможно, но пока не интересно **Использование условий для создания разных образов** Условия можно использовать только в конструкции RUN и CMD ```yaml RUN if [ "$TARGET" = "test" ]; then \ cp -r /files/src/tests .; \ fi # Разные команды для production и тестов CMD if [ "$TARGET" = "production" ]; then \ exec gunicorn app.main:app --bind 0.0.0.0:8000; \ else \ exec pytest -v; \ fi ``` Затем собирается образ с указанной переменной окружения ``` docker build --build-arg TARGET=production -t myapp:prod . ``` Полный пример: ``` FROM alpine:latest ARG BUILD_ENV RUN mkdir /var/www WORKDIR /var/www COPY test.txt . COPY prod.txt . RUN if [ "$BUILD_ENV" = "test" ]; then \ cat test.txt > first.txt; \ else \ cat prod.txt > first.txt; \ fi CMD ["cat", "/var/www/first.txt"] ``` **Использование multistage сборки для ограничения копирования** if не работает в команде COPY. Но иногда бывает нужен образ для тестирования без содержимого директории, а в prod с содержимым. Пример: ``` # Общая стадия для подготовки файлов FROM alpine:latest as base COPY common_files /app/common_files # Стадия для prod (копирует папку) FROM base as prod COPY prod_folder /app/prod_folder # Стадия для test (не копирует папку) FROM base as test RUN echo "Running in test mode, no prod_folder copied" # Выбираем финальную стадию через ARG ARG TARGET_ENV=prod FROM ${TARGET_ENV} as final # Остальные инструкции... ``` **Сжатие итогового образа (многоуровневого) в один уровень** Не рекомендуется, но если надо: --squash флаг при build **Разное** При apt-get install использовать no-install-recommends - сильно снижает объем. # Docker compose Инструмент для управления несколькими контейнерами при помощи одного файла. **Настройка прав на директорию** Создаем группу, которой будут предоставлены права на управление ``` sudo groupadd docker-users sudo usermod -aG docker-users user1 sudo usermod -aG docker-users user2 ``` Создаем директорию проекта ``` sudo mkdir /var/dockerimages sudo chown root:docker-users /var/dockerimages # Владелец — root, группа — docker-users sudo chmod 775 /var/dockerimages # Права: rwxrwxr-x ``` Права на создаваемые директории ``` sudo chmod g+s /var/dockerimages ``` Добавление пользователей в группу Docker. В этом случае пользователи получат полный доступ к Docker. ``` sudo usermod -aG docker user1 user2 ``` **Политики перезапуска** Применение compose файла с политикой restart always/unless-stopped нужно быть внимательным. Повторное применение может создать копию, которая будет постоянно перезагружаться и забивать ресурсы. Для диагностики docker ps Если такое произошло, то ``` docker update --restart=no 1945fa12ce27 ``` Это обновит политику перезагрузки для контейнера и позволит разобраться в проблеме. **Консольные команды:**

Основная команда	Доп. параметры	Описание
docker compose up		Запуск контейнеров через Compose файл. Вывод журнальных записей объединяется в один поток. Создает образы, если они не существовали ранее
	-d	запуск в фоновом режиме
	-f	определяет имя compose файла
	& в конце	возвращает консоль, но продолжает выводить логи
docker compose build		Пересоздание образов из Dockerfile.
docker compose ps		Вывод информации о состоянии контейнеров. Работает только в контексте файла в текущей директории.
docker compose run		Одноразовый запуск с выполнением одной команды (не в качестве сервиса). Также запускаются все контейнеры, с которыми должны быть установлены соединения, если не задан аргумент --no-deps. (Команды, передаваемые через run, заменяют команды, определенные в файле конфигурации сервиса. Кроме того, по умолчанию команда run не создает портов, определенных в файле конфигурации сервиса.)
docker compose top		процессы во всех контейнерах
docker compose stop		Останов контейнеров без их удаления
docker compose logs		Вывод журнальных записей с цветной подсветкой, объединенный для всех контейнеров
docker compose restart		запускает остановленные контейнеры
docker compose rm		Удаление остановленных контейнеров.
	-v	удаляет тома, управляемые механизмом Docker
docker compose down		это stop+rm
	--volumes	удаляет и тома
	--rmi all	удаляет образы

**Формат файла docker-compose.yaml** Имя файла docker-compose.yml Язык yaml. Уровни вложенности определяются пробелами, параметр:значение, - список Compose перекрывает настройки docker файла при пересечении. Если микросервисы в одной сети (networks), то могут взаимодействовать по имени. \# комментарий, пустые строки игнорируются сначала создается сеть и тома, затем сервисы. **Блоки конфигурации:** ```yaml services #настройки запускаемых образов firstapp: build: . #Расположение dockerfile, в данном случае в текущей папке command: python app.py #исполняемая комманда (точка входа) hostname: your-name ports: - target: 8080 #внутренний порт published: 5001 #внешний порт environment: - DEBUG=${DEBUG} networks: - counter-net #название подключенной сети, т е может быть разные подключенные сети. Подключенные к одной сети контейнеры видят друг друга по имени. Д б определена в networks volumes: - type: volume source: counter-vol #Д б определена в volumes target: /app networks #Сеть counter-net: over-net: #имя сети driver: overlay #драйвер attachable: true #разрешено подключаться из других докер контейнеров volumes #Тома ``` **Внешние переменные окружения** По умолчанию файл .env Формат файла: ``` VERSION=v1.3 PG_USERNAME="superadmin" ``` Кавычки: - Тип кавычек после = определяет внешние кавычки, которые убираются. - Внутри строки не может быть внешних неэкранированных кавычек - Одинарные не разыменовывают $ (и скорее всего остальные спец. символы), двойные разыменовывают - Одинарные поддерживают multiline Использование внутри yml файла (без доступа во время выполнения): ```yaml services: web: image: webapp:${VERSION} ``` Для использования внутри сервиса необходимо создать переменную внутри environment ```yaml services: db: image: postgres environment: POSTGRES_USER: ${PG_USERNAME} ``` Использование различных файлов с переменными окружения ``` docker compose --env-file up ``` Предварительный вывод итогового yml файла: ``` docker compose config ``` Приоритет переменных (от высокого к низкому): 1. Файл Compose. 2. Переменные среды оболочки. 3. Файл среды. 4. Dockerfile. 5. Переменная не определена. **Именование контейнеров.** В случае использования image, имя контейнера берется из имени сервиса. В случае build <имя проекта>-<имя сервиса> Переменные в имени сервиса не поддерживаются. **Политика перезагрузки контейнера** - always - всегда - uness-stopped - если контейнер был остановлен, затем перезагрузилась служба Docker - он не будет запущен. При перезагрузке работающего контейнера с unless-stopped будет запущен. - on-failure - перезагрузка при аварийном завершении работы. Контейнер запускается если был остановлен и служба Docker была перезапущена. ``` services: postgres: image: ${PROJECT_NAME}_db:${VERSION} restart: always ``` # Docker Swarm Кластеризация приложений от Docker, упрощенный K8s. Типы Nodes (хост Docker в Swarm кластере): - manager: управление состоянием кластера и распределение задач по workers - workers: получают и выполняют задачи Конфигурация и состояние кластера хранится в распределенной хранимой в ОП БД, реплицированной по всем manager. Сервис (service) является атомарным элементом для управления. Сверху накручиваются фишки типа масштабирования, постоянного обновления и восстановления. Для Node желательно настройка dns имен (в моем случае manager1, manager2, worker1, worker2) Роли можно совмещать на одном VPS, актуально для маленьких кластеров. **Инициализация кластера** Инициализация первого manager - добавление остальных manager - добавление worker. Инициализация первого manager: ``` docker swarm init ``` Затем при помощи команд ... join-token смотрим инструкцию по подключению node. При размещении где-то, должны быть доступны следующие порты: - 2377/tcp: для защищенного взаимодействия между нодами - 7946/tcp and udp: взаимодействие менеджеров - 4789/udp: VXLAN-based overlay сеть **Доступность кластера** Один manager активен в каждый момент времени. Это Leader manager. Остальные (Fallower managers) проксируют команды на лидера. Ситуации split-brain (в результате сбоя сети при котором одинаковое количество manager осталось в каждом сегменте и последующего восстановления связи) необходимо избегать. Желательно 3-5 manager. Подключение manager после перезагрузки / сбоя сети может привести к проблемам. Поэтому желательно установить правило блокировки при перезагрузке. ``` docker swarm update --autolock=true ``` Она выдаст ключ разблокировки. После перезагрузки потребуется разблокировать ``` docker swarm unlock ``` Есть нюанс: для работы кластера требуется доступность более половины manager. Поэтому кластер из 2 manager точно плохой вариант) **Сервисы (пользовательские приложения)** По умолчанию исполняются на всех нодах. Для исключения manager нужно ввести команду ``` docker node update --availability drain mgr1 ``` В списке node Active поменяется на Drain ``` ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE m1bhltzuvvzippoetl7b26m3j manager1.bobrobotirk.ru Ready Drain Leader 28.0.1 yjmubzqzvrvbhqaqw70rlorzk * manager2.bobrobotirk.ru Ready Drain Reachable 28.0.1 3s0jzf6fcw9ik5g9sqlrpmmgo worker1.bobrobotirk.ru Ready Active 28.0.1 ``` Сервисы создаются через интерактивные команды или через описание (compose file + доп. настройки). Стандартный режим создания - реплика (количество, распределено по активным worker). Есть глобальный режим (mode global) при котором на каждом worker создается по одной реплике. **Архивация и восстановление** Ключ разблокировки очень важен. При его утере и перезагрузке всех manager node хер что сделаешь. ``` tar -czvf swarm.bkp /var/lib/docker/swarm/ rm -r /var/lib/docker/swarm tar -zxvf swarm.bkp -C / docker swarm init --force-new-cluster ``` После восстановления директорий обязательна реинициализация кластера. **Примеры** 5 реплик, доступ через любую ноду ``` docker service create --name web-fe -p 8080:8080 --replicas 5 nigelpoulton/ddd-book:web0.1 или docker service create --name web-fe -p 8080:8080 --mode global nigelpoulton/ddd-book:web0.1 docker service rm web-fe ``` Через overlay сеть + обновление ``` docker network create -d overlay uber-net docker service create --name web-fe --network uber-net -p 8080:8080 --replicas 5 nigelpoulton/ddd-book:web0.1 #без указания сети, запрос на manager:8080 обрабатываться не будет docker service update --image nigelpoulton/ddd-book:web0.2 --update-parallelism 2 --update-delay 20s web-fe ``` Compose файл ``` networks: counter-net: driver: overlay driver_opts: encrypted: 'yes' volumes: counter-vol: services: web-fe: image: nigelpoulton/ddd-book:swarm-app mem_limit: 250m command: python app.py deploy: replicas: 4 update_config: parallelism: 2 delay: 10s failure_action: rollback placement: constraints: - 'node.role == worker' restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s networks: - counter-net ports: - published: 5001 target: 8080 volumes: - type: volume source: counter-vol target: /app redis: image: "redis:alpine" networks: counter-net: ``` **Основные команды**

Команда	Доп. пар.	Описание
docker swam init		Инициализация первого manager кластера
	--advertise-addr 10.0.0.1:2377	Необязательный параметр. Нужен если есть внешний балансировщик нагрузки - тогда адрес балансировщика, и указать listen-addr.
	--listen-addr 10.0.0.1:2377	Необязательный параметр. Нужен если много ip адресов.
docker node ls		Список node в кластере
docker swarm join-token	worker	Инструкция по подключению worker
	manager	Инструкция по подключению manager
docker swarm leave		Исключение node из кластера
docker swarm update	--autolock=true	Блокировка после перезагрузки / потере связи
	--availability drain name\_manager	Исключение manager из исполнения клиентских приложений.
docker swarm unlock		Разблокировка manager
docker service	ls	список сервисов
	ps name	список работающих контейнеров с именем name
	inspect --pretty name	детальная информация по сервису name
	scale name=10	Изменение количества реплик сервиса name в режиме реального времени
	rm name	Удалить сервис
	update \--image imname \--update-parallelism 2 \--update-delay 20s name	Обновление сервиса name до образа imname
	logs nameserv	Отобразить логи сервиса nameserv
docker stack	deploy -c name.yml nameofstack	Создает стэк nameofstack из файла name.yml ``` docker stack deploy -c compose.yaml ddd ``` Также используется для обновления существующего сервиса при обновлении compose файла
	rm nameofstack	Удаление стэка nameofstack
	ls	Список
	ps	Детализация

# Дополнительные инструменты

**Контейнеры**

**Docker Compose** – создание и выполнение приложений, скомпонованных из нескольких Docker-контейнеров. Такие компоновки используются главным образом при разработке и тестировании

**Docker Machine** - устанавливает и конфигурирует Docker-хосты на локальных и удаленных ресурсах. Кроме того, Machine конфигурирует клиента Docker, упрощая процедуру переключения между средами.

**Kitematic** - графический пользовательский интерфейс для операционных систем Mac OS и Windows, обеспечивающий запуск и управление контейнеров Docker

**Хранение и управление образами Docker**

**Docker Trusted Registry** – локальная версия реестра Docker Hub, которую можно объединить с существующей инфраструктурой. Исходный код закрыт.

**[Enterprise Registry](https://coreos.com/products/enterprise-registry/)** от CoreOS

**[Artifactory](http://www.jfrog.com/open-source/#os-arti)** от JFrog.

**Сетевая среда**

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

**[Weave](http://weave.works/net/)**

**[Project Calico](http://www.projectcalico.org/)**

**Обнаружение сервисов**

Поиск других сервисов для взаимодействия с ними.

**[Consul](https://consul.io/)**

**[Registrator](https://github.com/gliderlabs/registrator)**

**[SkyDNS](https://github.com/skynetservices/skydns/)**

**[etcd](https://github.com/coreos/etcd)**

**Оркестровка и управление кластером**

Контроль и управления всей системой в целом.

**[Kubernetes](http://kubernetes.io)** от Google

**[Marathon](https://github.com/me-sosphere/marathon)**

фреймворк для **[Mesos](https://mesos.apache.org)**

**[Fleet](https://github.com/coreos/fleet)** от CoreOS

**[Docker Swarm](https://docs.docker.com/engine/swarm/)** – решение задачи кластеризации от Docker. Группирует несколько Docker-хостов, после чего пользователь может работать с этой группой как с единым ресурсом.

# Примеры # Контейнеризация приложения из git Создаем папку app и переходим в нее. Клонируем git ```bash git clone https://github.com/sudaka/irksecrets.git ``` Создаем dockerfile ```ini FROM ubuntu:latest LABEL maintainer="..." RUN apt-get update RUN apt install -y python3 python3-pip uvicorn RUN mkdir /var/www WORKDIR /var/www COPY ./irksecrets /var/www RUN python3 -m pip install -r requirements.txt EXPOSE 8000 ENTRYPOINT ["uvicorn", "irksecrets:app", "--host", "0.0.0.0", "--port", "8000"] ``` Создаем образ ```bash docker build -t irkscweb:2.0 . ``` Создаем контейнер ```bash docker run -d --name fa2 -p 8000:8000 irkscweb:2.0 ``` Сейчас контейнер сервиса должен заработать, по адресу 127.0.0.1/docs должна быть страница сервиса. Останавливаем сервис. Информация по официальному образу postgres: POSTGRES\_PASSWORD=mysecretpassword POSTGRES\_USER POSTGRES\_DB #при отсутствии будет создана БД POSTGRES\_HOST\_AUTH\_METHOD все файлы .sql .sh в папке docker-entrypoint-initdb.d исполняются при инициализации БД Поднимаемся на один уровень и создаем папку db. Создаем скрипт настройки ```sql create role irksecrets with login superuser; alter role irksecrets with encrypted password 'Password'; create table secrets (chash char(64) primary key, enctext bytea); alter database irksecrets owner to irksecrets; ``` ```ini FROM postgres LABEL maintainer="sa@yandex.ru" ENV POSTGRES_PASSWORD 123458 ENV POSTGRES_HOST_AUTH_METHOD md5 ENV POSTGRES_DB: irksecrets COPY *.sql /docker-entrypoint-initdb.d/ #инит скрипты, при наличии БД не запускаются EXPOSE 5432 ``` Создаем compose файл. Директории app db рядом с .yaml файлом ```yaml services webapp: build: app/. ports: - target: 8000 published: 8000 networks: - isnet dbhost: build: db/. environment: - POSTGRES_PASSWORD=Password - POSTGRES_HOST_AUTH_METHOD=md5 - POSTGRES_DB=irksecrets ports: - target: 5432 published: 5432 networks: - isnet networks: isnet: ``` # Запуск из консоли и простые dockerfile **Запуск bash в контейнере:** ```bash docker run -i -t debian /bin/bash ``` **Удаление всех остановленных контейнеров** ```bash docker rm -v $(docker ps -aq -f status=exited) ``` **Создание контейнера, установка доп. приложения и запуск** ```bash docker run -it --name cowsay --hostname cowsay debian bash root@cowsay:/# apt-get update root@cowsay:/# apt-get install -y cowsay fortune root@cowsay:/# exit docker commit cowsay test/cowsayimage docker run test/cowsayimage /usr/games/cowsay "Moo" ``` **Создание образа из docker файла** Dockerfile: ```ini FROM debian:wheezy RUN apt-get update && apt-get install -y cowsay fortune ENTRYPOINT ["/usr/games/cowsay"] ``` Создание образа из dockerfile ```bash docker build -t test/cowsay-dockerfile . ``` **Пример скрипта вызова разных приложений при установленной точке входа** ```bash nano entrypoint.sh ``` ```bash #!/bin/bash if [ $# -eq 0 ]; then /usr/games/fortune | /usr/games/cowsay else /usr/games/cowsay "$@" ``` ```bash chmod +x entrypoint.sh ``` DockerFile: ```ini FROM debian RUN apt-get update && apt-get install -y cowsay fortune COPY entrypoint.sh / ENTRYPOINT ["/entrtypoint.sh"] ``` # 3 образа ```yaml services: identydock: build: . #build ссылается на docker file. Либо build, либо image. ports: - "5000:5000" environment: ENV: DEV volumes: - ./app:/app # старое описание - type: volume source: counter-vol target: /app links: - dnmonster - redis dnmonster: image: amouat/dnmonster redis: image: redis volumes: counter-vol: ``` # Postgresql [Основа инструкции на хабре](https://habr.com/ru/articles/578744/) Минимальный compose файл с возможностью подключиться извне, логином и паролем: ```yaml services: postgres: image: postgres:16.3 environment: POSTGRES_DB: "testdb" POSTGRES_USER: "testuser" POSTGRES_PASSWORD: "testpass" ports: - "5432:5432" ``` Точка входа для инициализации базы данных: **docker-entrypoint-initdb.d** Все \*.sql или \*.sh файлы в этом каталоге - скрипты для инициализации БД. Детали использования: 1. если БД уже была проинициализирована ранее, то никакие изменения к ней применяться не будут; 2. если в каталоге присутствует несколько файлов, то они будут отсортированы по имени с использованием текущей локали (по умолчанию en\_US.utf8). ```yaml services: postgres: image: postgres:16.3 environment: POSTGRES_DB: "testdb" POSTGRES_USER: "testuser" POSTGRES_PASSWORD: "testpass" volumes: - .:/docker-entrypoint-initdb.d ports: - "5432:5432" ``` Для постоянного размещения БД нужно подмонтировать соответствующий каталог (куда будут сохраняться данные) в контейнер и при необходимости переопределить переменную окружения **PGDATA** ```yaml services: postgres: image: postgres:16.3 environment: POSTGRES_DB: "testdb" POSTGRES_USER: "testuser" POSTGRES_PASSWORD: "testpass" PGDATA: "/var/lib/postgresql/data/pgdata" volumes: - .:/docker-entrypoint-initdb.d - mydata:/var/lib/postgresql/data ports: - "5432:5432" volumes: mydata: ``` Подключение к базе через psql ```bash psql -d testdb -U testuser -W -h 127.0.0.1 -p 5430 ``` # Nginx Создать директорию nginx\_config.conf и внутри файл python\_microservices ```bash server { listen 8080; location /api/firstendpoint { proxy_pass http://firstendpoint:8000/api/firstendpoint; } location /api/secondendpoint { proxy_pass http://secondendpoint:8000/api/secondendpoint; } } ``` Compose: ```yaml version: '3.7' services: nginx: image: nginx:latest ports: - "8080:8080" volumes: - ./nginx_config.conf:/etc/nginx/conf.d/default.conf ``` [Источник](https://habr.com/ru/articles/799337/) **NGINX reverse proxy с https терминацией** Обслуживает несколько доменов, для одного из доменов путь /auth ведет на отдельный сервер **Структура проекта:** ``` >certs .env docker-compose.yaml nginx.conf.template ``` **Размещение статических файлов** ``` location /static { alias /app/static; # Опционально: настройки для статики expires 30d; add_header Cache-Control "public, immutable"; } ``` **Директория certs:** сертификаты в формате <domain name>.crt и <domain name>.key **.env** ``` # Backend сервисы WOOD_BACKEND_IP=192.168.1.194 WOOD_BACKEND_PORT=8000 HUB_BACKEND_IP=192.168.1.194 HUB_BACKEND_PORT=8021 HUB_BACKEND_WEB_PORT=8020 WOOD_AUTH_IP=192.168.1.194 WOOD_AUTH_PORT=8001 # Домены HUB_DOMAIN=hub.bobrobotirk.ru HUB_WEB_DOMAIN=hubui.bobrobotirk.ru WOOD_DOMAIN=wood.bobrobotirk.ru ``` **nginx.conf.template** ``` worker_processes auto; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # SSL-настройки ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; # Upstreams upstream hub_backend { server ${HUB_BACKEND_IP}:${HUB_BACKEND_PORT}; } upstream hub_backend_web { server ${HUB_BACKEND_IP}:${HUB_BACKEND_WEB_PORT}; } upstream wood_backend { server ${WOOD_BACKEND_IP}:${WOOD_BACKEND_PORT}; } upstream wood_auth_backend { server ${WOOD_AUTH_IP}:${WOOD_AUTH_PORT}; } # HTTP → HTTPS редирект server { listen 80; server_name ${HUB_DOMAIN} ${WOOD_DOMAIN}; return 301 https://$host$request_uri; } # Конфиг для hub.bobrobotirk.ru server { listen 443 ssl; server_name ${HUB_DOMAIN}; ssl_certificate /etc/nginx/certs/${HUB_DOMAIN}.crt; ssl_certificate_key /etc/nginx/certs/${HUB_DOMAIN}.key; location / { proxy_pass http://hub_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; } } server { listen 443 ssl; server_name ${HUB_WEB_DOMAIN}; ssl_certificate /etc/nginx/certs/${HUB_WEB_DOMAIN}.crt; ssl_certificate_key /etc/nginx/certs/${HUB_WEB_DOMAIN}.key; location / { proxy_pass http://hub_backend_web; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } # Конфиг для wood.bobrobotirk.ru server { listen 443 ssl; server_name ${WOOD_DOMAIN}; ssl_certificate /etc/nginx/certs/${WOOD_DOMAIN}.crt; ssl_certificate_key /etc/nginx/certs/${WOOD_DOMAIN}.key; location /auth { proxy_pass http://wood_auth_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { proxy_pass http://wood_backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } } ``` Алгоритм добавления еще одного endpoint: Файл .env Константы, связанные с endpoint ``` ELSE_BACKEND_IP=192.168.1.198 ELSE_BACKEND_PORT=8000 ``` Файл docker-compose .yaml Добавляем эти константы в envsubst для машины nginx ``` envsubst '$${ELSE_BACKEND_IP} $${ELSE_BACKEND_PORT} ...' ``` И добавляем еще один сервис ``` else-backend: image: else-backend:0.1 container_name: else-backend #restart: unless-stopped # Автоперезапуск при ошибках ports: - "${ELSE_BACKEND_PORT}:8000" # host:container environment: - APP_ENV=production - LOG_LEVEL=info - WORKERS_PER_CORE=1 # Оптимально для CPU-bound приложений - MAX_WORKERS=4 # Лимит на случай автоскейлинга - TIMEOUT=120 # Макс. время выполнения запроса (сек) - KEEP_ALIVE=5 # Поддержка keep-alive соединений command: sh -c "uvicorn main:app --host=0.0.0.0 --port=8000 --reload" volumes: - ./backend/app:/app ``` В файле nginx.conf.template добавляем два раздела ``` ... # Upstreams upstream else-backend { server ${ELSE_BACKEND_IP}:${ELSE_BACKEND_PORT}; } ... location /else { proxy_pass http://else-backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } ``` **docker-compose.yaml** ```yaml services: nginx-proxy: image: nginx:latest container_name: nginx-proxy hostname: nginx-proxy ports: - "80:80" - "443:443" volumes: - ./nginx.conf.template:/etc/nginx/templates/nginx.conf.template - ./certs:/etc/nginx/certs env_file: - .env # Подключаем переменные из файла command: > /bin/sh -c " envsubst '$${HUB_BACKEND_IP} $${HUB_BACKEND_PORT} $${HUB_BACKEND_WEB_PORT} $${WOOD_BACKEND_IP} $${WOOD_BACKEND_PORT} $${WOOD_AUTH_IP} $${WOOD_AUTH_PORT} $${HUB_DOMAIN} $${HUB_WEB_DOMAIN} $${WOOD_DOMAIN}' < /etc/nginx/templates/nginx.conf.template > /etc/nginx/nginx.conf && nginx -g 'daemon off;' " restart: no ``` # Файловый сервер Один из самых простых S3-совместимых серверов - minio ([официальный сайт](https://min.io/)) Еще есть FreeNAS. **Запуск сервера** Compose файл для тестов: ``` services: minio: image: minio/minio:latest container_name: minio restart: unless-stopped volumes: - minio-storage:/data - minio-config:/root/.minio environment: - MINIO_ROOT_USER=miniuser - MINIO_ROOT_PASSWORD=admin123 command: server /data --console-address ":9001" ports: - "9000:9000" - "9001:9001" volumes: minio-storage: minio-config: ``` Запускает сервер API на 9000 порту, web интерфейс управления на 9001 [+ сертификаты](https://habr.com/ru/companies/veeam/articles/517392/) [Тоже интересно](https://pressanybutton.ru/post/primenenie-docker/sobstvennoe-s3-hranilishe-na-baze-minio/) **Настройка bucket** Создается группа с правом readwrite, создается пользователь и привязывается к группе. Создается bucket. Из-под пользователя создается ключ доступа. # Mariadb Установка клиента mariadb ``` sudo apt install mariadb-client mysql -u user -p -h 127.0.0.1 -P 3306 ``` Dockerfile ``` FROM mariadb:latest # Устанавливаем переменные окружения ENV MYSQL_ROOT_PASSWORD=... ENV MYSQL_DATABASE=... ENV MYSQL_USER=... ENV MYSQL_PASSWORD=... #ENV MYSQL_ROOT_HOST= '%' # Разрешить root-подключения с любого хоста (опционально) # Копируем SQL-скрипт для дополнительных прав COPY ./init.sql /docker-entrypoint-initdb.d/ ``` init.sql ``` GRANT ALL PRIVILEGES ON wood_db.* TO 'wooduser'@'%'; FLUSH PRIVILEGES; ``` docker-compose.yaml ```yaml services: mariadb: image: hub.bobrobotirk.ru/appone-db:0.1.0 container_name: mariadb volumes: - ./dbdata:/var/lib/mysql ports: - "${MYSQL_PORT}:3306" restart: unless-stopped ``` Еще вариант: ```yaml services: mariadb: image: mariadb:10.11 container_name: mariadb restart: unless-stopped environment: MARIADB_ROOT_PASSWORD: rootpassword MARIADB_DATABASE: mydb MARIADB_USER: myuser MARIADB_PASSWORD: mypassword ports: - "3306:3306" volumes: - ./mariadb_data:/var/lib/mysql - ./init:/docker-entrypoint-initdb.d ``` # k8s # Тестовый kubernetes [Гитхаб книги](https://github.com/nigelpoulton/TheK8sBook.git) [Интересная статья по настройке HA k8s](https://habr.com/ru/companies/slurm/articles/439562/) [Hard way установка](https://github.com/kelseyhightower/kubernetes-the-hard-way/tree/master) **Docker desktop** **Введение.** Для изучения kubernetes в книге "The kubernetes book 2024 edition" автора Nigel Poulton предложено использовать Docker Desktop для запуска одноузлового кластера и дальнейших экспериментов. Я решил не устанавливать лишнего в систему и запустить все на виртуальной машине. Итоговый стек: Windows 10 - Virtualbox 7.0 - Ubuntu 24.04 - Docker Desktop - K8s. **Настройки VM:** [![k8s_install_vmsettings1.JPG](http://bobrobotirk.ru/uploads/images/gallery/2024-11/scaled-1680-/k8s-install-vmsettings1.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2024-11/k8s-install-vmsettings1.JPG) [![k8s_install_vmsettings2.JPG](http://bobrobotirk.ru/uploads/images/gallery/2024-11/scaled-1680-/k8s-install-vmsettings2.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2024-11/k8s-install-vmsettings2.JPG) [![k8s_install_vmsettings3.JPG](http://bobrobotirk.ru/uploads/images/gallery/2024-11/scaled-1680-/k8s-install-vmsettings3.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2024-11/k8s-install-vmsettings3.JPG) **Установка** ``` mkdir -p $HOME/.kube sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gpg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl sudo systemctl enable --now kubelet swapoff -a kubectl kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.0.109 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config kubectl get nodes kubeadm token create --print-join-command kubectl get nodes kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml kubectl get no kubectl get po --all-namespaces ``` **Дополнительные удобства** Настройка другого редактора (по умолчанию vi) например при выполнении команды kubectl edit pod ... ``` nano .bashrc #Добавить строку export EDITOR=nano #Для использования в текущей сессии, в последующих сессиях автоматически source ~/.bashrc ``` При установке через kubeadm для балансировки трафика требуется MetalLB, [детали установки](http://bobrobotirk.ru/books/docker-k8s/page/setevaia-podsistema "Сетевая подсистема") Установка kubectl для управления с другой системы ``` curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl ``` Скопировать файл авторизации config в ~/.kube/config # Сетевая подсистема **Стартовая информация** Сетевой плагин выбирается во время установки кластера. [Документация, сетевая модель K8s](https://kubernetes.io/docs/concepts/services-networking/) Выдержки: 1. Сетевая подсистема используется только подами (не нодами). 2. У каждой node свой пул ip адресов для запущенных у них pod. 3. Каждый Pod в кластере имеет собственный уникальный в пределах кластера IP адрес. 4. У каждого Pod свое частное сетевое пространство, общее для всех контейнеров внутри Pod. Контейнеры внутри Pod взаимодействуют через localhost. 5. Pod'ы взаимодействуют с Pod на других нодах при помощи сетевого плагина (CNI). 6. Служба - это метод предоставления доступа к Pod в кластере (внутренний и внешний) Вот вроде просто, но нихера не понятно. Поэтому дальше начинается самое веселое) **Следствия пункта 1.** Связность между нодами и контроллером опосредованно зависит от сетевого взаимодействия подов. Поэтому вопрос сети при управлении - один вопрос, вопрос сети подов - второй вопрос. Первый вопрос относительно простой: сетевая видимость точка - точка между IP адресами. Необходимые порты при настройке port-forwarding: На мастер нодах: ``` TCP 6443* Kubernetes API Server TCP 2379-2380 etcd server client API TCP 10250 Kubelet API TCP 10251 kube-scheduler TCP 10252 kube-controller-manager TCP 10255 Read-Only Kubelet API ``` На воркерах: ``` TCP 10250 Kubelet API TCP 10255 Read-Only Kubelet API TCP 30000-32767 NodePort Services ``` Открываем порты и управление начнет работать. Теперь нужна сетевая связность между подами.

Для использования службы типа LoadBalancer необходимо установить балансировщик, например MetalLB. При существовании кластера в пределах одного L2 сегмента хватит L2 режима. Однако при разных сетях у worker потребуется BGP. Картинку можно представить следующим образом:

Роли маршрутизаторов R1 и R2 выполняют сетевые плагины (MetalLB, Calico, ...) в BGP режиме. Им необходим обмен маршрутной информацией в пределах L3 сети. Классическая сетевая задача - сделать видимым IP Pool 1 для IP Pool 2. Тут можно решить при помощи VXLAN и т д. В случае реализации без туннелей в L3 сети требуется, чтобы маршрутизаторы внутри этой сети также обладали маршрутной информацией. **Настройка MetalLB** Примените манифест для установки MetalLB ``` kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml ``` Дождаться запуска контейнеров ``` kubectl get pods -n metallb-system ``` Создайте конфигурационный файл для MetalLB. Например, `metallb-config.yaml` ```yaml apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: first-pool namespace: metallb-system spec: addresses: - 192.168.1.240-192.168.1.250 # Укажите диапазон IP-адресов, доступных в вашей сети --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2advert namespace: metallb-system spec: ipAddressPools: - first-pool ``` Применить конфигурацию: ``` kubectl apply -f metallb-config.yaml ```

# Pod & containers **Pod (под)** Pod это уровень абстракции. Он включает: - совместное использование ресурсов - управление планировщиком - тестирование на рабочеспособность - политики перезапуска - политики безопасности - контроль завершения - тома Он также абстрагирует детали рабочей нагрузки (контейнер, виртуальная машина, Wasm) но для некоторых могут потребоваться дополнительные модули (например KubeVirt для виртуалок). Под смертен (после завершения или ошибки он удаляется без возможности перезапуска) и постоянны (для изменения нужно удалить старый и создать новый). **Настройка ноды для пода** NodeSelectors - список меток нодов. Простейший случай. Affinity and anti-affinity - продвинутый способ Позволяет attract • Anti-affinity rules repel • Hard rules must be obeyed • Soft rules are only suggestions Topology spread constraints - ограничения на топологию Resource requests and resource limits **Теория процесса запуска pod** 1. Создать YAML манифест 2. Отправить манифест на API сервер 3. Запрос будет аутентифицирован и авторизован 4. Спецификация будет проверена 5. Планировщик отфильтрует ноды на основе ограничений 6. Под будет привязан к удовлетворяющей требованиям ноде 7. Сервис kubelet на ноде получит задание 8. Сервис kubelet скачает спецификацию и сформирует задачу для исполнения 9. Сервис kubelet мониторит статус поды и в случае изменения направляет информацию на планировщик **Запуск пода** Есть два варианта: непосредственно через манифест на ноде или через контроллер. Первый вариант быстрый но без большинства возможностей (статический под, типа docker container). Второй вариант используется обычно. Кластер создает сеть подов и автоматически подключает все поды к ней. Это одноуровневая L2 overlay сеть **Статусы пода** Pending под еще не создан, поиск ноды для запуска Running нода найдена, запуск произведен Init:X/Y исполнение инит контейнеров, завершено X из Y Политики перезапуска настраиваются для контейнера. Поэтому пока идет перезапуск контейнера, считается что под еще работает. При обновлении под удаляется и создается новый. Это необходимо учитывать при разработке архитектуры. **Структура YAML файла** Верхний уровень

Параметр	Описание
Kind	Тип определяемого объекта. В данном случае Pod
apiVersion	Версия API
metadata	Метаданные
spec	Спецификация контейнеров

Metadata: метаданные пода

Параметр	Описание
name	Имя пода. Используется в качестве hostname у всех контейнеров для этого пода. Поэтому должно быть валидным DNS именем
labels	Метки пода

Spec: описание параметров контейнера, томов, внутри для каждого контейнера - name: имя\_контейнера

Параметр	Описание
containers	Обычные контейнеры ```yaml spec: initContainers: - name: ... containers: - name: ... ```
initContainers	Контейнеры, запускаемые до старта обычных контейнеров. Обычные запускаются только после завершения init контейнеров.
volumes:	Тома ```yaml volumes: - name: html emptyDir: {} ```

Параметры контейнера:

Параметр	Описание
image	Образ ``` image: nigelpoulton/k8sbook:1.0 ``` Для использования другого хаба добавить URL перед именем образа
ports	Порты
resources	ограничения на ресурсы ``` resources: requests: <<==== Minimums for scheduling cpu: 0.5 memory: 256Mi limits: <<==== Maximums for kubelet to cap cpu: 1.0 memory: 512Mi ``` Если нода с нужными ресурсами не найдена - под в статусе Pending. Для всех контейнеров в поде.
env	Переменные окружения. ``` env: - name: GIT_SYNC_REPO value: https://github.com/nigelpoulton/ps-sidecar.git ```
volumeMounts	Тома ``` volumeMounts: - name: html <<==== Mount shared volume mountPath: /usr/share/nginx/ ``` Настройки тома проводятся отдельно

Пример 1. ```yaml kind: Pod apiVersion: v1 metadata: name: hello-pod labels: zone: prod version: v1 spec: containers: - name: hello-ctr image: nigelpoulton/k8sbook:1.0 ports: - containerPort: 8080 resources: limits: memory: 128Mi cpu: 0.5 ``` Пример 2. Init контейнер. ```yaml apiVersion: v1 kind: Pod metadata: name: initpod labels: app: initializer spec: initContainers: - name: init-ctr # Pinned to 1.28 as newer versions have a sketchy nslookup command that doesn't work. Can also use a non-busybox image here image: busybox:1.28.4 command: ['sh', '-c', 'until nslookup k8sbook; do echo waiting for k8sbook service; sleep 1; done; echo Service found!'] containers: - name: web-ctr image: nigelpoulton/web-app:1.0 ports: - containerPort: 8080 ``` Пока образы в init контейнере не завершились, статус в Init:0/1 ``` kubectl get pods --watch NAME READY STATUS RESTARTS AGE initpod 0/1 Init:0/1 0 16s ``` Пример 3. Дополнительный контейнер, обновляющий папку при изменении репозитория ```yaml # Some network drivers and laptop VM implementations cause issues with Service port mapping # Minikube users may have to `minikube service svc-sidecar` to be able to access on `localhost:30001` # Other users may have to run `kubectl port-forward service/svc-sidecar 30001:80` apiVersion: v1 kind: Pod metadata: name: git-sync labels: app: sidecar spec: containers: - name: ctr-web image: nginx volumeMounts: - name: html mountPath: /usr/share/nginx/ - name: ctr-sync image: k8s.gcr.io/git-sync:v3.1.6 volumeMounts: - name: html mountPath: /tmp/git env: - name: GIT_SYNC_REPO value: https://gitverse.ru/bobrobot/k8s_pods.git - name: GIT_SYNC_BRANCH value: master - name: GIT_SYNC_DEPTH value: "1" - name: GIT_SYNC_DEST value: "html" volumes: - name: html emptyDir: {} --- apiVersion: v1 kind: Service metadata: name: svc-sidecar spec: selector: app: sidecar type: NodePort ports: - port: 80 nodePort: 30001 ``` При обращении на адрес кластера или ноды будет отображаться страница. **Основные команды**

Команда	Доп. пар.	Описание
kubectl explain pods --recursive		Вывод всех параметров, доступных для конфигурирования Pod
kubectl get pods		список контейнеров
	-o yaml	расширенная информация о подах
kubectl apply	-f file.yml	Создание под из file.yml
kubectl describe	pod pod\_name	Описание пода
kubectl logs pod\_name		логи на поде. По умолчанию первого контейнера в поде
	--container cont\_name	логи конкретного контейнера
kubectl exec		Выполнение команд внутри контейнера Два варианта
	pod\_name -- command	Выполняет command на pod\_name и возвращает результат в консоль. По умолчанию на первом контейнере. -- container для указания контейнера.
	-it pod\_name -- command	Подключается в интерактивном режиме на контейнер и выполняет команду. ``` kubectl exec -it hello-pod -- sh ```
kubectl edit pod pod\_name		Редактирование под (для nano - в части дополнительные удобства Тестовый k8s) Пока не получилось.
kubectl delete	pod	Удаление подов. Имена подов через пробел
	svc	Удаление сервисов.
	-f	Удаление с использованием yaml файлов.

**Container (контейнер)** Паттерны мультиконтейнеров Init контейнеры - специальный тип контейнеров, для которых K8s гарантирует единственный запуск и завершение, перед остальными контейнерами. Пример: есть приложение и внешнее API с которым обязательно должно быть взаимодействие при старте. Вместо нагрузки на основную логику, можно процесс проверки вывести в init контейнер. Slidecar контейнеры - выполняют периферийные задачи. Пока что бета. # Namespaces Разделяет кластер на виртуальные кластеры. Это не Namespace ядра! По умолчанию объекты попадают в default namespace. Настраиваются свои пользователи, права, ресурсы и политики. **Создание и привязка к пространству имен** Императивный способ: ``` kubectl create ns hydra ``` Декларативный способ: создать yaml файл и применить его. --- Для привязки объекта к пространству имен в метаданных нужно указать namespace ``` apiVersion: v1 kind: ServiceAccount metadata: namespace: shield <<==== Namespace name: default ``` **Структура YAML файла** Верхний уровень

Параметр	Описание
Kind	Тип определяемого объекта, Namespace
apiVersion	Версия API
metadata	Метаданные

Metadata

Параметр	Описание
name	Имя
labels	метки

**Примеры** ``` kind: Namespace apiVersion: v1 metadata: name: shield labels: env: marvel ``` **Основные команды**

Команда	Доп. пар.	Описание
kubectl api-resources		Список API ресурсов, в частности - делятся ли на namespace
kubectl get namespaces		Список пространств имен
kubectl describe ns name\_ns		Информация по name\_ns пространству имен
Все команды получения информации	--namespace default	Фильтрация по определенному namespace
	--all-namespaces	Для всех namespace
kubectl create ns ns\_name		Создание пространства имен ns\_name
kubectl delete ns ns\_name		Удаление пространства имен ns\_name
kubectl config set-context --current --namespace shield		Установка пространства имен по умолчанию

# Deployment Deployments наиболее популярный способ для запуска приложений без сохранения состояния. Это добавляет проверку состояния, масштабирование, восстановление. Реализовано через deployment контроллер. Каждый контроллер управляет одним или несколькими одинаковыми подами. [![k8s_deployments_1.JPG](http://bobrobotirk.ru/uploads/images/gallery/2025-03/scaled-1680-/k8s-deployments-1.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2025-03/k8s-deployments-1.JPG) **Масштабирование (Scalling)** Существуют несколько типов

Тип	Описание
Horizontal Pod Autoscaler	Масштабирование количества подов, наиболее часто используется.
Vertical Pod Autoscaler	Масштабирование ресурсов, потребляемых подами. Не установлен по умолчанию. Редко используется
Cluster Autoscaler	Добавляет/удаляет ноды. По умолчанию, часто используется.

Например, указываем кол-во подов от 2 до 10. Нагрузка повысилась, и HPA запрашивает еще 2 пода. Они запускаются. Но нагрузка растет, и запрашивается еще 2 пода. Однако на существующем кластере нет возможности запустить еще 2 пода, и они переходят в статус Pending. CA определяет Pending поды и увеличивает количество нодов, запуская там поды. И наоборот. Масштабирование связано с понятием текущего состояния (state). Есть необходимое состояние и наблюдаемое состояние. При неравенстве контроллер запускает процесс изменений. Важно: архитектура приложения должна поддерживать возможность масштабирования. Микросервисы должны взаимодействовать только через API. При увеличении количества, добавляется новый под. **Реплики** ReplicaSets - набор настроек и подов с одной версией конфигурации. При обновлении yaml создается вторая ReplicaSet и один новый под. Из старой ReplicaSet удаляется один под. И так далее до полного обновления. Но конфигурация сохраняется. Можно вернуть к старым настройкам. **Структура YAML файла** Верхний уровень

Параметр	Описание
kind	Тип, в данном случае Deployments
spec	Спецификация

spec

Параметр	Описание
strategy	Стратегия восстановления
replicas	кол-во реплик
selector	правила выбора меток
template	описание шаблона (все аналогично описанию пода)

**Примеры** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: hello-deploy spec: replicas: 10 selector: matchLabels: app: hello-world revisionHistoryLimit: 5 progressDeadlineSeconds: 300 minReadySeconds: 10 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: hello-world spec: containers: - name: hello-pod image: nigelpoulton/k8sbook:1.0 ports: - containerPort: 8080 resources: limits: memory: 128Mi cpu: 0.1 ``` Пример сервиса для данного приложения ```yaml apiVersion: v1 kind: Service metadata: name: lb-svc labels: app: hello-world spec: type: LoadBalancer ports: - port: 8080 protocol: TCP selector: app: hello-world ``` **Основные команды**

Команда	Доп. пар.	Описание
kubectl get deploy dep\_name		статус
kubectl describe deploy dep-name		Расширенная информация
kubectl get rs		Список реплик
kubectl scale	deploy dep\_name --replicas count	Императивное масштабирование. Нежелательно.
kubectl rollout status deployment dep\_name		Статус обновления подов
kubectl rollout pause deploy dep\_name		Приостановка обновления
kubectl describe deploy dep\_name		Отображает в частности список роллбеков
kubectl rollout history deployment dep\_name		История роллбеков
kubectl rollout undo deployment hello-deploy --to-revision=1		Возврат. Быстро, но не рекомендуется. Лучше через загрузку старого файла из репозитория и обновление.

# Services Сервис используется для подключения подов к внешней сети. Сервис использует метки для выбора подов. Все указанные метки должны быть на поде (дополнительные метки пода игнорируются) В сервисе - раздел selector ``` spec: replicas: 10 template: metadata: labels: project: tkb zone: prod --- apiVersion: v1 kind: Service metadata: name: tkb spec: ports: - port: 8080 selector: project: tkb zone: prod ``` **Типы сервисов** **ClusterIP** Используется для доступности подов внутри кластера. Доступность по имени сервиса. **NodePort Services** Используется для доступа приложений снаружи кластера. Добавляет указанный порт на каждую ноду. ``` apiVersion: v1 kind: Service metadata: name: skippy <<==== Registered with the internal cluster DNS (ClusterIP) spec: type: NodePort <<==== Service type ports: - port: 8080 <<==== ClusterIP port targetPort: 9000 <<==== Application port in container nodePort: 30050 <<==== External port on every cluster node (NodePort) selector: app: hello-world ``` В данном примере изнутри под доступен по порту 8080, снаружи - по порту 30050. Диапазон портов 30000-32767. **LoadBalancer Services** Используется для сервисов со стартовым диапазоном портов, наиболее часто. ``` apiVersion: v1 kind: Service metadata: name: lb <<==== Registered with cluster DNS spec: type: LoadBalancer ports: - port: 8080 <<==== Load balancer port targetPort: 9000 <<==== Application port inside container selector: project: tkb ``` Мой кубер использует flannel, а для корректной работы LoadBalancer нужен балансировщик, например MetalLB. Стек в случае балансировщика: [![k8s_services_1.JPG](http://bobrobotirk.ru/uploads/images/gallery/2025-03/scaled-1680-/k8s-services-1.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2025-03/k8s-services-1.JPG) **Headless сервисы** Сервисы без IP адреса. Их цель - создать DNS записи для StatefulSet подов. Клиенты запрашивают DNS имена подов и направляют непосредственно им запросы вместо использования кластерного IP. Пример сервиса: ``` apiVersion: v1 kind: Service <<==== Normal Kubernetes Service metadata: name: dullahan labels: app: web spec: ports: - port: 80 name: web clusterIP: None <<==== Make this a headless Service selector: app: web ``` **Структура YAML файла** Верхний уровень

Параметр	Описание
kind	Тип, в данном случае Service
spec	Спецификация

spec

Параметр	Описание
type	тип (ClusterIP, NodePort, LoadBalancer)
ports	port - порт фронтенда targetPort - порт на бэке
selector	правила выбора меток

Пример yaml файла ``` apiVersion: v1 kind: Service metadata: name: cloud-lb spec: type: LoadBalancer ports: - port: 9000 targetPort: 8080 selector: chapter: services ``` **Основные команды**

Команда	Доп. пар.	Описание
kubectl expose deployment dep\_name --type=LoadBalancer		Ручное создание сервиса. Вот только не поехало.
kubectl get svc -o wide		Информация по сервисам
kubectl get endpointslices		Список ендпоинтов
kubectl describe endpointslice epname		Описание ендпоинта

# Ingress Используется для организации внешнего взаимодействия на L7 уровне. Ingress ресурсы определяют правила маршрутизации, Ingress контроллер выполняет задачу. Маршрутизация в смысле L7, не в смысле L3 Могут быть host-based и path-based маршруты:

Host-based example	Path-based example	Backend K8s Service
shield.mcu.com	mcu.com/shield	shield
hydra.mcu.com	mcu.com/hydra	hydra

[![k8s_ingress_1.JPG](http://bobrobotirk.ru/uploads/images/gallery/2025-03/scaled-1680-/k8s-ingress-1.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2025-03/k8s-ingress-1.JPG) Необходим внешний Ingress-controller, очень часто Nginx. **Ingress классы** Позволяют запустить несколько ingress контроллеров в одном кластере. Сначала привязывается Ingress контроллер к классу, затем при создании объект Ingress привязывается к классу. **Пример** ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: mcu-all annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: nginx rules: - host: shield.mcu.com http: paths: - path: / pathType: Prefix backend: service: name: svc-shield port: number: 8080 - host: mcu.com http: paths: - path: /shield pathType: Prefix backend: service: name: svc-shield port: number: 8080 ``` **Основные команды**

Команда	Доп. пар.	Описание
kubectl get ingressclass		Список классов Ingress
kubectl describe ingressclass class\_name		Детализация для класса class\_name
kubectl get ingress my-ingress -n my-ns -o yaml		Получить конфигурацию в виде yaml
kubectl get ing		Список ingress
kubectl describe ing mcu-all		Детализация ingress

# Storages Система хранения работает через драйверы (CSI плагины) или локально на нодах. Второй вариант неудобный. Далее первый вариант. Разработчик обычно предоставляет плагины в виде Helm чартов или yaml установщиков. Они устанавливаются в виде набора подов в namespace kube-system. [Список плагинов](https://kubernetes-csi.github.io/docs/drivers.html) Для тестов можно использовать встроенный драйвер, OpenEbs. К вопросу выбора драйвера, архитектуры хранилища и безопасности необходимо подходить очень серьезно. Процесс запроса ресурсов: Pod Volume - PVC - SC - CSI Plugin **Storage Classes** ресурсы в storage.k8s.io/v1 группе. Неизменяемый. Для обновления нужно удалить и создать. SC access mode: - ReadWriteOnce - один PVC может подключиться в режиме чтения/записи - ReadWriteMany - несколько PVC. Файловые и объектные хранилища обычно поддерживают, блоковые нет. - ReadOnlyMany - несколько PVC в режиме чтения. Все PV должны подключиться в одинаковом режиме. **Reclaim policy (политика восстановления)** Политики восстановления сообщают Kubernetes, что делать с PV и связанным с ним внешним хранилищем, когда его PVC будет запущен. - Delete. Удаление PVC приведет к удалению PV и внешнего хранилища. - Retain. Безопаснее, но нужно самостоятельно удалять ресурсы. **Volume binding mode** Момент создания бакета. Immediate - сразу же, WaitForFirstConsumer - при подключении первого. **Примеры** **Локальное хранилище (устаревшее)** На воркере ``` sudo mkdir -p /mnt/disks/ssd1 sudo chmod 777 /mnt/disks/ssd1 # Для упрощения примера ``` Настройка PV ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: example-local-pv labels: type: local spec: capacity: storage: 10Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: /mnt/disks/ssd1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - # Замените на имя узла, где находится директория ``` Настройка PVC ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: example-local-pvc spec: accessModes: - ReadWriteOnce storageClassName: local-storage resources: requests: storage: 10Gi ``` Проверка связи ``` kubectl get pv kubectl get pvc ``` Использование в Pod ```yaml apiVersion: v1 kind: Pod metadata: name: example-pod spec: containers: - name: example-container image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: local-storage volumes: - name: local-storage persistentVolumeClaim: claimName: example-local-pvc ``` Удаление ресурсов ``` kubectl delete pod example-pod kubectl delete pvc example-local-pvc kubectl delete pv example-local-pv ``` **Хранилище Yandex.cloud** S3 aws - совместимое хранилище. 1\. Настройка доступа через консоль Установить консоль yc ``` curl -sSL https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash source ~/.bashrc ``` Запросить новый OAuth токен. Время жизни токена 1 год. Инициализировать консоль ``` yc init ``` 2\. Настройка доступа к бакету Через web-консоль создать бакет. [![k8s_volumes_1.JPG](http://bobrobotirk.ru/uploads/images/gallery/2025-03/scaled-1680-/k8s-volumes-1.JPG)](http://bobrobotirk.ru/uploads/images/gallery/2025-03/k8s-volumes-1.JPG) Выяснить folder\_id созданного аккаунта ``` yc storage bucket get k8stest name: k8stest folder_id: b...q anonymous_access_flags: read: false list: false config_read: false default_storage_class: STANDARD versioning: VERSIONING_DISABLED max_size: "1073741824" created_at: "2025-03-23T06:35:58.715069Z" ``` Создать сервисный аккаунт для доступа к бакету, в выводе будет id аккаунта ``` yc iam service-account create --name k8stest --output key.json ``` Файл key.json понадобится далее. Добавить роль для созданного бакета сервис аккаунту ``` yc resource-manager folder add-access-binding <идентификатор_каталога> \ --role <роль> \ --subject serviceAccount:<идентификатор_сервисного_аккаунта> ``` 3\. Установка CSI плагина для yandex.cloud ``` git clone https://github.com/deckhouse/yandex-csi-driver.git cd yandex-csi-driver ``` В самом git сказано, что запускать нужно из папки deploy/1.17 установив 2 переменные. У меня это не заработало. В папке yandex-csi-driver/charts/yandex-csi-controller установить serviceAccountJSON и folderID В файле csidriver.yaml заменить apiVersion: storage.k8s.io/v1beta1 на apiVersion: storage.k8s.io/v1 Дополнительно: ``` # Список сервис аккаунтов yc iam service-account list # Детализация информации по аккаунту yc iam service-account get <идентификатор_аккаунта> # Удаление аккаунта yc iam service-account delete <идентификатор_аккаунта> ``` И нечего с yandex не получилось. **Настройка MinIO** [Настройка внешнего MinIO](http://bobrobotirk.ru/books/docker-k8s/page/failovyi-server "Файловый сервер") **Настройка авторизации** Создать Secret. Ключ и Секрет не в Base64, а как указано при создании бакета. ```yaml apiVersion: v1 kind: Secret metadata: namespace: kube-system name: csi-s3-secret stringData: accessKeyID: XP5...Ih secretAccessKey: klz...zo # For AWS set it to "https://s3..amazonaws.com" endpoint: http://192.168.1.194:9000 # If not on S3, set it to "" region: "" ``` Применить Secret ``` kubectl apply -f 1-minio-credentials.yaml kubectl get secret ``` **Установка csi драйвера** Проверить установленные csi драйверы, поставить драйвер ``` git clone https://github.com/ctrox/csi-s3.git cd csi-s3/deploy/kubernetes kubectl apply -f . ``` Вот только какого-то хера в данной директории не было yaml для создания драйвера) Добавляем драйвер ```yaml apiVersion: storage.k8s.io/v1 kind: CSIDriver metadata: name: ch.ctrox.csi.s3-driver spec: attachRequired: false podInfoOnMount: true ``` Обязательно в списке драйверов должен появиться драйвер ``` kubectl get csidrivers.storage.k8s.io NAME ATTACHREQUIRED PODINFOONMOUNT TOKENREQUESTS REQUIRESREPUBLISH MODES AGE ch.ctrox.csi.s3-driver false true false Persistent 36m ``` И все поды csi должны быть запущены ``` kubectl --namespace kube-system get pods | grep csi csi-attacher-s3-0 1/1 Running 0 9h csi-provisioner-s3-0 2/2 Running 0 9h csi-s3-f5v74 2/2 Running 0 9h ``` **Настройка класса и PVC** Добавляем StorageClass ```yaml --- kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: csi-s3 provisioner: ch.ctrox.csi.s3-driver parameters: # specify which mounter to use # can be set to rclone, s3fs, goofys or s3backer #mounter: rclone mounter: "s3fs" otherOpts: "-o allow_other -o uid=0 -o gid=0 -o umask=000" # to use an existing bucket, specify it here: bucket: bucketone path: "pvc-fbd999ab-1ba7-4b07-922d-51270e6028d9" csi.storage.k8s.io/provisioner-secret-name: csi-s3-secret csi.storage.k8s.io/provisioner-secret-namespace: kube-system csi.storage.k8s.io/controller-publish-secret-name: csi-s3-secret csi.storage.k8s.io/controller-publish-secret-namespace: kube-system csi.storage.k8s.io/node-stage-secret-name: csi-s3-secret csi.storage.k8s.io/node-stage-secret-namespace: kube-system csi.storage.k8s.io/node-publish-secret-name: csi-s3-secret csi.storage.k8s.io/node-publish-secret-namespace: kube-system sslVerify: "false" reclaimPolicy: Retain volumeBindingMode: Immediate ``` mounter rclone на финальном этапе отказался создавать файлы. В директории бакета была создана директория pvc-fbd999ab-1ba7-4b07-922d-51270e6028d9/csi-fs Не знаю почему. но при команде ls (проверка) он находился внутри нее. Добавляем PVC ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: csi-s3-pvc namespace: default spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: csi-s3 ``` **Проверка:** ``` apiVersion: v1 kind: Pod metadata: name: minio-test-pod spec: containers: - name: app image: alpine command: ["sleep", "infinity"] volumeMounts: - name: minio-storage mountPath: /mnt/minio volumes: - name: minio-storage persistentVolumeClaim: claimName: csi-s3-pvc readOnly: false ``` Команда ``` kubectl exec -it minio-test-pod -- sh -c "echo 'New test' > /mnt/minio/test2.txt && ls /mnt/minio" ``` должна вывести созданный файл в списке. **Основные команды**

Команда	Доп. пар.	Описание
kubectl get csidrivers.storage.k8s.io		Список CSI-драйверов
kubectl get storageclass -o wide		Какой PROVISIONER используется
kubectl get pods -n kube-system \| grep csi		Поды CSI-драйверов. Какие поды отвечают за CSI
kubectl get daemonsets -n kube-system		Где работает CSI-драйвер

# Config maps & secrets Набор конфигураций для различных окружений. Включают переменные окружения, конфиг файлы, имена хостов, порты, аккаунты. ``` kind: ConfigMap apiVersion: v1 metadata: name: epl data: Competition: epl Season: 2022-2023 Champions: Manchester City test.conf: | env = plex-test endpoint = 0.0.0.0:31001 char = utf8 vault = PLEX/test log-size = 512M ``` Их можно использовать как переменные окружения, параметры запуска и файлы внутри контейнера. **Использование ConfigMap** **В виде переменных окружения:** ``` apiVersion: v1 kind: Pod spec: containers: - name: ctr1 env: - name: FIRSTNAME valueFrom: configMapKeyRef: <<==== a ConfigMap name: multimap <<==== called "multimap" key: given ``` Не изменяются после создания. **В виде аргументов:** Сначала как переменные окружения, затем в команду создания ``` spec: containers: - name: args1 image: busybox env: - name: FIRSTNAME <<==== Environment variable called FIRSTNAME valueFrom: <<==== based on configMapKeyRef: <<==== a ConfigMap name: multimap <<==== called "multimap" key: given <<==== and populated by the value in the "given" field - name: LASTNAME <<==== Environment variable called LASTNAME valueFrom: <<==== based on configMapKeyRef: <<==== a ConfigMap name: multimap <<==== called "multimap" key: family <<==== and populated by the value in the "family" field command: [ "/bin/sh", "-c", "echo First name $(FIRSTNAME) last name $(LASTNAME)" ] ``` **В виде файлов:** Создается том и привязывается к нему ConfigMap ``` apiVersion: v1 kind: Pod metadata: name: cmvol spec: volumes: - name: volmap <<==== Create a volume called "volmap" configMap: <<==== based on the ConfigMap name: multimap <<==== called "multimap" containers: - name: ctr image: nginx volumeMounts: <<==== These lines mount the - name: volmap <<==== the "volmap" volume into the mountPath: /etc/name <<==== container at "/etc/name" ``` Файлы будут созданы в соответствии именам в ConfigMap. При обновлении ConfigMap файлы в контейнере обновятся. **Secrets** Хранятся в Base64 но внутри контейнера хранятся в tmpfs виде обычного текста. ``` apiVersion: v1 kind: Secret metadata: name: tkb-secret labels: chapter: configmaps type: Opaque data: <<==== Change to "stringData" for plain text username: bmlnZWxwb3VsdG9u password: UGFzc3dvcmQxMjM= ``` Использование в Pod: ``` apiVersion: v1 kind: Pod metadata: name: secret-pod labels: topic: secrets spec: volumes: - name: secret-vol <<==== Volume name secret: <<==== Volume type secretName: tkb-secret <<==== Populate volume with this Secret containers: - name: secret-ctr image: nginx volumeMounts: - name: secret-vol <<==== Mount the volume defined above mountPath: "/etc/tkb" <<==== into this path ``` В директории /etc/tkb будут храниться файлы, по одному на каждое значение. **Основные команды**

Команда	Доп. пар.	Описание
kubectl get cm		Список ConfigMap

# StatefulSet Очень похожи на Deployments, но StatefulSet дополнительные функции: - Предсказуемые и постоянные имена модулей - Предсказуемые и постоянные имена узлов DNS - Предсказуемые и постоянные привязки томов Отличие: Deployment создает поды сразу же, а StatefulSet по одному. Это критично для сохранения данных. **Именование подов:** <StatefulSet name>-<integer>. Число от 0-... Для каждого пода создается свой том, с соответствующим именованием. Созданные тома имеют свой жизненный цикл и они не удаляются при масштабировании подов. **Удаление Statefulset:** Автоматического удаления подов нет. Сначала нужно снизить количество до 0. Также нужно использовать terminationGracePeriodSeconds около 10 секунд для безопасного завершения работы. Создаем headless сервис ([Services](http://bobrobotirk.ru/books/docker-k8s/page/services "Services")) # Безопасность **Авторизация и аутентификация** По умолчанию аутентификация на основе сертификата, но поддерживаются внешние источники. Аутентификация на основе сертификата. Авторизация RBAC (пользователь - действие - ресурс). По умолчанию запрещено все что не разрешено. Роли определяют правила, RoleBindings определяют принадлежность пользователей к ролям. Пример настройки ролей: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: shield name: read-deployments rules: - verbs: ["get", "watch", "list"] <<==== Allowed actions apiGroups: ["apps"] <<==== on resources resources: ["deployments"] <<==== of this type ``` Пример RoleBinding: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-deployments namespace: shield subjects: - kind: User name: sky <<==== Name of the authenticated user apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: read-deployments <<==== This is the Role to bind to the user apiGroup: rbac.authorization.k8s.io ``` Свойства правил роли: verbs \["get", "watch", "list", "create", "update", "patch", "delete"\] ApiGroups (в пределах namespace):

apiGroup	Ресурс
""	pods, secrets
“storage.k8s.io”	storageclass
“apps”	deployments

Полный список API ресурсов: ``` kubectl api-resources --sort-by name -o wide ``` Можно использовать звездочку. Все роли используются только в контексте namespace! **Кластерные роли и привязки** ClusterRoleBindings используется для создания шаблонов ролей и привязки их к конкретным ролям. ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole <<==== Cluster-scoped role metadata: name: read-deployments rules: - verbs: ["get", "watch", "list"] apiGroups: ["apps"] resources: ["deployments"] ``` **Пользователи** [Интересная статья](https://habr.com/ru/companies/flant/articles/470503/) [Еще одна, тоже стоит почитать](https://devopstales.github.io/kubernetes/k8s-user-accounts/) Обычных пользователей нельзя добавить через вызовы API. Возможные варианты: - Базовая аутентификация *(basic auth)*: - передача конфигурации API-серверу со следующим (или похожим) содержимым: password, username, uid, group; - Клиентский сертификат X.509: - создание секретного ключа пользователя и запроса на подпись сертификата; - заверение его в центре сертификации (Kubernetes CA) для получения сертификата пользователя; - Bearer-токены (JSON Web Tokens, JWT): - OpenID Connect; - слой аутентификации поверх OAuth 2.0; - веб-хуки *(webhooks)*. Структура файла ~/.kube/config - Clusters - список кластеров. Сертификат кластера, адрес и внутреннее имя - Users - пользователи. Внутреннее имя, сертификат и ключ - Contexts - объединение пользователя и кластера. Внутреннее имя, внутреннее имя кластера и внутреннее имя пользователя - Current-context - имя текущего контекста --- Важный момент: кубер не управляет членством пользователей в группах. Получить напрямую доступ к спискам пользователей в группе нельзя. --- **Пример создания пользователя с авторизацией через X.509 сертификат.** Создаем директорию хранения информации о пользователях и генерируем в нее ключ ``` mkdir -p users/sergey/.certs openssl genrsa -out ~/users/sergey/.certs/sergey.key 2048 ``` Генерируем запрос на сертификат ``` openssl req -new -key ~/users/sergey/.certs/sergey.key -out ~/users/sergey/.certs/sergey.csr -subj "/CN=sergey/O=testgroup" ``` Обработка запроса на сертификат ``` openssl x509 -req -in ~/users/sergey/.certs/sergey.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/users/sergey/.certs/sergey.crt -days 500 ``` В некоторых ресурсах говорится, что команда kubectl config set-credentials ... создает пользователя в кластере Kubernetes. Но это не так, команда kubectl config ... создает/модифицирует файл .kube/config, поэтому нужно быть осторожным и не побить свой файл. А Kubernetes авторизует всех пользователей, чей сертификат подписан его центром сертификации. Добавляем пользователя sergey ``` kubectl config set-credentials sergey \ --client-certificate=/root/users/sergey/.certs/sergey.crt \ --client-key=/root/users/sergey/.certs/sergey.key \ --embed-certs=true ``` Если нужно - создали бы настройки кластера, но у нас есть, поэтому создаем контекст с существующим кластером. Namespace, если нужно, указывается в настройках контекста. ``` kubectl config set-context sergey-context --cluster=kubernetes --user=sergey --namespace=sergey-ns ``` Теперь осталось пользователю определить права. Например определим роль sergey-ns-full с полным доступом к namespace sergey-ns ``` apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: sergey-ns-full namespace: sergey-ns rules: - apiGroups: [ "*" ] resources: [ "*" ] verbs: [ "*" ] ``` Сейчас вместо привязки пользователя, привяжем группу к роли. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: testgroup-rolebinding # Название RoleBinding namespace: sergey-ns # Namespace, где применяется subjects: - kind: Group # Тип субъекта — группа name: testgroup # Название группы apiGroup: rbac.authorization.k8s.io roleRef: kind: Role # Тип привязываемой роли (Role или ClusterRole) name: sergey-ns-full # Название роли apiGroup: rbac.authorization.k8s.io ``` Переключаемся на контекст и проверяем ``` kubectl config use-context sergey-context ``` Создаем простой под ``` kind: Pod apiVersion: v1 metadata: name: hello-pod labels: zone: prod version: v1 spec: containers: - name: hello-ctr image: nigelpoulton/k8sbook:1.0 ports: - containerPort: 8080 resources: limits: memory: 128Mi cpu: 0.5 ``` Проверяем факт создания пода ``` kubectl get pods ``` Удалось! **Основные команды управления пользователями** Если при создании ... указать флаг --embed-certs=true то тогда вместо путей к файлам сертификатов, в файл настройки будут встроено содержание сертификатов в Base64.

Команда	Доп. параметры	Описание
kubectl get clusterroles.rbac.authorization.k8s.io --all-namespaces		Список пользователей
kubectl config view		Показать текущую конфигурацию (.kube/config)
kubectl config current-context		Показать текущий активный контекст
kubectl config get-contexts		Список всех контекстов
kubectl config use-context cont\_name		Переключиться на контекст cont\_name
kubectl config set-cluster clast\_name		Добавить/изменить кластер ``` kubectl config set-cluster my-new-cluster \ --server=https://10.0.0.1:6443 \ --certificate-authority=./ca.crt ```
kubectl config set-credentials		Добавить/изменить учетные данные пользователя ``` kubectl config set-credentials sergey \ --client-certificate=/root/users/sergey/.certs/sergey.crt \ --client-key=/root/users/sergey/.certs/sergey.key \ --embed-certs=true ```
kubectl config set-context cont\_name	--cluster=dev-cluster \\ --user=dev-user \\ --namespace=dev-ns	Создать/изменить контекст
kubectl config delete-context		Удалить контекст
kubectl config delete-cluster		Удалить кластер
kubectl config delete-user user\_name		Удалить пользователя
kubectl config rename-context		Переименовать контекст

**Безопасность, общая теория** [Инструменты](https://habr.com/ru/companies/flant/articles/465141/) **Запрет передачи ключей SA** Каждому поду по умолчанию передаются ключи сервисный аккаунт. Поэтому при получении доступа к поду можно получить доступ вплоть до всего кластера. Обычно подам не нужно управлять кластером. Поэтому можно запретить передачу ключей. ``` apiVersion: v1 kind: Pod metadata: name: service-account-example-pod spec: serviceAccountName: some-service-account automountServiceAccountToken: false <<==== This line ``` Также можно передавать временные ключи, но это потом. **Контроль целостности ресурсов** - Ограничьте доступ к серверам, на которых запущены компоненты Kubernetes, особенно к компонентам control plane - Ограничьте доступ к репозиториям, хранящим конфигурационные файлы Kubernetes - Передача файлов и управление только через SSH - Проверка контрольной суммы после скачивания - Ограничьте доступ к регистру образов и связанным хранилищам **Файловая система пода в read-only режим** ``` apiVersion: v1 kind: Pod metadata: name: readonly-test spec: securityContext: readOnlyRootFilesystem: true <<==== R/O root filesystem allowedHostPaths: <<==== Make anything below - pathPrefix: "/test" <<==== this mount point readOnly: true <<==== read-only (R/O) ``` **Лог действий на кластере и связанной инфраструктуре** **Защита данных кластера** Cluster store (обычно etcd) хранит все данные. Необходимо ограничить и контролировать доступ к серверам, на которых работает Cluster store. **DoS** Подвергается API сервер. Должно быть минимум 3 Control plane сервера и 3 worker ноды. Изоляция etcd на сетевом уровне. Ограничения ресурсов для подов и количества подов. ``` apiVersion: v1 kind: ResourceQuota metadata: name: pod-quota namespace: skippy spec: hard: pods: "100" ``` Доп. опция podPidsLimit ограничивает количество процессов одним подом. Также можно ограничить кол-во подов на одной ноде. По умолчанию etcd устанавливается на сервер с control plane. На production кластере нужно разделять. Запретить сетевое взаимодействие между подами и внешние взаимодействия (где это не нужно) при помощи сетевых политик Kubernetes. **Защита подов и контейнеров** Запрет запуска процессов от root ``` apiVersion: v1 kind: Pod metadata: name: demo spec: securityContext: <<==== Applies to all containers in this Pod runAsUser: 1000 <<==== Non-root user containers: - name: demo image: example.io/simple:1.0 ``` Это запускает все контейнеры от одного непривилегированного пользователя, но позволяет контейнерам использовать общие ресурсы. При запуске нескольких подов, будет аналогично. Поэтому лучше дополнительно настраивать пользователей контейнера: ``` apiVersion: v1 kind: Pod metadata: name: demo spec: securityContext: <<==== Applies to all containers in this Pod runAsUser: 1000 <<==== Non-root user containers: - name: demo image: example.io/simple:1.0 securityContext: runAsUser: 2000 <<==== Overrides the Pod-level setting ``` Рутовые права складываются примерно из 30 capabilities. Простой способ - в тестовом окружении ограничить все и по логам добавлять нужные. Естественно финальное тестирование должно быть максимально всеобъемлющим. Пример разрешений: ``` apiVersion: v1 kind: Pod metadata: name: capability-test spec: containers: - name: demo image: example.io/simple:1.0 securityContext: capabilities: add: ["NET_ADMIN", "CHOWN"] ``` Фильтрация системных вызовов. Похоже на capabilities, но фильтрует системные вызовы. Способы поиска минимальных разрешений: разрешить все + логгирование, запрет + постепенное разрешение. Также есть Pod Security Standarts (PSS) и Pod Security Admission (PSA). PSA применяют PSS при старте пода. **Основные команды**

Параметр	Описание
kubectl describe clusterrole role\_name	Описание роли
kubectl get clusterrolebindings \| grep role\_name	Список пользователей с такой ролью
kubectl describe clusterrolebindings role\_name	Информация по сопоставлению
Аналогично для ролей (clusterrolebindings -> rolebindings)

# Job, cronjob **Job** Выполнения разовой задачи. Если запуск задачи завершается с ошибкой, Job перезапускает поды до успешного выполнения или до истечения таймаутов. Когда задача выполнена, Job считается завершённым и больше никогда в кластере не запускается. Параметры в spec:

Параметр	Описание
activeDeadlineSeconds	количество секунд, которое отводится всему Job (не для одного пода) на выполнение.
backoffLimit	количество попыток. Если указать 2, то Job дважды попробует запустить под и остановится.
ttlSecondsAfterFinished	через сколько секунд специальный TimeToLive контроллер должен удалить завершившийся Job вместе с подами и их логами

После успешного завершения задания манифесты (Job и созданные поды) остаются в кластере навсегда. Все поля Job имеют статус Immutable, и поэтому при создании Job из автоматических сценариев сначала удаляют Job, который остался от предыдущего запуска. Генерация уникальных имен для Job приведет к накоплению ненужных манифестов. Обязательно указание ttlseconds... При создании бесконечного цикла через activeDeadlineSeconds будет отправлен sigterm, затем через 30 секунд sigkill. Если указать backoffLimit без restartPolicy, то при ошибке Job будет выполняться бесконечно. **Cronjob** Создание Job по расписанию. Параметры в spec:

Параметр	Описание
schedule	Расписание в виде строчки в cron-формате.
startingDeadlineSeconds	Опциональный. Если по прошествии этого времени job не стартовал, старт отменяется. Желательно вместе с Forbid.
concurrencyPolicy	Одновременное выполнение заданий. Allow позволяет подам следующего задания запускаться. Если задание ежеминутное, за минуту Job не отработал, все равно будет создан ещё один. Одновременно могут выполняться несколько Job’ов. Есть риск перегрузки. Replace заменяет запущенную нагрузку: старый Job убивается, запускается новый. Не самый лучший вариант, этот вариант осознанно. Forbid запрет запуска новых Job’ов, пока не отработает предыдущий. С этой политикой можно быть уверенным, что всегда запускается только один экземпляр задачи. Используют наиболее часто
successfulJobsHistoryLimit	Глубина истории хранения удачных job, по умолчанию 3
failedJobsHistoryLimit	Глубина истории хранения неудачных job, по умолчанию 1

CronJob использовать аккуратно. Должны быть независимы и иметь возможность работать параллельно. В качестве альтернативы CronJob можно использовать под, в котором запущен самый обычный crond. **Основные команды**

Команда	Доп. пар.	Описание
kubectl get job		список job
	--all-namespaces
kubectl delete job jname		Удалить jname
kubectl get cronjobs.batch		Список cronjob

**Примеры** Job ``` apiVersion: batch/v1 kind: Job metadata: name: hello spec: backoffLimit: 2 activeDeadlineSeconds: 60 ttlSecondsAfterFinished: 100 template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: Never ``` Cronjob ``` apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "*/1 * * * *" concurrencyPolicy: Allow jobTemplate: spec: backoffLimit: 2 activeDeadlineSeconds: 100 template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: Never ``` # Helm # Helm Один из самых популярных пакетных менеджеров для Kubernetes. **Управление helm** **Установка helm:** ``` curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null sudo apt-get install apt-transport-https --yes echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm ``` **Репозиторий**

Команда	Доп. пар.	Описание
helm repo	list	Список репозиториев
	add repo\_name repo\_url	Добавить репозиторий repo\_name с адресом repo\_url ``` helm repo add stable https://kubernetes-charts.storage.googleapis.com/ ``` Часто используют bitnami, но в России он сейчас закрыт. Есть зеркало: ``` helm repo add bitnami https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami ```
	update	обновить репозиторий
helm search	repo keyword	Поиск чартов по репозиториям ключевого слова keyword
	hub keyword	В официальном репозитории
	--max-col-width=0	\+ hub/repo полный вывод текста
	--output yaml	+hub/repo вывод в yaml
	--versions	Отсортировать по версиям чарта

**Плагины** Он сам по себе мощный, но [ссылка на плагины](https://helm.sh/docs/community/related/)

Команда	Доп. пар.	Описание
helm plugin install url		Установка плагина
helm plugin list		Список плагинов
helm plugin update pl\_name		Обновление плагина
helm plugin unistall pl\_name		Удаление плагина

**Переменные окружения** Зависит от переменных окружения. Основные переменные:

Переменная	Описание
XDG\_CACHE\_HOME	Размещение кешированных данных. По умолчанию ~/.cache/helm
XDG\_CONFIG\_HOME	Размещение конфигурационного файла По умолчанию ~/.config/helm
XDG\_DATA\_HOME	Размещение плагинов helm По умолчанию ~/.local/share/helm
HELM\_DRIVER	Драйвер для хранения данных. Secret - хранение авторизационных данных в файле, может быть configmap и memory
HELM\_NO\_PLUGINS	Отключить плагины
KUBECONFIG	Размещение конфигурационного файла kubectl

**Charts**

Команда	Доп. пар.	Описание
helm install	name\_chart repo	Установить из репозитория repo чарт name\_chart
	--...	Переменные внутри чарта ``` helm install kubeapps --namespace kubeapps bitnami/kubeapps ```
	--debug --dry-run pr\_name path\_to\_ch	протестировать без установки чарта
helm inspect values	name\_chart > ...	Сохранение чарта в файл ``` helm inspect values stable/kube-ops-view > kube-ops-view.yaml ```
helm lint --strict path-to-chart		Проверить соответствие values схеме
helm fetch name\_chart		Скачать чарт в tar
	--untar	И распаковать ``` helm fetch bitnami/wordpress --untar ```
helm ls	--namespace namespace	список установленных чартов
helm upgrade	...	Обновление
helm rollback ch\_name count		Откатить чарт ch\_name на count назад ``` helm rollback redis 1 --namespace=redis ```
helm uninstall name\_ch		``` helm uninstall kubeapps --namespace kubeapps ```

**Общая структура чарта** Helm автоматически определяет последовательность применения шаблонов в чарте.

Директория/файл	Описание	Обяз.
Chart.yaml	Метаданные чарта	+
templates/	Ресурсы кубера в формате yaml helm (yaml с переменными) Но файлы начинающиеся с \_ не обрабатываются, \_\*.tpl обрабатываются как helper файлы.	+ если не составной
templates/NOTES.txt	Инструкции по использованию	-
values.yaml	Переменные по умолчанию	-
.helmignore	Файлы исключения при упаковке чарта	-
charts/	Зависимости (другие чарты)	-, при отсутствии helm их сгенерирует в соответствии с Chart.yaml
Chart.lock	Первично примененные зависимости.	-, будет создан автоматически
crds/	Зависимости, которые должны быть собраны до основного чарта	-
README.md	Описание	-
LICENSE	Лицензия	-
value.shema,json	Шаблон в json формате	-
files/	Дополнительные файлы

**templates/** Измененные yaml. Добавлены переменные в формате Go шаблонизации. Переменные берутся из файла values.yaml ``` apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }} data: configuration.txt: |- {{ .Values.configurationData }} ``` Родительские пространства имен у переменных:

Пространство имен	Описание
.Release	Переменные, связанные с релизом в устанавливаемой системе. .Release.Name - имя релиза .Release.Namespace - пространство имен релиза .Release.Revision - номер версии
.Values	Переменные, размещенные в файле values.yaml
.Chart	Переменные, получаемые из файла Chart.yaml Например, .Chart.Name, .Chart.Version .Chart.AppVersion
.Files	Работа с файлами в директории из директории files. Если файл не существует - вернется ошибка. .Files.Get - Извлекает содержимое файлов .Files.AsSecrets - Возвращает Base-64 закодированную строку для создания secret .Files.AsConfig - Возвращает данные для использования в виде ConfigMap
.Subcharts	Пространство имен дочерних чартов. Например .Subchart.MyChart.firstvalue

**values.yaml** В виде обычного key: value yaml **Chart.yaml** Чарты бывают application и library. Application используются для деплоя приложений, library - для предоставления именованных шаблонов, используемых в других чартах. В library чартах не может быть ни одного шаблона, только helper файлы. Обязательные поля:

Поле	Описание
apiVersion	Версия. В helm 3 формате используется v2
name	Имя чарта. Должно совпадать с именем директории чарта. В именах стоит использовать только -, например first-chart
version	Версия. Формат X.Y.Z

Пример файла

Команда	Доп. пар.	Описание
helm create chart\_name		Создание шаблона чарта
helm install proj\_name path		Создание проекта с названием proj\_name используя чарт по пути path
	-f par\_file	ссылка на другой файл параметров
	--set foo=bar	Ручная установка параметров
helm get manifest proj\_name		Получить манифест проекта proj\_name

**Зависимости чарта** Заполняются в разделе dependencies файла Chart.yaml

Команда	Доп. пар.	Описание
helm dependency build	путь до Chart.yaml	Перестроить зависимые чарты, базируясь на файле Chart.lock Если этого файла нет - то же что и update
helm dependency list		Список зависимостей
helm dependency update		Обновление чартов и генерация Chart.lock

В зависимостях могут быть условия: ``` dependencies: - name: dependency1 repository: https://example.com version: 1.x.x condition: dependency1.enabled tags: - monitoring: true - name: dependency2 repository: https://example.com version: 2.x.x condition: dependency2.enabled tags: - monitoring: true ``` В данном случае переменные dependency1.enabled и dependency2.enabled должны быть установлены в values.yaml файле. Можно несколько переменных через запятую, но лучше завести одну общую переменную и в values ее заполнять. Раздел tags разделяет по группам: если в родительском чарте переменная monitoring не выставлена - данные зависимости установлены не будут. Может быть несколько тэгов, но если хотя бы один подходит - будет добавлено. Дочерние параметры чарта могут быть переопределены. Можно импортировать параметры из дочернего чарта (если его параметры отмечены как экспортируемые). Также есть хуки, позволяющие выполнять что-то при достижении определенной стадии. # Go templates Элементы шаблонизации заключены в двойные фигурные скобки, остальные - статический текст. Элементы шаблонизации могут включать переменные, условия, циклы, функции. Конструкция {{- удаляет строку в которой функция. **Условия:** ``` {{ if ConditionOne }} # Do something {{ else if ConditionTwo }} # Do something else {{ else }} # Default case {{ end }} ``` ``` {{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }} ``` **With** Работает так же как и в python ``` apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} ``` **Циклы** values.yaml: ``` favorite: drink: coffee food: pizza pizzaToppings: - mushrooms - cheese - peppers - onions - pineapple ``` cur.yaml: ``` apiVersion: v1 kind: ConfigMap metadata: name: {{ .Release.Name }}-configmap data: myvalue: "Hello World" {{- with .Values.favorite }} drink: {{ .drink | default "tea" | quote }} food: {{ .food | upper | quote }} {{- end }} toppings: |- {{- range .Values.pizzaToppings }} - {{ . | title | quote }} {{- end }} ``` **Функции:** Можно использовать pipeline: {{ .Values.favorite.drink | quote }}

Функция	Описание
quote	Добавляет кавычки ``` {{ quote .Values.favorite.food }} ```
upper	В верхний регистр
repeat n	Повтор значения n раз ``` {{ .Values.favorite.drink \| repeat 5 \| quote }} ```
default "some\_hy"	Присвоить значение по умолчанию если отсутствует ``` drink: {{ .Values.favorite.drink \| default "tea" \| quote }} ```
eq, ne, lt, gt, and, or	Логические функции
indent n	Поставить n пробелов перед конструкцией

[Список функций](https://helm.sh/docs/chart_template_guide/function_list/) **Именованные шаблоны** С шаблонами нужно запускать ``` helm install --dry-run --disable-openapi-validation ``` Шаблон внутри \_helpers.tpl файла: ``` {{- define "first.labels" -}} labels: 'app.kubernetes.io/instacce': {{ .Release.Name }} 'app.kubernetes.io/managed-by': {{ .Release.Service }} {{- end }} {{- define "first.nameofchart" -}} {{- printf "mycurname" -}} {{ - end }} ``` ``` apiVersion: v1 kind: ConfigMap metadata: name: {{ include "first.nameofchart" . }} {{- include "first.labels" . | nindent 2 }} data: myvalue: "Hello World" food: {{ .Values.favourite.food }} drink: {{ .Values.favourite.drink }} ``` Точка означает передачу внутрь шаблона всех переменных. Разница между include и template: проще использовать include, template не дает использовать дополнительные функции через pipeline # Пример проекта **Задача:** helm чарт приложения guestbook с БД redis Создаем namespace для теста ``` kubectl create namespace guestbook-learn ``` Создаем шаблон структуры папок ``` helm create guestbook ``` Добавляем зеркало проекта bitnami и находим последнюю версию чарта ``` helm repo add bitnami https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami helm search repo redis --versions NAME CHART VERSION APP VERSION DESCRIPTION bitnami/redis 20.11.4 7.4.2 Redis(R) is an open source, advanced key-value ... bitnami/redis 20.11.3 7.4.2 Redis(R) is an open source, advanced key-value ... bitnami/redis 20.11.2 7.4.2 Redis(R) is an open source, advanced key-value ... ``` В моем случае это 20.11.4. Добавляем зависимость в Chart.yaml ```yaml dependencies: - name: redis version: 20.11.x repository: https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami ``` Попробуем загрузить зависимость ``` guestbook# helm dependency update . Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "bitnami" chart repository Update Complete. ⎈Happy Helming!⎈ Saving 1 charts Downloading redis from repo https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami Pulled: registry-1.docker.io/bitnamicharts/redis:20.11.4 Digest: sha256:51ee4afc621d0e0b26109d41c32bf23f3db114f15dd816c1acf8d1ddbf8d57ed Deleting outdated charts ``` Действительно, в папке charts появился архив ``` guestbook# ls charts/ redis-20.11.4.tgz ``` Для завершения настройки redis посмотрим переменные, необходимые для запуска. ``` helm show values charts/redis-20.11.4.tgz ``` Это выдало портянку (если убрать комментарии) в 698 строк. Был задан вопрос ИИ. Ответ отличался от приведенного варианта в книге и прямое использование не поехало бы. В values.yaml было добавлено