← Containers / containers

Локальная разработка

Вы можете запустить и контейнер, и Worker локально, просто выполнив npx wrangler dev (или vite dev для проектов Vite, использующих Cloudflare Vite plugin) в каталоге вашего проекта.

Чтобы разрабатывать Workers с поддержкой Container локально, сначала убедитесь, что установлены совместимый с Docker CLI-инструмент и Engine. Например, можно использовать Docker Desktop ↗ или Colima ↗.

При запуске сеанса разработки образ вашего контейнера будет собран или загружен. Если ваш Конфигурация Wrangler задаёт переменную image атрибут на локальный путь, образ будет собран с использованием локального Dockerfile. Если image атрибут указывает на ссылку на образ, этот образ будет получен из указанного реестра, например Cloudflare Registry, Docker Hub, Amazon ECR или Google Artifact Registry.

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

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

Miniflare автоматически предоставляет локальным контейнерам права Docker, необходимые для Filesystem in Userspace (FUSE). Это относится к wrangler dev, плагин Cloudflare для Vite и прямое использование Miniflare.

Miniflare предоставляет эти права, когда локальный демон Docker работает внутри виртуальной машины (ВМ). Сюда входят движки Docker на macOS и через Windows Subsystem for Linux (WSL). В Linux Miniflare предоставляет права для локального rootless-Docker, если /dev/fuse доступен.

Docker с правами root в Linux по умолчанию не поддерживает FUSE при локальной разработке. Miniflare не предоставляет привилегии FUSE, если демон Docker не соответствует этим условиям или его невозможно проверить.

При разработке с Wrangler или Vite код вашего Worker автоматически перезагружается при каждом сохранении изменений, но код, выполняющийся внутри контейнера, не перезагружается.

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

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

В продакшене все порты вашего контейнера будут доступны Worker, поэтому не нужно отдельно открывать порты с помощью EXPOSE инструкция ↗ в вашем Dockerfile.

Но для локальной разработки вам нужно объявить все порты, к которым требуется доступ, в Dockerfile с помощью инструкции EXPOSE, например: EXPOSE 4000, если вы будете обращаться к порту 4000.

Если вы не открыли ни одного порта, вы увидите следующую ошибку при локальной разработке:

The container "MyContainer" does not expose any ports. In your Dockerfile, please expose any ports you intend to connect to.

А если вы попытаетесь подключиться к порту, который не открыт в вашем Dockerfile вы увидите следующую ошибку:

connect(): Connection refused: container port not found. Make sure you exposed the port in your container definition.

Это также может возникать, пока контейнер запускается и порты ещё не доступны. Повторяйте попытку, пока порты не станут доступны. Эта логика повторных попыток уже реализована за вас, если вы используете пакет containers ↗.

Если вы видите неясную internal error при попытке подключиться к контейнеру вам может понадобиться задать DOCKER_HOST переменную окружения в путь к сокету, который прослушивает ваш движок контейнеров. Wrangler или Vite попытаются автоматически найти нужный сокет для взаимодействия с движком контейнеров, но если это не сработает, вам может понадобиться задать эту переменную окружения на нужный путь к сокету.

Если вы используете Cloudflare One Client или VPN с проверкой TLS-трафика, HTTPS-запросы во время сборки Docker могут завершаться с ошибками SSL или сертификата. Это происходит потому, что VPN перехватывает HTTPS-трафик и повторно подписывает его собственным удостоверяющим центром, которому Docker по умолчанию не доверяет.

Чтобы решить эту проблему, можно либо:

• Отключите Cloudflare One Client или VPN при запуске wrangler dev или wrangler deploy, а затем снова включите это.

• Добавьте сертификат в контекст сборки Docker. Cloudflare One Client предоставляет свой сертификат через NODE_EXTRA_CA_CERTS и SSL_CERT_FILE переменные окружения на вашей хост-машине. Вы можете передать сертификат в сборку Docker как переменную окружения, чтобы он был доступен во время сборки, не встраиваясь в итоговый образ.

  RUN if [ -n "$SSL_CERT_FILE" ]; then \
      cp "$SSL_CERT_FILE" /usr/local/share/ca-certificates/Custom_CA.crt && \
      update-ca-certificates; \
      fi

  Wrangler автоматически вызывает Docker при выполнении команды wrangler dev или wrangler deploy, поэтому если вам нужно передать секреты сборки, потребуется собрать и отправить образ вручную с помощью wrangler containers push.