Предварительное извлечение docker изображений в AMI для уменьшения частоты узла и модуля sh время запуска замедляет его выполнение при использовании nvidia- docker с модулями с поддержкой графического процессора - PullRequest
8 голосов
/ 20 февраля 2020

Использование Kubernetes v1.16 на AWS Я сталкиваюсь со странной проблемой, пытаясь сократить время, необходимое для запуска модуля на недавно созданном узле.

По умолчанию AMI узла не содержит любое предварительно кэшированное docker изображение, поэтому, когда на него запланирован модуль, его первой задачей является извлечение docker изображения.

Извлечение большого docker изображения может занять некоторое время, поэтому модуль требуется много времени для запуска.

Недавно я пришел с идеей предварительно вытянуть мое большое docker изображение прямо в AMI, так что, когда на него запланирован модуль, ему не придется скачать это. Оказывается, многие люди занимались этим в течение некоторого времени, известного как «выпечка AMI»:

Моя проблема в том, что когда Я генерирую AMI с моим большим изображением на нем и использую этот AMI, все работает как положено, и изображение docker не загружается как уже имеющееся, поэтому модуль запускается почти через 1 секунду, но сам модуль работает в 1000 раз медленнее, чем если бы docker изображение не было предварительно извлечено на AMI.

Что я делаю:

  • запуска базового рабочего AMI на экземпляре EC2
  • с sh на него
  • запустите docker вытяните myreposiroty / myimage
  • щелкните правой кнопкой мыши на экземпляре EC2 с консоли AWS и сгенерируйте AMI

Если я не не обрабатывает мой docker образ, затем он работает нормально, только если я предварительно обработал его, используя сгенерированный новый AMI, а затем eben, если его запуск через секунду контейнер будет медленным, как никогда before.

Мой docker образ использует ресурсы графического процессора и основан на тензорном потоке / тензорном потоке: образ 1.14.0-gpu-py3. Похоже, это связано с использованием комбинированного nvidia- docker & tenorflow om GPU с поддержкой EC2.

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

EDIT # 1

С тех пор я использую Packer для сборки AMI. Вот мой файл шаблона:

{
  "builders": [
    {
      "type": "amazon-ebs",
      "access_key": "{{user `aws_access_key`}}",
      "secret_key": "{{user `aws_secret_key`}}",
      "ami_name": "compute-{{user `environment_name`}}-{{timestamp}}",
      "region": "{{user `region`}}",
      "instance_type": "{{user `instance`}}",
      "ssh_username": "admin",
      "source_ami_filter": {
        "filters": {
          "virtualization-type": "hvm",
          "name": "debian-stretch-hvm-x86_64-gp2-*",
          "root-device-type": "ebs"
        },
        "owners":"379101102735",
        "most_recent": true
      }
    }
  ],
  "provisioners": [
    {
      "execute_command": "sudo env {{ .Vars }} {{ .Path }}",
      "scripts": [
        "ami/setup_vm.sh"
      ],
      "type": "shell",
      "environment_vars": [
        "ENVIRONMENT_NAME={{user `environment_name`}}",
        "AWS_ACCOUNT_ID={{user `aws_account_id`}}",
        "AWS_REGION={{user `region`}}",
        "AWS_ACCESS_KEY_ID={{user `aws_access_key`}}",
        "AWS_SECRET_ACCESS_KEY={{user `aws_secret_key`}}",
        "DOCKER_IMAGE_NAME={{user `docker_image_name`}}"
      ]
    }
  ],
  "post-processors": [
    {
      "type": "manifest",
      "output": "ami/manifest.json",
      "strip_path": true
    }
  ],
  "variables": {
    "aws_access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
    "aws_secret_key": "{{env `AWS_SECRET_ACCESS_KEY`}}",
    "environment_name": "",
    "region": "eu-west-1",
    "instance": "g4dn.xlarge",
    "aws_account_id":"",
    "docker_image_name":""
  }
}

и вот связанный скрипт для настройки AMI для Docker & Nvidia Docker:

#!/bin/bash
cd /tmp

export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=noninteractive

# docker
apt-get update
apt-get install -y apt-transport-https ca-certificates curl gnupg2 software-properties-common
curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian stretch stable"
apt-get update
apt-get install -y docker-ce
usermod -a -G docker $USER

# graphical drivers
apt-get install -y software-properties-common
wget http://us.download.nvidia.com/XFree86/Linux-x86_64/440.64/NVIDIA-Linux-x86_64-440.64.run
bash NVIDIA-Linux-x86_64-440.64.run -sZ

# nvidia-docker
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | tee /etc/apt/sources.list.d/nvidia-docker.list
apt-get update
apt-get install -y nvidia-container-toolkit
apt-get install -y nvidia-docker2
cat > /etc/docker/daemon.json <<EOL
{
    "default-runtime": "nvidia",
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    }
}
EOL
systemctl restart docker

# enable nvidia-persistenced service
cat > /etc/systemd/system/nvidia-persistenced.service <<EOL
[Unit]
Description=NVIDIA Persistence Daemon
Wants=syslog.target

[Service]
Type=forking
PIDFile=/var/run/nvidia-persistenced/nvidia-persistenced.pid
Restart=always
ExecStart=/usr/bin/nvidia-persistenced --verbose
ExecStopPost=/bin/rm -rf /var/run/nvidia-persistenced

[Install]
WantedBy=multi-user.target
EOL
systemctl enable nvidia-persistenced

# prepull docker
apt-get install -y python3-pip
pip3 install awscli --upgrade
aws ecr get-login-password --region $AWS_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com
docker pull $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$DOCKER_IMAGE_NAME:$ENVIRONMENT_NAME

# Clean up
apt-get -y autoremove
apt-get -y clean

В любом случае, как только я поместите эту строку:

docker pull $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$DOCKER_IMAGE_NAME:$ENVIRONMENT_NAME

Я сталкиваюсь с той же странной проблемой, когда блоки планируются на узлах, загруженных из этого AMI, он говорит: «образ уже присутствует на компьютере», поэтому он не тянет его снова , но при использовании TensorFlow контейнер работает медленно, например. Для запуска ts.Session () требуется около минуты.

EDIT # 2

Добавление дополнительной информации о том, что выполняется в модуле:

Dockerfile

FROM tensorflow/tensorflow:1.14.0-gpu-py3
CMD ["python", "main.py"]

main.py

import tensorflow as tf

config = tf.ConfigProto(allow_soft_placement=True)
config.gpu_options.allow_growth = True
return tf.Session(graph=tf.Graph(), config=config)

Только с этими строками Инициализация сеанса TF занимает до 1 минуты, когда изображение предварительно свернуто, и 1 секунду, когда изображение нет.

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