Cloud-init, как запускать Curl до и после каждого запуска cmd

Это моя облачная инициализация по умолчанию

      package_update: true
package_upgrade: true
users:
  - name: sammy
    ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1...
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    shell: /bin/bash
write_files:
  - path: /etc/issue.root
    content: |
      SSH access for root is blocked. Please use xxx instead.
  - path: /etc/issue.everybody
    content: |
      Welcome! This Ubuntu 22.04 is spun up by xxx using DigitalOcean APIv2.
  
runcmd:
  - |
    curl https://events.hookdeck.com/e/abc -X POST -d "{ "command": "configure-sshd-config" }"

На самом деле у меня есть больше, но я урезал yaml cloud-init

Мне нравится бегатьcurl https://events.hookdeck.com/e/abc -X POST -d "{ "event": "dependent on where i run this" }"

в некоторых областях, например, до/после добавления пользователя Sammy или до/после запуска обновления пакета и записи файлов.

Я знаю, как легко это сделать в рамках моего длительного runcmd.

Но я не уверен, как это сделать для не-runcmd.

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

Мне нравится показывать им индикатор выполнения, и единственный способ сделать это — позвонитьcurlна вебхуках.

Источник

2 ответа

Это не функция Cloud-init (за исключением отчетов, как отметил @falcojr).

На ваш вопрос уже ответили другие, поэтому я поделюсь некоторой вспомогательной информацией, связанной с тем, как можно измерить (и оптимизировать) производительность cloud-init. Это не даст вам строку состояния, но, возможно, это ускорит загрузку (что часто является мотивацией такого рода вопросов).

Инструменты производительности:

Если вы заинтересованы в лучшем понимании или оптимизации времени загрузки Cloud-init, вы можете рассмотреть некоторые утилиты.

Cloud-init Analysis : аналогично systemd-analyze, он покажет, на что Cloud-init потратил время.

systemd-analyze: показывает, на что systemd потратил время.

Стратегия оптимизации:

Пытаясь оптимизировать время загрузки системы, я обычно начинаю с запускаsystemd-analyze blame, глядя на самую трудоемкую услугу, а потом спрашивая себя: а) Нужна ли она мне? и если я это сделаю б) Могу ли я что-нибудь сделать, чтобы сделать это быстрее?

Отключите/перенастройте, промойте и повторите. Если не знаешь, не гадай. Прежде чем выпотрошить свою ОС, проведите исследование.

То же самое сcloud-init analyze blame.

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

Быстрый пример:

Я видел несколько облачных конфигураций, которые делают такие вещи, как:

      runcmd:
  - "apt-get install git"
  - "apt-get install neovim"

который не будет работать так же хорошо, как следующий (или встроенный модуль ):

      runcmd:
  - "apt-get install git neovim"

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

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

Источник

Мое предложение взято с этих страниц:

Примерно это:

  • Создайте bootcmd ( https://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot ), который опрашивает, пока сеть не заработает, затем загружает и выполняет следующий этап.
  • Второй этап активно отслеживает и обрабатывает данные журнала (например, из: /var/log/cloud-init.log), чтобы оценить, на каком этапе процесса установки вы находитесь.
  • На этом этапе вы можете начать отправлять обновления с помощью «curl» или любого другого удобного инструмента, поскольку в файлах журналов появляются строки.

Потенциальные проблемы:

  • Требует программирования.
  • Требуется понимание файлов журналов.

Я предлагаю выполнить несколько тестовых установок и отправлять каждую строку по мере ее появления (например, с помощью «curl»), чтобы понять, как выглядит «обычная» установка, найти некоторые ключевые моменты и использовать эти точки для запуска обновлений.

Источник
Другие вопросы по тегам