Для экземпляров, запущенных в наш VPC в EC2, требуется HTTP_PROXY и партнеры должны иметь доступ ко всему, что находится за пределами VPC.
Теперь я столкнулся с проблемой (с использованием конвейера данных), когда я не могу контролировать пользовательские данные, передаваемые для облачной конфигурации. Поскольку прокси не установлены, я вижу, что wget зависает (пытается подключиться) во время пользовательских скриптов cloud-init.
Установив переменные среды в /etc/environment кажется, это не читается на уровне запуска 3 (здесь используется положительно древний Amazon Linux 2013.03, и ps axf предполагает, что он вызывается с уровня запуска 3, но я должен признать, что не знаком с различными демонами инициализации и их взаимодействием с cloud-init):
1354 ? S 0:00 \_ /bin/bash /etc/rc3.d/S99cloud-init-user-scripts start
1355 ? S 0:00 \_ /usr/bin/python2.6 /usr/bin/cloud-init-run-module once-per-instance user-scripts execute run-parts /var/lib/cloud/data/scripts
1356 ? S 0:00 \_ /bin/bash /usr/bin/run-parts /var/lib/cloud/data/scripts
1360 ? S 0:00 \_ /bin/bash /var/lib/cloud/data/scripts/part-000
1362 ? S 0:00 \_ wget -O remote-runner-install -N http://datapipeline-ap-southeast-2.s3.amazonaws.com/ap-southeast-2/bootstrap-actions/latest/TaskRu...
\
\ This works in a login shell as I've set
the variables in /etc/environment
Установка этих переменных здесь, похоже, не работает:
Как установить прокси, используемый во время cloud-init время выполнения?
На данный момент нет хорошего способа добавить прокси к облачной инициализации во время выполнения. В этом есть открытая ошибка на панели запуска / cloud-init.
В комментариях упоминаются обходные пути, но все они по своей сути зависят от приложения (например, для yum или apt), задав переменные прокси в их конфигах.