v /config
docker cp config.conf name_container:/config/
Статистика использованных ресурсов в реальном времени:
essh@kubernetes-master:~/mongo-rs$ docker ps -q | docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
c8222b91737e mongo-rs_slave_1 19.83% 44.12MiB / 15.55GiB 0.28% 54.5kB / 78.8kB 12.7MB / 5.42MB 31
aa12810d16f5 mongo-rs_backup_1 0.81% 44.64MiB / 15.55GiB 0.28% 12.7kB / 0B 24.6kB / 4.83MB 26
7537c906a7ef mongo-rs_master_1 20.09% 47.67MiB / 15.55GiB 0.30% 140kB / 70.7kB 19.2MB / 7.5MB 57
f3916da35b6b redis 0.15% 3.043MiB / 15.55GiB 0.02% 13.2kB / 0B 2.97MB / 0B 4
f97e0697db61 node_api 0.00% 65.52MiB / 15.55GiB 0.41% 862kB / 8.23kB 137MB / 24.6kB 20
8c0d1adc9b9c portainer 0.00% 8.859MiB / 15.55GiB 0.06% 102kB / 3.87MB 57.8MB / 122MB 20
6018b7e3d9cd node_payin 0.00% 9.297MiB / 15.55GiB 0.06% 222kB / 3.04kB 82.4MB / 24.6kB 11
^C
При создании образов нужно учитывать:
** изменение большого слоя он будет пересоздан, поэтому его, часто лучше разделить, например, создать один слой с 'NPM i' и уже на втором скопировать код ;
* если файл в образе большой и контейнер иго изменят, то из слоя образа доступного только для чтения файл будет целиком скопирован в слой для редактирования, поэтому, контейнера предполагаются быть легковесными, а контент принято располагать в специальном хранилище. code-as-a-service: 12 факторов (12factor.net)
* Codebase один сервис они репозиторий;
* Dependeces все зависимые сервисы в конфиге;
* Config конфиги доступны через среду;
* BackEnd обмениваются данными с другими сервисами через сеть на основе API;
* Processes один сервис одни процесс, что позволяет в случае падения однозначно отслеживать (завершается сам контейнер) и перезапускать его;
* Независимость о окружения и не влияние на него.
* СI/CD code control (git) build (jenkins, GitLab) relies (Docker, jenkins) deploy (helm, Kubernetes). Поддержание легковесности сервиса важно, но есть программы, не предназначенные для запуска в контейнерах, таки как базы данных. Из-за своей особенности к их запуску предъявляются определённые требования, а профит ограничен. Так, из-за больших данных они не просто медленно масштабируется, а ролинг-абдейт маловероятен, при этом перезапуск необходимо производить на тех же нодах, что и их данные из соображений производительности доступа к ним.
* Config взаимоотношения сервисов определённо в конфигурации, например, docker-compose.yml;
* Port bindign общение сервисов происходит через порты, при этом порт может выбираться автоматически, например, если в Dockerfile указан EXPOSE PORT, то при вызове контейнера с флагом -P он будет прикончен к свободному автоматически.
* Env настройки среды предаются через переменные окружения, а не через конфиги, что позволяет их вносить в конфигурацию конфига сервисов, например, docker-compose.yml
* Logs логи передаются потоком по сети, например, ELK, или выводится в вывод, который уже Docker передаёт потоком.
Внутренности Dockerd:
essh@kubernetes-master:~/mongo-rs$ ps aux | grep dockerd
root 6345 1.1 0.7 3257968 123640 ? Ssl июл05 76:11 /usr/bin/dockerd -H fd:// containerd=/run/containerd/containerd.sock
essh 16650 0.0 0.0 21536 1036 pts/6 S+ 23:37 0:00 grep color=auto dockerd
essh@kubernetes-master:~/mongo-rs$ pgrep dockerd
6345
essh@kubernetes-master:~/mongo-rs$ pstree -c -p -A $(pgrep dockerd)
dockerd(6345)-+-docker-proxy(720)-+-{docker-proxy}(721)
| |-{docker-proxy}(722)
| |-{docker-proxy}(723)
| |-{docker-proxy}(724)
| |-{docker-proxy}(725)
| |-{docker-proxy}(726)
| |-{docker-proxy}(727)
| `-{docker-proxy}(728)
|-docker-proxy(7794)-+-{docker-proxy}(7808)
Docker-File:
* чистка кэши от пакетных менеджеров: apt-get, pip и других, этот кэш не нужен на продакшне, лишь
занимает место и нагружает сеть, но ныне не зачастую не актуально, так как есть многоэтапные
сборки, но об этом ниже.
* группируйте команды одних сущностей, например, получение кэша APT, установку программ и удаление
кэша: в одной инструкции код только программ, при разнесённом варианте код программ и кэш,
так как если не удалить кэш в одной инструкции, то он будет сохранён в слое, не зависимо от
последующих действий.
* разделяйте инструкции по частоте изменения, так, например, если не разделить установку
программного обеспечения и код, то при изменении чего-либо в коде, то вместо использования готового
слоя с программами они будут переустановлены заново, что повлечёт существенное время на подготовку
образа, которое критично для разработчиков:
ADD ./app/package.json /app
RUN npm install
ADD ./app /app
Альтернативы Docker
** Rocket или rkt контейнеры для операционной среды CoreOS от RedHut, специально созданной на использование контейнеров.
** Hyper-V среда для запуска Docker в операционной системе Windows, представляющая из себя обертку (легковесную виртуальную машину) контейнера.
От Docker ответвились его базовые компоненты, которые используются им как примитивы, ставшие стандартными компонентами для реализации контейнеров, таких как RKT, объединенных в проект containerd: