Как проверить сам контейнер Docker - PullRequest
Новая
       7

Как проверить сам контейнер Docker

0 голосов
/ 06 сентября 2018

Я знакомлюсь с докером и думаю, что это действительно отличный инструмент.

Однако я иногда делаю небольшие опечатки, заставляющие контейнер не работать или работать в плохом состоянии, и мне часто требуется много времени, чтобы найти проблему. Есть статьи о том, как использовать докер для тестирования, и это здорово. Но прежде чем приступить к тестированию целевого приложения, которое выполняется в док-контейнере, я хотел бы проверить, была ли успешной сборка и запуск установки, другими словами, написать тест для проверки «готов к тестированию» (эти тесты могут быть повторно используется для проверки готовности к производству, однако для этого могут потребоваться дополнительные усилия, такие как проверка работоспособности и производительности). Удивительно, но я почти не нахожу статей о том, как протестировать инфраструктуру док-контейнера.

Я думаю о том, чтобы найти стратегии и лучшие практики для тестирования того, что делается для создания и запуска любой инфраструктуры докеров, а именно: создания образов, запуска контейнеров, композиций, роя и т. Д. Это будет включать проверку того, все ли необходимые файлы и ресурсы скопированы в нужное место, серверы, необходимые в сети, работают и дают ожидаемый ответ на правильные порты, и, в конечном итоге, даже тестируют, хорошо ли это выполнено с измерениями производительности.

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

1 Ответ

0 голосов
/ 06 сентября 2018

Это мой рабочий процесс с докером, может быть, он вам поможет:

  1. Весь код разрабатывается в среде docker-compose, аналогичной производственной (кроме хранилища, которое использует Cloudstor для управления томами в AWS)
  2. Перед выпуском версии все автоматизированные тесты должны быть зелеными. [ВАЖНО]
  3. Образ докера строится на основе этой версии и содержит только www, например nginx. Это изображение хранится в закрытом хранилище.
  4. Другие образы докеров используются для: database, cache, log stack. Я всегда использую базовые образы для этих контейнеров и настраиваю только некоторые файлы конфигурации.
  5. Файл Docker Compose выгружается с использованием нового тега www image.
  6. Проект Docker Compose перезагружается (потяните && вниз && вверх)
  7. Поскольку образ www уже тестировался перед сборкой, я могу рассчитывать, что, поскольку другие контейнеры работают, мое приложение должно работать.
  8. У меня есть несколько тестовых конечных точек, которые я могу проверить после перезагрузки проекта. Эта конечная точка проверяет, работают ли database, cache и другие службы должным образом, и возвращает код состояния 200 или 500.
  9. Перед перезагрузкой я всегда закрываю приложение, запускаю скрипт резервного копирования базы данных и хранилища
  10. У меня есть сценарий bash, который сделает все это за меня, что ускорит весь этот процесс.

Этот метод, который я использую, практически безошибочен, но требует некоторой дисциплины для проверки всего после любого изменения. Использование автоматизированных тестов (с хорошо написанными тестами) имеет важное значение, и весь этот процесс может использовать инструмент непрерывной интеграции для автоматизации всего.

Я использую этот процесс, так как год назад я перешел на докер на производстве, без проблем было выпущено не менее 100 версий.

...