Запуск временного контейнера в интерактивном режиме -it. Для входа нужно нажать Ctrl+D, которое отравит сигнал на завершение работы, после чего он будет удалён rm во избежание засорения системы остановленными современными контейнерами. Если образ создан таким образом, что в контейнере приложение запускается в оболочке, что неправильно, то сигнал буде отравлен приложению, а контейнер продолжит работать с оболочкой, в таком случае для выхода в отдельном терминале нужно будет его убить по его имени name name_container. Например,:
Docker run rm -it name name_container ubuntu BASH
В начале CLI Docker имел простой набор команд, позволяющий управлять жизненным циклом контейнеров. Среди них:
* Docker run для запуска контейнера;
* Docker ps для просмотра запущенных контейнеров;
* Docker rm для удаления контейнера;
* Docker build для создания своего образа;
* Docker images для просмотра существующих контейнеров;
* Docker rmi для удаления образа.
Но с ростом популярности, команд становилось всё больше и их было решено сгруппировать в группы, так вместо простого "Docker run" появилась команда "Docker container", которая имеет 25 команд в 19 версии Docker. Это очистка, и остановка с восстановлением, и логи и различные виды подсоединений к контейнеру. Таже судьба постигла и работы с образами. Но, старые команды остались пока из-за совместимости и удобства, ведь в большинстве случаев требуется базовый набор. На нём и остановимся:
Запуск контейнера:
docker run -d name name_container ubuntu bash
Удалить работающий контейнер:
docker rm -f name_container
Вывод всех контейнеров:
docker ps -a
Вывод работающих контейнеров:
docker ps
Вывод контейнеров с потребляемыми ресурсами:
docker stats
Вывод процессов в контейнере:
docker top {name_container}
Подключиться к контейнеру через оболочку sh (BASH в контейнерах alpine нет):
docker exec -it sh
Чистка системы от неиспользуемых образов:
docker image prune
Удалить весящие образа:
docker rmi $(docker images -f "dangling=true" -q)
Показать образа:
docker images
Создать образ в папке dir с Dockerfile:
docker build -t docker_user/name_image dir
Удалить образ:
docker rmi docker_user/name_image dir
Подключиться к Docker hub:
docker login
Отравить последнюю редакцию (тэг ставится и смещается автоматически, если не указан иной) образ на Docker hub:
docker push ocker_user/name_image dir:latest
Более широкий список в https://niqdev.github.io/devops/docker/.
Создание Docker Machine можно описать следующими этапами:
Создание виртуальной машины VirtualBox
docker-machine create name_virtual_system
Создание виртуальной машины generic
docker-machine create -d generic name_virtual_system
Список виртуальных машин:
docker-machine ls
Остановить виртуальную машину:
docker-machine stop name_virtual_system
Запустить остановленную виртуальную машину:
docker-machine start name_virtual_system
Удалить виртуальную машину:
docker-machine rm name_virtual_system
Подключиться к виртуальной машине:
eval "$(docker-machine env name_virtual_system)"
Отключить Docker от виртуальной машины:
eval $(docker-machine env -u)
Зайти по SSH:
docker-machine ssh name_virtual_system
Выйти из виртуальной машины:
exit
Запуcк команды sleep 10 в виртуальной машине:
docker-machine ssh name_virtual_system 'sleep 10'
Запуск команд в среде BASH:
docker-machine ssh dev 'bash -c "sleep 10 && echo 1"'
Скопировать папку dir в вируальную машину:
docker-machine scp -r /dir name_virtual_system:/dir
Сделать запрос к контейнерам виртуальной машины:
curl $(docker-machine ip name_virtual_system):9000
Пробросить порт 9005 хостовой машины на 9005 виртуальной машины
docker-machine ssh name_virtual_system -f -N -L 9005:0.0.0.0:9007
Инициализация мастера:
docker swarm init
Запуск множества контейнеров с одинаковыми EXPOSE:
essh@kubernetes-master:~/mongo-rs$ docker run name redis -p 6379 -d redis
f3916da35b6ba5cd393c21d5305002b78c32b089a6cc01e3e2425930c9310cba
essh@kubernetes-master:~/mongo-rs$ docker ps | grep redis
f3916da35b6b redis"docker-entrypoint.s" 8 seconds ago Up 6 seconds 0.0.0.0:32769->6379/tcp redis
essh@kubernetes-master:~/mongo-rs$ docker port reids
Error: No such container: reids
essh@kubernetes-master:~/mongo-rs$ docker port redis
6379/tcp > 0.0.0.0:32769
essh@kubernetes-master:~/mongo-rs$ docker port redis 6379
0.0.0.0:32769
Сборка первое решение скопировать все файлы и установить. В результате при изменении любого файла будет производится переустановка всех пакетов:
COPY ./ /src/app
WORKDIR /src/app
RUN NPM install
Воспользуемся кэшированием и разделим статические файлы и установку:
COPY ./package.json /src/app/package.json
WORKDIR /src/app
RUN npm install
COPY . /src/app
Использование шаблона базового образа node:7-onbuild:
$ cat Dockerfile
FROM node:7-onbuild
EXPOSE 3000
$ docker build .
В таком случае, файлы, которые не нужно включать в образ, такие как системные файлы, например, Dockerfile, .git, .node_modules, файлы с ключами, их нужно внести в node_modules, файлы с ключами, их нужно внести в .dockerignore.
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: