Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: Научного журнала «Студенческий» № 1(213)

Рубрика журнала: Информационные технологии

Скачать книгу(-и): скачать журнал часть 1, скачать журнал часть 2, скачать журнал часть 3, скачать журнал часть 4, скачать журнал часть 5, скачать журнал часть 6, скачать журнал часть 7

Библиографическое описание:
Берьянов М.С. ЛУЧШИЕ ПРАКТИКИ ИСПОЛЬЗОВАНИЯ ИНСТРУМЕНТА DOCKER // Студенческий: электрон. научн. журн. 2023. № 1(213). URL: https://sibac.info/journal/student/213/276549 (дата обращения: 28.07.2024).

ЛУЧШИЕ ПРАКТИКИ ИСПОЛЬЗОВАНИЯ ИНСТРУМЕНТА DOCKER

Берьянов Максим Сергеевич

студент, факультет ПИиКТ, Университет ИТМО,

РФ, г. Санкт-Петербург

DOCKER TOOL USAGE BEST PRACTICES

 

Maxim Beryanov

Student, PIKT faculty, ITMO University,

Russia, Saint-Petersburg

 

АННОТАЦИЯ

Docker на сегодняшний день является одним из самых популярных инструментов в мире DevOps. Если мы работаем с контейнерами, нам, скорее всего, приходится иметь дело с Docker. Эта статья посвящена увеличению эффективности и производительности при работе с данной технологией.

ABSTRACT

Docker is one of the most popular tools in DevOps world today. If we work with containers, we most likely have to deal with Docker. This article is about increasing efficiency and productivity when working with this technology.

 

Ключевые слова: Docker, DevOps, лучшая практика, контейнер.

Keywords: Docker, DevOps, best practice, container.

 

Следующие подсказки и правила работы с Docker [1] можно рассматривать, как наиболее правильные и полезные:

  • Незавершенную работу не следует хранить в безымянных остановленных контейнерах [2] – нужно принимать во внимание, что безымянные контейнеры являются потенциальными уязвимостями в контексте ситуаций, где они могут быть удалены при возникновении проблем с памятью. Поэтому мы стараемся не хранить незавершенную работу в таких уязвимых контейнерах;
  • Необходимо регулярно очищать образы [3], так как они могут быстро накапливаться, если их забывать своевременно удалять – в конце концов это требует большого объема памяти. Хотя Docker правильно расходует память (общие части контейнеров не будут дублироваться), избыточные образы могут занимать дополнительное место;
  • Следует извлекать зависимости, которым мы доверяем – не нужно скачивать какие-либо нестабильные или непопулярные зависимости, владельца которых мы не знаем, или не видим соответствующую отметку безопасности, к примеру на Docker Hub;
  • Требуется помещать те части контейнера, которые сильно меняются, в конец Dockerfile – Docker кэширует каждый шаг как отдельную часть контейнера (слой), таким образом, скачивание повторяющихся слоев не выполняется снова и снова, поскольку для каждого шага Docker-манифеста проверяется его наличие в кэше. Следовательно, размещение изменяющих базовый образ частей в конце Dockerfile делает новый контейнер более производительным, поскольку верхние слои скорее всего будут уже скачаны;
  • Не нужно скачивать зависимости в контейнер при его запуске – выборка зависимостей должна быть отдельным шагом манифеста, более того, в таком случае контейнер продолжает быть открытым для расширения;
  • Не следует монтировать общие папки в Dockerfile, которые указывают на наш личный компьютер – это отлично заработает на нашем компьютере, но не на компьютере другого человека;
  • Необходимо создавать контейнер с нуля – не нужно полагаться на чей-то готовый образ в общем смысле. Хорошим решением будет стараться создавать всё с нуля на основе базовых образов, чтобы иметь минимальную зависимость от других образов и авторов;
  • Правильным будет помечать контейнер тегом – у сборок должны быть разумные теги. Это поможет нам сортировать их – хорошей практикой является помещать в качестве значения хэш git-коммита;
  • Нужно пытаться создавать такие контейнеры, которые можно остановить и уничтожить, а затем видоизменить и пересобрать с абсолютно минимальной дополнительной настройкой;
  • Нужно использовать многоэтапные сборки – Docker позволяет нам определять несколько таких этапов с помощью команды as – это поможет нам разграничивать контейнеры для разработки или тестирования, что в конечном итоге минимизирует размер образов.
  • Необходимо использовать .dockerignore файл – мы можем исключить из сборки ненужные файлы (он очень похож на файл .gitignore).

Таким образом, благодаря следованию вышеперечисленных шагов и правил, можно грандиозным образом оптимизировать свой рабочий процесс в качестве DevOps-инженера.

 

Список литературы:

  1. Docker [Электронный ресурс] URL: https://www.docker.com (дата обращения: 04.01.2023).
  2. Docker Container [Электронный ресурс] URL: https://selectel.ru/blog/what-is-docker (дата обращения: 04.01.2023).
  3. Docker Images [Электронный ресурс] URL: https://docs.docker.com/engine/reference/commandline/images/ (дата обращения: 04.01.2023).

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.