Building the Image Using a Dockerfile
Instead of building the Image in a manual way — as shown in the previous section, we can automate the whole process using a Dockerfile.
Prepare the Dockerfile:
In a new directory, create a Dockerfile (with the name Dockerfile), and write the following commands in it. Mostly, they are the same commands we have executed individually in the previous section:
Prepare a Startup Shell Script (startup.sh):
This file will be copied to the Image and will run automatically every time you instantiate a Container from that Image. The script will assign certain permissions and startup the necessary services. In addition, it will create the iptables rules that will port-forward RDP traffic.
Build the Container from the Docker file:
sudo chmod +x startup.shsudo docker build -t ubuntukvm:latest -f Dockerfile .
Instantiate a Container and Run it:
sudo docker run --privileged -it --name kvmcontainer1 --device=/dev/kvm --device=/dev/net/tun -v /sys/fs/cgroup:/sys/fs/cgroup:rw --cap-add=NET_ADMIN --cap-add=SYS_ADMIN ubuntukvm bash
Testing the RDP Access
By now, we should be able to access the RDP service on the Windows Vagrant box by connecting to the IP address of the Docker container. To test that port 3389/tcp (RDP) is reachable from the main OS, we will use a simple Nmap command.
First, if you are inside the Docker container, press Ctrl+p+q to put the Container in the background while running; this should return you to the main OS terminal prompt:
root@<container_id>:/win10# <Ctrl+p+q>$ sudo nmap -Pn -p 3389 172.17.0.2
Next, we need to install an RDP client for Linux. A popular one is RDesktop:
sudo apt-get install rdesktop
Finally, we can access the Windows VM:
sudo rdesktop 172.17.0.2
The Windows Vagrant box that we have installed has two built-in accounts:
- Username: vagrant Password: vagrant
- Username: Administrator Password: vagrant
Conclusion
I hope this post has been a comprehensive guide to containerize a virtual machine. There are different advantages of running a VM in a Container; one of them is running multiple Containers simultaneously. You can automatically build the desired image using a Dockerfile, or you can build it manually by running each command individually. We have covered both ways in this post.
На этом все?
Конечно же нет. Как видим, bind-mount работает некорректно, потому что Docker-демон ожидает подходящего пути Windows, а пути WSL не переводятся автоматически. Но есть несколько приемов, которые помогут нам в данной ситуации.
Выбор конкретного метода зависит от вашей версии Windows. Нажмите Win+R и введите команду . Появится сообщение, в котором указана версия. Наример:
Если версия будет 18.03 или новее, то можно отредактировать следующим образом:
automount]root = /options = "metadata"
То есть WSL смонтирует диск С: под вместо обычного
Почему это важно? Потому что этого ожидает Docker-демон от путей Windows. Кстати, после сохранения файла необходимо перезайти (re-login), чтобы изменения вступили в силу
Осторожно! Если вы используете WSL-терминал, то это изменение сломает его. Тогда можно сделать следующее
Если вы не хотите перезагружать систему или версия Windows более ранняя, то можно примонтировать одну точку монтирования к другой следующим образом:
sudo mkdir /csudo mount --bind /mnt/c /c
Так быстрее, но функция будет доступна только до тех пор, пока вы не выйдете из системы. После перезапуска нужно повторять процедуру или добавить ее в конфигурацию среды выполнения shell (например, или ). Это происходит из-за того, что не работает на WSL так, как требуется.
Теперь можно запускать Docker с монтированием, но только если приложение находится в файловой системе WIndows. У вас не должно возникнуть проблем с командной строкой , которая ожидает абсолютные пути, но с Docker Compose нужно быть максимально внимательным. Он позволяет использовать относительные пути, и все, что начинается с не будет работать.
Если вы все-таки решили монтировать файловую систему WSL с помощью Docker, то можете попробовать заменить все и на . Здесь означает не имя пользователя WSL, а имя пользователя Windows.
Я также хотел написать оболочку для Docker Compose, чтобы изменить рабочий каталог на , но у WSL нет к нему доступа. И думаю, это правильно!
Support
Docker Engine releases of a year-month branch are supported with patches as
needed for one month after the next year-month general availability release.
This means bug reports and backports to release branches are assessed
until the end-of-life date.
After the year-month branch has reached end-of-life, the branch may be
deleted from the repository.
Backporting
Backports to the Docker products are prioritized by the Docker company. A
Docker employee or repository maintainer will endeavour to ensure sensible
bugfixes make it into active releases.
If there are important fixes that ought to be considered for backport to
active release branches, be sure to highlight this in the PR description
or by adding a comment to the PR.
Release channels
Docker Engine has three types of update channels, stable, test,
and nightly:
- The Stable channel gives you latest releases for general availability.
- The Test channel gives pre-releases that are ready for testing before
general availability (GA). - The Nightly channel gives you latest builds of work in progress for the
next major release.
Stable
Year-month releases are made from a release branch diverged from the master
branch. The branch is created with format , for example
. The year-month name indicates the earliest possible calendar
month to expect the release to be generally available. All further patch
releases are performed from that branch. For example, once is
released, all subsequent patch releases are built from the branch.
Test
In preparation for a new year-month release, a branch is created from
the master branch with format when the milestones desired by
Docker for the release have achieved feature-complete. Pre-releases
such as betas and release candidates are conducted from their respective release
branches. Patch releases and the corresponding pre-releases are performed
from within the corresponding release branch.
Nightly
Nightly builds give you the latest builds of work in progress for the next major
release. They are created once per day from the master branch with the version
format:
where the time is the commit time in UTC and the final suffix is the prefix
of the commit hash, for example .
These builds allow for testing from the latest code on the master branch. No
qualifications or guarantees are made for the nightly builds.
Запуск Docker-контейнеров с ускорением на графических процессорах NVIDIA
С помощью NVIDIA Container Toolkit (рекомендовано)
Установите пакет AUR и перезапустите Docker. Теперь вы можете запускать контейнеры Docker, использующие графические процессоры NVIDIA, с помощью параметра :
# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi
Укажите, сколько графических процессоров разрешено в контейнере:
# docker run --gpus 2 nvidia/cuda:9.0-base nvidia-smi
Укажите, какие GPU следует использовать:
# docker run --gpus '"device=1,2"' nvidia/cuda:9.0-base nvidia-smi
или
# docker run --gpus '"device=UUID-ABCDEF,1"' nvidia/cuda:9.0-base nvidia-smi
Укажите возможности («graphics», «compute», …) контейнера (хотя это редко, если вообще когда либо используется таким образом):
# docker run --gpus all,capabilities=utility nvidia/cuda:9.0-base nvidia-smi
С помощью NVIDIA Container Runtime
Установите пакет AUR. Затем, зарегистрируйте среду выполнения NVIDIA, отредактировав конфигурационный файл :
/etc/docker/daemon.json
{
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
}
}
и перезапустите docker.
Среда выполнения также может быть зарегистрирована с помощью параметра командной строки dockerd:
# /usr/bin/dockerd --add-runtime=nvidia=/usr/bin/nvidia-container-runtime
После этого контейнеры с ускорением на графических процессорах могут быть запущены с помощью следующей команды:
# docker run --runtime=nvidia nvidia/cuda:9.0-base nvidia-smi
или (требуется Docker версии 19.03 или выше):
# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi
С помощью nvidia-docker (устарело)
Чтобы использовать nvidia-docker, установите пакет AUR и перезапустите Docker. Контейнеры с поддержкой NVIDIA GPU могут быть запущены, используя один из следующих методов:
# docker run --runtime=nvidia nvidia/cuda:9.0-base nvidia-smi
# nvidia-docker run nvidia/cuda:9.0-base nvidia-smi
или (требуется Docker версии 19.03 или выше)
# docker run --gpus all nvidia/cuda:9.0-base nvidia-smi
Примечание: nvidia-docker — устаревший метод запуска Docker-контейнеров с ускорением на графических процессорах NVIDIA, использующийся в версиях Docker, предшествующих версии 19.03. Если вы используете Docker версии 19.03 или выше, рекомендуется использовать .
Настройка/Использование Spinnaker в Unix/Linux
И так, настройка прошла успешно. Открыли Spinnaker на http://localhost:9000. Домашняя станица Spinnaker-а выглядит следующим образом:
В поле поиска, можно поискать проекты, кластера, ЛБ, секьюрити группы и тд и тп. Например:
Приступим к использованию!
Создание Spinnaker пайплайна
Начну создание приложения под названием MyTestApp:
Нажимаем на кнопку «Create». Созданное приложение выглядит так:
Идем далее, создаем лоад баллансер, для этого клацаем по «Load Balancers» -> «Create Load Balancer»:
Во вкладке с «BASIC SETTINGS», заполняем:
- Account -> local.
- Namespace -> default.
- Stack -> prod.
Далее, во вкладке с «PORTS»:
В данной вкладке стоит прописать:
Далее, во вкладке с «ADVANCED SETTINGS»:
В данной вкладке, прописываем:
Нажимаем на «Create». Аналогичными действиями, создаем ЛБ с названием «dev», но только в последней вкладке стоит выбрать «ClusterIP»:
После чего, должно выти что-то типа следующего:
ЛБы готовы и теперь можно создавать pipeline, переходим в данную вкладку и нажимаем на «Create»:
Заполняем:
Нажимаем на «Create»:
Жмакаем на «Save Changes». Прокручиваем стрцницу вверх и кликаем на «Add stage»:
Заполняем:
Затем кликаем по «Add server group»:
Я выбрал:
Нажимаем на «Continue without a template»:
Нажимаем на вкладку «LOAD BALANCERS» и выбираем нужный (в данном случае — mytestapp-prod):
Переходим во «CONTAINER» вкладку и заполняем:
В данной вкладке, стоит открыть «Probes» и добавляем использование Readiness Probe и Liveness Probe:
И так, нажимаем на «Add» чтобы добавить наши ченджи. И потом, кликаем по «Save Changes».
Т.к я деплою nginx, а не приложение с кодом (так бы сработал триггер по коммиту), то запущу «Start manual execution»:
Выбераем параметры:
Нажимаем на «Run».
Получаем сервисы:
Чтобы проверить, работает ли деплоймент, пробросим прокси куба:
ЗАМЕЧАНИЕ: для того чтобы прокси работал в бэкграунде, выполняем:
Т.к я деплоил mytestapp-prod приложение, а оно находится на http://127.0.0.1:30294/ то кликаем по нему и попадаем собственно на задеплоенный nginx!
Стоит выполнить ряд действий для dev стейджа. Клацаем «Pipelines» -> «Create». Название выбираем название «DeployToDev»:
После чего. Нажимаем на «Save Changes». И кликаем «Add Stage»:
Заполняем:
- Type -> Deploy.
- Stage Name -> Deploy.
В поле «Add server group», выбераем «mytestapp-prod-v000»:
Выбираем из списка и нажимаем на «Use this template». Он скопирует темплейт в новый. Немного поправим его:
Далее, в поле «Load Balancers»:
Заменили и идем в «Container»:
Во вкладке «Probes», включаем Readiness Probe и Liveness Probe (как в примерах выше). После всех настроек, клацаем на «Add» -> «Save Changes».
Вернусь в главное меню апликейшина и нажму на только созданный пайплайн:
Скачаем дашборды для куба:
Смотрим токены:
Открываем — http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
С помощью данных бордов можно смотреть инфу.
В завершении, содаем новый пайплайн с названием PromoteToProd:
Жмакаем на «Create». И заполняем поля:
Нажимаем на «Save Changes». После чего, открываем «Add Stage»:
Заполняем и клацаем на «Save Changes». Клацаем на «Add stage» для создания деплоя на ПРОД:
Клацаем на «Add server group» и выбераем «Copy configuration from», а имеено с «None» и кликаем на «Continue without any templates». Заполняем:
Кликаем на «Add» -> «Save Changes».
Нажимаем на билды. Перекидываем с dev -> prod:
Проверяем через ИП деплой! Все должно работать.
Вот и все, статья «Установка Spinnaker в Unix/Linux» завершена.
Запуск Docker от имени пользователя без полномочий root
На данный момент вы можете запускать контейнеры Docker только как суперпользователь, поэтому в приведенной выше команде используется sudo . Демон Docker связывается с сокетом Unix, который по умолчанию принадлежит пользователю root, а пользователи без полномочий root могут получить к нему доступ только через sudo.
Чтобы иметь возможность запускать контейнеры Docker и другие важные команды, не будучи суперпользователем, вам сначала нужно создать группу пользователей с именем docker, а затем добавить своего пользователя в группу докеров на вашем компьютере. Команда groupadd отвечает за управление группами пользователей в Linux .
Используйте команду ниже, чтобы активировать групповые изменения.
Примечание . Не забудьте выйти и снова войти, чтобы система распознала членство в вновь созданной группе. Вы можете использовать следующую команду для выхода.
В некоторых случаях может потребоваться перезагрузить компьютер, если вы по-прежнему не можете выполнить команду Docker от имени пользователя без полномочий root.
Что такого особенного в Docker?
В отличие от многих приложений, используемых мной ежедневно, Docker является системным. То есть он находится глубоко в системе и для его работы на хост-компьютере необходим демон. В данном случае под хост-компьютером я подразумеваю Microsoft Windows.
Значит ли это, что мы не можем использовать Docker изнутри WSL? Можем, но нужно постараться, чтобы добраться до него. Во-первых, нужно установить Docker под Windows. Для этого есть Docker Enterprise Editions для Windows Server 2016 (и новее), Community Edition для Windows 10 Professional и Enterprise. У меня установлена Windows 10 Home.
Установка Compose
Команда docker-compose позволяет развернуть многоконтейнерные Docker-приложения.
Для ее установка сначала переходим на страницу github.com/docker/compose/releases/latest и смотрим последнюю версию docker-compose. В моем случае, это была 1.29.2.
После вводим:
COMVER=1.29.2
curl -L «https://github.com/docker/compose/releases/download/$COMVER/docker-compose-$(uname -s)-$(uname -m)» -o /usr/bin/docker-compose
* где 1.29.2 — последняя версия файла.
Даем права файлу на исполнение:
chmod +x /usr/bin/docker-compose
Запускаем docker-compose с выводом его версии:
Настройка
Драйвер хранения
Драйвер хранения Docker (storage driver или graph driver) значительно влияет на производительность. Его задача — эффективно хранить слои образов контейнеров, то есть когда несколько образов совместно используют слой, только один слой использует дисковое пространство. Совместимая опция `devicemapper` предлагает неоптимальную производительность, которая просто ужасна на вращающихся дисках. Кроме того, `devicemapper` не рекомендуется использовать в промышленной среде.
Поскольку Arch Linux поставляется с новыми ядрами Linux, нет смысла использовать опцию совместимости. Хороший, современный выбор — .
Выполните , чтобы увидеть текущий драйвер хранилища. Новые установки Docker уже должны использовать по умолчанию.
Отредактируйте файл (создайте его, если он не существует), чтобы изменить драйвер хранения:
/etc/docker/daemon.json
{
"storage-driver": "overlay2"
}
После чего перезапустите Docker.
Remote API
Используйте следующую команду, чтобы вручную открыть порт для Remote API:
# /usr/bin/dockerd -H tcp://0.0.0.0:4243 -H unix:///var/run/docker.sock
— часть для открытия Remote API.
— часть для доступа к хост-машине через терминал.
Remote API с systemd
Чтобы запустить Remote API с помощью демона Docker, создайте Drop-in сниппет со следующим содержимым:
/etc/systemd/system/docker.service.d/override.conf
ExecStart= ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:4243 -H unix:///var/run/docker.sock
Конфигурация сокета демона
Демон docker по умолчанию прослушивает Unix-сокет. Чтобы прослушивать определённый порт, создайте Drop-in сниппет со следующим содержимым:
/etc/systemd/system/docker.socket.d/socket.conf
ListenStream=0.0.0.0:2375
Прокси
Конфигурация прокси
Создайте Drop-in сниппет со следующим содержанием:
/etc/systemd/system/docker.service.d/proxy.conf
Environment="HTTP_PROXY=192.168.1.1:8080" Environment="HTTPS_PROXY=192.168.1.1:8080"
Примечание: Предполагается, что прокси-сервер имеет адрес , не используйте .
Убедитесь, что конфигурация была загружена:
# systemctl show docker --property Environment
Environment=HTTP_PROXY=192.168.1.1:8080 HTTPS_PROXY=192.168.1.1:8080
Конфигурация контейнера
Настройки в файле не применяются к контейнерам. Для этого необходимо задать переменные в следующим образом:
FROM archlinux/base ENV http_proxy="http://192.168.1.1:3128" ENV https_proxy="https://192.168.1.1:3128"
Запуск Docker с сетью, заданной вручную, в systemd-networkd
Если вы вручную конфигурируете свою сеть, используя systemd-networkd версии 220 или выше, контейнеры, которые вы запускаете с помощью Docker, могут не иметь доступа к вашей сети.
Начиная с версии 220, параметр переадресации для данной сети () по умолчанию равен . Этот параметр запрещает переадресацию IP. Он также конфликтует с Docker, который включает параметр внутри контейнера.
Обходной путь — отредактировать файл в , добавив на хосте Docker:
/etc/systemd/network/<interface>.network
... IPForward=kernel ...
Эта конфигурация разрешает переадресацию IP из контейнера, как и ожидалось.
Расположение образов
По умолчанию Docker образы расположены в . Они могут быть перемещены в другие разделы.
Во-первых, остановите .
Если вы запустили Docker образы, вам необходимо убедиться, что они полностью размонтированы. После этого вы можете переместить изображения из в целевой путь.
Затем добавьте Drop-in сниппет для , добавив параметр в :
/etc/systemd/system/docker.service.d/docker-storage.conf
ExecStart= ExecStart=/usr/bin/dockerd --data-root=/path/to/new/location/docker -H fd://
Небезопасные реестры
Если вы решите использовать самозаверенный сертификат для своего личного реестра, Docker откажется использовать его, пока вы не заявите, что доверяете ему.
Добавьте Drop-in сниппет для , добавив параметр в :
/etc/systemd/system/docker.service.d/override.conf
ExecStart= ExecStart=/usr/bin/dockerd -H fd:// --insecure-registry my.registry.name:5000
Настройка репозитория программного обеспечения Docker
Существует несколько способов установки Docker, и это руководство покажет вам, как установить Docker из репозиториев Docker с помощью служебной программы команды apt. Установка Docker таким образом позволяет легко обновлять пакет Docker в будущем, и это также рекомендуемый подход командой Docker.
Первым шагом в установке является добавление репозитория программного обеспечения Docker в список источников программного обеспечения. Вы будете использовать репозиторий программного обеспечения Docker через HTTPS, а затем установите необходимое программное обеспечение, используя команду ниже.
Рекомендуется сначала обновить список доступных программных пакетов.
Затем загрузите все необходимые зависимости для установки с помощью apt install .
Программное обеспечение Docker использует GnuPG, также известный как GPG, для защиты связи при загрузке пакетов программного обеспечения из своего репозитория. GPG – это стандарт реализации PGP (Pretty Good Privacy), который используется для шифрования сообщений или данных .
Чтобы добавить официальный ключ Docker GPG в локальные связки ключей, используйте следующую команду.
У Docker есть три основных версии программного обеспечения в своих репозиториях: стабильная версия, тестовая версия и версия для ночного выпуска. В этом руководстве будет рассказано о стабильной версии Docker.
Выполните следующую команду, чтобы использовать стабильную версию выпуска репозитория Docker.
Примечание . Вышеупомянутая команда предполагает, что вы используете архитектуру AMD. Если вы используете архитектуру ARM, вы можете заменить слово arch = amd64 в приведенной выше команде на arch = arm64 или arch = armhf, если вы используете arm hard float.
Подтверждение установки
Чтобы проверить, успешно ли установлен Docker, вы можете запустить следующую команду, и она выведет номер версии установленного Docker Engine.
В Ubuntu Linux и большинстве дистрибутивов на основе Debian служба Docker запускается автоматически при загрузке вашей системы.
Вы можете попробовать запустить образ Docker hello-world, чтобы проверить установку. Поскольку образ недоступен локально на вашем компьютере, система загрузит его из Docker Hub, библиотеки образов контейнеров. В следующий раз, когда вы снова запустите образ, он будет использовать локальную копию на вашем компьютере.
Manage Docker as a non-root user
The Docker daemon binds to a Unix socket instead of a TCP port. By default
that Unix socket is owned by the user and other users can only access it
using . The Docker daemon always runs as the user.
If you don’t want to preface the command with , create a Unix
group called and add users to it. When the Docker daemon starts, it
creates a Unix socket accessible by members of the group.
To create the group and add your user:
-
Create the group.
-
Add your user to the group.
-
Log out and log back in so that your group membership is re-evaluated.
If testing on a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.
On a desktop Linux environment such as X Windows, log out of your session completely and then log back in.
On Linux, you can also run the following command to activate the changes to groups:
-
Verify that you can run commands without .
This command downloads a test image and runs it in a container. When the
container runs, it prints a message and exits.If you initially ran Docker CLI commands using before adding
your user to the group, you may see the following error,
which indicates that your directory was created with
incorrect permissions due to the commands.To fix this problem, either remove the directory
(it is recreated automatically, but any custom settings
are lost), or change its ownership and permissions using the
following commands:
Установка PORTAINER
Portainer — графическая панель для управления docker контейнерами.
Создайте хранилище данных для Portainer:
Запустите контейнер c Portainer:
После запуска перейдите в браузере по адресу ip-сервера:9000, интерфейс предложит установить пароль администратора.
Далее выбираете расположение Docker на локальном сервере (Local) или на удаленном.
Панель установлена, можно запускать контейнеры.
В панели управления в разделе «App Template» можно найти шаблоны с ПО и запустить их в контейнерах.
В разделе «Containers» можно увидеть все статусы по контейнерам на сервере. В нашем случае один контейнер с текущей панелью Portainer, а в двух других запущенные ранее тестовые образы hello-world.
