← Containers / containers

Часто задаваемые вопросы

Чтобы получать логи в Dashboard, включая просмотр в реальном времени, включите observability в значение true в конфигурации wrangler вашего Worker:

{
	"observability": {
		"enabled": true
	}
}

[observability]
enabled = true

На логи распространяются те же ограничения, как у логов Worker, а значит, они хранятся 3 дня на плане Free и 7 дней на платных планах.

См. Тарифы Workers Logs подробнее о стоимости.

Если вы используете план Enterprise, вы можете экспортировать журналы контейнеров через Logpush в нужный вам пункт назначения.

При первом развёртывании Container Cloudflare выбирает точки присутствия по всей нашей сети для развёртывания экземпляров. Эти точки охватывают несколько регионов.

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

Пример:

• Пользователь развёртывает Container, а Cloudflare автоматически подготавливает экземпляры по всей своей сети.
• Клиент в Барилоче, Аргентина, отправляет запрос. Он поступает на Worker в локации Cloudflare в Неукене, Аргентина.
• Этот запрос Worker вызывает MY_CONTAINER.get("session-1337") который активирует Durable Object, а тот затем вызывает this.ctx.container.start.
• Это запрашивает ближайший свободный экземпляр Container.
• Cloudflare обнаруживает, что в Буэнос-Айресе, Аргентина, есть свободный экземпляр, и запускает его там.
• Другому пользователю нужно попасть в тот же контейнер. Его запрос поступает на Worker, который выполняется в локации Cloudflare в Сан-Диего.
• Worker снова вызывает MY_CONTAINER.get("session-1337").
• Если исходный экземпляр контейнера всё ещё работает, запрос направляется в местоположение в Буэнос-Айресе. Если исходный контейнер перешёл в спящий режим, Cloudflare снова попытается найти ближайший «свободный» экземпляр Container, вероятно, в Северной Америке, и запустит там новый экземпляр.

На wrangler deploy, Worker публикуется первым. Экземпляры контейнеров по умолчанию обновляются с помощью постепенного развёртывания. См. Развёртывания шаги, периоды ожидания и режимы. См. Развертывание Containers чтобы выполнить развёртывание.

В продакшен-ветке Workers Builds должен запускаться wrangler deploy чтобы можно было обновлять образы и экземпляры контейнеров. Для непроизводственных сборок Workers Builds по умолчанию используется wrangler versions upload, который не обновляет образы. Containers Workers реализуют Durable Objects, поэтому для них не создаются URL предпросмотра. См. Развертывание Containers.

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

См. масштабирование и маршрутизация для получения подробностей.

Пока нет, но Cloudflare планирует добавить встроенное автомасштабирование в одном из будущих релизов.

А до тех пор используйте getRandom для простой маршрутизации без сохранения состояния и конкретных ID экземпляров, когда нужен явный контроль над жизненным циклом контейнера.

Холодный старт происходит, когда экземпляр контейнера запускается из полностью остановленного состояния.

Если вы вызовете env.MY_CONTAINER.get(id) с совершенно новым ID и запускаете этот экземпляр впервые, произойдёт холодный старт.

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

Холодный старт Container часто занимает от 1 до 3 секунд, но это зависит от размера образа, времени выполнения кода и других факторов.

См. управление образами.

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

Снапшоты появятся в ближайшее время: они позволят пользователю быстро сохранять и восстанавливать диск из всего контейнера или из отдельного каталога.

Также можно использовать FUSE для сохранения диска в R2 или другое объектное хранилище. Однако при использовании FUSE не ожидайте нативной производительности на уровне SSD.

Если памяти окажется недостаточно, экземпляр выдаст ошибку Out of Memory (OOM) и будет перезапущен.

Containers не используют своп-память.

Cloudflare не останавливает экземпляр контейнера по истечении фиксированного максимального времени работы. Класс Container задаёт sleepAfter до 10 минут по умолчанию, а его значение по умолчанию onActivityExpired() реализация сигнализирует контейнеру об остановке после указанного периода бездействия. Вы можете изменить длительность или переопределить хук. Даже если ваш хук удерживает экземпляр запущенным, другое событие платформы все равно может его остановить. Один из таких случаев: перезапуск хост-сервера, который происходит с нерегулярной периодичностью. Cloudflare не гарантирует, что какой-либо экземпляр контейнера будет работать в течение определённого периода времени.

Перед остановкой экземпляра контейнера (в том числе перед тем, как хост переносит нагрузку с сервера), платформа выполняет следующее:

1. Отправляет SIGTERM основному процессу в контейнере.
2. Ожидает завершения этого процесса до 15 минут.
3. Отправляет SIGKILL если процесс ещё выполняется.

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

Обновления образов при развёртывании используют ту же последовательность остановки. См. Развёртывания.

Вы можете использовать Worker Secrets или Secrets Store чтобы задать секреты для ваших Workers.

Подробности реализации см. в Переменные окружения и секреты.

Да. Используйте docker:dind-rootless базовый образ, так как Containers запускаются без привилегий root.

При запуске демона Docker необходимо отключить iptables, поскольку Containers не поддерживают манипуляции с iptables:

FROM docker:dind-rootless

# Start dockerd with iptables disabled, then run your app
ENTRYPOINT ["sh", "-c", "dockerd-entrypoint.sh dockerd --iptables=false --ip6tables=false & exec /path/to/your-app"]

Если вашему приложению нужно дождаться готовности dockerd перед использованием Docker, используйте entrypoint-скрипт вместо встроенной команды, приведённой выше:

#!/bin/sh
set -eu

# Wait for dockerd to be ready
until docker version >/dev/null 2>&1; do
  sleep 0.2
done

exec /path/to/your-app

Полный рабочий пример см. в Пример Docker-in-Docker для Containers ↗.

См. Обработка исходящего трафика о том, как управлять исходящим трафиком и доступом в интернет.