файл cloud-config не загружен и модули не запущены на машине, созданной из AMI

Мы работаем над кодом, который с помощью terraform (на AWS) выполняет следующие действия:

Создает экземпляр core-os (1) с предоставленным нами yaml-файлом облачной конфигурации
Создает AMI из этого экземпляра

До сих пор процесс работает отлично.

Когда мы запускаем экземпляр (2) из этого AMI через консоль AWS. Вновь запущенный экземпляр не использует файл облачной конфигурации.

В нем (2) есть блоки services / systemd, которые были созданы в экземпляре (1) с помощью yaml-файла cloud-config. Но эти службы мертвы. Они отлично работают, если мы запустим их явно, используя systemctl

Как мы можем убедиться, что ЛЮБОЙ экземпляр, созданный из этого AMI, должен запускать эти службы / модули systemd при запуске или загружать этот файл облачной конфигурации?

(У нас есть этот yaml-файл с облачной конфигурацией, сохраненный в месте внутри машины, если мы запустим файл облачной конфигурации вручную через coreos-cloudinit --from-file=path/to/file/cloud-config.yaml, все работает отлично. Но мы хотим, чтобы он работал при запуске без каких-либо ручных действий)

Вот наш файл облачной конфигурации

#cloud-config
coreos:
  etcd2:
    # generate a new token for each unique cluster from https://discovery.etcd.io/new?size=3
    # specify the initial size of your cluster with ?size=X
    discovery: https://discovery.etcd.io/2cb27f1fecb57e14837016e04547aa32
    # multi-region and multi-cloud deployments need to use $public_ipv4
    advertise-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
    initial-advertise-peer-urls: http://127.0.0.1:2380
    # listen on both the official ports and the legacy ports
    # legacy ports can be omitted if your application doesn't depend on them
    listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
    listen-peer-urls: http://0.0.0.0:2380,http://0.0.0.0:7001
  units:
    - name: etcd2.service
      command: start
    - name: fleet.service
      command: start
    - name: hello.service
      command: start
      content: |
        [Unit]
        Description=hello_docker
        After=docker.service
        Requires=docker.service

        [Service]
        TimeoutStartSec=0
        ExecStartPre=-/usr/bin/docker rm busybox1
        ExecStartPre=/usr/bin/docker pull busybox
        ExecStart=/usr/bin/docker run --rm --name busybox1 busybox /bin/sh -c "while true; do echo Hello Docker; sleep 1; done"
        ExecStop=/usr/bin/docker stop busybox1

Мне не хватало того, что первый экземпляр (1) использовал сценарий в качестве пользовательских данных, который затем запускал облачную конфигурацию с помощью команды cloud-init.

Вместо этого мне пришлось скопировать мою облачную конфигурацию в / usr / share / oem /, чтобы экземпляр, созданный AMI, также использовал эту облачную конфигурацию по умолчанию.

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

Вам необходимо включить службы (убедитесь, что в них есть разделы Install).

#cloud-config

coreos:
  units:
    - name: "example.service"
      enable: true
      content: |
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/echo Hello World

        [Install]
        WantedBy=multi-user.target

Эта служба не запускается при первой загрузке (поскольку модуль включается после того, как systemd реализует multi-user.target), но она будет работать при последующих загрузках.

Кроме того, при создании снимка убедитесь, что вы удалили / etc / machine-id раньше. В противном случае все машины будут иметь одинаковый идентификатор.

ссылка: ссылка на сайт

Вам не нужно создавать собственный AMI для коробки CoreOS, просто используйте официальные AMI CoreOS. Передача одного и того же файла облачной конфигурации в каждый ящик, который вы хотите создать, и модули будут запущены. Это делает вашу инфраструктуру более неизменной, чем если бы вам приходилось делать снимки.